经验分享敏捷开发流程ppt课件.ppt

《经验分享敏捷开发流程ppt课件.ppt》由会员分享，可在线阅读，更多相关《经验分享敏捷开发流程ppt课件.ppt（24页珍藏版）》请在三一办公上搜索。

1、经验分享敏捷开发流程,1,敏捷开发流程介绍,经验分享敏捷开发流程,2,目录,什么是软件开发方法什么是敏捷开发方法我们该采用什么方法,经验分享敏捷开发流程,3,什么是软件开发方法,软件开发定义 根据用户需求建造出软件系统的产品开发过程。包括需求获取、开发规划、需求分析和设计、编程实现、软件测试、版本控制。-维基百科,常见种类瀑布式开发迭代式开发敏捷式开发,经验分享敏捷开发流程,4,瀑布式开发,最典型的预见性方法，严格遵循预先计划按照需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果用以衡量进度，例如需求规格，设计文档，测试计划等，方便定义里程碑主要问题是严格分级导致自由度降低，早期承

2、诺导致对后期需求变化难以调整，代价高昂,经验分享敏捷开发流程,5,迭代式开发,弥补传统开发方式的一些弱点，具有更高的成功率和生产率开发被分为一系列的小的、固定长度的小项目，称为一系列的迭代。每次都包括需求分析、设计、实现与测试。开发工作可在需求被完全确定前启动，并在一次迭代中完成部分功能。再通过客户反馈来细化需求，开始新一轮迭代。,经验分享敏捷开发流程,6,Agile software development,什么是敏捷开发方法,主要原则：个体和互动：高于流程和工具工作的软件：高于详尽的文档客户合作：高于合同谈判响应变化：高于遵循计划,vs迭代：都强调在短的开发周期提交软件，敏捷的周期可能更短

3、，更强调人的高度协作,vs瀑布：敏捷强调尽早将小的可用功能交付使用，在项目周期中持续改善，自由度高,主要方法：极限编程测试驱动开发Scrum机制看板文化,经验分享敏捷开发流程,7,极限编程,Extreme programming，缩写为XP，强调可适应性而不是可预测性认为软件需求变化是自然现象在项目周期的任何阶段去适应变化，降低因需求变更而带来的成本,快速反馈：对客户反馈做到及时、迅速，重视单元测试假设简单：认为任何问题都可以“极度简单”地解决，拒绝预测需求，拒绝为了未来而考虑重用 增量变化：一次完成大的改造是不可能的，采用增量变化，小步前进包容变化：强调不反抗变化，应该包容变化,经验分享敏捷

4、开发流程,8,测试驱动开发,Test-Driven Development，简称TDD。它要求在编写代码之前先写测试代码，只编写使测试通过的功能代码，通过测试来推动整个开发的进行。编写简洁可用和高质量的代码，并加速开发过程。（FDD,DDD）,根据客户需求编写测试用例，从使用者角度设计代码易测试和测试独立性的要求使设计松耦合频繁地运行测试，尽早地发现错误，提高代码质量持续的回归测试，持续地跟踪整个系统的状态单元测试代码可作为文档，展示所有的API该如何使用和运作,经验分享敏捷开发流程,9,主要角色：Scrum Master：Scrum教练和团队带头人，确保团队合理的运作Scrum产品负责人（P

5、roduct Owner）:确定产品方向，定义产品内容、优先级及交付时间开发团队（Team）:跨职能的小团队（5-9人），拥有交付软件需要的各种技能,一种迭代式增量软件开发过程，包括了一系列实践和预定义角色的过程骨架，通常用于敏捷软件开发。英语是橄榄球中争球的意思,Scrum,经验分享敏捷开发流程,10,Scrum过程总览,经验分享敏捷开发流程,11,Scrum阶段1：制定产品Backlog,产品 backlog 是 Scrum 的核心由需求或特性等组成的列表用客户的术语加以描述按照重要性的级别进行排序backlog 条目称为故事（story）每个故事包括如下字段：ID(统一标识符)Name（

6、名称）Importance（重要性）Initial estimate（初始估算工作量）How to demo（如何做演示）Notes（注解）Bug tracking ID（Bug 跟踪 ID）,经验分享敏捷开发流程,12,独立基本相当于一个feature对客户有价值易于评估时间和难度不易太大或太小可测试,Story的准则,-,+,+,+,Value,Risk,Low,High,High,优先级评估,经验分享敏捷开发流程,13,工作量的估算,最小单位为一个故事点（story point），相当于一个理想的人天投入最适合的人员，完全没有打扰，需要几天给出一个经过验证，可以交付的完整实现不需要绝对无

7、误，保证相对准确（即:两个点的时间应该是四个点的一半）估算全部工作，而不只是自己的部分把故事分拆成更小的故事以达到更精确最小值是 0.5，太小的任务要么被移除，要么就给 0.5,经验分享敏捷开发流程,14,Scrum阶段2:制定Sprint Backlog,sprint 目标团队成员名单（以及投入程度）确定sprint backlog（即 故事列表）确定好 sprint 演示日期确定每日 scrum 会议时间地点协商sprint的时间长度,经验分享敏捷开发流程,15,召开Sprint 会议,Sprint 计划会议：13:00 17:00（每小时休息 10 分钟）13:00 13:30 产品负责

8、人对 sprint 目标进行总体介绍，概 括产品 backlog。定下演示的时间地点。13:30 15:00 团队估算时间，在必要的情况下拆分 backlog 条目。产品负责人在必要时修改重要性评分。理清每个条 目的含义。所有重要性高的 backlog 条目都要填写“如何演 示”。15:00 16:00 团队选择要放入 sprint 中的故事。计算生产率，用作核查工作安排的基础。16:00 17:00 为每日 scrum 会议安排固定的时间地点，把故事进一步拆分成任务。,经验分享敏捷开发流程,16,确定Sprint生产力,如果没有参考怎么办？随便猜一个，只会在第一个 sprint 里面使用，以

9、后有了历史数据然后做改进。新团队中使用的“默认”投入程度通常是 70%，大多数团队都能达到的数值。,经验分享敏捷开发流程,17,Scrum阶段3：每天站会,经验分享敏捷开发流程,18,看板和站会,用户体验比投影仪好，大家保持清醒，并留心会议进展，更多的参与感多个故事可以同时编辑重新划分优先级变得易如反掌挪动索引卡就行互相看到,所有人都可以看到彼此，都能看到任务板例会结束时算出剩余工作量之和，在 sprint 燃尽图上画上一个新的点处理迟到，惩罚机制,经验分享敏捷开发流程,19,看板,经验分享敏捷开发流程,20,燃尽图,经验分享敏捷开发流程,21,Scrum阶段4：Sprint演示,清晰阐述 s

10、print 目标不要花太多时间准备演示，集中精力演示实际工作的代码节奏要快，保持演示的快节奏关注业务层次，不要管技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”可能的话，让观众自己试一下产品不要演示一大堆细碎的 bug 修复和微不足道的特性,经验分享敏捷开发流程,22,Scrum阶段5：Sprint总结,设定时间为 1 至 3 个小时参与者：产品负责人，整个团队向大家展示 sprint backlog，对sprint 做总结每个人轮流发言，讲出自己的想法，什么是好的，哪些可以更好，哪些需要在下个 sprint 中改变对预估生产率和实际生产率比较，差异大的话，分析原因对建议进行总结，得出下个 sprint 需要改进的地方,经验分享敏捷开发流程,23,我们该采用什么流程？,学习敏捷对沟通的重视，对项目状态的紧密跟踪学习瀑布对于设计和文档的重视学习测试驱动开发对于测试的重视,经验分享敏捷开发流程,24,此课件下载可自行编辑修改，供参考！感谢您的支持，我们努力做得更好！,