敏捷开发规程详解

1、敏捷开发流程详解byyangdl1敏捷开发流程?敏捷软件开发核心是迭代式开发，增量交付。?每一次迭代都建立在稳定的质量基础上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每次 迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。?迭代型的方法就是将整个软件生命周期分成多个小的迭代，每一次迭代都由需求分析、设计、实现和测试在内的多个活动组 成，每一次迭代都可以生成一个稳定和被验证过的软件版本。?迭代建议采用固定的周期（1-4 ）周，可以每个迭代周期不一定要相同，但迭代内工作不能完成，应该缩减交付范围而不是延 长周期。1.1 敏捷流程详解图-敏捷流程图1.2 敏捷

2、流程三种角色及其职责ProductOwner （ P0）-产品负责人确保Team做正确的事代表利益相关人（如用户、 市场、管理等），对产品投资 回报负责确定产品发布计划定义产品需求，根据市场价 值确定功能优先级验收迭代结果，并根据验收 结果和需求变化更新需求清 单和优先级除了客户需求之外， 内部任务如重构、持 续集成环境搭建等 也由PO纳入统一管 理ScrumMaster （ SM）-Scrum教练确保Team正确的做事辅导团队正确应用敏捷实践 引导团队建立并遵守规则 保护团队不受打扰 推动解决团队遇到的障碍 保证开发过程按计划进行， 组织站立会，冲刺评审会， 冲刺回顾会议不命令和控制Team

3、Team于发团队负责产品需求实现负责估计工作量并根据自身 能力找出最佳方案去完成任 务且保证交付质量向PO和利益相关人员演示 工作成果（可运行的软件） 团队自身管理、持续改进一般由5-9人左右 跨职能领域人员（开 发人员、测试人员、 设计师等）组成 团队车管员构成在 sprint内不允许变化 有共同的目标、共担 责任团队成员严格遵守 团队规则1.3 敏捷开发流程详解流 程图详解步骤1. 制定产品需求列表?P0收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合理的产品需求列表；2. 召开计划会议?P0召集TM和SM（也可邀请其他利益相关者参加）

4、召开计划会议（发布计划会议和冲刺会议一块开），发布计划主要是说明产品完整交付给客户的计划时间和交付物，? 冲刺计划就是确定该冲刺阶的长度 （建议冲刺长度 1-4 周）、目标和冲刺任务单及其工作量估算 （以理想人天 manday=7.5h 估算，单位为小时计算） ，会议时间建议不要超过 6h 时间；? 在计划会议上就需要进行确认，是否需要使用持续集成；若使用持续集成，团队需要每天下班前至少提交一次私有构建 成功的代码到服务器，并且要求写详细的日志信息；若不使用持续集成，团队每天有完成任务单的情况，都需要在svn上以增量形式发包并通知到相关人员；? 项目计划会议上可以确定每天站立会时间及其规则要求

5、 （建议会议时间在 15-20 分钟左右），每个人回答 3 个问题： 昨天 做了什么，遇到什么问题，今天要做什么。具体问题讨论及其解决，在私下进行沟通，不要在会议上讨论。站立会上只 有TM人员有发言权，其他人员不要干预，SM主要是维护秩序、规则及其引导作用。3. 需求分析、设计、编码和测试：? 计划会议结束后，TM获取各自的冲刺任务单进行后面的需求分析、设计、编码和测试；? 这里特别要说明的是，开发和测试是并行工作，必要的文档还是需要输出（如：讨论次数较多的功能点、备选方案很多 但最后确认一种、重要功能、业务逻辑复杂的等等） 。具体情况，需要项目组根据实际情况决定，但客户要求交付的文档 必须要

6、输出；4. 冲刺任务单和燃尽图更新每天SM需要根据每日站立会上 TM反馈的情况，进行更新冲刺任务单和燃尽图或SM和 TM之间达成共识，TM各自完成后进行更改状态，这里涉及到的文档都会有相对应的模板供参考使用。5. 迭代周期结束点? 已到迭代周期结束点，只有哪些经过测试通过的冲刺需求列表才能算是真正的完成，其他未经过测试或测试不通过的不 能算是完成。? 这里要特别注意，所谓的测试通过不是说要把所有的问题都解决才算是通过，这个要根据项目具体的要求和规定来定。 还没有达到迭代结束点，该冲刺任务需求列表就完成，可以从产品需求列表中挑选优先级高的进行开发。6. 冲刺评审会议? TM需要召开冲刺评审会议，

7、邀请 PO客户或客户代表来参加，由这些客户或客户代表来表决是否满足需求和期望目标。 一般会议时间建议不要超过 2个小时，参加人员除 P0及其相关利益人来参加外， TM全体成员，也可以邀请其他相关人员参加7. 冲刺回顾会议?迭代输岀的增量交付可能会引起原产品需求列表的改变，可能需要更新原产品需求列表；最后TM需要开展本次迭代的好的实践和不足的改进机会，最终稿由SM整理汇总，作为下一次的迭代的经验参考。回顾会议建议时间不用太长，一般15-30分钟即可，全体人员都需要参加，包括： PO SM TM其他相关人员也可以参加。?这里要说明的是在每次的计划会议上要注意安排时间做冲刺评审会议和冲刺回顾会议。下

8、一次迭代的计划会议建议在上一次迭代的冲刺回顾会议结束后再开展。8. 重复2-7步骤?直到所有列入本版本规划的任务单都完成，最后发布版本；?特别说明：通常最后一个迭代可能是全量进行验证的周期，管理结合目前jira进行管理“使用敏捷开发模式的项目”也是很方便。每一个迭代在jira中作为一个版本控制，每个迭代下面的任务单，参照迭代计划预估的时间进行创建，实际工时根据每个人的实际填写日报为准计算。可以考虑安装一款支持jira的敏捷开发插件GreenHopper，完全实现电子版的看板功能和图表功能。在confluence上以项目名称创建项目，然后二级目录是每个迭代名称、产品需求列表，三级目录放每次迭代冲

9、刺评审会议纪要、 冲刺回顾会议纪要、站立会纪要、燃尽图、迭代任务订单。说明：燃尽图使用excel表格式的模板，项目组可以参照使用。度量计划交付任务订单数2614实际交付任务订单数2613价值交付率100%92.85%实际完成率开发任务完成100% （遗留大100% （所有任务完成，量 BUG）BUG清空）计划估算精准度偏差31%=（实际-计划）/计偏差31%=（实际-计划）划/计划开发计划估算精确度偏差20%=（实际开发-计划开偏差20%=（实际开发-发）/计划开发计划开发）/计划开发测试计划估算精确度偏差30%=（实际测试-计划测偏差30%=（实际测试-试）/计划测试计划测试）/计划测试开发测试工时比开发工时：测试工时开发工时：测试工时1515100%100% （遗留2个偶现BUG）偏差31%=（实际-计划）/计划偏差20%=（实际开发-计划开发）/计划开发偏差30%=（实际测试-计划测试）/计划测试开发工时：测试工时测试效率发现有效bug/测试工时发现有效bug/测试工时测试验证一次通过率（按任务单）一次通过任务订单/本迭代预计要完成的任务订单 *100%一次通过任务订单/本迭代预计要完成的任务发现有效bug/测试工时 一次通过任务订单/本 迭代预计要完成的任务订单*100%订单*1