[I suspect what I'm about to bring up has been endlessly discussed in
the goal-centered design (and related) literature. So pointers, instead
of answers, are welcome.]
There's an interesting rant here:
'[...] Technologies that always frustrate people are those that assume
wrongly what the user wants. Worse still are those that repeatedly make
erroneous assumptions, and masterfully obscure corrective actions or
settings. Microsoft Word is the Lord High Pooh-Bah of this approach --
wherever Rick says, "Let Word do it," what he really means is, "Word
will do it for you, whether you like it or not." [...]
'There is no difference between the needs of the average user and the
professional writer when it comes to sitting in front of a computer to
get a task done -- both want the computer to help and stay out of the
way. Word asserts, 70% of all users want a bulleted list right here! or
an URL with a blue underline right here! -- and annoys the hell out of
30% of all users. Worse, you will inevitably move from the 70% group to
the 30% group several times in each document.'
Now, goal-centered design people would want to do a *really* good job
of discovering what the user needs (and perhaps wants), and I believe
that there are some people who can do a fantastic job of that.
But I think I see two traits of agile projects that - perhaps - lead in
a different direction.
One is that agile projects strive to shrug and be OK with being wrong.
Instead of trying really hard to be right, they try to find low-cost
ways to be wrong, so that it's cheaper to be wrong and fix it than to
be right in the first place.
The other is the focus on what Eric Evans calls "ubiquitous language",
the idea that both the Customer Role and the Programmer Role develop a
language that lets them understand each other enough and that the
programmers use to structure the code. (It seems to me that half of my
problems with Word are that its model of a document has nothing to do
with mine. To me, a paragraph is the thing on the screen, not a basket
of information at the end of a string of text. The fact that features
have been kludged on top of each other is abundantly obvious in things
like bullets and numbering.)
(Galison's _Image and Logic_ talks about this creation of a
intermediary "creole" in the context of particle physics. The theorists
and experimentalists faced language-and-meaning gulfs like those
between programmers and business experts.)
From this, I start to think that a project is a way to teach everyone
involved how to talk and think about the product. Any computer is a
language engine that takes language statements and produces results. A
project maybe produces a somewhat less general-purpose language engine
that takes language statements /about/ some domain and produces
results. From that, one can tailor the engine to meet goals.
That suggests that goal-driven design proceed throughout the project.
We need the personae and goals because the project needs concrete
examples to generate the abstract language. A flow of new personae and
goals trains the team and project into flexibility (the same way new
and unanticipated stories do). As the language develops, the
goal-driven designer gets a powerful and flexible tool (the code, the
language, and the team) that she can use at will.
Does that make any sense?
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
Book in progress: www.exampler.com/book