>Ed‘s posting about rules and feeling blue resparked a thought I’ve had on and off over the last year. Is the Eclipse Development Process still an agile process? Bjorn replied to a comment I had posted to Ed’s original blog, unfortunately I never saw the reply, and owe him an answer. The short answer, Bjorn, is that I can’t put my finger on any one particular thing, it’s more of a general overall feeling, with some key points. Basically it comes down to how much control, and process is put in place and where. The more detailed analysis of this feeling is below.
Eclipse Development Process:
The Eclipse Development Process is the guiding principle for all Eclipse Foundation projects. The Development Process is not addressed until the last section. The prior sections are really dealing with how to create a new project, graduation of a project, and finally the release of the project. What I consider the development process to be includes:
While the above are pretty much the core of developing any type of software, how it is done, to what level of detail, and when it is done is a key to making a project agile. There are also some key concepts that make a process agile, as posted by Kelly Walters. In his article: 10 Key Principles of Agile Software Development. It’s a good general overview of what entails an agile process, and at first glance the Eclipse Development Process seems agile, but the process really isn’t about the development and how project should develop the plugins, it’s more of a development process for moving a project through eclipse’s various release and maturity stages.
The keys principles outlined are:
1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential
Overall the eclipse process follows these principles, but item 3 is starting to slowly deviate away from the principle. Let me explain this. The eclipse project plan is an important item. Adopters and the community should have an idea of what is coming down the line, however, the feeling I’m getting from this is that projects are starting to use it as a hard set set rule, that they can’t deviate from. If it isn’t on the plan, it won’t be worked on. You can’t have a hard set in stone plan and still be able to be agile, and react to changing conditions. What you thought would be a priority 6 months ago, might not be any longer. A plan needs to be as agile as the rest of the process, it must be able to be evolved and changed as it goes forward. Items that may have originally been in the plan, may need to be dropped. It’s a balancing act, between adopters wanting to know what is going to be in a particular release train, and the need for a committer and project to be able to adapt.
Item 10 is also at times being ignored out right. It doesn’t happen often, but I’ve seen it start to happen in various projects over the last year. An example would be a new feature is put into the project, without there being a corresponding bug, and some appropriate review period by the user community. Typically, this will come from an adopter that has committers on the project, and they want the feature in the product. All of a sudden the feature shows up, and if you go back to review the bugzilla backlog, there is no corresponding bug or feature request for it. The collaboration between a project’s stake holders is key to make sure that no one stake holder’s interest is taking precedence. What may be good for a particular stake holder may not necessarily be good for the project as a whole. It’s a difficult place for a committer to be put into, especially when a stake holder is paying them to work on a project.
Item 9 is one that is a pet peeve of mine. How many projects do not have adequate test coverage? How many projects have let a build go broken for days, weeks on an end? Has a milestone been declared even though the tests failed, just so that the milestone target date can be hit? Test have been commented out because they “randomly” fail. Testing is one of the corner stones of an agile process, it’s done often, it’s repeatable, and it’s automated. If a test fails, it’s given higher priority over anything else. However, many committers may not have had to do unit testing before. Primarily because their company that committed them to the project never had to do it. Understanding why testing needs to be done, and why it’s important to address failing tests, needs to be a higher priority for all eclipse projects. One thing I’ve learned, since really concentrating on tests, is that it really does make it much easier and quicker to change or migrate a design, and still make sure existing functionality is kept. With out a suite of unit tests for VEX, I would not have been able to make a transition to EMF for the VEX document model. Tests enable you to refactor code, with confidence, with out it, there is reluctance to do any major redesign or clean up of an existing framework.
As for the actual development of the software itself, make sure you are following the other principles. There are many methodologies, my personal favorite is a combination of XP and Scrum. XP gives a good set of rules and requirements to follow for the actual development of the code, and Scrum provides the necessary project management and planning. There are many others, but the key is only doing what is necessary and making sure you are involving all portions of the community.