敏捷开发——User Story

敏捷开发流程：

一、咱们首先须要肯定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

二、Scrum Team根据Product Backlog列表，作工做量的预估和安排；

三、有了Product Backlog列表，咱们须要经过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story做为本次迭代完成的目标，这个目标的时间周期是1~4个星期，而后把这个Story进行细化，造成一个Sprint Backlog；

四、Sprint Backlog是由Scrum Team去完成的，每一个成员根据Sprint Backlog再细化成更小的任务（细到每一个任务的工做量在2天内能完成）；

五、在Scrum Team完成计划会议上选出的Sprint Backlog过程当中，须要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每一个人都必须发言，而且要向全部成员当面汇报你昨天完成了什么，而且向全部成员承诺你今天要完成什么，同时遇到不能解决的问题也能够提出，每一个人回答完成后，要走到黑板前更新本身的 Sprint burn down（Sprint燃尽图）；

六、作到每日集成，也就是天天都要有一个能够成功编译、而且能够演示的版本；不少人可能尚未用过自动化的每日集成，其实TFS就有这个功能，它能够支持每次有成员进行签入操做的时候，在服务器上自动获取最新版本，而后在服务器中编译，若是经过则立刻再执行单元测试代码，若是也所有经过，则将该版本发布，这时一次正式的签入操做才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

七、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，咱们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每个Scrum Team的成员都要向他们演示本身完成的软件产品（这个会议很是重要，必定不能取消）；

八、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每一个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

user story 定义：

Story就是一个可测试的小功能点（Story：功能点=1：1）、或者是多个继承性的小功能点组成的一个Story（Story：功能点=1:N）、或者是一个没法再分割的功能点（再分割这个功能点就没法进行测试了）包含多个Story（Story：功能点=N：1）。

1、Story

Story最原始的目的是指导开发工做量的划分，Story是将一个大的特性划分红小颗粒度的功能块，方便分配工做量，以便得到快速反馈；

2、特性：

敏捷中的特性相似于在双V模型或者其余模型中的子系统、子模块或者说是较大的功能模块，是由不少的功能块组成的，一个特性是耦合度很高的子模块；

3、功能块：

敏捷中的功能块相似于双V模型或者其余模型中的较小的模块，从子模块里划分出来的较小的功能模块，是由不少的功能点组成的；

4、功能点：是不可再分割的可测试的小功能模块；

5、特性团队：

特性团队是指由设计人员、开发人员、测试人员、资料人员、特性团队组长等人一块儿组成的一个完整的团队（7人左右），特性团队是按特性进行划分的团队，团队成员对该特性的交付全权负责

6、头脑风暴：

由特性团队中全部成员一块儿就一个Story的方案、设计、用例设计、验收标准等内容而进行的团队中的讨论会，以澄清Story的设计，用例，测试验收标准等；

7、Story验收标准

每个Story都须要在进行头脑风暴时，由团队里的人一块儿制定该Story的验收标准；

Story划分时以测试功能点做为依据，实现Story与功能点的融合，测试时基于功能点进行设计测试用例，开发基于Story进行开发。