Could someone fill in a simple cookbook for impact modelling here?
One way I explain it is that it involves going from the
simplistic customer statement "I want X" (static model of requirements) into the following questions (the first two straight from TomGilb
in the early 80s):
- Is X a function or quality (atomic requirement or measurable one) ?
- If X is a quality, how much of X do you want (target and worst acceptable) ?
- When do you want (that much of) X ?
- Who exactly wants X at that time ?
- How successful would they judge the system to be if X is achieved then (100 = successful) ?
In the very early days of a project, when the shape of even a first SpikeSolution
isn't yet clear (for example the software tools or hardware it's going to use aren't) the answers lead to a set of SuccessStatement
's of the form:
60S(Head Accountant, Jun99) |= AgedDebtors?
(5%) [the head accountant would consider the system 60%
successful if it reduced the number of debtors not paying within 30 days to 5% or less by June 1999]
Then there's discussion (involving customers) of high-level technical solutions that would 'solve' the statements at some point in the future (earlier the better in line with BusinessValueFirst
). This then coalesces into one or more milestones (agreed delivery points) in a CommitmentSchedule
. [Sorry I can't link to all relevant XP terms and corresponding WikiNames
We call the early days situation high potential
and the whole aim of ImpactModelling
is to progress as soon as possible from that
dangerous but exciting consultancy state, where programmers assigned to the project probably don't have enough definition about what to do, to steady state
. Steady state is where
impact modelling simply becomes the regular updating, with the customer, of a list on a single piece of paper of one line EngineeringTask
's or simple UserStories
updatable as often as weekly.
We've recently tried using a Wiki clone for updating the list, linked to separate pages for each task or story (as I think KenAuer
does). We're wondering if we need to think again about IndexCard
s for any descriptions to back up one line task definitions, as I explain a little in KnowingWhenToStop
certainly aims to SimplifyTheRequirements
with the customer wherever possible. This is one part of the challenge of doing just enough ExternalAndInternalDesign
for the next set of SuccessStatement
's to be met. We believe strongly that it's a benefit for experienced IT and HumanComputerInteraction
people to work closely with customers on external design issues, using prototyping or paper. In some areas, in other words, it's not wrong for developers to influence SuccessStatement
's, it's essential. But it must be highly visible (and thus agreed).
Steady state is intended to be kind of boring and predictable for customers - except for those exciting scoops
that the evolutionary process and well factored code allow, as described in SuccessStatement
. Another way of saying this is NoNegativeSurprises?
As I've read Wiki pages concerned with XP the impression that I'm given by most of them is that they assume steady state is achievable in all projects from day one. Although this is much better than presuming the need for conventional BigDesignUpFront
I believe that it is over-simplistic if applied to all project situations. --RichardDrake
See also ChryslerAndSteadyState
See also the 1997 slideware around http://www.objective.co.uk/events/presentation/9710_java_design/sld025.htm