首页 > 代码库 > 敏捷开发——User Story

敏捷开发——User Story

敏捷开发流程:

1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;

3、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

4、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);

6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

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

user story 定义:

Story就是一个可测试的小功能点Story:功能点=11)、或者是多个继承性的小功能点组成的一个StoryStory:功能点=1:N)、或者是一个无法再分割的功能点(再分割这个功能点就无法进行测试了)包含多个StoryStory:功能点=N1)。

1Story

Story最原始的目的是指导开发工作量的划分,Story是将一个大的特性划分成小颗粒度的功能块,方便分配工作量,以便获得快速反馈;

2、特性:

敏捷中的特性类似于在双V模型或者其他模型中的子系统、子模块或者说是较大的功能模块,是由很多的功能块组成的,一个特性是耦合度很高的子模块;

3、功能块:

敏捷中的功能块类似于双V模型或者其他模型中的较小的模块,从子模块里划分出来的较小的功能模块,是由很多的功能点组成的;

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

5特性团队

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

6头脑风暴

由特性团队中所有成员一起就一个Story的方案、设计、用例设计验收标准等内容而进行的团队中的讨论会,以澄清Story的设计,用例,测试验收标准等;

7Story验收标准

每一个Story都需要在进行头脑风暴时,由团队里的人一起制定该Story的验收标准;

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

敏捷开发——User Story