On Wed, 29 Dec 2004 15:36:09 +0100, Mattias Vannerg�rd <[EMAIL PROTECTED]>
wrote:
> But the Conversation in Ron Jeferries "Card, Conversation, Confirmation" is.
> I wonder how much of it is kept in cards?
Typically about half a sentence. I think Alistair Cockburn had it
right when he described the cards as "tokens" for a conversation.
> Or where else you keep the design, that is inspired from that Conversation?
The design goes into the code. You might have some diagrams written on
a whiteboard along the way. Once in a while a permanent document might
result.
> Somewhere in the details, you may go beyond the technical
> knowledge of the customer.
> How do you keep the conversation at the customer level?
The customer's not afraid to say, "I don't care about how that works".
Or, if they should care, the team can educate them: "Here's the
consequence of this way vs. that."
> >> I like also to think in terms of expanding the User Stories into Use
> >> Cases, to capture the interesting design issues.
>
> > Once you've done that, what would you do with those documents?
>
> Keep it away from the customer, and the Conversation on the story card,
> reflects the technical design issues on a level that the customer still
> can easily understand. (Know nowe, that I am still only in theory. This
> might not work out well in real-life?)
It might help to think of using user stories at different levels. Then
think of the goal of doing things with as little overhead as possible,
and "just in time" as much as possible. We don't elaborate everything
out to a consistent level of detail; rather we create enough detail
for the purpose at hand.
- For planning purposes, we put a sentence on a card. This is almost
like a marketing bullet point (maybe one level deeper): "Chat text
allows bold, italic, and underlined styles."
- To estimate that at a rough level, a sentence is probably not
enough. But a sentence plus a few minutes conversation might be. Now
this conversation is in the heads of its participants, and the
sentence on the card is enough to remind them of its essence.
- When it's time to implement the story, we want to be more clear
about what it means, so we'll invest in some tests. Ideally, these
become automated. We don't need these tests 3 months in advance, we
need them only around the time of implementation. Once we have them,
they're worth keeping, so we can be reminded about the details of what
we decided, and for regression purposes.
- A user story is a small bit of work (often only a couple days'
work). There may be some discussion of design, but a 2-day project
doesn't usually need more than sketch or some CRC cards. We try to
make the code as clean as possible, so most of the design is apparent
there.
So what happens to the pieces:
- Card - you might keep it around a little while, but in practice it's
pretty rare that you care about that sentence.
- Conversation - this is still in the heads of the participants,
though fading over time. If related stories come up, the conversation
is refreshed. If not, much of it fades.
- Confirmation - these are kept around, for the reasons mentioned above.
- Code - most of the design is reflected here. The sketches aren't
typically needed any more, so they can be erased. If you really need
some auxiliary documentation, create it. (But what's the purpose of
this? It's not for the current team, since they've implemented it
without it. It's for a future team. They might value an overview of
the essence, but they'll mostly go to the code for the details.)
--
Bill Wake [EMAIL PROTECTED] www.xp123.com
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
