>Particularly the need for the powers-that-be to have a plan that details what is being done, the requirements, who is buying lunch and when, etc, and for the developers to have the freedom to adapt to the changing requirements and needs quickly, plus the ability to freely order pizza when ever they want. The Standard Project Plan request from the eclipse board has opened up a bit of this debate.
While I agree that some sort of plan needs to be out there for each project, I don’t think an overall scoping of a traditional requirements plan is useful or necessary. Mainly because they are never kept up to-date with the actual development process. The same holds true for documentation.
One of the things that attracted me to eclipse is it’s Agile development philosophy. Unfortunately with some of the migration of key people from the Agile community towards other projects (i.e. Ward Cunningham moving on), it seems that more traditional project management philosophies are being put on top of Agile practices. Unfortunately, from my own experience this doesn’t work well. The Agile Manifesto needs to be restated:
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
Personally, I think both priorities can be met in regards to Responding to change over following a plan. To me it’s the Project management from SCRUM (no I’m not talking rugby). Mike Cohn has a very good book that all developer’s and project management teams from eclipse should read, called “Agile Estimating and Planning”. It promotes just enough project management to provide the necessary communication. Also, that the plan is continually updated based on the work that was done to-date. However, it is a very light weigh of doing it. No big requirements documents, no big 6 month long plans, just a Product Backlog, some Burn Down Charts to give visibility into how a project is completing those goals, and an Iteration Plan for what work is going to be done during each Milestone release. The thing about iteration planning it should only be for the current iteration, not all of the iterations. Priorities change, the plan needs to be dynamic.
SCRUM is simplicity at it’s best. Programmers tend to like it because existing tools they use like Bugzilla can track this information, and with the few reports from a planning aspect that are recommended, they can be easily maintained, and are more accurate than traditional plans.
So, as the board and our committer representatives to the board come up with this Standard Plan requirement, I hope they keep the words of the Agile Manifesto in mind. Besides it’ll give me more time to order pizza and play Scorched Earth 2000.