Re: XP and estimating

On Wednesday, December 11, 2002, at 2:17:33 AM, STEURS Stefan wrote:

> Can you clarify:
> 1. do we, in this statement, perform the analysis/design/test/code for the
> same "item" every day (item could be "a story")
> or
> 2. do we, in this statement, stage as in analysis today for "item A", design
> and code (including tests) tomorrow for "item A", test completely and accept
> by customer for "item A" the day after?  The fact that I use "days" is not
> too relevant, it could be any chunck of time you find appropriate for the
> discussion.

> I ask this question as I see myself in a process that attempts to do the
> same although staged and with chunks of time that may be a bit bigger than
> you have in mind.

The ideal, I suppose, is to do a few minutes' analysis, a few minutes'
design, a few minutes' testing, a few minutes' coding, in a very tight
loop. Each time through the loop one would consider some small piece
of a story.

In the classic "Bowling Game" Test-Driven Development demonstration,
which takes about an hour to do, it goes like this:

1. Review bowling scoring rules (ten frames, ten pins, up to two
throws per frame, frame score is sum of both throws if they total less
than ten, frame score is 10 + next throw if they total ten, frame
score is 10 + next two balls if first throw is 10 (and you don't get
the second throw in this frame). Takes a few minutes.

2. Sketch on the whiteboard what one thinks the bowling game scoring
object diagram should look like. (In the demo, this is a red herring,
because the TDD process generally produces an entirely different
structure.) Takes a few minutes.

3. Write test for each of the following games, making each one run
before writing next test. Each of these steps has a little analysis,
design, test, code. I'll sketch it for some of them:

  a. Game consists of missing all pins on all throws.
     Analysis: reflect long enough to know that this is 20 throws with
     a total score of zero.
     Test: write test saying "ball scores are 20 zeros, game score
     should be zero".
     Design: test refers, say, to BowlingGame class, a roll() method
     representing pins knocked down by one roll, a score() method
     answering the game score.
     Code: create BowlingGame class implied by test, create ball score
     method that ignores input, create score method that answers zero.

  b. Game where player throws, say, 4 on first roll, 3 on second, in
  every frame.
    Analysis: reflect long enough to know that this is 20 throws, 4,
    3, 4, 3, ..., and that the score for the game is 70.
    Test: write test saying the above. Uses no new classes or methods.
    Design: figure out that ignoring the input values isn't robust
    enough, decide to add them up.
    Code: change roll() method to cumulate rolls (score += pins).
    Change score() method to return score.

  c. Game where player throws a spare in first frame, i.e. knocks down
  all ten pins in TWO throws.
    Analysis: figure out what the score is.
    Test: write test. implies no new classes or methods.
    Design: figure out that the spare algorithm needs to look ahead to
    frame n+1 to score frame n. Decide that individual throws need to
    be remembered. (There may be other ways to do this.) A couple of
    other things. (This step (c) takes a bit longer than the previous
    two, perhaps as much as three minutes.
      Analysis: figure out for first time that maximum number of
      throws in a bowling game is 21.
    Code: add throws array. in roll() save ball in array. change
    score() method to loop over array, summing. (confirm that all
    tests but current one still run.)
      Design: figure out that should loop over frames 1..10, not over
      balls.
      Code: Change score() to loop by frames, summing two balls.
      Test: confirm that all tests but current still run.
    Code: change score() to have an if statement to test if frame is
    spare, and to add in the next ball if it is.
    Test: verify that all tests now run.

  d. Game where player throws a strike in first frame, i.e. knocks
  down all pins with ONE throw.
    Analysis: figure score.
    Test: write standard test.
    Design: plan to add an if statement for strike.
    Analysis: notice that have to tick only one ball through in this
    case.
    Design: depending on how the particular session went, decide how
    to implement ticking two balls each frame unless strike.
    Code: make the change to add strike.
    Test: all tests run.

  e. Try to think of a game that will not work. If you think of one,
  write the test. (It probably works.)

  f. Repeat similarly until done.

As we see in the example above, the switching among A/D/T/C occurs
moment to moment. In this case it was all one story. The story takes
an hour to implement. A typical story on a "real" project might take a
day or a week. (Most XP teams seem to be moving toward story sizes of
a few days rather than a couple of weeks.)

So, as described above, from the viewpoint of a pair of programmers,
the process is not phased or staged at all. It is focused on a single
"large" story, and recursively does ADTC to implement it.

However, while this is going on, the customer members of the team may
well be working out which stories to give to the programmers in the
next iteration, a week or two in the future. And they may be working
on Customer Acceptance Tests for this iteration's stories. Both of
these activities are best described as Requirements Specification,
which I'd lump under Analysis. Naturally, the acceptance tests serve
several roles: they are tests. But they are also unambiguous
statements of requirements in a very formal language. They are
permanent, so they serve as an ongoing formal requirements document.
And their scores are tracked, so that they serve as a formal project
tracking document, similar to the Earned Value concept.

I hope that this long response gives a picture of the rich, almost
fractal nature of ADTC inside an XP project. Please inquire further if
need be.

And thanks for asking. It was fun to write it up this way. And, I
hope, useful.

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


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/CBxunD/vN2EAA/xGHJAA/NhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
extremecustomering-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/