Hi, Matttias. From your questions, I feel like we haven't done a good job
of conveying the context into which user stories fits. Hopefully these
explanations will help; if not, let me know!
> Great!
> And the confirmation should be Re-executable. Like regressiontesting?
Exactly.
> I'm still intrested in where the Conversation is stored (does it always
> fit on the story card?)
If you take a look here, you can see images of some story cards from a
recent project:
http://www.scissor.com/resources/teamroom/
As you can see, there isn't much written on a card; generally it's just a
3-6 word title like "Member Logs In". The conversation is kept where most
people keep their conversations: in their heads. Occasionally we jot
notes, like the names of fields involved, or a note about something
explicitly excluded from the esitmate.
The disadvantage is that you sometimes need to explain something more than
once. There are several advantages. One is that discussion is much easier
than writing. Another is that there's less speculative transfer of
information; instead of writing docs that may never be used, you just
answer the questions that are asked. A third is that it's much less likely
you'll be working with stale information.
> Don't you technically elaborate on the
> Conversation-part? (My idea was expanding the story card into a use
> case, see below)
I often technically elaborate the conversation. Often it's during the
conversation. We sketch user interfaces or system designs on a whiteboard.
Sometimes we make paper prototypes. Sometimes we take a break from
discussion and come back after thinking about it or making simple mockups.
But all of these artifacts are ephemeral. Once they stop being an active
part of a current discussion, we destroy them or file them away and ignore
them. Why? Because each representation of the project you try to keep in
sync adds substantially to your burdens, reducing productivity.
On an XP project, the story cards cover the future. For records of the
past, you have the source code, the unit tests, and the customer tests
(aka story tests aka acceptance tests). Keeping all of that in sync is
plenty of work already, but it seems to be the minimum sufficient to let
us build good software.
Because we want to maximize productivity, we avoid adding any other
burdens, like detailed specifications or records of conversations. That
has scared some clients of mine at first, so they kept maintaining those
artifacts for a while. But those who successfully adopted XP eventually
got tired of doing extra work for little benefit.
Hoping that helps,
William
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/
