Calling Eclipse "One of the most successful software projects in history", John Gage opened JavaOne Day 4 by introducing Eclipse project managers Erich Gamma and John Wiegand.
Erich and John begain with a description of what they call "The Eclipse Way", the process that the Eclipse project has used to deliver releases for several years. The talk was similar to one given at EclipseCon earlier this year, but included a demo of some new collaboration technology being developed in the research labs. The rest of this article is a summary of their presentation and demo.
The Eclipse Way is based on certain core values, refined in the trenches by iterating, learning, and improving, at each stage. The key to the Eclipse Way is "rhythm". The rhythm is the heartbeat of a project, making it predictable for both consumers and developers.
The process of creating a new release is broken into three phases: warm up, steady state, and end game.
Warm up
We start by having warm-up phase. This is a recovery time after the last release. We try to schedule this during vacation time. When the developers come back, when they're refreshed and ready, we do retrospectives of the previous cycle, and try to work up an initial release plan. This is just a first pass.
At first we tried static plans but it didn't work so we went into a dynamic plan style. For each feature we mark it as committed, proposed, and deferred. At first, we tried to hold the plan back, afraid to put something out because we weren't sure it was going to happen, planning behind closed doors. So we decided to reflect that this was a proposed item, be transparent, and get feedback early. The plan is revised.
Steady state
Next we go into the steady state of the project, and start cranking out milestone releases at regular intervals. Each milestone has phases of its own, and it's always the same: plan, develop, and stabilize. Through trial and error we found that a milestone length of 6 weeks works out well. We tried shorter cycles (like 2 weeks) but it wasn't enough time to make some real progress.
End game
After we're done with the milestone phase we transition into the end game. The end game is the sprinting point, where we get the quality from "good" to "golden". To get there, we iterate quickly through fix and test cycles, first lookint at the "spit and polish" issues and then limiting changes to only more serious problems.
To keep developers from being fatigued, we amortize the cost over the milestones. In other words, the quality and polish effort is distributed throughout the release. We don't have a seperate testing organization, so developers oscillate between testing and fixing.
During the end game, initially we had one week testing, one week fixing, one week testing, etc.. But that proved to be too tiring for the developers so currently we do about 2 days of test and have a longer fixing pass.
As we move through the release candidates in the end game, we raise the bar on what fixes go in - more reviewers, more approvers, and published fixed lists.
Then comes the point where you're really getting ready. There is a collective signoff, which gives everybody on the team a feeling of shared responsibility and committment. We do GO/NO-GO decisions at each milestone. It's not just a formalism.