User Stories Applied读书笔记（第一章）

user stories仅仅列出用户关心的细节（例如产品采用何种语言实现，采用何种架构，哪种数据库等不应该包含在其中）

user stories不应该太长太大，一个笼统的user story可以和一些作为补充的user stories联系起来

只要一个user stories最终覆盖了所有需要的细节，那么它就不需要再进行分解，例如： "A user can view information about each job that is matched by a search" 就已经足够，不需要再分解成1)user can view a job description. 2)A user can view a job's salary range. 3)A user can view the location of a job.

一个user storiy卡上同时应该注明用户对于这个user story工作时的期望，例如能否和如何处理输入异常。这些期望可以用来作为test case和coding的指导。

建立一个A customer Team来随时跟踪和确认用户的需求，应该包含测试人员，开发人员，项目经理，客户代表，ui设计师等。

user stories应该由customer team来完成，在编写user stories的时候，应该采用头脑风暴的方式，尽可能多的编写stories，之后，由程序员对每个user story进行评审，确认stories的尺寸（一个user story应该能在半天到两个星期内完成）

由customer team和开发者一同指定每一次迭代的周期，在本次迭代结束的时候，开发者负责交付所有的代码，开发文档和测试用例，而customer team负责确认本次迭代是朝着预期的目标在前进，一次迭代完成整个系统的一部分。

项目开始的时候，会由开发者预测一次迭代可以完成的工作量，并把这个工作量叫做“velocity”，每次迭代完成的时候，都需要根据实际完成的情况对“velocity”进行调整，一次迭代中实际包含的user stories个数也需要根据velocity进行调整，确保每次迭代中包含的stories都能够完成，如果无法完成，则将无法完成的stories调整到下一次迭代中，甚至调整到下一个版本中。下次迭代中包含的stories数量也需要根据velocity的值进行动态调整。

每次迭代开始的时候，由开发者和customer team一起确认那些是重要的必须优先实现的stories，并将这些stories优先放入当前的迭代中。

三种情况下的story是应该被优先实现的：
1）大部分用户广泛需要的。
2）少数但是是重要用户需要的。
3）其他高优先级stories依赖的。

在提高一个user story的优先级的时候，必须仔细考虑这个user story的成本，这个成本用一个叫做story point的指标来表示，用来衡量这个story本身的复杂性以及和其他story之间的依赖度，值越高表示实现这个story需要花费的成本越高。注意，不要将一个story point大于项目组velocity的story分配给一个项目组。

 一个总结：

• A story card contains a short description of user- or customer-valued functionality.

• A story card is the visible part of a story, but the important parts are the conversations between the customer and developers about the story.

• The customer team includes those who ensure that the software will meet the needs of its intended users. This may include testers, a product manager, real users, and interaction designers.

• The customer team writes the story cards because they are in the best position to express the desired features and because they must later be able to work out story details with the developers and to prioritize the stories.

• Stories are prioritized based on their value to the organization.

• Releases and iterations are planned by placing stories into iterations.

• Velocity is the amount of work the developers can complete in an iteration.

• The sum of the estimates of the stories placed in an iteration cannot exceed the velocity the developers forecast for that iteration.

• If a story won't fit in an iteration, you can split the story into two or more smaller stories.

• Acceptance tests validate that a story has been developed with the functionality the customer team had in mind when they wrote the story.

• User stories are worth using because they emphasize verbal communication, can be understood equally by you and the developers, can be used for planning iterations, work well within an iterative development process, and because they encourage the deferring of detail.