敏捷开发流程详解

敏捷开发流程详解 

 

1       敏捷开发流程

ü   敏捷软件开发核心是迭代式开发，增量交付。 

ü   每一次迭代都创建在稳定的质量基础上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地增加和不断完善。每次迭代要邀请用户表明（外部或内部）验收，提供需求是否知足的反馈。

ü   迭代型的方法就是将整个软件生命周期分红多个小的迭代，每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代均可以生成一个稳定和被验证过的软件版本。

ü   迭代建议采用固定的周期（1-4）周，能够每一个迭代周期不必定要相同，但迭代内工做不能完成，应该缩减交付范围而不是延长周期。

1.1      敏捷流程详解图-敏捷流程图

1.2      敏捷流程三种角色及其职责

角色名称	角色定义	角色职责	注意事项
Product Owner（PO）- 产品负责人	确保Team作正确的事	l   表明利益相关人（如用户、市场、管理等），对产品投资回报负责 l   肯定产品发布计划 l   定义产品需求，根据市场价值肯定功能优先级 l   验收迭代结果，并根据验收结果和需求变化更新需求清单和优先级	l   除了客户需求以外，内部任务如重构、持续集成环境搭建等也由PO归入统一管理
Scrum Master（SM）- Scrum 教练	确保Team正确的作事	l   辅导团队正确应用敏捷实践 l   引导团队创建并遵照规则 l   保护团队不受打扰 l   推进解决团队遇到的障碍 l   保证开发过程按计划进行，组织站立会，冲刺评审会，冲刺回顾会议	l   不命令和控制Team
Team – 开发团队	负责产品需求实现	l   负责估计工做量并根据自身能力找出最佳方案去完成任务且保证交付质量 l   向PO和利益相关人员演示工做成果（可运行的软件） l   团队自身管理、持续改进	l   通常由5-9人左右跨职能领域人员（开发人员、测试人员、设计师等）组成 l   团队车管员构成在sprint内不容许变化 l   有共同的目标、共担责任 l   团队成员严格遵照团队规则

 

1.3      敏捷开发流程详解

1.3.1   流程图详解步骤

1.          制定产品需求列表

ü   PO收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合理的产品需求列表；

2.          召开计划会议

ü   PO召集TM和SM（也可邀请其余利益相关者参加）召开计划会议（发布计划会议和冲刺会议一块开），发布计划主要是说明产品完整交付给客户的计划时间和交付物，

ü   冲刺计划就是肯定该冲刺阶的长度（建议冲刺长度1-4周）、目标和冲刺任务单及其工做量估算（以理想人天manday=7.5h估算，单位为小时计算），会议时间建议不要超过6h时间；

ü   在计划会议上就须要进行确认，是否须要使用持续集成；若使用持续集成，团队须要天天下班前至少提交一次私有构建成功的代码到服务器，而且要求写详细的日志信息；若不使用持续集成，团队天天有完成任务单的状况，都须要在svn上以增量形式发包并通知到相关人员；

ü   项目计划会议上能够肯定天天站立会时间及其规则要求（建议会议时间在15-20分钟左右），每一个人回答3个问题：昨天作了什么，遇到什么问题，今天要作什么。具体问题讨论及其解决，在私下进行沟通，不要在会议上讨论。站立会上只有TM人员有发言权，其余人员不要干预，SM主要是维护秩序、规则及其引导做用。

3.          需求分析、设计、编码和测试：

ü   计划会议结束后，TM获取各自的冲刺任务单进行后面的需求分析、设计、编码和测试；

ü   这里特别要说明的是，开发和测试是并行工做，必要的文档仍是须要输出（如：讨论次数较多的功能点、备选方案不少但最后确认一种、重要功能、业务逻辑复杂的等等）。具体状况，须要项目组根据实际状况决定，但客户要求交付的文档必需要输出；

4.          冲刺任务单和燃尽图更新

天天SM须要根据每日站立会上TM反馈的状况，进行更新冲刺任务单和燃尽图或SM和TM之间达成共识，TM各自完成后进行更改状态，这里涉及到的文档都会有相对应的模板供参考使用。

5.          迭代周期结束点

ü   已到迭代周期结束点，只有哪些通过测试经过的冲刺需求列表才能算是真正的完成，其余未通过测试或测试不经过的不能算是完成。

ü   这里要特别注意，所谓的测试经过不是说要把全部的问题都解决才算是经过，这个要根据项目具体的要求和规定来定。尚未达到迭代结束点，该冲刺任务需求列表就完成，能够从产品需求列表中挑选优先级高的进行开发。

6.          冲刺评审会议

ü   TM须要召开冲刺评审会议，邀请PO、客户或客户表明来参加，由这些客户或客户表明来表决是否知足需求和指望目标。通常会议时间建议不要超过2个小时，参加人员除PO及其相关利益人来参加外，TM全体成员，也能够邀请其余相关人员参加。

7.          冲刺回顾会议

ü   迭代输出的增量交付可能会引发原产品需求列表的改变，可能须要更新原产品需求列表；最后TM须要开展本次迭代的好的实践和不足的改进机会，最终稿由SM整理汇总，做为下一次的迭代的经验参考。回顾会议建议时间不用太长，通常15-30分钟便可，全体人员都须要参加，包括：PO、SM、TM，其余相关人员也能够参加。

ü   这里要说明的是在每次的计划会议上要注意安排时间作冲刺评审会议和冲刺回顾会议。下一次迭代的计划会议建议在上一次迭代的冲刺回顾会议结束后再开展。

8.          重复2-7步骤

ü   直到全部列入本版本规划的任务单都完成，最后发布版本；

ü   特别说明：一般最后一个迭代多是全量进行验证的周期，

 

1.3.2  管理

结合目前jira进行管理“使用敏捷开发模式的项目”也是很方便。每个迭代在jira中做为一个版本控制，每一个迭代下面的任务单，参照迭代计划预估的时间进行建立，实际工时根据每一个人的实际填写日报为准计算。能够考虑安装一款支持jira的敏捷开发插件GreenHopper，彻底实现电子版的看板功能和图表功能。

在confluence上以项目名称建立项目，而后二级目录是每一个迭代名称、产品需求列表，三级目录放每次迭代冲刺评审会议纪要、冲刺回顾会议纪要、站立会纪要、燃尽图、迭代任务订单。

 

说明：燃尽图使用excel表格式的模板，项目组能够参照使用。

1.3.3   度量

类别	指标	XX项目
迭代1	迭代2	迭代3
范围	计划交付任务订单数	26	14	15
实际交付任务订单数	26	13	15
价值交付率	100%	92.85%	100%
工做量	实际完成率	开发任务完成100%（遗留大量BUG）	100%（全部任务完成，BUG清空）	100%（遗留2个偶现BUG）
	计划估算精准度	误差31%=（实际-计划）/计划	误差31%=（实际-计划）/计划	误差31%=（实际-计划）/计划
开发计划估算精确度	误差20%=（实际开发-计划开发）/计划开发	误差20%=（实际开发-计划开发）/计划开发	误差20%=（实际开发-计划开发）/计划开发
测试计划估算精确度	误差30%=（实际测试-计划测试）/计划测试	误差30%=（实际测试-计划测试）/计划测试	误差30%=（实际测试-计划测试）/计划测试
质量	开发测试工时比	开发工时：测试工时	开发工时：测试工时	开发工时：测试工时
	测试效率	发现有效bug/测试工时	发现有效bug/测试工时	发现有效bug/测试工时
测试验证一次经过率（按任务单）	一次经过任务订单/本迭代预计要完成的任务订单*100%	一次经过任务订单/本迭代预计要完成的任务订单*100%	一次经过任务订单/本迭代预计要完成的任务订单*100%
测试验证一次经过率（按用例）
缺陷总数
缺陷密度（个/开发工时）
缺陷级别	1:20:10:4:3
测试用例内BUG占比
系统测试先后BUG比	NA（无单独系统测试）	NA（无单独系统测试）	系统测试前：系统测试后
成本	不良质量成本占比	修复bug所耗工时/总工时
	总工时数	800人时
团队工做负载	100%	112%	80%（学习其余）