There are many ways for a project to start. But I've found the
successful ones eventually move to iterative development. Those
that start out as a waterfall become iterative during a
stabilization period, sometimes longer than the original
development.[1]
Everyone may think they know exactly what they want a product to do
at the beginning, but that always seems to change as everyone
discovers what is possible. When too many features are rushed into
a product simultaneously, instability results.
It is very tempting to fill a room with "stakeholders" to specify
features for the product, rank them by importance, and estimate the
effort for each. This exercise gives everyone a feeling that the
project is under control. This is the first step of a waterfall.
Unfortunately, the next temptation is to make a quick prototype of
each feature, with incomplete, buggy implementations. A long
stabilization then tries to decide how all these individual ideas
actually coexist in the same product.
Lightweight, agile methods (XP, Scrum) provide another way to keep a
project under control: Continuous Integration.[2] At any hour of the
day, you can get a stable version of the product from the
repository. Every feature that is visible actually works. The most
essential features were done first. All implemented features are
reconciled with each other. You have a good record of how fast you
are moving.
Here's my recipe for a more sensible beginning.
o Identify the customer. What does he do, and how does he do it
right now? What software is he using, and what does he like or
dislike about it? What are the biggest pains, the biggest gaps in
the workflow? Where could you have the biggest impact?
o Compare your natural advantages. What are you good at? Who do
you have? What code do you have? What special expertise do you
have?
o Make a short list (five) of some of the biggest problems you could
address, and a few ideas for how you might begin to tackle each.
What would the be very first thing you could do that would be
interesting to your users and relatively easy to write and test?
What would best clarify what you want to do next?
o Evaluate longer-term contingencies. If these ideas work out, or
do not, what might you do afterward? You'll appreciate the
uncertainties more.
Make sure people who will be doing the actual work are involved.
You should have an equal number of people who can identify with
users, who could not care less how it is done.
Software design is essentially a conversation between user
representatives (domain experts) who want to solve specific problems
and programmers who know what is possible. It often feels more like
a negotiation, but when the conversation works best, these minds
find clever solutions that never would have occurred to one
alone.[3]
The projects that really gel can usually come up with a single
phrase that describes what they are trying to do. If that seems
hard, then maybe you really have a collection of projects.
Sub-projects can be isolated and iterated separately, while still
continuously integrating with the others.
Footnote 1: [[Moving_to_iterative_development.html]]
Footnote 2:
http://martinfowler.com/articles/continuousIntegration.html
Footnote 3: [[Software_Development_is_a_Negotiation.html]]
Bill Harlan, April 2008