读〖User Stories Applied: For Agile Software Development〗

我们实践User Story的process（结合scrum）也有两三个月了。但是,每当写User Story时，总感觉不知所措，不知道写些什么，写到什么程度。
带着这些问题，开始阅读了Mike Cohn的〖User Stories Applied: For Agile Software Development〗。
读完后，我顿时豁然开朗，弄明白了如何写User Story，如何做estimation，如何好好得利用story point。

下面的一些文字，是我从书中摘录的，它们给我带来了一些启发。

As a starting point it's good to have stories that can be coded and tested between half a day and perhaps two weeks by one or a pair of programmers.

 

The customer team, rather than the developers, writes the user stories for two primary reasons.

First, each story must be written in the language of the business, not in technical jargon, so that the customer team can prioritize the stories for inclusion into iterations and releases.

Second, as the primary product visionaries, the customer team is in the best position to describe the behavior of the product.

 

Writing tests early is extremely helpful because more of the customer team's assumptions and expectations are communicated earlier to the developers.

 

Independent
Negotiable
Valuable to users or customers
Estimatable
Small
Testable

 

As much as possible, care should be taken to avoid introducing dependencies between stories.

#Combine the dependent stories into one larger but independent story
#Find a different way of splitting the stories

 

Stories are negotiable.

#a phrase or two that act as reminders to hold the conversation
#notes about issues to be resolved during the conversation

 

 

 

->All connections to the database are through a connection pool.
->ll error handling and logging is done through a set of common classes.

<-Up to fifty users should be able to use the application with a five-user database license.
<-All errors are presented to the user and logged in a consistent manner.

 

Stories must be written so as to be testable.
->A user must never have to wait long for any screen to appear.
<-New screens appear within two seconds in 95% of all cases.

 

We will use the following steps to identify and select a useful set of user roles:

#brainstorm an initial set of user roles
#organize the initial set
#consolidate roles
#refine the roles

 

Acceptance tests provide a great deal of information that the programmers can use in advance of coding the story.

 

you may want to consider any or all of the following:

#User interface testing, which ensures that all of the components of the user interface behave as expected
#Usability testing, which is done to ensure an application that can be easily used
#Performance testing, which is done to gauge how well the application will perform under various workloads
#Stress testing, in which the application is subjected to extreme values of users, transactions, or anything else that may put the application under stress

 

My preference is to treat a story point as an ideal day of work. We rarely have these ideal days, but thinking about stories in ideal time offers two advantages. First, it is easier than estimating in elapsed time. Estimating in elapsed time forces us to consider all other possible impacts on our time, such as the all-company meeting on Tuesday, my dentist appointment on Wednesday, a few hours a day for answering email, and so on. Second, estimating story points in ideal time gives our estimates a slightly better foundation than when they are estimated in entirely nebulous units. Since one of the main purposes of estimating is to be able to answer questions about the overall expected effort in a project, we will eventually need to convert estimates into time. Starting with ideal time makes that conversion a little simpler than starting with an entirely nebulous unit.

Story estimates, however, are owned by the team for two reasons:

First, since the team doesn't yet know who will work on the story, ownership of the story cannot be more precisely assigned than to the team collectively.
Second, estimates derived by the team, rather than a single individual, are probably more useful.

 

Triangulating an estimate refers to estimating a story based on its relationship to one or more other stories.

 

#the risk that the story cannot be completed as desired (for example, with desired performance characteristics or with a novel algorithm)
#the impact the story will have on other stories if deferred (we don't want to wait until the last iteration to learn that the application is to be three-tiered and multi-threaded)
#the desirability of the story to a broad base of users or customers
#the desirability of the story to a small number of important users or customers
#the cohesiveness of the story in relation to other stories

 

The general sequence of activities for an iteration planning meeting is as follows:

1. Discuss a story.
2. Disaggregate the story into its constituent tasks.
3. One developer accepts responsibility for each task.

After all stories have been discussed and all tasks have been accepted, developers individually estimate the tasks they've accepted to make sure they are not over-committed.

 

Use these guidelines when disaggregating stories into tasks:

#If one task of a story is particularly difficult to estimate, separate that task from the rest of the story.
#If tasks could easily be done by separate developers, then split those tasks.
#If there is benefit in knowing that a part of the story is done, break that part out as a task.