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

RE: [XP] Alert

Expand Messages
  • Steve Ropa
    I would agree. I actually thought that, while I didn t like his particular bent towards why everyone else is a problem, he was pointing out a valuable lesson.
    Message 1 of 27 , Aug 28, 2002
      I would agree. I actually thought that, while I didn't like his particular bent towards why everyone else is a problem, he was pointing out a valuable lesson. XP only works if you actually *do* XP. He showed some good examples where saying you are doing it is probably worse than not doing it at all.

      Of course the RUP requirements phase grafted to the beginning of an XP project didn't help his case, since I can't imagine how you could *do* XP without stories and the planning game.

      Steve

      > -----Original Message-----
      > From: dhemeryy [mailto:dale@...]
      > Sent: Wednesday, August 28, 2002 12:51 PM
      > To: extremeprogramming@yahoogroups.com
      > Subject: Re: [XP] Troll Alert
      >
      >
      > Hi Rob,
      >
      > > The problem with his partially reasonable rules is they are wrapped
      > > in justifying text that says his team was doing XP when, in fact,
      > > they weren't doing anything that resembles XP.
      >
      > Given that, what can we do to make things better?
      >
      > My first recommendation: Drop the word "troll."
      > My second recommendation: Identify and acknowledge the good
      > intentions behind people's criticisms.
      >
      > Dale
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      >
      > Your use of Yahoo! Groups is subject to
      > http://docs.yahoo.com/info/terms/
      >
      >
      >
    • Booch, Grady
      ... [egb ] There is no such thing as a RUP requirements phase; use cases drive each iteration, and those use cases are grown over time just as the system is
      Message 2 of 27 , Aug 28, 2002
        > Of course the RUP requirements phase grafted to the beginning of an XP
        > project didn't help his case, since I can't imagine how you could *do* XP
        > without stories and the planning game.

        [egb> ] There is no such thing as a "RUP requirements phase;" use cases
        drive each iteration, and those use cases are grown over time just as the
        system is grown.
      • Steve Ropa
        Sorry, I stand corrected. I was glossing and I should know better. I was alluding to Gilbert s Third Law: Use the Requirements phase of the Rational
        Message 3 of 27 , Aug 28, 2002
          Sorry, I stand corrected. I was glossing and I should know better. I was alluding to "Gilbert's Third Law: Use the "Requirements" phase of the Rational Unified Process (RUP) to front-end your Extreme Programming process ".

          You clarification makes his "law" even more silly, though.

          > -----Original Message-----
          > From: Booch, Grady [mailto:egb@...]
          > Sent: Wednesday, August 28, 2002 3:05 PM
          > To: 'extremeprogramming@yahoogroups.com'
          > Subject: RE: [XP] <something> Alert
          >
          >
          > > Of course the RUP requirements phase grafted to the
          > beginning of an XP
          > > project didn't help his case, since I can't imagine how you
          > could *do* XP
          > > without stories and the planning game.
          >
          > [egb> ] There is no such thing as a "RUP requirements phase;"
          > use cases
          > drive each iteration, and those use cases are grown over time
          > just as the
          > system is grown.
          >
          > To Post a message, send it to: extremeprogramming@...
          >
          > To Unsubscribe, send a blank message to:
          > extremeprogramming-unsubscribe@...
          >
          > ad-free courtesy of objectmentor.com
          >
          > Your use of Yahoo! Groups is subject to
          > http://docs.yahoo.com/info/terms/
          >
          >
          >
        • Scott W. Ambler
          Grady s right, it s the RUP Inception phase that you re likely talking about. I assume that you started out by creating a collection of use cases, likely to
          Message 4 of 27 , Aug 28, 2002
            Grady's right, it's the RUP Inception phase that you're likely talking
            about.

            I assume that you started out by creating a collection of use cases, likely
            to get a handle on the scope and initial requirements. I also assume that
            you then decided "hey, this looks like a good project to take an XP
            approach". My next step would have been to create a collection of user
            stories from the information contained in your use cases to get you going
            into XP. You could then baseline the use cases and never touch them again,
            you don't need them on an XP project, or apply Agile Modeling's
            (www.agilemodeling.com) practice of Discard Temporary Models and toss them
            away.

            - Scott
            =====================================================
            Scott W. Ambler scott.ambler@...
            Senior Consultant, Ronin International, Inc.
            http://www.ronin-intl.com/company/scottAmbler.html

            ----- Original Message -----
            From: "Booch, Grady" <egb@...>
            To: <extremeprogramming@yahoogroups.com>
            Sent: Wednesday, August 28, 2002 5:05 PM
            Subject: RE: [XP] <something> Alert


            > > Of course the RUP requirements phase grafted to the beginning of an XP
            > > project didn't help his case, since I can't imagine how you could *do*
            XP
            > > without stories and the planning game.
            >
            > [egb> ] There is no such thing as a "RUP requirements phase;" use cases
            > drive each iteration, and those use cases are grown over time just as the
            > system is grown.
            >
          • Steve Ropa
            I am sure that it is. I was responding somewhat knee-jerk to what someone else said, rather than think it through. Oh well, there s my one mistake for the
            Message 5 of 27 , Aug 28, 2002
              I am sure that it is. I was responding somewhat knee-jerk to what someone else said, rather than think it through. Oh well, there's my one mistake for the week ;-)

              > -----Original Message-----
              > From: Scott W. Ambler [mailto:scott.ambler@...]
              > Sent: Wednesday, August 28, 2002 3:20 PM
              > To: extremeprogramming@yahoogroups.com
              > Subject: Re: [XP] <something> Alert
              >
              >
              > Grady's right, it's the RUP Inception phase that you're likely talking
              > about.
              >
              > I assume that you started out by creating a collection of use
              > cases, likely
              > to get a handle on the scope and initial requirements. I
              > also assume that
              > you then decided "hey, this looks like a good project to take an XP
              > approach". My next step would have been to create a
              > collection of user
              > stories from the information contained in your use cases to
              > get you going
              > into XP. You could then baseline the use cases and never
              > touch them again,
              > you don't need them on an XP project, or apply Agile Modeling's
              > (www.agilemodeling.com) practice of Discard Temporary Models
              > and toss them
              > away.
              >
              > - Scott
              > =====================================================
              > Scott W. Ambler scott.ambler@...
              > Senior Consultant, Ronin International, Inc.
              > http://www.ronin-intl.com/company/scottAmbler.html
              >
              > ----- Original Message -----
              > From: "Booch, Grady" <egb@...>
              > To: <extremeprogramming@yahoogroups.com>
              > Sent: Wednesday, August 28, 2002 5:05 PM
              > Subject: RE: [XP] <something> Alert
              >
              >
              > > > Of course the RUP requirements phase grafted to the
              > beginning of an XP
              > > > project didn't help his case, since I can't imagine how
              > you could *do*
              > XP
              > > > without stories and the planning game.
              > >
              > > [egb> ] There is no such thing as a "RUP requirements
              > phase;" use cases
              > > drive each iteration, and those use cases are grown over
              > time just as the
              > > system is grown.
              > >
              >
              >
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to:
              > extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.com
              >
              > Your use of Yahoo! Groups is subject to
              http://docs.yahoo.com/info/terms/
            • Bryan Dollery
              Hi Scott, ... Or even that the original author was trying to talk about. ... Assuming that the use-cases are understandable, why would you want to go through
              Message 6 of 27 , Aug 28, 2002
                Hi Scott,

                > Grady's right, it's the RUP Inception phase that you're likely talking
                > about.

                Or even that the original author was trying to talk about.

                > I assume that you started out by creating a collection of use
                > cases, likely
                > to get a handle on the scope and initial requirements. I also
                > assume that
                > you then decided "hey, this looks like a good project to take an XP
                > approach". My next step would have been to create a collection of user
                > stories from the information contained in your use cases to get you going
                > into XP.

                Assuming that the use-cases are understandable, why would you want to go
                through the extra step of turning them into stories. IMO stories are
                written because they're the simplest way to collect some requirements - if
                some requirements are already collected, why not use those rather than
                spend time rewriting them.

                If a use-case gets estimated at greater than an iteration in length, then
                we can split it, and stories would be a natural way of doing that, but if
                it doesn't I'd just build the use-case.

                Why waste time?

                Cheers,

                Bryan
              • Ron Jeffries
                ... Seems to me that if you re gonna do XP, you need stories. Card, Conversation, Confirmation. Use cases are /none/ of those. Use cases are a bag on the side
                Message 7 of 27 , Aug 28, 2002
                  Around Wednesday, August 28, 2002, 9:27:56 PM, Bryan Dollery wrote:

                  > Assuming that the use-cases are understandable, why would you want to go
                  > through the extra step of turning them into stories. IMO stories are
                  > written because they're the simplest way to collect some requirements - if
                  > some requirements are already collected, why not use those rather than
                  > spend time rewriting them.

                  > If a use-case gets estimated at greater than an iteration in length, then
                  > we can split it, and stories would be a natural way of doing that, but if
                  > it doesn't I'd just build the use-case.

                  > Why waste time?

                  Seems to me that if you're gonna do XP, you need stories. Card,
                  Conversation, Confirmation. Use cases are /none/ of those. Use cases
                  are a bag on the side of XP. Besides, all you need on each card is a
                  sentence. We could have made the stories up in the time it took to
                  write these emails.

                  Ron Jeffries
                  www.XProgramming.com
                  Wisdom begins when we discover the difference between
                  "That makes no sense" and "I don't understand". --Mary Doria Russell
                • Booch, Grady
                  ... [egb ] Ron, would you please explain why you believe that use cases are not stories? Use cases ARE stories in the way that I apply them. [egb ] Another
                  Message 8 of 27 , Aug 28, 2002
                    > Seems to me that if you're gonna do XP, you need stories. Card,
                    > Conversation, Confirmation. Use cases are /none/ of those. Use cases
                    > are a bag on the side of XP. Besides, all you need on each card is a
                    > sentence. We could have made the stories up in the time it took to
                    > write these emails.

                    [egb> ] Ron, would you please explain why you believe that use cases are not
                    stories? Use cases ARE stories in the way that I apply them.

                    [egb> ] Another way to approach this: you tell me the semantics of stories;
                    I'll tell you the semantics of use cases, then we'll compare notes. I think
                    we will both learn something, for I think that you do not understand use
                    cases, and I'm sure I can learn some things from you about what you think
                    stories are.
                  • Kay A. Pentecost
                    Hi, Ron, ... ... So now we ve got CRC Cards, KRC Cards and CCC Cards. Kay
                    Message 9 of 27 , Aug 28, 2002
                      Hi, Ron,

                      > -----Original Message-----
                      > From: Ron Jeffries [mailto:ronjeffries@...]
                      > Sent: Wednesday, August 28, 2002 9:45 PM
                      > To: extremeprogramming@yahoogroups.com
                      > Subject: Re: [XP] <something> Alert
                      >
                      <snip>
                      >
                      > Seems to me that if you're gonna do XP, you need stories. Card,
                      > Conversation, Confirmation. Use cases are /none/ of those. Use cases
                      > are a bag on the side of XP. Besides, all you need on each card is a
                      > sentence. We could have made the stories up in the time it took to
                      > write these emails.

                      So now we've got CRC Cards, KRC Cards and CCC Cards.

                      Kay

                      >
                    • Bryan Dollery
                      Hi Ron, ... Seems to me that you didn t examine the context. I wasn t suggesting that we write use-cases. I was just replying to Dale s post where he described
                      Message 10 of 27 , Aug 28, 2002
                        Hi Ron,

                        > > Assuming that the use-cases are understandable, why would you
                        > want to go
                        > > through the extra step of turning them into stories. IMO stories are
                        > > written because they're the simplest way to collect some
                        > requirements - if
                        > > some requirements are already collected, why not use those rather than
                        > > spend time rewriting them.
                        >
                        > > If a use-case gets estimated at greater than an iteration in
                        > length, then
                        > > we can split it, and stories would be a natural way of doing
                        > that, but if
                        > > it doesn't I'd just build the use-case.
                        >
                        > > Why waste time?
                        >
                        > Seems to me that if you're gonna do XP, you need stories. Card,
                        > Conversation, Confirmation. Use cases are /none/ of those. Use cases
                        > are a bag on the side of XP. Besides, all you need on each card is a
                        > sentence. We could have made the stories up in the time it took to
                        > write these emails.

                        Seems to me that you didn't examine the context. I wasn't suggesting that
                        we write use-cases. I was just replying to Dale's post where he described a
                        project where the use-cases already exists.

                        He suggested turning them into stories, I asked why bother.

                        It's not XP!

                        Boo-hoo, maybe XP isn't the 'best' solution to this problem. What happened
                        to flexibility and pragmatism? Turning these use cases into stories
                        wouldn't add much value to the project - other than to allow it to maintain
                        the name 'XP' during its first iteration.

                        You can still talk with the customers about them - they have more info than
                        you need, but what harm does that do *if it's already there*?

                        All new requirements can be delivered to the project as stories. All
                        splitting of use-cases is done into stories, etc. I'm at a loss to see why
                        this wouldn't work, and how it would be harmful to the project.

                        Cheers,

                        Bryan
                      • Ron Jeffries
                        ... Grady: A use case might conceivably include the same information as is associated with a story. But the form is different. They aren t directly
                        Message 11 of 27 , Aug 28, 2002
                          Around Wednesday, August 28, 2002, 10:08:32 PM, Booch, Grady wrote:

                          >> Seems to me that if you're gonna do XP, you need stories. Card,
                          >> Conversation, Confirmation. Use cases are /none/ of those. Use cases
                          >> are a bag on the side of XP. Besides, all you need on each card is a
                          >> sentence. We could have made the stories up in the time it took to
                          >> write these emails.

                          > [egb> ] Ron, would you please explain why you believe that use cases are not
                          > stories? Use cases ARE stories in the way that I apply them.

                          > [egb> ] Another way to approach this: you tell me the semantics of stories;
                          > I'll tell you the semantics of use cases, then we'll compare notes. I think
                          > we will both learn something, for I think that you do not understand use
                          > cases, and I'm sure I can learn some things from you about what you think
                          > stories are.

                          Grady: A use case might conceivably include the same information as is
                          associated with a story. But the form is different. They aren't
                          directly substitutable.

                          A story is arguably a valid use case. It is possible to write a use
                          case that looks like a story. But when you ask for a use case, you're
                          not likely to get anything that an XPer would recognize as a story,
                          and when you ask for a story, you're not likely to get anything that a
                          use case person would recognize as a use case. I shall alaborate:

                          First, stories:

                          See my article, Card, Conversation, Confirmation, at
                          http://www.xprogramming.com/xpmag/EXPCardConversationConfirmation.htm
                          for some background.

                          An XP story is, as Alistair Cockburn, put it, a promise of a
                          conversation. It consists of a sentence or two written on a card, to
                          serve as a mnemonic for the feature intended. For example:

                          CARD:

                          Calculate sales tax at 6 percent for all sales in Michigan

                          The card is a token. It is used in the planning game, carried around
                          by the customer when the story isn't scheduled, and often handed to
                          the programmers when the story is in process.

                          The understanding represented by the card, the idea of what the
                          customer wants and the programmer must do, is passed from customer to
                          programmer by conversation. For example:

                          CONVERSATION:

                          CUSTOMER

                          So on this one, we want all the sales in Michigan to start charging
                          6 percent tax.

                          PROGRAMMER

                          So when they buy something for a dollar, we should just charge them
                          $1.06?

                          CUSTOMER

                          Not exactly. You have to show a line item for tax on the invoice.

                          PROGRAMMER

                          What about rounding? What's the tax on $1.39?

                          CUSTOMER

                          Good question! There's a table of the tax on values less than a
                          dollar. The rounding isn't what you'd think it would be. I think
                          you'll have to look it up. I'll get you a copy of the table.

                          PROGRAMMER

                          OK, good enough. Line item on the invoice, six percent, look up the
                          specific value on the pennies. We can get started. Get us the table
                          as soon as you can, please, and of course we'll need your acceptance
                          tests as usual.

                          The customer provides the final "layer" of precision on the story, the
                          Confirmation, by providing one or more acceptance tests. The exact
                          form depends on the team and the tools available. In this case, the
                          customer might provide a typed or written list of invoice amounts,
                          sales tax amounts, and invoice total.

                          Now for use cases, which of course I don't understand:

                          A use case, as the RUP defines it, is a set of "use case instances",
                          where each instance is a sequence of actions that the system takes.
                          Presumably, the simplest possible use case is therefore a set
                          containing one sequence of actions that the system should take.

                          In practice, according to the RUP, a use case has a name (this might
                          be the same as the story name), a brief description of the role and
                          purpose of the case (which in the case of my story above is more
                          likely "Tax Compliance: ensure that state taxes are taken" than the
                          text of my story ... but it might be the same text), a flow of events
                          that is understandable by the customer (which might correspond to the
                          conversation above), plus a few other items:

                          Special requirements, preconditions, postconditions, extension
                          points, relationships, activity diagrams, use-case diagrams, and
                          "other" diagrams.

                          It is possible to interpret the RUP as allowing use cases to be
                          written on cards, kept in lunch boxes, and communicated verbally. It
                          is difficult to read the RUP as actually suggesting that anyone would
                          do anything that casual, however. And as far as I can tell, a RUP use
                          case does not include a test, though pre- and post-conditions /could/
                          be used to express tests.

                          Alistair Cockburn prescribes a pretty simple and clear way of writing
                          use cases, and in Agile Software Development, describes four levels of
                          use case precision:

                          1. Actors-Goals list. Just a list of the primary actors and ... their
                          goals.

                          2. One paragraph brief synopsis of precision: title and main success
                          scenario.

                          3. extensions and error conditions, named but not expanded

                          4. extensions and error conditions, including handling.

                          Alistair created this list with but one purpose in mind, namely
                          referring to XP Stories as "Two-bit Use Cases", since the story card
                          is approximately at his level 2.

                          Alistair's approach to use cases is relatively light weight compared
                          to classics such as Ivar's OOSE, which explicitly calls for a detailed
                          description. I don't remember whether the little stick people are
                          optional or not.

                          So ... that's why I think that while use cases and user stories stand
                          in roughly corresponding places in their respective processes, they
                          aren't the same thing.


                          ;-> ;-> ;-> ;-> ;-> ;-> ;-> ;-> ;-> ;->
                          What this all comes down to is this. I propose a wager. We'll collect
                          a large number of experienced software engineers. We'll lock them in a
                          room and ask them each to write one example of a use case. If more
                          than half of them come out of the room with a 4x6 card with a name and
                          a paragraph on one side, and a sketch of a test on the other, you'll
                          have won and I'll agree that a use case is a story.

                          As a control, we could lock a bunch of XPers in a room, ask them each
                          to write a story, unlock the door 45 seconds later, collect the cards
                          and tell Ivar that we have collected them as the final exam from a
                          class on use cases, and ask him to grade them. If they all get A, you
                          win again.
                          ;-> ;-> ;-> ;-> ;-> ;-> ;-> ;-> ;-> ;->

                          So ... have I made clear why I think they're different? Have I
                          exhibited enough misunderstanding about use cases for you to pillory
                          me? Carry on!

                          Ron Jeffries
                          www.XProgramming.com
                          The central "e" in "Jeffries" is silent ... and invisible.
                        • Ron Jeffries
                          ... Certainly if you want to do it, do it. But planning game without story cards is a different beast. It can work, but it s a bit like like we have offices,
                          Message 12 of 27 , Aug 28, 2002
                            Around Wednesday, August 28, 2002, 11:30:28 PM, Bryan Dollery wrote:

                            >> > Why waste time?
                            >>
                            >> Seems to me that if you're gonna do XP, you need stories. Card,
                            >> Conversation, Confirmation. Use cases are /none/ of those. Use cases
                            >> are a bag on the side of XP. Besides, all you need on each card is a
                            >> sentence. We could have made the stories up in the time it took to
                            >> write these emails.

                            > Seems to me that you didn't examine the context. I wasn't suggesting that
                            > we write use-cases. I was just replying to Dale's post where he described a
                            > project where the use-cases already exists.

                            > He suggested turning them into stories, I asked why bother.

                            > It's not XP!

                            > Boo-hoo, maybe XP isn't the 'best' solution to this problem. What happened
                            > to flexibility and pragmatism? Turning these use cases into stories
                            > wouldn't add much value to the project - other than to allow it to maintain
                            > the name 'XP' during its first iteration.

                            > You can still talk with the customers about them - they have more info than
                            > you need, but what harm does that do *if it's already there*?

                            > All new requirements can be delivered to the project as stories. All
                            > splitting of use-cases is done into stories, etc. I'm at a loss to see why
                            > this wouldn't work, and how it would be harmful to the project.

                            Certainly if you want to do it, do it. But planning game without story
                            cards is a different beast. It can work, but it's a bit like like "we
                            have offices, why should we get a common workspace", or "we have code
                            reviews, why should we pair program", or "we have QA, why do we need
                            customer tests".

                            Asim's remarks on stories on the wiki a few messages ago underlines
                            why I think the story cards are important. And it should, I hope, be
                            clear that I think written use cases will not come close to
                            communicating as well as having the use case owner talk with the
                            programmers.

                            Ya see what I'm sayin'?

                            Ron Jeffries
                            www.XProgramming.com
                            Yesterday's code should be as good as we could make it yesterday.
                            The fact that we know more today, and are more capable today,
                            is good news about today, not bad news about yesterday.
                          • dhemeryy
                            Hi Bryan, ... I think that was Scott s post. Dale
                            Message 13 of 27 , Aug 28, 2002
                              Hi Bryan,

                              > I was just replying to Dale's post where he described a project
                              > where the use-cases already exists.

                              I think that was Scott's post.

                              Dale
                            • Booch, Grady
                              ... [egb ] yes; stand by while I go assemble the lumber for said pillory, then we ll assemble a crowd and sell tickets :-) [egb ] Let me dredge up some
                              Message 14 of 27 , Aug 28, 2002
                                > Have I exhibited enough misunderstanding about use cases for you to
                                > pillory me?

                                [egb> ] yes; stand by while I go assemble the lumber for said pillory, then
                                we'll assemble a crowd and sell tickets :-)

                                [egb> ] Let me dredge up some sample use cases from a few real projects the
                                next couple of days, and we'll compare notes. BTW, one thing I'll mention,
                                just to set you thinking, is that the story you offer up as an example is a)
                                entirely without context and thus full of unstated assumptions and b)
                                incredibly tiny relative to the level of abstraction a typical use case
                                addresses...what you have is closer to a scenario (a use case instance).
                              • Ron Jeffries
                                ... Cool. Will there be a lashing? ... Yes. But it s a perfectly good story, and probably pretty close to a real one. Might be that it would say Calculate
                                Message 15 of 27 , Aug 28, 2002
                                  Around Thursday, August 29, 2002, 12:21:22 AM, Booch, Grady wrote:

                                  >> Have I exhibited enough misunderstanding about use cases for you to
                                  >> pillory me?

                                  > [egb> ] yes; stand by while I go assemble the lumber for said pillory, then
                                  > we'll assemble a crowd and sell tickets :-)

                                  Cool. Will there be a lashing?

                                  > [egb> ] Let me dredge up some sample use cases from a few real projects the
                                  > next couple of days, and we'll compare notes. BTW, one thing I'll mention,
                                  > just to set you thinking, is that the story you offer up as an example is a)
                                  > entirely without context and thus full of unstated assumptions and b)
                                  > incredibly tiny relative to the level of abstraction a typical use case
                                  > addresses...what you have is closer to a scenario (a use case instance).

                                  Yes. But it's a perfectly good story, and probably pretty close to a
                                  real one. Might be that it would say "Calculate sales tax for all the
                                  states on the attached spreadsheet, at the rate shown", but the
                                  conversation and tests would go the same way.

                                  And some teams ... quite likely IMO the wise ones ... would do just
                                  the one state first, to build the "happy path" or "main line" of the
                                  story, which lays in the bulk of the architecture.

                                  As for the context ... that comes from the other stories, and the
                                  customer in the room.


                                  We might be getting at why stories and use cases, while they address
                                  the same part of the problem space, aren't the same solution. They
                                  both cover the space, but they're not the same shape or size.

                                  Stories are 4x6 and approach zero thickness. Use cases are 8.5x11 or
                                  A4, and approach infinite thickness. Both rectangular, tho ...

                                  Ron Jeffries
                                  www.XProgramming.com
                                  To be on the wire is life. The rest is waiting. --Karl Wallenda
                                • Pollice, Gary
                                  Good description Ron. Some obserevations embedded. --Gary ... From: Ron Jeffries To: extremeprogramming@yahoogroups.com Sent: 8/28/2002 11:33 PM Subject: Re:
                                  Message 16 of 27 , Aug 29, 2002
                                    Good description Ron. Some obserevations embedded.

                                    --Gary

                                    -----Original Message-----
                                    From: Ron Jeffries
                                    To: extremeprogramming@yahoogroups.com
                                    Sent: 8/28/2002 11:33 PM
                                    Subject: Re: [XP] <something> Alert

                                    ...

                                    An XP story is, as Alistair Cockburn, put it, a promise of a
                                    conversation. It consists of a sentence or two written on a card, to
                                    serve as a mnemonic for the feature intended. For example:

                                    CARD:

                                    Calculate sales tax at 6 percent for all sales in Michigan

                                    The card is a token. It is used in the planning game, carried around
                                    by the customer when the story isn't scheduled, and often handed to
                                    the programmers when the story is in process.

                                    [gfp] I think stories are a great way to plan individual developers'
                                    activities. I think when you do an iteration plan you probably put together
                                    an implicit use case. In this example, if you program the capability to
                                    implement the Michigan sales tax, but don't have the code to actually
                                    perform the sale, the sales tax code provides no value. When you put
                                    together what you'll deliver at the end of an iteration, I would think (but
                                    I could be wrong) that you'll make sure that you also deliver the capability
                                    to record the sale. The set of user stories that describe the, often larger
                                    story, of a sequence of steps that provide visable value is what I would
                                    call a use case.

                                    The understanding represented by the card, the idea of what the
                                    customer wants and the programmer must do, is passed from customer to
                                    programmer by conversation. For example:

                                    CONVERSATION:

                                    CUSTOMER

                                    So on this one, we want all the sales in Michigan to start charging
                                    6 percent tax.

                                    PROGRAMMER

                                    So when they buy something for a dollar, we should just charge them
                                    $1.06?

                                    CUSTOMER

                                    Not exactly. You have to show a line item for tax on the invoice.

                                    PROGRAMMER

                                    What about rounding? What's the tax on $1.39?

                                    CUSTOMER

                                    Good question! There's a table of the tax on values less than a
                                    dollar. The rounding isn't what you'd think it would be. I think
                                    you'll have to look it up. I'll get you a copy of the table.

                                    PROGRAMMER

                                    OK, good enough. Line item on the invoice, six percent, look up the
                                    specific value on the pennies. We can get started. Get us the table
                                    as soon as you can, please, and of course we'll need your acceptance
                                    tests as usual.

                                    The customer provides the final "layer" of precision on the story, the
                                    Confirmation, by providing one or more acceptance tests. The exact
                                    form depends on the team and the tools available. In this case, the
                                    customer might provide a typed or written list of invoice amounts,
                                    sales tax amounts, and invoice total.

                                    [gfp] Again, good examples and good things to have. I think you're assuming
                                    that use cases are written without talking to the customer, however. If
                                    that's the case, then they're probably bad use cases (bad use case, down
                                    boy!). Stories and use cases are simply mechanisms for capturing
                                    requirements. They need to be done collaboratively and in a way that makes
                                    sense for the project and help ensure that you deliver value to your
                                    customer. That even applies to the old software functional requirement
                                    specifications, which have been used successfully.

                                    [gfp] One thing I'm not clear about that maybe you can help me with. When I
                                    look at some stories, such as the Michigan sales tax example, it seems like
                                    there's a possibility of falling into functional decomposition, rather than
                                    a more robust O-O approach. I know that you use continual refactoring to
                                    handle this, but in your experience, does this lead to the functional
                                    decomposition first?


                                    ...
                                  • Bryan Dollery
                                    Hi Gary, ... ... What if you do have the code to perform the sale? Maybe the sale code was of more value to the customer - she may have wanted it for a
                                    Message 17 of 27 , Aug 29, 2002
                                      Hi Gary,

                                      Gary wrote:
                                      > CARD:
                                      >
                                      > Calculate sales tax at 6 percent for all sales in Michigan
                                      <snip/>
                                      >
                                      > [gfp] I think stories are a great way to plan individual developers'
                                      > activities. I think when you do an iteration plan you probably
                                      > put together
                                      > an implicit use case. In this example, if you program the capability to
                                      > implement the Michigan sales tax, but don't have the code to actually
                                      > perform the sale, the sales tax code provides no value.

                                      What if you do have the code to perform the sale?

                                      Maybe the sale code was of more value to the customer - she may have wanted
                                      it for a trade-show somewhere, and thought that the tax stuff was of
                                      considerably less value for the show, than say a pretty gui, or the ability
                                      to provide printed output, or a hundred other things.

                                      > When you put
                                      > together what you'll deliver at the end of an iteration, I would
                                      > think (but
                                      > I could be wrong) that you'll make sure that you also deliver
                                      > the capability
                                      > to record the sale. The set of user stories that describe the,
                                      > often larger
                                      > story, of a sequence of steps that provide visable value is what I would
                                      > call a use case.

                                      But, the tax story may not be alone. In the time leading up the first
                                      release, the one for the trade-show, the customer decided on a broad set of
                                      features, none of which would be complete to a production level, but which
                                      would suffice to broadly demonstrate the product's concept at the show.

                                      The next iterations leading up to the next release are full of the missing
                                      details. These iterations don't contain a single conceptual use-case. They
                                      contain many disconnected stories.

                                      The tax story is being built at the same time as:

                                      Only authorized users should have access to the system

                                      and that is being built in the same iteration as

                                      Every page should display a copyright notice

                                      See?

                                      What I'm suggesting here is that the use-case concept you describe is
                                      certainly a possible, but not a necessary, consequence of XP.

                                      > [gfp] Again, good examples and good things to have. I think
                                      > you're assuming
                                      > that use cases are written without talking to the customer, however. If
                                      > that's the case, then they're probably bad use cases (bad use case, down
                                      > boy!). Stories and use cases are simply mechanisms for capturing
                                      > requirements.

                                      I'm not sure that they are. A story card is a mnemonic device, and a token
                                      by which we can refer to a requirement. The story is the communication and
                                      elaboration of a requirement using the medium of conversation. The actual
                                      *capturing* is done in code.

                                      A use-case is a formal communication medium, the form of which dictates the
                                      collection process, and which actually captures the requirement.

                                      Stories are free-form, and are guided only by the title of the story being
                                      discussed.

                                      Use-Cases is a constrained technique, stories are chaotic and thus allow
                                      the possibility of patterns of behaviour and communication that are
                                      superior to use-cases to occur.

                                      We believe that usually stories produce better results than use-cases.
                                      That's why we use them. (Also, there's the thing about them being quicker,
                                      and more accurately reflecting the customer's real needs.)

                                      Cheers,

                                      Bryan
                                    • Gee, Joe
                                      ... I almost but not quite agree with you on this. I would say that the actual capturing of the requirements is in the acceptance tests. Joe Gee [Non-text
                                      Message 18 of 27 , Aug 29, 2002
                                        Gary and Bryan said:

                                        > > [gfp] Again, good examples and good things to have. I think
                                        > > you're assuming
                                        > > that use cases are written without talking to the customer,
                                        > however. If
                                        > > that's the case, then they're probably bad use cases (bad
                                        > use case, down
                                        > > boy!). Stories and use cases are simply mechanisms for capturing
                                        > > requirements.
                                        >
                                        > I'm not sure that they are. A story card is a mnemonic
                                        > device, and a token
                                        > by which we can refer to a requirement. The story is the
                                        > communication and
                                        > elaboration of a requirement using the medium of
                                        > conversation. The actual
                                        > *capturing* is done in code.

                                        I almost but not quite agree with you on this. I would say that the actual
                                        capturing of the requirements is in the acceptance tests.

                                        Joe Gee


                                        [Non-text portions of this message have been removed]
                                      • Dan Rawsthorne
                                        Ron Jeffries [mailto:ronjeffries@acm.org] ... I m a heavy-duty use case guy, and I agree with Ron here. To work with developers, you want stories. Use Cases
                                        Message 19 of 27 , Aug 29, 2002
                                          Ron Jeffries [mailto:ronjeffries@...]
                                          >
                                          > Around Wednesday, August 28, 2002, 9:27:56 PM, Bryan Dollery wrote:
                                          >
                                          > > Assuming that the use-cases are understandable, why would
                                          > you want to go
                                          > > through the extra step of turning them into stories. IMO stories are
                                          > > written because they're the simplest way to collect some
                                          > requirements - if
                                          > > some requirements are already collected, why not use those
                                          > rather than
                                          > > spend time rewriting them.
                                          >
                                          > > If a use-case gets estimated at greater than an iteration
                                          > in length, then
                                          > > we can split it, and stories would be a natural way of
                                          > doing that, but if
                                          > > it doesn't I'd just build the use-case.
                                          >
                                          > > Why waste time?
                                          >
                                          > Seems to me that if you're gonna do XP, you need stories. Card,
                                          > Conversation, Confirmation. Use cases are /none/ of those. Use cases
                                          > are a bag on the side of XP. Besides, all you need on each card is a
                                          > sentence. We could have made the stories up in the time it took to
                                          > write these emails.

                                          I'm a heavy-duty use case guy, and I agree with Ron here. To work with
                                          developers, you want stories. Use Cases are nice if you need to work at a
                                          distance or convey the bigger picture to somebody who is not keeping track
                                          of the stories. IMHO, use cases are a tool the Customer would use to deal
                                          with the other stakeholders. Dan ;-)
                                          >
                                          > Ron Jeffries
                                          > www.XProgramming.com
                                          > Wisdom begins when we discover the difference between
                                          > "That makes no sense" and "I don't understand". --Mary Doria Russell
                                          >
                                          >
                                          > To Post a message, send it to: extremeprogramming@...
                                          >
                                          > To Unsubscribe, send a blank message to:
                                          > extremeprogramming-unsubscribe@...
                                          >
                                          > ad-free courtesy of objectmentor.com
                                          >
                                          > Your use of Yahoo! Groups is subject to
                                          http://docs.yahoo.com/info/terms/
                                        • Michael Feathers
                                          Gary Pollice wrote: PG [gfp] One thing I m not clear about that maybe you can help me with. When I PG look at some stories, such as the Michigan sales tax
                                          Message 20 of 27 , Aug 29, 2002
                                            Gary Pollice wrote:
                                            PG> [gfp] One thing I'm not clear about that maybe you can help me with. When I
                                            PG> look at some stories, such as the Michigan sales tax example, it seems like
                                            PG> there's a possibility of falling into functional decomposition, rather than
                                            PG> a more robust O-O approach. I know that you use continual refactoring to
                                            PG> handle this, but in your experience, does this lead to the functional
                                            PG> decomposition first?

                                            I've seen people end up with functional decomposition with use cases. It
                                            just seems to depend on whether people can make the separation in
                                            their minds between 'this is what I need' (the use case/story) and 'I
                                            can ask this object to do this bit of the work for me.'

                                            It is possible to end up with functional decomposition in test first,
                                            but it depends on your sensitivity level. Sometimes you start out with
                                            something that feels like functional decomposition, but it is really
                                            driving behavior from tests and using 'extract method' to arrive at
                                            decomposition. When you look at those methods you may start to notice
                                            that they don't really belong to the class, they use only portion of
                                            the classes features, so you create a new class and move the features
                                            over. Other times, you notice right away that you need a new "thing"
                                            in your program. You create a class and start to grow it to help in
                                            your current task.

                                            Duplication is key. There are some forms of duplication that you
                                            can't easily get rid of nicely without introducing new classes.


                                            Michael Feathers
                                            www.objectmentor.com
                                          • Robert Martin UncleBob
                                            ... I don t think there *is* such a thing as the RUP requirements phase . The initial phase of RUP is called Inception . It is composed of a batch of
                                            Message 21 of 27 , Sep 1, 2002
                                              > -----Original Message-----
                                              > From: Steve Ropa [mailto:steve@...]

                                              > Of course the RUP requirements phase grafted to the beginning
                                              > of an XP project didn't help his case, since I can't imagine
                                              > how you could *do* XP without stories and the planning game.

                                              I don't think there *is* such a thing as "the RUP requirements phase". The
                                              initial phase of RUP is called "Inception". It is composed of a batch of
                                              self-similar iterations, each of which deliver executable code, and each of
                                              which is driven by use-cases.

                                              There is nothing in RUP that says your use-cases have to be complete and
                                              detailed before starting development. (Though I could wish that more people
                                              understood that...)

                                              -----------------------------------------------
                                              Robert C. Martin |
                                              President & Founder |
                                              Object Mentor Inc. | unclebob @ objectmentor dot com
                                              PO Box 5757 | Tel: (800) 338-6716 x15
                                              565 Lakeview Pkwy | Fax: (847) 573-1658
                                              Suite 135 |
                                              Vernon Hills, IL, | www.objectmentor.com
                                              60061 |
                                              -----------------------------------------------
                                            • Robert Martin UncleBob
                                              ... Use cases, as Ivar describes them in OOSE, are stories. One or two sentences describing simple situations. Unfortunately (IMHO) many people have
                                              Message 22 of 27 , Sep 1, 2002
                                                > -----Original Message-----
                                                > From: Booch, Grady [mailto:egb@...]
                                                > Sent: Wednesday, August 28, 2002 9:09 PM
                                                > To: 'extremeprogramming@yahoogroups.com'
                                                > Subject: RE: [XP] <something> Alert
                                                >
                                                >
                                                > > Seems to me that if you're gonna do XP, you need stories. Card,
                                                > > Conversation, Confirmation. Use cases are /none/ of those. Use cases
                                                > > are a bag on the side of XP. Besides, all you need on each card is a
                                                > > sentence. We could have made the stories up in the time it took to
                                                > > write these emails.
                                                >
                                                > [egb> ] Ron, would you please explain why you believe that
                                                > use cases are not
                                                > stories? Use cases ARE stories in the way that I apply them.

                                                Use cases, as Ivar describes them in OOSE, are stories. One or two
                                                sentences describing simple situations. Unfortunately (IMHO) many people
                                                have formalized use-cases to an unecessary degree. What's more, many people
                                                try to get *all* there use cases *done* before they ever start developing.
                                                They turn use cases into a *phase* and a deliverable. This is the kind of
                                                use-case analysis that is completely incompatible with XP (and with RUP for
                                                that matter.)
                                              • Robert Martin UncleBob
                                                ... I agree with you. We don t want to treat stories like a phase or a deliverable. Given use cases we don t want to institute a phase to translate them into
                                                Message 23 of 27 , Sep 1, 2002
                                                  > -----Original Message-----
                                                  > From: Bryan Dollery [mailto:Bryan.Dollery@...]

                                                  > I wasn't suggesting that
                                                  > we write use-cases. I was just replying to Dale's post where
                                                  > he described a
                                                  > project where the use-cases already exists.
                                                  >
                                                  > He suggested turning them into stories, I asked why bother.

                                                  I agree with you. We don't want to treat stories like a phase or a
                                                  deliverable. Given use cases we don't want to institute a phase to
                                                  translate them into stories. Stories are, after all, just planning tokens.

                                                  If a customer has gone to the trouble to write elaborated use cases, I'd
                                                  surely read them and get familiar with them. I'd treat this as *part* of
                                                  the conversation with the customer. But then I'd still need planning
                                                  tokens. For those I'd work with the customer to break the use-cases into
                                                  plannable stories. This is not extra work, its just part of the process.

                                                  -----------------------------------------------
                                                  Robert C. Martin |
                                                  President & Founder |
                                                  Object Mentor Inc. | unclebob @ objectmentor dot com
                                                  PO Box 5757 | Tel: (800) 338-6716 x15
                                                  565 Lakeview Pkwy | Fax: (847) 573-1658
                                                  Suite 135 |
                                                  Vernon Hills, IL, | www.objectmentor.com
                                                  60061 |
                                                  -----------------------------------------------
                                                • Dan Rawsthorne
                                                  Robert Martin UncleBob [mailto:unclebob@objectmentor.com] Booch, Grady [mailto:egb@rational.com] ... There is one big difference between Stories and Use Cases.
                                                  Message 24 of 27 , Sep 1, 2002
                                                    Robert Martin UncleBob [mailto:unclebob@...]

                                                    Booch, Grady [mailto:egb@...]
                                                    > >
                                                    > > > Seems to me that if you're gonna do XP, you need stories. Card,
                                                    > > > Conversation, Confirmation. Use cases are /none/ of
                                                    > those. Use cases
                                                    > > > are a bag on the side of XP. Besides, all you need on
                                                    > each card is a
                                                    > > > sentence. We could have made the stories up in the time it took to
                                                    > > > write these emails.
                                                    > >
                                                    > > [egb> ] Ron, would you please explain why you believe that
                                                    > > use cases are not
                                                    > > stories? Use cases ARE stories in the way that I apply them.
                                                    >
                                                    > Use cases, as Ivar describes them in OOSE, are stories. One or two
                                                    > sentences describing simple situations. Unfortunately (IMHO)
                                                    > many people
                                                    > have formalized use-cases to an unecessary degree. What's
                                                    > more, many people
                                                    > try to get *all* there use cases *done* before they ever
                                                    > start developing.
                                                    > They turn use cases into a *phase* and a deliverable. This
                                                    > is the kind of
                                                    > use-case analysis that is completely incompatible with XP
                                                    > (and with RUP for
                                                    > that matter.)

                                                    There is one big difference between Stories and Use Cases. Stories are not
                                                    intended to be complete, they are "promises for conversation". Use Cases, on
                                                    the other hand, are intended to provide enough informaton to develop from.
                                                    This is independent from whether or not they are developed iteratively - it
                                                    is just their substance.

                                                    The way I look at it is: the story is the first draft, the use case is the
                                                    final (probably undocumented) draft (after the conversations). Of course,
                                                    the use cases can be at yet another level of abstraction, and provide the
                                                    context for understanding the individual stories, which is how I like to use
                                                    them.

                                                    Dan ;-)
                                                  • Dan Rawsthorne
                                                    Robert Martin UncleBob [mailto:unclebob@objectmentor.com] ... My thoughts, exactly. This is one way to use XP within the context of a large formal development
                                                    Message 25 of 27 , Sep 1, 2002
                                                      Robert Martin UncleBob [mailto:unclebob@...]
                                                      >
                                                      > > -----Original Message-----
                                                      > > From: Bryan Dollery [mailto:Bryan.Dollery@...]
                                                      >
                                                      > > I wasn't suggesting that
                                                      > > we write use-cases. I was just replying to Dale's post where
                                                      > > he described a
                                                      > > project where the use-cases already exists.
                                                      > >
                                                      > > He suggested turning them into stories, I asked why bother.
                                                      >
                                                      > I agree with you. We don't want to treat stories like a phase or a
                                                      > deliverable. Given use cases we don't want to institute a phase to
                                                      > translate them into stories. Stories are, after all, just
                                                      > planning tokens.
                                                      >
                                                      > If a customer has gone to the trouble to write elaborated use
                                                      > cases, I'd
                                                      > surely read them and get familiar with them. I'd treat this
                                                      > as *part* of
                                                      > the conversation with the customer. But then I'd still need planning
                                                      > tokens. For those I'd work with the customer to break the
                                                      > use-cases into
                                                      > plannable stories. This is not extra work, its just part of
                                                      > the process.

                                                      My thoughts, exactly. This is one way to use XP within the context of a
                                                      large formal development structure... Dan ;-)
                                                    • Ron Jeffries
                                                      ... I understand everything you say here except the part about agreeing. Ron Jeffries www.XProgramming.com The central e in Jeffries is silent ... and
                                                      Message 26 of 27 , Sep 1, 2002
                                                        Around Sunday, September 1, 2002, 2:55:26 PM, Robert Martin UncleBob wrote:

                                                        >> I wasn't suggesting that
                                                        >> we write use-cases. I was just replying to Dale's post where
                                                        >> he described a
                                                        >> project where the use-cases already exists.
                                                        >>
                                                        >> He suggested turning them into stories, I asked why bother.

                                                        > I agree with you. We don't want to treat stories like a phase or a
                                                        > deliverable. Given use cases we don't want to institute a phase to
                                                        > translate them into stories. Stories are, after all, just planning tokens.

                                                        > If a customer has gone to the trouble to write elaborated use cases, I'd
                                                        > surely read them and get familiar with them. I'd treat this as *part* of
                                                        > the conversation with the customer. But then I'd still need planning
                                                        > tokens. For those I'd work with the customer to break the use-cases into
                                                        > plannable stories. This is not extra work, its just part of the process.

                                                        I understand everything you say here except the part about agreeing.

                                                        Ron Jeffries
                                                        www.XProgramming.com
                                                        The central "e" in "Jeffries" is silent ... and invisible.
                                                      • Steve Ropa
                                                        Boy, a week later and I still get in trouble for being too quick on the reply! Yes, I was responding directly to the writer s law that XP should start with
                                                        Message 27 of 27 , Sep 3, 2002
                                                          Boy, a week later and I still get in trouble for being too quick on the reply!

                                                          Yes, I was responding directly to the writer's "law" that XP should start with the RUP Requirements Phase bolted on the front.

                                                          When I was "doing RUP" as I understood it(even after official training from Rational), it truly appeared that the inception phase was almost exclusively requirements gathering and business justification, and that no design or code really was to happen until elaboration. I misunderstood, like many developers, but I'm feeling much better now.

                                                          Steve

                                                          > -----Original Message-----
                                                          > From: Robert Martin UncleBob [mailto:unclebob@...]
                                                          > Sent: Sunday, September 01, 2002 12:33 PM
                                                          > To: 'extremeprogramming@yahoogroups.com'
                                                          > Subject: RE: [XP] <something> Alert
                                                          >
                                                          >
                                                          >
                                                          >
                                                          > > -----Original Message-----
                                                          > > From: Steve Ropa [mailto:steve@...]
                                                          >
                                                          > > Of course the RUP requirements phase grafted to the beginning
                                                          > > of an XP project didn't help his case, since I can't imagine
                                                          > > how you could *do* XP without stories and the planning game.
                                                          >
                                                          > I don't think there *is* such a thing as "the RUP
                                                          > requirements phase". The
                                                          > initial phase of RUP is called "Inception". It is composed
                                                          > of a batch of
                                                          > self-similar iterations, each of which deliver executable
                                                          > code, and each of
                                                          > which is driven by use-cases.
                                                          >
                                                          > There is nothing in RUP that says your use-cases have to be
                                                          > complete and
                                                          > detailed before starting development. (Though I could wish
                                                          > that more people
                                                          > understood that...)
                                                          >
                                                          > -----------------------------------------------
                                                          > Robert C. Martin |
                                                          > President & Founder |
                                                          > Object Mentor Inc. | unclebob @ objectmentor dot com
                                                          > PO Box 5757 | Tel: (800) 338-6716 x15
                                                          > 565 Lakeview Pkwy | Fax: (847) 573-1658
                                                          > Suite 135 |
                                                          > Vernon Hills, IL, | www.objectmentor.com
                                                          > 60061 |
                                                          > -----------------------------------------------
                                                          >
                                                          >
                                                          > To Post a message, send it to: extremeprogramming@...
                                                          >
                                                          > To Unsubscribe, send a blank message to:
                                                          > extremeprogramming-unsubscribe@...
                                                          >
                                                          > ad-free courtesy of objectmentor.com
                                                          >
                                                          > Your use of Yahoo! Groups is subject to
                                                          > http://docs.yahoo.com/info/terms/
                                                          >
                                                          >
                                                          >
                                                        Your message has been successfully submitted and would be delivered to recipients shortly.