Re: [scrumdevelopment] UML and Scrum
- I like Agile Model Driven Development's approach to UMLs.
Basically (if I understood/am applying it correctly), the models that depicts that overview (business & architecture) are what usually are kept. These are mostly produced during iteration 0. While those that you produce via communicating to another person or to the team during actual implementation are usually the throw-aways.
But strictly adhering to the UML standards is not the point (you can even use something else other than UML). The point is communication (analogous to what DDD does for written/spoken language).
As for Scrum specifically, it does not mention anything about it. You may or may not use it, as long as your team is self-organizing :-)
Franz Allan Valencia See | Java Software Engineer
Twitter: http://www.twitter.com/franz_seeOn Fri, Feb 26, 2010 at 1:17 AM, dsrkkk <dsrkkk@...> wrote:
I am trying to know whether UML modeling is used for scrum projects.
- I get lots of mileage out of banging out a bunch of class and sequence
diagrams using togethersoft and generating some code, taking screen
shots of the diagrams for quick and dirty future reference, than
focusing on the code,...
It accelerates the coding I do, mostly because I am a visual person.
I'm not as big a fan of visio because it feels like I'm doing it
twice, once in visio and once in the IDE, seems wasteful.
I take the hit for whiteboarding and sticky notes because its so
collabvorative, also think CRC cards are a great replacement for UML
and am a big fan.
On 3/16/10, woynam <woyna@...> wrote:
> That's what I was trying to address: bring a new team up to speed. It sounds
> rather wasteful to create and maintain formal diagrams in order to be able
> to bring new team members up to speed. I don't know about you, but we don't
> get new people all that often. We certainly create new software a higher
> rate, so I don't see the cost benefit.
> As I stated previously, I'm all for a little ad-hoc modeling upfront at the
> whiteboard. Once in a while I'll create a crude Visio diagram, but nothing
> too detailed or formal.
> --- In firstname.lastname@example.org, "pauloldfield1" <PaulOldfield1@...>
>> (responding to Mark)
>> > There are plenty of tools that will generate diagrams from code,
>> > so you don't have to create a detailed diagram before coding.
>> > When the sh*t hits the fan, I've never met a developer that runs
>> > to a diagram to figure out what's going on. :-) The same holds
>> > for code comments. Diagrams are notoriously out of date.
>> In the past I found that those developers who did some UML modelling
>> before coding produced code sooner and of better quality than those
>> who did not (caveat - very small sample size). More recently I have
>> found that writing the tests first produces similar results. The
>> developers who do that rarely find out what they would do "When the
>> sh*t hits the fan". So far I've rarely found value from
>> producing diagrams after the code - only ever (so far) when trying
>> to get a quick understanding of a new (to the team) existing
>> code set.
>> Paul Oldfield
Sent from my mobile device