RE: XP and estimating

> -----Original Message-----
> From: Ron Jeffries [mailto:[email protected]]

First a thanks for your reply, further some questions.
> 
> > 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.

This seems extremely tight to me. What if the problem space is not yet
understood.  In my context the introduction of a new concept and how it will
affect our business may take months to do, the ripple effects are big.  I'm
not talking yet about solution space, but giving a good definition of the
problem space that all the stakeholders can agree upon.  I will give an
example of this below.
> 
> 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.

In your example the problem space is well defined.  You are automating an
existing business process.  I can understand in such cases the problem
definition is rather straightforward.  Imagine this case "In the
pan-European airspace there are military airspaces which are used for
training flights and patrol flights of the military.  These airspaces are
used on a planned basis and during these periods they cannot be used by
commercial aircraft.  We know that there is a shortage on capacity in nearby
airspaces which leads to excessive delays for commercial flights in some
periods and being able to use the military airspace would increase the
capacity.  We want to be able to build a function into an existing system
that allows to co-ordinate the use of the military airspace to make use of
that extra capacity to reduce the delays."

Perhaps you think "this is trivial".  Well I can assure you it has taken a
long time to agree on what the problem space exactly is and even longer to
define the solution.  "Takes a few minutes" is not something that you can
apply here.  Also, it's damned difficult to implement a partial solution.
Only an end-to-end solution that involves the airlines, the air traffic
controllers, the national administrations that co-ordinate the airspace
use/capacity, the data providers and then some with the required
"functionality" can lead to added value.

The solution cannot exist without software.  There is no physical model
(like a bowling game) to implement.

I can expand further on this.  I can give many more examples.  But a simple
sounding story like "Allow the flexible use of military airspace to increase
the capacity and reduce delays" translates into a book a couple of hundred
pages thick.
> 
> 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.

Now we are in the solution space.  In your bowling game example the business
process is rather thin.  There are business processes that are like this but
I know some of them are definitely not.  Take my example again.  To allow
the information to be exchanged with the stakeholders we don't only need
some presentation aspects to be defined, we need to define interfaces
between systems that allow to exchange the information.  But even the
presentation aspects are not trivial.  How do you indicate in 4 dimensions
the availability of routes in airspaces ?  Also imagine that you have slow
communication lines to distant users who may be living in areas with very
poor communications infrastructure.  It's not uncommon for people to think
that the whole world is connected to the internet, even to think that PCs
are available in abundance and that there is adequate technical support to
keep the whole thing running.  Ok, I'm going to much to the extreme but I
want to bring this case across.  There are technical constraints.  You don't
have the degrees of freedom that some people take for granted.
> 
> 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.

I can see how useful your approach is within the context of this problem and
solution domain.  I hope you can also see that as soon as you have a problem
space for which there is not a physical equivalent it can get more difficult
and if you have multiple stakeholders with different interests it becomes
even more difficult because the interactions themselves are undefined.

You already know how many pins there are, how many players, that you have a
ball which rolls, etc.  Try to think about an implementation where the game
you are trying to "model" does not even exist.  You know who wants to play
but the rules of the game still have to be determined and you know what
should be the outcome but you don't know the exact starting points, how many
cards there are, etc.

> 
>   b. Game where player throws, say, 4 on first roll, 3 on second, in
>   every frame.

... I hope you don't mind I cut this a bit shorter.

You are capable of defining the test before you implement or even find a
consensus on the requirements because you are implementing something that
exists.  What happens in the scenario I am trying to sketch?  A test only
makes sense if you can predict an outcome.  If you cannot predict an
outcome, define an expectation, then you are not testing in the tradional
sense of the word, you are eliciting requirements, prototyping, ...

Is this unuseful?  No.  Asking the right questions at the right time to the
right person is extremely useful.  However, if the problem space is not yet
fully defined, asking questions leads to redefinition of the problem space.
You can start thinking about certain aspects of the solution space but there
is a high cost if you get it wrong because going back to the drawing board
with many stakeholders with different interests is a tedious and expensive
process.

What you are defining with your tests is a kind of requirements analysis
process.  We cannot afford to go to all our stakeholders with a bunch of
tests and a bunch of method names to try and explain them how we understand
their problem space looks like.  Some of these people have only seen
software as a PC with Windows.  They don't know what databases are (ok, they
know what they are by definition, not how they work), etc.  Those people are
business specialists but may have very little skills in the area of software
programming or even thinking in terms of ANDs, ORs, XORs, IF...THEN, etc.

Rather than thinking in terms of tests, you can think in terms of scenarios,
actors, workflows and business processes.  When you agree about the business
process and all its ingredients, then you can move on.  You can test your
business process of course, but you cannot "run" this test automatically.
Some parts of the business process will not be automated, there is no need
to, and also running a test end-to-end in a multi-platform, heterogenous
environment consisting of multiple systems that do not have a common
"driver" is hard to achieve.

> 
>   c. Game where player throws a spare in first frame, i.e. knocks down
>   all ten pins in TWO throws.
[snip]
> 
>   d. Game where player throws a strike in first frame, i.e. knocks
>   down all pins with ONE throw.
[snip]
> 
>   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.)

Can you imagine having a story as I've tried to describe?  From what I see
there are opportunities to break the big story into smaller stories in order
to allow a more iterative/incremental/evolutionary approach but don't
forget, we don't have a real business value until we can free the military
airspace (co-ordinated across state boundaries), input the necessary data to
feed the systems that have to process the flight plans, tell the airlines
that they can plan their flights to use routes through these airspaces,
allow airlines to reroute flights that were already filed through those
airspaces, co-ordinate with the atc's and the flow management positions what
capacity will be available, re-allocate the slots for flights which have a
delay because the capacity has been increased, ... etc.
> 
> 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.

I agree with the recursive strategy.  I see how you apply your approach to
certain implementations, but from my experience it does not seem all that
easy to do it at the same "speed".
> 
> 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 see what you mean but I hope you understand that having the tests may not
be enough to start defining the problem domain.  In the project I've
sketched there is a lot of negotiation to come to a common understanding of
the problem, to make sure that what is proposed as a solution can also be
implemented, etc.

I could be wrong of course but what we need primarily is a better way to
come to a problem definition that everyone agrees upon.  It's like business
process engineering (or re-engineering).  I think the power of IT(C) is to
do things that were previously impossible, for which no physical alternative
is possible or achievable.  Look at the formidable challenges of driving by
wire for cars and what it will bring to car manufacturing in terms of added
value.  The problem space is not trivial because you are no longer talking
of adding software to a physical instrument, you are replacing the physical
instrument altogether.  Ok, ... perhaps the things I am interested in are
too uncommon, but of course that makes them fantastic playground for
thoughts and imagination.

Regards, Stefan Steurs.


> 
> 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

I hope my long response also give a picture of the rich nature of the
projects I am involved in ;-)

Consider also things like the introduction of Reduced Vertical Separation
Minima (RVSM) for aircraft.  How did a project like this start, how is it
managed, and how does it finally end in functionality for software systems.
I'm sure there is on-line information you can find on Flexible Use of
Airspace, RVSM and other projects which involve software systems.  It might
even be on our website.

www.eurocontrol.int - FUA =
http://www.eurocontrol.be/eatmp/fua/index.html#documents
RVSM = http://www.eur-rvsm.com/

Regards, Stefan Steurs.



____
 
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
 
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL unless it is confirmed by appropriately signed hard copy.
 
Any views expressed in this message are those of the sender.


------------------------ 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/