UML and Scrum
- 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 email@example.com, "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