posted on Saturday, July 17, 2004 12:20 PM
by
Benjy
Agile Methodologies and Documentation
I just came across an interesting article on the NewArchitect website dealing with the issue of scaling XP approaches for large projects. I had this opinion that opting for an agile approach was merely a cop-out from writing documentation and then read the Agile Manifesto where one of the key points is that while documentation is fine, living code is considered more important.
Methodologies should never become millstones round a developers neck. But heads down coding without anything to prepare the customer for and and without anything to train new developers on the team with is, IMO, ridiculous. [Again, the manifesto does recommend Interaction with the customer as highly important. The thing is , I've been involved with many customers who need to see up-front a lot of what we are going to deliver, and will not even sign-off on the project until this has been agreed upon. Usually this involves Architecture and Design documents not just working code. They have sent representatives to work with us on the projects, but they have placed a lot of emphasis in the stages of Inception and Elaboration (to use RUP terminology) (not that we use RUP at my workplace anyway. We have traditionally used a (still evolving) methodology which borrows a lot from RAD and DSDM]
Lets consider the other developers who get involved in the project at some stage (some early on and some maybe later, for various reasons) Its all well and good to give them an object model and a set of tests, but thats not all you should give them. How are they supposed to know what patterns you have adopted and how they fit together for the various components in the whole solution? For example, what good is it to just tell someone you used MVC or the UIP app block for your site? Sure, it communicates a certain amount, which is why patterns are so useful as a communication enabler (among other things), but thats not enough.
Now before any XP proponents out there decide to blast me, note that I'm NOT dismissing it off hand entirely. In fact, I'm going to be involved in an XP style project very shortly (which is why I'm keen to get more out of it than just pretty code) . And I DO NOT propose writing a million pages of documentation for every project. In a situation where requirements are fluid, big design up front can be counter-productive. But launching into coding without even setting the scene with some (at least a minimum amount of) proper documentation is, still, in my book, a cop-out.
Martin Fowler, in his article on Agile Handover has some good points and cites an example where the customer interacts with the dev team and drives the documentation so that what is produced is really relevant and useful. I say how about doing that earlier in the project and refining it at the end?
With this in mind, i favor Juval Lowy's more structured approach. The methods he suggested at the .NET Architecture Clinic (at Tech Ed Europe 2004), based on the IDesign Method were really cool. I dont think that asking an architect to write this kind of Architecture Report up-front is too much. I think its essential to better understanding of the project especially if its a big one. What happens if he/she goes under a bus and has carried all the info in their head?
I wonder if MSF and other groups in MS have any guidance or suggestions on architectural approaches in agile-method projects. I just sent a mail to Harry Pierson, the Architecture lead on MSDN, asking him the same. Lets see what they come back with.