A SIMPLE HISTORY
The Requirements
The Players and Roles
The History and Outcomes
Where it succeeded:
- requirements met, on time
- a design-centered process
- extra functionality QAed and deployed outside the release cycle
- broad-based input and contributions
- work conducted transparently
- collateral communication (things we learned from each other that
were not specific to this project)
Where it failed:
- broadening resources skill among developers (Jim still did all the
Sakai-centric work) - taking some of the development burden off of Jim
- didn't cement (at least not practically) a long-term investment or
productivity - clarity: who was making decisions, when and how (some time wasted here)
- communicating ourselves to the community (we were heads-down towards the end)
RISK MANAGEMENT
(or what made it bearable)
- start early: preparatory engagement with project lead
- get clear about commitments
- partner with those under similar pressures
- focused attention on QA, test plans
- extra attention from developer(s) when it counts
- a practical aim, well-defined goals
LESSONS LEARNED
- don't just think about development resources
- there are limits to how much community approval can be sought and
accommodated - understand what people are getting out of it: negotiate a useful exchange
- making use of the wiki as a record, keeping us on the same page,
and communication - don't force the project lead to do all the coordination
- start early, think about Sakai's release cycle, and how this can
leverage the broader process
CHOOSING THE RIGHT PROJECT
- find a tool you have a long-term interest in (understand what your
users want and need) - an area of Sakai that you want to develop an expertise with, and
be responsive with - a project lead you can work with
- local requirements that are not otherwise being met by other teams
- find a project of a suitable scope and kind for the resources you can commit
- developing it for broader use makes others more willing to contribute
- understand the incentives and limitations of your collaborators
THE IMPACT OF THE REQUIREMENTS PROCESS
- not much
- the ranking of our requirements mattered little
- the articulation of these requirements helped little - we had to
rework that anyway - however, we may not have come together in quite the same way otherwise
- it did make it easier for us to talk about what we were doing
- it did make it easier to approach Jim with what we wanted to do
THE IMPACT OF THE FOUNDATION
- Chuck helped make the connection with Jim, and an initial meeting
- otherwise this was very project-specific, and just us and Jim
working things out - some (local) resources committed to broader Sakai community work
were pulled back and reallocated to this project (e.g. QA server).
THE IMPACT OF THE COMMUNITY
- a lot of input early on, during the design phases
- some concerns about overlapping work
- some concerns about resources "bloat"
Upon reflection, this should really go in Confluence for ongoing
editing and comment. I'll do that tomorrow. But an email exchange
may be just as well for getting people's initial reactions.