views:

1986

answers:

8

It feels like an artifacts of an earlier days, but UML sure does have its use. However, agile processes like Extreme Programming advocates "embracing changes", does that also means I should make less documents and UML models as well? Since they gives the impression of setting something in stone.

Where does UML belongs in an Agile development practice? Other than the preliminary spec documents, should I use it at all?

EDIT: Found this: Potential artifacts for agile modeling

+4  A: 

For throw away diagrams, yes. I'd generally only use it as a tool for communicating ideas, issues etc. Sequence diagrams, use cases and class diagrams.

Quibblesome
+2  A: 

For true agility you should express your design once and only once -- in code.

So while UML diagrams might well be useful as a shorthand notation for communication while preparing a task, and can usefully summarize a design while discussing designs with colleagues, they shouldn't be a delivered artifact.

In particular, they shouldn't be maintained, as this is needless duplication.

Jeremy McGee
I guess it depends on what you're building; but shouldn't other project artifacts (like design docs) be living and breathing? Otherwise I don't think they have much value.
Martin Clarke
+2  A: 

I've not formed my own solid conclusions about UML within Agile development practices, but I find it very useful as a simple communications medium between programmers.

Imagine you have started working on a story that you've taken on and you find that you have to swap your partner. You could find UML useful to sketch out your current position to your new pair to bring them up to speed.

I also find it useful in helping to explain design patterns and design principles when I give presentations.

quamrana
+7  A: 

Use what you find helpful. If a UML diagram helps you visualize what you need to do, use it. If a whiteboard does the same thing, use that.

Just don't make UML diagrams for the sake of making UML diagrams. Our time is too expensive to spend doing useless things.

jodonnell
I like the whiteboard part haha it sure is true
chakrit
Second paragraph is right on the money. There is no point doing something if it isn't helping you get done.
Martin Clarke
+9  A: 

Breeze through Robert Martin's Agile Principles, Patterns and Practices

  • The suggestion is to use UML to communicate designs within the team.. a shared language ; anyone taking a look at the diagram can understand the solution (faster than talking about it) and contribute quicker.
  • If you find the team making the same diagrams over and over again, someone will make a good version and store it on the wiki / source control. Overtime the more useful diagrams will start to collate in that place.
  • Don't spend too much time on it... you don't need too much detail. Models are built in the architectural / construction realms because building a house to validate-test the design is expensive/infeasible. Software is not like that - you could validate your design by just coding it up in the time you make a UML model of your untested design (with all the bells and whistles).

So says UncleBob... I concur.

Gishu
ah, i like the wiki/collate point... I'll have to try it out
chakrit
+2  A: 

In my experience, what has been more useful is doing initial UML design (per feature, module or project basis,depending on the project itself), and then do initial code generation, and then in every iteration just doing simple reverse engineering to the models keeps them updated and reliable, in order to use them on refactoring meetings and such. This works for static diagrams.

But dynamic diagrams should be made and updated as needed only, they consume too much time and they change too often in agile projects for they to be part of the documentation. But then, if you find yourself updating a dynamic diagram too often, it's kindda a project smell, in my opinion, because, as it's said before, they should be used only for communication among the team.

David Lay
+1  A: 

For a very well thought out and expressed view on this topic read Martin Fowler's "Is Design Dead?" and if that convinces you, buy/borrow and read Scott Ambler's Agile Modelling.

In a nutshell, UML is a useful tool but don't over use it/abuse it; it's for thinking, as well as documenting but the code is the ultimate (though not only) expression of the design - the executable design. To this end, the team should do the architecture and design. Finally, use whatever tools to do it that helps (i.e. whiteboards and pens and digital cameras are great - you don't need a CASE tool)

Andrew Harmel-Law
A: 

We use UML when you need to explain to other programmers how the user story works. You can just sketch out the interaction diagram and show which objects talk to which other ones.

Very much like what Martin Fowler describes here: http://martinfowler.com/bliki/UmlAsSketch.html

cartoonfox