below you find some feedback from Ricardo
and me on the process we followed for last project that hopefully
can be useful starting point for tomorrows retrospective:
Bugzilla and Burndown chart were out-of-sync
most of the time. It's hard to maintain two repositories of information. Recommendation: Use Bugzilla and leverage it's report capabilities.
Owners of bugs did not always adhere
to guidelines for state transitions. E.g., some bugs were moved to Verify
without being in CVS. Recommendation: Communicate guidelines.
At some point in time, we stopped posting
meeting minutes on the epf-dev list. We exchanged emails between a closed
group (usually the meeting participants) and forgot to broadcast the decisions
to the larger group. Chris S does a great job writing many minutes. He
sends them to the participants, and expect the owner of the meeting to
distribute to epf-dev assuming that he agrees with the minutes. Recommendation: Make sure to clarify in each meeting who is the
owner that will send the minutes to epf-dev.
Project Plan and iteration plans. We
only revisited project plan once, rather than after every iteration. We
didn't have iteration plans for each iteration, nor retrospectives. As
we are expected to develop content iteratively, each iteration should include:
planning, authoring of content and reviews. Those things happened ad-hoc
for some content areas, though. Recommendation: Determine iteration dates, planning meetings and
retrospectives in advance. Do a better job following our iterative process.
Work items assigned to an iteration
in OpenUP should be completed in that iteration, menaning that we should
write and review the content within that iteration. In our case, many work
items took several iterations to complete. This breaks a fundamental concept
in how to manage iterations, inherent in OpenUP and other agile processes. Recommendation: Find ways of identifying work items that can be
completed within the iteration.
Copy-editing of content should be done
earlier, before release. This means we need to freeze content development
earlier than for this release. Recommendation: Stick to the plan of having last iteration to be
stabilization, editing, tuning, rather than cramming out large volumes
Reviews like the one done by RUP team
should happen at least 2 weeks before release, ideally once per Iteration.
This gives plenty of time for reviewers and for feedback to be incorporated. Recommendation:
Collateral should be part of a release.
It's fair to say we got all swamped on the last few weeks before release
and couldn't spend time on papers, recorded demos etc., but we may want
to have some buffer on project plan to accommodate those. Recommendation: Stick to original plan of having last iteration
to focus on end game, that is tuning, collateral, quality improvement.
Some contributors worked a lot, and
should be promoted to committers. Recommendation: Review top contributors and promote some to committers.
Some committers have done nothing or
very little. As project manager, I am obliged to revoke committer priveliges
if people are not active in the project. Recommendation: Per to have a discussion with some committers regarding
their continued involvement.
Some (active) committers never made
a single committ to CVS. Committers needs to learn how to use EPF Composer
and CVS. Recommendation: Train all committers on using EPF Composer / CVS.
Contributors should be encouraged to
learn using EPF Composer and CVS. This would enable them to see the latest
content, versus relying on published configurations. Recommendation: Train contributors on using EPF Composer / CVS.
For each of the major plug-ins being
developed (either in OpenUP or other process), we should have a committer
leading the work with contributors, being accountable for delivery of results.
For this release, many plug-ins were stalled since we ended up focusing
solely on OpenUP. We need to maintain pace across many plug-ins moving
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp