Re: Flexibility and changing requirements

[Elna Tymes <Etymes -at- LTS -dot- com>]

Lisa Wright wrote:

> This is the whole idea behind XP programming--you design as you go.
> You're flexible. You don't invest a lot in developing things that are
> miles down the road. You deal with the here and now. You plan for short
> iterations of a product based on known requirements. Actually, you're
> not even supposed to deal with ALL the known requirements, though that
> one's a struggle. "Just ignore the 2-ton elephant in the corner. He
> doesn't get involved until *much* later!"

The XP approach works well when it's already been decided that (1) developers are
going to use that environment to maximize product design flexibility and (2) any
writer is going to be part of the development team from day 1, and be treated like
the developers in terms of not measuring productivity by some arbitrary output -
for developers, it's number of lines of code; for writers, it's usually number of
pages of finished documentation.  This approach tends to appeal to development
managers who understand and can deal with why you sometimes wind up going back and
starting over several times before you come up with something that works.  And it's
the kind of approach that tends to make bean counters apoplectic.

The problem is that there are enough bean counters (and people who use words like
"cost effective" as part of their daily jargon) that finding the true flexibility
to use XP properly is pretty rare, particularly in a down economy. One certainly
doesn't use contractors in that kind of environment unless one has bushels of money
and a really relaxed CFO.  (This isn't to say that the XP environment is more
expensive than other methods - if one takes the long view of product development,
you probably get a better product over the life cycle of the product.  But that
view may take 3-5  years to prove itself, and most corporate environments don't
have that kind of patience.)

> The key part is that you are highly flexible. Hackos is right: people
> often don't know what they want until they begin to see it take shape.
> So instead of running them through the "you didn't stick to our process"
> mill, you have a process where change is a natural, expected,
> encouraged, nay, critical part of the process that enables you to get
> the best product with very high customer satisfaction.

Change is a normal and natural part of the documentation process.  The problem is
containing it within reasonable financial bounds.  Endless iterations of a document
are expensive and time-consuming, and you usually wind up with a document that
doesn't quite hit the mark, because someone with clout finally said "Enough!"
Putting some bounds on the number and kind of iterations is a more reasonable thing
to do.  For instance, we don't expect that all the software or hardware features
will be implemented when we produce a first draft.  Nor do we expect the design
team to have completely agreed on where the feature list for this version stops and
the new version begins.  However the farther into the process we go, the more we
expect definitions to stay put - that is, if we are to stay on schedule and within
budget.  If the schedule slips or the budget expands, well then that's quite
another story!  But most products don't have that kind of luxury.

Case in point: one of our clients had a set of manuals that had to go out according
to a specific schedule, largely because one of the customers wanted finished
software and manuals by a certain date.  The product manager agreed that
development would stop at a certain date so that the manuals could get printed and
delivered on time.  The software was being delivered on CD via FedEx, so changes
could take place after the documentation deadlines.  To cover those changes, the
product manager decided on some extensive Release Notes to accompany the CD's.  We
generated 16 separate iterations of Release Notes over a 9-day period, each one
being declared to be the very last set of Release Notes for that version of the
product, including one hair-raising day with The Last Word being written three
different times. I learned to love time/date stamps in the header.

Elna Tymes
Los Trancos Systems


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sponsored by eHelp Corporation, makers of RoboHelp. RoboHelp 2002 is now available! Get the very latest in Help functionality 
to create superior Help systems. Get special savings when you buy 
in January!  Visit http://www.ehelp.com/techwr

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.