>There has been some renewed chatter about Agile within various eclipse circles. So I think it’s good to review what are the principles of agile development. According to the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
From my limited review of various eclipse projects, for the most part item 2 is followed pretty well. Most of the software that comes out is working, even though it does not have a lot of comprehensive documentation. What documentation is produced actually could be improved through more unit tests of the code, and clearer java doc where it makes sense. There is enough in most cases to get started though.
In some cases though the right side is dominating the left side. In particular, some of it reminds me of the TPS reports from “Office Space’.
I realize the need for process to be involved but when the process starts to become the overriding concern, it starts feeling like TPS reports. Where the overriding concern becomes how closely somebody is completing those TPS reports.
Those of us in the agile community also need to maintain a balancing act. We have to be flexible and adjust when it makes sense to do so. Being agile does not mean doing away with all process, but limiting that to the bare bones essentials. There is a balancing act between the need to follow an agile process and the principles and the need to have certain deliverables to make sure the release that we produce is a quality one.
Various projects handle this better than others. EMF is very active with their community, and from what I’ve seen in many ways is taking in the overall community goals above individual member goals. Part of this is because of the diversification that exists in that group. It’s not dominated by any one particular member.
One concern I’m hearing is that more and more process is being added at the top, when that process should be delegated to the individual projects. Personally, even at the project level adding more process is not going to address the issues. Especially if you have consistent broken builds. If your builds are consistently broken it means you need to build and integrate more often. If the build takes 6 hours to complete, break it into smaller builds. It’s critical to get the feedback so that the problems can be addressed sooner rather than later.
I know the latter may seem counter intuitive, but it really is a key. If nothing else, adopt unit testing. With that, I’ll leave you with the following YouTube video on Clean Code and Unit Testing: