01.用户故事与敏捷方法——起步笔记

00.软件需求是一个沟通问题。需要新软件的人（使用或销售软件的人）必须与开发新软件的人进行交流。一个项目的成功，依赖于很多不同的信息，这些信息来自各有不同的人员：一方是客户和用户，有时还有分析人员、领域专家和其他从业务或组织视角来审视软件的人；另一方面是技术团队。

 

01.一旦任何一方在沟通中把持绝对地位，项目就会遭受损失。

　　如果业务方把持绝对地位，他们就会关注软件功能和交付日期，却很少关注开发人员是否能够同时满足这两个目标，或者开发人员是否确切地了解需求。

　　如果开发人员把持绝对地位，技术属于就会代替业务语言，从而导致开发人员无法倾听业务方的实际需求。

 

02.用户故事描述了对用户、系统或软件购买者有价值的功能。　

　　*一份书面的故事描述，用来做计划和作为提示

　　*有关故事的对话，用于具体化故事细节

　　*测试，用于表达和编挡故事细节且可用于确定故事合适完成。

 

03.如果一个故事很大，我们有时候就称为之为史诗故事（Epic）。史诗故事可以分为两个或更多的小故事。用户的期望最好以验收测试的形式被记录下来。

 

04.客户团队中包括确保软件满足用户需求的所有人。这意味着客户团队可以包括测试人员、产品经理、实际用户和交互设计师。

 

05.面向瀑布模型的过程会有书写所有需求、分析需求、设计方案、编码、最终测试的周期。

 

06.软件的客户和最终用户应该在编写用户故事时承担着非常活跃的角色，尤其是在团队使用基线编程进行软件开发时。编写用户故事的过程最好从考虑系统的用户类别开始。

 

07.由客户团队而不是开发人员来编写用户故事主要基于两个原因。首先，每个故事必须用商业语言来写，不是用技术术语，这样一来，客户团队可以排列故事的优先级，放入迭代和发布。其次，作为主要的作品构想者，客户团队所处的位置最适合描述产品行为。

 

08.与其写这些故事细节，还不如让开发团队和客户讨论这些细节。

 

09. 发布规划指的是确定项目时间表和预期功能集合之间达到平衡。迭代规划设计选择迭代包含的故事。客户团队和开发人员在发布和迭代规划中都要参与

 

10.当程序员开始编程前，故事卡被卖你就写下测试描述时，可以节省程序员的时间。更多关于编写故事验收测试的内容。