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

Re: [XP] Practices questions

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.