Fri, 21 Apr 2006
Agile definitions
No doubt because I'm
a self-proclaimed
skeptic about definitions, I was asked:
[...] can you supply dictionary-like definitions for:
test-driven design
example-driven design
agile methodology
?
My answer:
- test-driven design
A style of program design that begins by writing one simple test, then
writing just enough code to pass it. Then another simple test is
written, and code is added to pass both it and the previous test. The
programmer then looks for opportunities to improve the code by
generalizing it, removing duplication, restructuring it, or making it
more understandable. The test-code-improve cycle repeats until there
are no more tests to be had. It is claimed that a good global design
emerges from (1) the need to decouple the code to make tests run fast,
and (2) the local heuristic rules for code improvement. The tests are
retained and run frequently to prevent unintended effects of changes to the
design.
- example-driven design
-
A variant of test-driven design with a particular answer to the
question "What test should be next?" The tests are written as if they
were a series of examples being used to teach someone how to use the
code, beginning with simple cases and moving toward the trickier
ones.
- agile methodology
-
A style of software development characterized by its release schedule,
attitude toward change, and patterns of communication. (1) The product
is developed in iterations, usually one to four weeks long. At the end
of each iteration, it has additional, fully implemented business
value--not just more code--and is ready to be deployed (although it
may not be). (2) The design horizon usually extends only to the end of
the current iteration; little code is written in anticipation of
future needs. Since the project is seen by the programmers as a stream of unanticipated
requirements, the team and product are forced to learn to accommodate
change. There is no concept of "requirements churn" and no need for a
requirements freeze. (3) Written natural language communication is
considered a usually-inefficient compromise. Face-to-face
communication is higher bandwidth (but transient). Executable
documentation—code and tests—is permanent, less ambiguous, and
self-checking (but slower to write and read). Agile projects prefer a
combination of the latter two over the the first.
## Posted at 17:00 in category /agile
[permalink]
[top]
How to be a product director
I've finished
a first
draft of "How to be a Product Director." PDF, 17 pages (with
pictures and screen shots and pull quotes and sidebars). Comments
welcome.
Some projects call it "the Customer."
Others call it "the product owner." Some
call it "the goal donor." I and a few others
call it the Product Director. Like a film
director, the product director is the one
person with the clearest vision of the final
result. But—like a film director—the role
isn't a passive one of "expressing the vision."
It's an active role, one of pointing
the work of other people in a particular direction, evaluating the results, and adjusting the
direction based on the reality of what the last bout of work produced.
It's the hardest job on an Agile project.
The job revolves around four verbs: inform, observe, adjust, and
represent.
The product director informs the programmers
of what to do next by providing
them with stories. [sidebar defining "story"] In order
to estimate the
cost of a story and implement it successfully,
the programmers need:[...]
## Posted at 07:33 in category /agile
[permalink]
[top]
|
|
