I've been looking at some of Scott Ambler's Agile Modelling stuff today and I can't quite make my mind up as to where it fits. Clearly there is a lot of modelling that takes place in *UP type methodologies and cutting down the amount that you do is surely a good thing. In addition to this, formalising some modelling into XP and other agile development processes is (IMHO) also a good thing since having a diagrammatic abstraction of the system (or even just parts of it) is often very useful.

Anyway, having read only some of the papers on the http://www.agilemodeling.com/ website, a couple of things spring to mind.

1. How many of the 18 agile modelling practices do you have to do before you can say that you are performing agile modelling? After all, some people proclaim that you aren't doing XP if you're not pair programming.
2. However much modelling you do, you are always going to fall into the trap that the model doesn't match up with the code. As Scott says, this is particularly apparent with development methodologies that promote a great deal of refactoring such as XP. Of course, one answer is to make use of a tool's ability to reverse engineer the source code back into the model. However, I can't help feeling that you start moving away from being agile in attempting to keep everything in sync. On a couple of projects that I've been involved in, the only modelling that we actually did was fairly abstract and represented only the concepts and structure of the components/modules/etc that we were creating. Rather than model every last class in the system, I think that this could be the key to retaining the usefulness of modelling in combination with a lightweight process.

I'd be interested to hear anybody's thoughts on this...

Add a comment

Posted by on 13 February 2003 21:48:12 GMT #