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

Practices questions

Expand Messages
  • Hélio Perroni Filho
    Gentlemen, I and some working peers are currently running a XP study group, admitedly aiming at building a XP user base to, in the near future, implement the
    Message 1 of 10 , Dec 1, 2002
      Gentlemen,

      I and some working peers are currently running a XP study group, admitedly
      aiming at building a XP user base to, in the near future, implement the XP
      pratices at our company. One week ago we had our very first group meeting:
      although much motivating, it left us with some questions we were to this
      date unable to answer.

      The questions are:

      * When The Client Is Always Available, is not there the risk that he will
      start asking the developers to add "just one more thing" on every feature,
      does leading the development out of scope? How to prevent that?

      * How to solve dependency problems among User Stories? For example, if the
      Client has no legacy system, and asks us to deliver the report subsystem
      before the interface that will collect the data that should go in the
      report, what do we do?

      * Is it possible / interesting to combine Use Cases with Use Stories? Why? How?

      * How to manage Collective Code Ownership in projects divided among several
      development teams?

      Obviously, any help with these questions would be much appreciated.

      --
      []'s
      Hélio Perroni Filho
      h-kun@...
    • Kevin Smith
      ... Excellent! ... At the beginning of each iteration, the Client (Customer) agrees to a list of stories that will be worked on during that iteration. The only
      Message 2 of 10 , Dec 1, 2002
        On Sun, 2002-12-01 at 03:31, Hélio Perroni Filho wrote:
        > I and some working peers are currently running a XP study group

        Excellent!

        > * When The Client Is Always Available, is not there the risk that he will
        > start asking the developers to add "just one more thing" on every feature,
        > does leading the development out of scope? How to prevent that?

        At the beginning of each iteration, the Client (Customer) agrees to a
        list of stories that will be worked on during that iteration. The only
        reason the Customer would bring in new stories is in some emergency
        situation--this should be very rare. Remember that an iteration is only
        one to three weeks long, which is not that long to wait.

        There is some danger that the Customer might have described a very
        simple story during the Planning Game, but might try to make it a bigger
        story during the further discussions with coders. One solution to this
        is to require the Customer to provide Customer Tests for the story
        before the coders start to work on it. This can be difficult.

        Another option is for coders to be aware of when the story is becoming
        larger than what they had estimated. They might then push back, and
        require the customer to write up a new story for the added features,
        which would not be worked on during this iteration.

        Or the coders might give the Customer the option of expanding this
        story, but only if the Customer is willing to remove an equal amount of
        work from this iteration by postponing other stories that had been
        scheduled for this iteration.

        Some other important ideas to remember are that the Customer can't force
        the coders to produce more than is possible, that the Customer and
        coders talk to each other frequently during an iteration, and that the
        goal of both the Customer and the coders is to produce the highest value
        software as quickly and early as possible.

        > * How to solve dependency problems among User Stories? For example, if the
        > Client has no legacy system, and asks us to deliver the report subsystem
        > before the interface that will collect the data that should go in the
        > report, what do we do?

        As you become comfortable working with stories, you'll find that true
        dependencies are very rare. When they happen, you can include a note
        with your estimate like "2 points, assuming the 'Add Data' story has
        already been completed".

        In the case you mention, it would be easy to write a report subsystem
        before the data collection interface. In fact, that might be a better
        approach anyway. By writing the reports first, you can be certain that
        the necessary information is being stored.

        Your report subsystem might initially create reports based on hard-coded
        data. Or it might read the data from from spreadsheet files or from flat
        data files that the Customer could create.

        > * Is it possible / interesting to combine Use Cases with Use Stories? Why? How?

        I think the better question is whether _you_ think it might be
        interesting to combine stories and Use Cases. Personally, I find stories
        to be sufficient in most cases. I can imagine that Use Cases might help
        certain Customers, Testers, Documentation Writers, or Executive Sponsors
        to better understand what the system is trying to accomplish.

        If Use Cases help, use them. If not, don't bother with them. Feel free
        to experiment.

        > * How to manage Collective Code Ownership in projects divided among several
        > development teams?

        There is quite a bit of work in this area, but I'm afraid I have ignored
        most of it so far because I'm in a one-team arena.

        Kevin
      • Ron Jeffries
        ... The customer only gets to order as much work this iteration as the team got done last iteration. The team estimates all features. If you got 20 bits done
        Message 3 of 10 , Dec 1, 2002
          On Sunday, December 1, 2002, at 6:31:24 AM, Hélio Perroni Filho wrote:

          > The questions are:

          > * When The Client Is Always Available, is not there the risk that he will
          > start asking the developers to add "just one more thing" on every feature,
          > does leading the development out of scope? How to prevent that?

          The customer only gets to order as much work this iteration as the
          team got done last iteration. The team estimates all features. If you
          got 20 bits done last time, the customer can have any 20 he wants this
          time. This quickly induces him to spend wisely.

          > * How to solve dependency problems among User Stories? For example, if the
          > Client has no legacy system, and asks us to deliver the report subsystem
          > before the interface that will collect the data that should go in the
          > report, what do we do?

          Here are a couple of approaches:

          1. Estimate all stories requiring infrastructure as if they will be the
          first one, and thus the infrastructure will make each one, say, 10
          points. Also mark all stories depending on a particular infrastructure
          item with their cost if they are not first. Suppose that's 2 points.
          Mark each story 10 / 2 meaning "10 if first, 2 otherwise". Customers
          have no trouble understanding this.

          2. Average the cost of infrastructure across all stories using that
          bit of infrastructure, and implement each one with just enough
          infrastructure to get the job done. (This is an advanced technique,
          in my opinion, but it is often quite possible when you think about
          it.)

          The main thing NOT to do is to break infrastructure out as a separate
          story. Infrastructure does not offer business value and therefore
          can't really be a story. (Some teams do this. Some of them get away
          with it. I'm deeply scared of the tactic.)

          > * Is it possible / interesting to combine Use Cases with Use Stories? Why? How?

          No. Use Cases are completely redundant with stories, and, as they are
          generally written rather than spoken, contain less information.

          Yes. Use cases are a decent way of documenting some aspects of some
          stories, and if done in a lightweight enough fashion are mostly
          harmless.

          Advice: If you must, try a few of each. Note which you like best, and
          why.

          > * How to manage Collective Code Ownership in projects divided among several
          > development teams?

          Don't know. XP projects don't generally have separate development teams.

          Ron Jeffries
          www.XProgramming.com
          Do, or do not. There is no try. --Yoda
        • Phlip
          ... That s the point of the whole process; steering. If your customer is a sociopath who can t wait
          Message 4 of 10 , Dec 1, 2002
            Hélio Perroni Filho sez:

            > * When The Client Is Always Available, is not there the risk that he will
            > start asking the developers to add "just one more thing" on every feature,
            > does leading the development out of scope? How to prevent that?

            That's the point of the whole process; steering.

            If your customer is a sociopath who can't wait <2 weeks for the PlanningGame
            for this "just one more thing", you are screwed. However, the process works
            with sufficient visibility that the answer to the question "Who screwed you"
            is unambiguous and irrefutable.

            > * How to solve dependency problems among User Stories? For example, if the
            > Client has no legacy system, and asks us to deliver the report subsystem
            > before the interface that will collect the data that should go in the
            > report, what do we do?

            USs can have two estimates. Pencil a high one and a low one, with the
            verbiage "The low estimate is if story X comes first".

            > * Is it possible / interesting to combine Use Cases with Use Stories? Why?
            > How?

            Teams try to discover, per project, what extra elements are needed. The big
            admonition is against some kind of delay between drawing an artifact and
            writing its code. The potential feedback leaks out of the system.

            > * How to manage Collective Code Ownership in projects divided among several
            > development teams?

            Declare each team an XP cell, interfaced to the other by appointed proxy
            Customers.

            But, for a big code base, the odds of a collision at check in time are very
            low.

            Shared Code Ownership is a lofty goal one should aspire towards. But in
            reality what usually happens is exchanges like "Who wrote this?" "Okay, I'm
            going to pair with him when I do the next Engineering Task." That's how
            knowledge spreads.

            --
            Phlip
            http://www.greencheese.org/DontPlanDesigns
            -- This machine last rebooted during the Second Millenium --
          • Ron Jeffries
            ... Not true, in my opinion, that you re screwed. What if every time they ask for another little thing, the answer was we re signed up for 31 this iteration,
            Message 5 of 10 , Dec 1, 2002
              On Sunday, December 1, 2002, at 1:10:20 PM, Phlip wrote:

              >> * When The Client Is Always Available, is not there the risk that he will
              >> start asking the developers to add "just one more thing" on every feature,
              >> does leading the development out of scope? How to prevent that?

              > That's the point of the whole process; steering.

              > If your customer is a sociopath who can't wait <2 weeks for the PlanningGame
              > for this "just one more thing", you are screwed. However, the process works
              > with sufficient visibility that the answer to the question "Who screwed you"
              > is unambiguous and irrefutable.

              Not true, in my opinion, that you're screwed. What if every time they
              ask for another little thing, the answer was "we're signed up for 31
              this iteration, and 15 of them are done. This idea is a two. Which two
              would you like to remove from the plan?"

              Ron Jeffries
              www.XProgramming.com
              Bang, bang, Jeffries' silver hammer came down upon their heads ...
            • jhrothjr
              ... y aiming at building a XP user base to, in the near future, implement the X= P pratices at our company. One week ago we had our very first group
              Message 6 of 10 , Dec 1, 2002
                --- In extremeprogramming@y..., Hélio Perroni Filho <runecarver@H...> wrote=
                :
                > Gentlemen,
                >
                > I and some working peers are currently running a XP study group, admitedl=
                y
                > aiming at building a XP user base to, in the near future, implement the X=
                P
                > pratices at our company. One week ago we had our very first group meeting=
                :
                > although much motivating, it left us with some questions we were to this =

                > date unable to answer.
                >
                > The questions are:
                >
                > * When The Client Is Always Available, is not there the risk that he will=

                > start asking the developers to add "just one more thing" on every feature=
                ,
                > does leading the development out of scope? How to prevent that?

                Yes, there is that possibility. The response is to ask what unimplemented s=
                tories in the current iteration can be dropped.

                Once you're past the current iteration, you've got more leverage. You simpl=
                y add the story in to the pile, and ask him to prioritize. As Ron says, unle=
                ss you've got a completely irrational customer, he's going to prioritize. It=
                's his job.

                > * How to solve dependency problems among User Stories? For example, if th=
                e
                > Client has no legacy system, and asks us to deliver the report subsystem =

                > before the interface that will collect the data that should go in the
                > report, what do we do?

                You do both pieces in one release. If you've got that kind of dependency, y=
                ou're scheduling based on something other than user priority.

                In general, letting the user set the order in which things are delivered me=
                ans that you don't get to decide how to clump stories for implementation eff=
                iciency.

                > * Is it possible / interesting to combine Use Cases with User Stories? Wh=
                y? How?

                Depends on what you mean by Use Cases. If it's a formal technique, probably=
                not. If it's fairly lightweight, on the order of: on transaction foobar, we=
                expect the entry clerk to do w, x, y and z, then it's information you need =
                anyway.

                > * How to manage Collective Code Ownership in projects divided among sever=
                al
                > development teams?

                I wouldn't attempt to do it. A team is the group of people working on one c=
                ode base. Part of what makes XP work is the tight integration among members =
                of the team; you need less formal communication because you've got more info=
                rmal communication. Attempting to share a code base among multiple teams vio=
                lates this assumption.

                There's a limit on how much code a team can be responsible for. It's fuzzy =
                and has all kinds of qualifictions, but if this question comes up, either th=
                e team is too small, or the code base is too big for one person to be famili=
                ar enough with it to be useful.


                John Roth
                Genuine, certified personal opinions.

                > Obviously, any help with these questions would be much appreciated.
                >
                > --
                > []'s
                > Hélio Perroni Filho
                > h-kun@t...
              • Laurent Bossavit
                ... Some of us are ladies. ...proclivities toward unladylike behavior involving exotic hats and ordnance notwithstanding. (This just to make sure Kay still
                Message 7 of 10 , Dec 1, 2002
                  > Gentlemen,

                  Some of us are ladies.

                  ...proclivities toward unladylike behavior involving exotic hats and
                  ordnance notwithstanding. (This just to make sure Kay still likes
                  me.)

                  Cheers,

                  -[Morendil]-
                  A professional programmer is an amateur who never quit.
                • Hélio Perroni Filho
                  ... ... Sorry. Too much exposition to the Harry Potter And The Chamber of Secrets movie has somewhat affected my style. I am not usually that formal anyway,
                  Message 8 of 10 , Dec 1, 2002
                    At 22:17 01/12/02 +0100, you wrote:
                    > > Gentlemen,
                    >
                    >Some of us are ladies.

                    ...

                    Sorry. Too much exposition to the "Harry Potter And The Chamber of Secrets"
                    movie has somewhat affected my style. I am not usually that formal anyway,
                    nor... "unladylikely" either. ¬_¬

                    --
                    []'s
                    Hélio Perroni Filho
                    h-kun@...
                  • William Pietri
                    ... Generally, I let little requests slide, often with little chiding; being agreeable helps the relationship. But if an addition might break my estimate, I
                    Message 9 of 10 , Dec 1, 2002
                      On Sun, 2002-12-01 at 03:31, Hélio Perroni Filho wrote:

                      > * When The Client Is Always Available, is not there the risk that he will
                      > start asking the developers to add "just one more thing" on every feature,
                      > does leading the development out of scope? How to prevent that?

                      Generally, I let little requests slide, often with little chiding; being
                      agreeable helps the relationship. But if an addition might break my
                      estimate, I generally say, "Let's write that on a card; you can put that
                      in the stack wherever you want." That also sounds very agreeable, and it
                      lets the client sort out his conflicting desires on his own.

                      William

                      --
                      brains for sale: http://scissor.com/
                    • Kay A. Pentecost
                      Hey, Laurent! ... Sorta.... ... Oh, I see you took that into account!! (This just to make sure Kay still likes ... Actally, Laurent, I don t like you any more.
                      Message 10 of 10 , Dec 1, 2002
                        Hey, Laurent!

                        > -----Original Message-----
                        > From: Laurent Bossavit [mailto:laurent@...]
                        > Sent: Sunday, December 01, 2002 4:17 PM
                        > To: extremeprogramming@yahoogroups.com
                        > Subject: [XP] Re: Practices questions
                        >
                        >
                        > > Gentlemen,
                        >
                        > Some of us are ladies.

                        Sorta....

                        >
                        > ...proclivities toward unladylike behavior involving exotic hats and
                        > ordnance notwithstanding.

                        Oh, I see you took that into account!!



                        (This just to make sure Kay still likes
                        > me.)

                        Actally, Laurent, I don't like you any more.


                        Just as much, however, just as much...

                        (just not *more* ) <giggle>

                        <grin>

                        Kay



                        >
                        > Cheers,
                        >
                        > -[Morendil]-
                        > A professional programmer is an amateur who never quit.
                        >
                        >
                        >
                        > 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.