Child pages
  • OSP Functional Team Kickoff Meeting October 2008
Skip to end of metadata
Go to start of metadata

OSP Functional Team Notes from the IUPUI Meeting 10/22 to 10/23/07

Team Members: John Gosney, Sean Keesler, Ros Orgel, Melissa Peet, Hannah Reeves, Janice Smith, Lynn Ward
Current Functional Team Leader: Janice Smith
Technical Liaison: Noah Botimer
Overall Mission: To provide a coherent functional vision for OSP as a product

At both the May 2007 meeting in Ann Arbor and the Amsterdam post-conference meeting, suggestions were made that the OSP group needed some kind of steering/governance committee. On both occasions, it was noted that while such a committee had existed in previous years, it was seen as being too, as Jan Smith put it, "hierarchical and rigid." However, there was consensus at both the prior meetings and at the October 2007 meeting at IUPUI that we needed to re-think the problem and re-form such a group.

Moving Forward:
Team members intend to learn from prior negative experience in order to avoid making the same kinds of mistakes. Jan mentioned that there were too many silos and not enough communication between functional experts and the programmers who were developing the requirements. While we agreed that the situation has improved since then, it was also noted that we need more input from people with expertise in user interface. Jan suggested that the designs selected to interpret the functional requirements made too many demands of the developers and that everyone got frustrated in the process. We probably need to know more of the story so we can figure out what else went wrong before proceeding much further with this new group.

We agreed that the OSP Functional Team will:

  • Need a clear charge/mission
  • Find a volunteer to serve as the group leader on a rotating basis
  • Report to the larger OSP community on the Monday morning phone calls

To kick things off, during lunch at the October 2007 meeting, Noah, Sean, Lynn, Jan, and Ros held an informal, and slightly chaotic, brainstorming session during which we tried to define the kinds of tasks this group might take on. If we can nail this list down, it could form the beginning of a charge/mission statement for this group.

Summary of Issues Raised:

  1. In addition to what can be done on JIRA and Confluence, we need a better way to keep track of requirements and the reasons such requirements come into being. We agreed, in both our small lunch-time discussion and in the large group discussion, that providing more of a narrative and rationale, the big picture (the story of the requirement) and the use of personas (a semi-fictional people such as professor, student, administrator, evaluator, etc. who need and will use the service that fulfilling the requirement would provide) might help institutions find common ground among what might at first glance seem to be disparate requirements.
    • Noah suggested trying a template that he has devised to get requirements into a common, easy to read and understand format. The idea is to clearly articulate the rationale for the requirement using a narrative to get at the "why" of the requirement rather than "how to achieve" them, something the developers will have to think about at later time.
    • We recognize that we are all stretched to the limit already but agreed that some of this narrative has probably already been written and may just need a little tweaking. Possible sources for chunks of text we could use are the requirements we wrote as homework prior to the Ann Arbor 2007 meeting, the OSP 2.0 Functional Requirements document assembled by Jay Fern, Indiana's 17-page description of assessment needs (to be obtained through John Gosney), other places in Confluence, and the memories of OSP practitioners.
    • Noah noted that once developers understand the requirements, it would be good if they were asked to break them down into doable chunks that different developers could "own."
  2. Establish a system for prioritizing the requirements and articulate the rationale for how and why requirements are prioritized.
  3. Figure out how to leverage the resources we have to make best use of them. For example, Jan noted that rSmart will help, but would have to understand how the work of rSmart developers will help not only the community but also rSmart clients.
  4. Develop a way of presenting OSP that makes it easier for new and potential users to understand its purposes and features. Noah suggested something like the bulleted list of "box features" that would go on the shiny box that OSP might have on a shelf in a computer store. He also noted that if new users, educators, developers, testers, and institutions intending to use OSP could open a user manual and see a list of more detailed features consisting of just a few words that would indicate "stuff you can do" within a specific part of the system, it might prove to be very helpful to them.
  5. Develop a new Blue Sky document that is easier for all to understand.
    • It was noted that previous Blue Sky documents were too specific.
    • Someone suggested we take the OSP 2.0 Functional Requirements document and reduce it to broad scope functionality.
    • The requirements and background narrative written into the template format described in the first point above will help us to develop the Blue Sky document.
  6. Sean noted that the Blue Sky document is not just the next release. This group should develop the product vision. Fundamentally, the vision is to be a community product that connects to institutional and vendor needs.
  7. Analyze the software development lifecycle. What are the critical pieces that we need to have? Where are the gaps? What are resources institutions can bring? How do we ask for them? How do we leverage what we have right now to make the biggest impact? Concern: We're chipping away at making small dents in big problems.
  8. Lynn noted several times during this lunch discussion and our large group meeting that the QA process has severe problems. We're under-staffed, no one has time to write the scripts, much less test them. As a result, releases are bug-ridden. We're not unlike Microsoft; but, we can try to do better and this group might help that effort along. Noah suggested that the decision as to whether a feature would be in or out of a particular release should be made on the basis of whether it had been fully tested, not just the deadline. He and Sean agreed that if we can't improve the process, we should at least take the responsible step of adding a buyer beware statement, and clearly mark pieces as being in beta version. This would help us to maintain truth in advertising.
    • Sean and Noah noted that we need to inject design review and prototyping into the process.
    • Noah also suggested that we could probably use a features management process. If we can set guidelines for complete features, this chore might be one that our group could take on. He suggested that features need to be owned, and that we should consider having a fairly complete feature before tying it to the code.
  9. Coordinate the OSP planning meetings. We want to do more advance planning, particularly if we want participants to do any homework before the meeting. If we're going to ask people to report on progress, perhaps it can be written up in advance so we can use the meeting time for other purposes. But, we need to give people time to get that homework done.

Next Steps:

  1. Proposed name of group: OSP Functional Team
  2. Beth has written to some of the active European OSP users to see if they want to have representation on this group.
  3. We all agreed we would try to put at least a couple of our requirements into Noah's template. Ros and Noah will start and send what they do around to the other folks in the group as a model.
  4. We'll review our progress during the Monday morning phone calls.
  5. We should decide on the structure of the rotating leadership position. Jan volunteered to serve as leader of this group through the month of November. Melissa said she'd be happy to help out. Do we want to stick to a one-month rotation? Would it make more sense to set this up as a four-month or six-month rotation? Will a one month rotation create more cracks? (Note from Ros - It seems to me that one month is barely enough time to get used to the job and figure out how to do it efficiently, but I'm happy to be wrong about that, particularly if past experience with this kind of group would indicate that shorter duration is better.)

Notes from October 2007 discussions

  1. There is much discussion about the role for Noah's template in our process. Noah's template is for the end of the requirements process and is important for implementation because it provides a context for the development process. A use case is a step before that. Erica will assemble information on use cases and user scenarios and report back to the group.
  2. Whatever documentation we use should keep the scope limited and manageable. Blue sky discussion should be translated into specific discrete tasks that can be done in the time available.
  3. The documents that IU has posted outline their process and provide an additional example of documentation.
  4. Hannah will older planning documents on this page. These may include the OSP 2.0 planning document, Blue Sky documents, conversation at Amsterdam, discussions in Phoenix, Michigan dashboard design. Note: The document from 2005, rests on a lot of changes in Sakai core tools that have not happened and may not happen if no time, do not start with it as the gospel. Ros may take a look at it to try to recover what is still relevant so that the group can go through a check-off process to determine what was done and what was not done so that the group can go through a check-off process to determine what was done and what was not done.
  5. Jan will provide notes on what the process has been in the past
  6. Lynn wants us to also consider more immediate concerns in terms of fixing what is broken, bugs, missing details, and tools that are not functioning well for their intended purpose
  7. Hannah is wants us to concentrate on where we want to be in two years – in conjunction with where Sakai is going to be. What do we have now and what do we want to do in a few years. What's the next chunk? We need to stop being reactive so that we can communicate with the Sakai community.
  8. If we limit our process to resources we have, we will miss what the group can do. We need to seek funding for the stuff we can't do with available resources. This means we need to frame the opportunity better.
  9. We also need to focus on ubiquitous processes in portfolio use like collect, reflect, tag.
  10. Those planning to be at Dec 1-2 Sakai Meeting to represent OSP include Hannah, John, Beth, another U of Michigan person, probably someone from Indiana.

For consideration of the Functional Team: Proposed Format for Usage Scenarios and Personas

  • No labels