Loading ...
Sorry, an error occurred while loading the content.

6905Re: [scrumdevelopment] Re: SCRUM & UML

Expand Messages
  • Stefan Ahrensdorf
    Apr 5, 2005
      I agree with the other two responses on the subject but wanted to add what I found to work well for us:

      Apply UML as one of several tools in your arsenal when appropriate, that is optional.
      I like state, activity and sequence diagrams both for internal elaboration and when communicating with the product owner and users - it's the old "a picture says more than a thousand words". Don't have your BA's draw tons (or any for that matter) of them upfront but whiteboard them in an interactive fashion. Take a picture with your digicam for reference. If and only if you need to extend the diagram in a future sprint, or the diagram is pertinent to core business rules that you need to reference throughout the project consider drawing it up nicely in Visio or similar.
      On class diagrams - beyond whiteboarding use them only if there is a good (read automated) way of keeping them in sync with your code. If you can't keep them in sync then your code becomes your documentation. Same goes for database schemas.
      If your team grows/changes a lot start thinking about some basic references to get help people get up to speed, i.e. a high level architecture overview, deployment diagrams, and some database stuff.

      Best regards

      witster_1 wrote on 4/5/2005 11:25 AM:

      I'm implementing Scrum for the first time and we're going to try to
      incorporate UML notation with it.  I know in reading the Scrum
      resources that it's best to have the team determine what artifacts
      will guide them in their development effort.  To always remember that
      when we're documented to answer the question, "How is this helping us
      code?"  But my issue is how do I move forward?  In my first sprint,
      I've been asked, "What should the developers be doing while the BA's
      are writing Use Cases?"  I have responded by saying that the
      developer should be working right alongside the BA's and coding while
      the Use Cases are being documented.  Is this the correct approach??
      Does anyone have some advice for me in moving forward?  I'm starting
      to feel that maybe we should spend more time upfront with Use Case
      modeling, writing Use Cases and specs, but then I feel that's not
      being very agile.


      --- In scrumdevelopment@yahoogroups.com, Schiel James - SHS Malvern
      <james.schiel@s...> wrote:
      > Same here...we employ UML in some of our use case work, but only
      because it
      > works well for the team, not because of any relationship with Scrum.
      > > -----Original Message-----
      > > From: Ron Jeffries [mailto:ronjeffries@X...]
      > > Sent: Sunday, March 06, 2005 6:37 AM
      > > To: scrumdevelopment@yahoogroups.com
      > > Subject: Re: [scrumdevelopment] SCRUM & UML
      > >
      > >
      > >
      > > On Sunday, March 6, 2005, at 6:16:00 AM, Alex Jouravlev wrote:
      > >
      > > > I wonder if anybody knows of sucessful projects combining
      > > SCRUM & UML?
      > >
      > > What kind of use of UML are you concerned about? I'm aware of many
      > > projects that draw some UML on the whiteboard from time to time,
      > > example.
      > >
      > > Ron Jeffries
      > > www.XProgramming.com
      > > The main reason that testing at the end of a development cycle
      > > problems is not that problems were put in near the end, it is that
      > > testing was put off until then.
      > >
      > >
      > >
      > >
      > > To Post a message, send it to:   scrumdevelopment@e...
      > > To Unsubscribe, send a blank message to:
      > > scrumdevelopment-unsubscribe@e...
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > > 
      > >
      > >
      > >
      > --------------------------------------------------------------------
      > This message and any included attachments are from Siemens Medical
      > USA, Inc. and are intended only for the addressee(s). 
      > The information contained herein may include trade secrets or
      privileged or
      > otherwise confidential information.  Unauthorized review,
      forwarding, printing,
      > copying, distributing, or using such information is strictly
      prohibited and may
      > be unlawful.  If you received this message in error, or have reason
      to believe
      > you are not authorized to receive it, please promptly delete this
      message and
      > notify the sender by e-mail with a copy to
      > Thank you

      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...

    • Show all 10 messages in this topic