>Note 2009-04-15: It has been correctly pointed out that the six week milestone process is the actual “eclipse project” way of working within the Eclipse Development Process. This entry has been updated as appropriate.
A while ago, I compared the Eclipse Development Process (EDP) to that of the Rational Unified Processs. The EDP specifically addresses the steps that a eclipse project goes through to be released. It addresses a little bit on management, and touches only briefly on technical practices of actual development. I’ve been told that the Eclipse Foundation feels that how the code is developed is best left up to the individual projects. In general, I’m okay with that, as not every team works best the same way. However, for those teams that want to be more agile in their development, and incorporate some more technical practices what can be done?
The EDP can be interpreted in many different ways, which is good. The most popular way that eclipse projects have interpreted and worked within the EDP, is to follow the lead of the the top-level “eclipse project” which has it’s own OpenRUP like process (EPDP). This methodology is shown above from a management stand point. As can be seen by the picture above, it focuses on 6 week iterations. With one week for planning and one week for stabilization. In many cases during the plan, develop, stabilize you could write “Magic Black Box Here”. As we all know that the magic black box solves it all.
There are some challenges from an agile point of view with the EPDP. First, a team may not need a complete week for planning. They may not even need a stabilization week. However, some projects following the EPDP see it as being set in stone. That you have to do a week, and you have to have a stabilization week. Those not following the EPDP, planning can be shortened to a day, and a week for stabilization may not even be needed. While the EPDP does take some concepts from Agile processes it in my opinion does not go far enough to help document clearly the technical process that needs to go along with the management process. A picture does not clearly specify what all entails the EPDP, so I ecourage readers to review the information that is available on the Eclipse Projects wiki.
The EDP is a management process. It, however, is running into some of the same issues that SCRUM by itself experiences. SCRUM is an agile project management practice. Organizations that only implement an agile project management solution may not be gaining the full benefit of the solution. In fact, many companies or projects that just adopt SCRUM by itself, are not any more successful than the waterfall methodologies they replaced.
In my opinion, where these highly focused project management solutions fail, is not addressing the technical practices that are needed to make them a success. SCRUM is a great project management addition to other agile practices like XP, FDD, BDD, and TDD. With out some of the disciplines of the technical practices no project management practice is going to succeed.
Over the coming weeks, I’ll start to focus in on how I think the EDP can be enhanced with a bit of SCRUM for project management, and pieces of XP for project development. There are pain points that I’ll try to address including technical debt, builds that are never green (or rarely), and last minute cram sessions. Ideally an eclipse project should be able to declare a milestone or release quality build at any given day. Impossible? Unlikely? It can be done, it just takes a bit more discipline on our parts as committers to make it happen.
One cautionary note is that there is a danger in assuming that the process followed by the Eclipse Platform is the right fit for all eclipse projects. So the release train and planning council should be flexible where possible to allow projects to participate without stating that they MUST follow a particular way of developing. The problem is that they specify Milestone Numbers based on the EPDP way of developing. Target dates of when items are to be completed should be given but not necessarily milestone dates, and then it’s up to the individual projects how best they see to accomplish this.
I challenge all projects after Galileo to review their process as a whole. If your project is constantly running into failed builds, rushing to get things done, or manually tweaking builds so they appear green just to make a milestone date, then your development process may need to be reviewed and tweaked to correct your pain points. Processes need to evolve…what worked in the past may not necessarily be the best solution for the present.