Re: XP and estimating

On Thursday, December 12, 2002, at 1:01:12 AM, STEURS Stefan wrote:

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

This is not an XP User Story. An XP User Story must be small enough to
be implemented by the team -- and ideally by one pair -- inside one
iteration, typically two weeks. An XP User Story must be capable of
being estimated by the developers, which means it must be clear and
precise. This clarity and precision is expressed by the story's
Confirmation, one or more automated Customer Acceptance Tests.

This means, in more conventional terms, that the "analysis" isn't
done, at least not to a precision fine enough for an XP project.

Now ... XP as presently defined BEGINS when you have stories that are
small enough to estimate. We do not as yet give much guidance on how
to get to stories that fine grained.

Therefore: while I feel quite sure that IF a team working on your
problem above had stories that fine, they could do XP, it is a big if,
because I can't sit here and say how to get those stories.

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

No, it seems like quite a complex and interesting problem to me.

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

This, I suggest, is overstated. First of all, there are many kinds of
value, not just the single value of real airplanes all over the world
flying in this new space. In XP, I would focus my search for value on
the people who are asking the developers for this solution. I take
those to be someone else within your company, not some guy in a
control tower somewhere. The people within your company need many
things of value. Naturally I don't really know what they want but I
would guess that they could use things like this:

  1. Increasingly solid knowledge of when the software that supports
  this could be released. They might use this to plan deployment,
  begin briefing airlines and government agencies, and so on.

  2. Increasingly solid knowledge of what the constraints will be in
  the system. They might use this to ensure that the solution will be
  viable in the minds of those who must approve it.

  3. Increasingly solid knowledge of how much it will cost to write
  the software. They might use this to decide whether to go ahead, and
  how to fund the project.

  4. Increasingly solid knowledge that the developers are really
  making progress on the solution. They might use this to decide
  allocation of resources, or just to decide whether to keep the
  project alive.

All of these things, and many like them, are "value" to the managers
and executives who authorize and support a project. The idea in an XP
project is to provide value like that, on a regular basis, based on
software that they can understand.

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

Sure there is. It's not as well-defined as bowling, but in fact the
airspace is already divided into corridors and volumes that are
dedicated to various functions. The inverted wedding cake around an
airport isn't drawn in the sky in blue lines, but it has been drawn on
whiteboards and sketchpads and aeronautical maps all over.

So. I am of course completely unaware of what software exists already
and of what techniques are used. So let me describe how I would go
about addressing this problem. Your people could go about it faster,
because they already know robust solutions to the small problems I
would start with.

I reason as follows: OK, there are volumes of space into which my
commercial flights may not today be vectored. I have software today
that somehow tells me not to do that. (I'll make up how it works,
since I don't know how the real stuff works.)

There are other volumes that can be used.

First test: switch a volume from "cannot be used" to "can be used".
Test whether planes are now vectored into that new volume.

  There might be many small tests inside this test. I'm assuming for
  the sake of the discussion that ideas like "volume" and "planes can
  go there" are already abstractions in the system that I can refer
  to. I'm assuming that I already have a full framework of tests.

  If I were trying to convert to XP with the real software you have,
  this would likely not be the case. That's a more complex case,
  transition of existing software, and I'm not on about that right
  here.

Second test: switch a volume from "can be used" to "cannot". Test
whether places are no longer vectored into that new volume. (Of course
some planes are already in there. I know that's a problem.)

Third test: Hmm. When a volume goes "red" (note that I just made up a
color metaphor about my problem for convenience in speaking) I need to
vector all planes out of it ASAP. OK. "Easy" enough. We already have
(I assume) software for computing an emergency vector to a known
location, for use in sending endangered planes to the nearest airport
and the like. Therefore compute the shortest path to the boundary of
the red zone. Vector the aircraft there.

And so on. There would be tests that address stories like this: "The
government can only give us ten minutes' warning that a volume is
going red. Therefore never allow use of the volume other than within
ten minutes of the boundary." Or "Change flight vectors so that no
plane ever has to 'back up' to get out of the volume". And so on.

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

Yes. Therefore it isn't an XP User Story yet. Each of those pages
might be a user story.

Now. This may seem daunting and maybe impossible. It might be
impossible to do your project in full on XP. (It would not be
impossible to build the actual code using many XP practices, but
that's not our topic right now.)

I would accept that I might not know how to divide up your problem
into small enough bites to do pure 10-programmer scale XP. I would
even accept that it might be truly impossible. But incremental
thinking like the tests sketched above, done by people who actually
have a clue instead of me who has not, might well work. I say this
because so far, I've never encountered a problem that couldn't be
broken down that way. So that's not a proof, just an expectation. It
is surely MUCH MUCH harder to break down your example than it is to
break down the bowling game. But the bowling game can be done in an
hour. The trick in XP for air traffic control is to find the things
that can be done in a few days or weeks. Once you have those things,
it might be very little trouble to figure out how to do those things
in smaller and smaller tests.

So: might be impossible. Would be difficult. Might be worth
addressing. Someone in your software development area, someone with
actual knowledge about the domain, needs to assess these ideas, and
decide whether and how far to explore.

Ron Jeffries
www.XProgramming.com
How do I sell my executive team on doing this stuff?  -- Questioner
Don't. Just do it. They don't know what you're doing anyway. -- Jim Highsmith


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