敏捷开发流程详解
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%（学习其他） |
|
|
|
|
|
|
来源：oschina
链接：https://my.oschina.net/u/1767631/blog/756085