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

Re: [scrumdevelopment] SCRUM & UML

Expand Messages
  • Phlip
    ... Let me see how much I got from the book /Agile Modeling/ by Scott Ambler... Draw the right kind of diagram. Not everything is the Class Inheritance
    Message 1 of 10 , Apr 5 12:36 PM
      Alex Jouravlev wrote:

      > I wonder if anybody knows of sucessful projects combining SCRUM & UML?

      Let me see how much I got from the book /Agile Modeling/ by Scott Ambler...

      Draw the right kind of diagram. Not everything is the Class Inheritance diagram.

      Draw it to scratch an itch - to satisfy an immediate need. Don't draw
      it to speculate about code to be written a long time from now.

      Enforce the diagram is temporary. Date it - don't waste time upgrading
      it each time the code refactors. Don't use the UML to enable more
      complexity than your code needs.

      Upgrade the document only if the new version is still useful for an
      immediate need.

      Draw simply. A map of California doesn't include my driveway. Don't
      use powertools (such as Visio) to push up the details or complexity.

      Draw collaboratively, and implement the design in code immediately and
      collaboratively. Don't throw anything over any wall.

      Finally, UML is not a methodology, so it has no conflict with Scrum.

      --
      Phlip
    • Steven Gordon
      The point of Scrum is to empower a group of people with the requisite talents, resources, and inputs to work together unencumbered during a predetermined
      Message 2 of 10 , Apr 5 12:50 PM
        The point of Scrum is to empower a group of people with the requisite talents, resources, and inputs to work together unencumbered during a predetermined period of time to accomplish the tasks they commit to doing. 
         
        When external forces start dictating the use of UML to represent requirements instead of customer interaction and start pre-determining what BA-types will do and what coders will do, then do not be surprised if Scrum will not work well.
         
        Please, consider:
        - creating a team with some BA-types, some QA-types, some architect-types, and some coder-types,
        - give them a backlog of prioritized requirements and access to the customers who have those needs, and
        - empower them decide how to go about understanding and fulfilling the requirements they commit to handling in an iteration.
         
        After each iteration, empower them to decide how to reorganize to become more effective.  If you are the manager, your job is to clear all the obstacles to their effectiveness, not dictate to them how to go about doing their jobs.
         
        Steven A. Gordon, Ph.D.
        Manager, Software Factory
        Arizona State University
        PO Box 875506
        Tempe, AZ 85287-9509
        http://sf.asu.edu
        (480)-727-6271
        -----Original Message-----
        From: witster_1 [mailto:cwitty@...]
        Sent: Tuesday, April 05, 2005 11:25 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Re: SCRUM & UML


        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.

        thanks!


        --- 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,
        for
        > > example.
        > >
        > > Ron Jeffries
        > > www.XProgramming.com
        > > The main reason that testing at the end of a development cycle
        finds
        > > 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
        Solutions
        > 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
        Central.SecurityOffice@s...
        >
        > Thank you





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


      • Stefan Ahrensdorf
        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
        Message 3 of 10 , Apr 5 2:40 PM
          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.

          hth
          Best regards
          Stefan

          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.

          thanks!


          --- 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,
          for
          > > example.
          > >
          > > Ron Jeffries
          > > www.XProgramming.com
          > > The main reason that testing at the end of a development cycle
          finds
          > > 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
          Solutions
          > 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
          Central.SecurityOffice@s...
          >
          > Thank you





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


        • Leo Zancani
          A pair of ponderings on about UML: First: IMHO, UML is a useful way of communicating about software when you want to be just a little bit more specific in your
          Message 4 of 10 , Apr 6 7:38 AM
            A pair of ponderings on about UML:

            First:
            IMHO, UML is a useful way of communicating about software when you want
            to be just a little bit more specific in your communication than
            undefined-semantics-boxes-and-arrows scribbles (also very useful of
            course).

            Worrying about it feels a bit like some maths guys worrying about
            whether to use the "f'(x)" or "df(x)/dx" notation for derivatives; who
            cares as long as everyone understands it?

            Second:
            Again only an opinion, but I think UML *notation* has two distinct uses:
            (1) to notate UML *models* (which are abstract entities for which the
            different UML diagram types represent views) and (2) to help software
            people talk about software.

            Unless you are doing (1), where the diagrams need to be "correct and
            complete" for the underlying model to be consistent and complete, using
            "correct and complete" UML is a bit like putting serifs on characters
            when you draw them by hand.

            I've never heard of anyone doing UML modelling in an agile context
            (mostly because we don't live in a world where the tools are good enough
            that a UML model is just an alternative to code). A lot of teams I've
            seen use it (to whatever degree of detail/correctness is appropriate at
            that instant) to talk to each other about software though...

            Cheers,
            Leo

            > 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.
            >
            > thanks!
            >
            >
          • Boris Gloger
            Hi ----, I do have four Scrum Teams runningn in sync and we will using MDSD in the future. [...] I have ... So I hope I will be able to answer this question in
            Message 5 of 10 , Apr 6 10:09 AM
              Hi ----,

              I do have four Scrum Teams runningn in sync and we will using MDSD in
              the future.
              [...]

              I have
              > not yet worked with a Scrum team that used UML in a Model
              > Driven Architecture context to generate code from UML models,
              > but I'm very interested if anyone has done so.
              >

              So I hope I will be able to answer this question in future with more insight.

              What I will try to find out ist to see in which way we will be able to
              build an "incremental" archtitecture that emerges by using MDSD and
              the tools for this.

              Cheers

              Boris
            Your message has been successfully submitted and would be delivered to recipients shortly.