[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [epf-dev] Input to retrospectives
|
Hi,
attached you find meeting minutes from
today's call.
We will not have the Package Owners
call tomorrow.
Next call will be on Monday 10/16, 8
AM PDT, where we will discuss both plan for next release, as well as actions
related to the retrospective.
Toll-free dial-in: 1-877-421-0003
Toll dial-in: 1-770-615-1374
<For IBMers> Tie-line dial-in: 421-0003
Participant passcode: 667201 |
|
|
|
Cheers
Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963
Per Kroll/Cupertino/IBM@IBMUS
Sent by: epf-dev-bounces@xxxxxxxxxxx
10/09/2006 09:31 PM
|
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx> |
|
|
To
| epf-dev@xxxxxxxxxxx
|
|
cc
|
|
|
Subject
| [epf-dev] Input to retrospectives |
|
Hi,
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 of content.
- 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
forward.
Recommendation:
Cheers
Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
Attachment:
EPF 1.0 Retrospective - Meeting Minutes.doc
Description: Binary data
