《敏捷开发规程详解1201》由会员分享，可在线阅读，更多相关《敏捷开发规程详解1201（5页珍藏版）》请在金锄头文库上搜索。
1、精心整理敏捷开发流程详解by yangdl1 敏捷开发流程敏捷软件开发核心是迭代式开发，增量交付。每一次迭代都建立在稳定的质量基础上，并作为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每 次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈。迭代型的方法就是将整个软件生命周期分成多个小的迭代，每一次迭代都由需求分析、设计、实现和测试在内的多个活动 组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。迭代建议采用固定的周期（1-4 ）周，可以每个迭代周期不一定要相同，但迭代内工作不能完成，应该缩减交付范围而不是 延长周期。1.1 敏捷流程详解图-敏捷流程图1.2
2、敏捷流程三种角色及其职责Product Owner (PO)-产品负责人确保Team做正确的事代表利益相关人（如用户、 市场、管理等），对产品投资 回报负责确定产品发布计划定义产品需求，根据市场价 值确定功能优先级验收迭代结果，并根据验收 结果和需求变化更新需求清 单和优先级除了客户需求之外， 内部任务如重构、持 续集成环境搭建等 也由PO纳入统一管 理Scrum Master (SM) -Scrum教练确保Team正确的做事辅导团队正确应用敏捷实践 引导团队建立并遵守规则 保护团队不受打扰 推动解决团队遇到的障碍 保证开发过程按计划进行， 组织站立会，冲刺评审会， 冲刺回顾会议不命令和控制T
3、eamTeam -开发团队负责产品需求实现负责估计工作量并根据自身 能力找出最佳方案去完成任 务且保证交付质量向PO和利益相关人员演示 工作成果（可运行的软件） 团队自身管理、持续改进一般由5-9人左右 跨职能领域人员（开 发人员、测试人员、 设计师等）组成 团队车管员构成在 sprint内不允许变化 有共同的目标、共担 责任精心整理团队成员严格遵守团队规则1.3 敏捷开发流程详解1.3.1流程图详解步骤1. 制定产品需求列表P0收集来自客户、市场、领导等渠道的信息，从业务角度和市场价值编制一份按优先级排序的、明确的、可度量的、合 理的产品需求列表；2. 召开计划会议P0召集TM和SM（也可邀
4、请其他利益相关者参加）召开计划会议（发布计划会议和冲刺会议一块开），发布计划主要是说明产品完整交付给客户的计划时间和交付物，冲刺计划就是确定该冲刺阶的长度（建议冲刺长度1-4周）、目标和冲刺任务单及其工作量估算（以理想人天manday=7.5h 估算，单位为小时计算），会议时间建议不要超过 6h时间；在计划会议上就需要进行确认，是否需要使用持续集成；若使用持续集成，团队需要每天下班前至少提交一次私有构建成功的代码到服务器，并且要求写详细的日志信息；若不使用持续集成，团队每天有完成任务单的情况，都需要在svn上以增量形式发包并通知到相关人员；项目计划会议上可以确定每天站立会时间及其规则要求（建议
5、会议时间在15-20分钟左右），每个人回答3个问题：昨天做了什么，遇到什么问题，今天要做什么。具体问题讨论及其解决，在私下进行沟通，不要在会议上讨论。站立会上只 有TM人员有发言权，其他人员不要干预，SM主要是维护秩序、规则及其引导作用。3. 需求分析、设计、编码和测试：计划会议结束后，TM获取各自的冲刺任务单进行后面的需求分析、设计、编码和测试；,-JI这里特别要说明的是，开发和测试是并行工作，必要的文档还是需要输岀（如：讨论次数较多的功能点、备选方案很多但最后确认一种、重要功能、业务逻辑复杂的等等）。具体情况，需要项目组根据实际情况决定，但客户要求交付的文档必须要输出；4. 冲刺任务单和燃
6、尽图更新每天SM需要根据每日站立会上 TM反馈的情况，进行更新冲刺任务单和燃尽图或SM和 TM之间达成共识，TM各自完成后进行更改状态，这里涉及到的文档都会有相对应的模板供参考使用。5. 迭代周期结束点已到迭代周期结束点，只有哪些经过测试通过的冲刺需求列表才能算是真正的完成，其他未经过测试或测试不通过的不能算是完成。这里要特别注意，所谓的测试通过不是说要把所有的问题都解决才算是通过，这个要根据项目具体的要求和规定来定。还没有达到迭代结束点，该冲刺任务需求列表就完成，可以从产品需求列表中挑选优先级高的进行开发。精心整理6. 冲刺评审会议TM需要召开冲刺评审会议，邀请PO客户或客户代表来参加，由这
7、些客户或客户代表来表决是否满足需求和期望目标。一般会议时间建议不要超过 2个小时，参加人员除 P0及其相关利益人来参加外，TM全体成员，也可以邀请其他相关人员参加。7. 冲刺回顾会议迭代输岀的增量交付可能会引起原产品需求列表的改变，可能需要更新原产品需求列表；最后TM需要开展本次迭代的好的实践和不足的改进机会，最终稿由SM整理汇总，作为下一次的迭代的经验参考。回顾会议建议时间不用太长，一般15-30分钟即可，全体人员都需要参加，包括：PO SM TM其他相关人员也可以参加。这里要说明的是在每次的计划会议上要注意安排时间做冲刺评审会议和冲刺回顾会议。下一次迭代的计划会议建议在上 一次迭代的冲刺回
8、顾会议结束后再开展。8. 重复2-7步骤直到所有列入本版本规划的任务单都完成，最后发布版本； I特别说明：通常最后一个迭代可能是全量进行验证的周期，厂L予1.3.2管理结合目前jira进行管理“使用敏捷开发模式的项目”也是很方便。每一个迭代在 jira中作为一个版本控制，每个迭代下面的任务 单，参照迭代计划预估的时间进行创建，实际工时根据每个人的实际填写日报为准计算。可以考虑安装一款支持jira的敏捷开发插件GreenHopper，完全实现电子版的看板功能和图表功能。在confluence上以项目名称创建项目，然后二级目录是每个迭代名称、产品需求列表，三级目录放每次迭代冲刺评审会议纪要、 冲刺
9、回顾会议纪要、站立会纪要、燃尽图、迭代任务订单。说明：燃尽图使用excel表格式的模板，项目组可以参照使用。1.3.3度量计划交付任务订单数261415实际交付任务订单数261315价值交付率100%92.85%100%实际完成率开发任务完成100% （遗留大100% （所有任务完成，100% （遗留2个偶现量 BUG)BUG清空）BUG)计划估算精准度偏差31%=（实际-计划）/计偏差31%=（实际-计划）偏差31%=（实际-计划）划/计划/计划开发计划估算精确度偏差20%=（实际开发-计划开偏差20%=（实际开发-偏差20%=（实际开发-发）/计划开发计划开发）/计划开发计划开发）/计划开
10、发测试计划估算精确度偏差30%=（实际测试-计划测偏差30%=（实际测试-偏差30%=（实际测试-试）/计划测试计划测试）/计划测试计划测试）/计划测试开发测试工时比开发工时：测试工时开发工时：测试工时开发工时：测试工时测试效率发现有效bug/测试工时发现有效bug/测试工时发现有效bug/测试工时精心整理测试验证一次通过率（按任务单）一次通过任务订单/本迭代预计要完成的任务订单 *100%一次通过任务订单/本迭代预计要完成的任务订单*100%一次通过任务订单/本迭代预计要完成的任务订单*100%测试验证一次通过率（按用例）缺陷总数缺陷密度（个/开发工时）缺陷级别1:20:1043测试用例内BUG占比系统测试前后BUG比NA （无单独系统测试）NA （无单独系统测试）系统测试前：系统测试后不良质量成本占比修复bug所耗工时/总工时总工时数800人时团队工作负载100%112%80% （学习其他）
