文档介绍：敏捷开发分享篇演示文稿
1页，共28页，星期四。
敏捷开发分享篇
2页，共28页，星期四。
二. 敏捷核心价值&原则
三. 敏捷大致流程
一. 什么是敏捷开发？
四.
提纲
五. 给敏捷28页，星期四。
二. 敏捷12条原则
6、在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
理解：在十几或者二十几个人组成的大团队中，文档是一种比较合适的传递知识和交流的途径。而敏捷团队一般不会很多人（大团队实施敏捷时也会分成多个小的敏捷团队），所以大量的文档交流其实并不是很经济的做法。此时面对面的交谈反而更快速有效。
14页，共28页，星期四。
二. 敏捷12条原则
7、 工作的软件是首要进度度量标准。
理解：衡量这个功能是否完成的首要标准就是这个功能可以工作了，对用户来说已经可以应用了。(关键点： 完成标准要明确好，最好是可工作的软件）
15页，共28页，星期四。
二. 敏捷12条原则
8、敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
理解：
很多人都认为软件开发中加班是很正常的，不加班反而不正常。敏捷过程应该摒弃拼拼的态度，下一个项目依旧会让你的组员再次突击。这时不知道有人会不会说，那我们就一直加班，也是“持续的开发速度”啊，这时可要注意了，持续加班只会导致人疲劳、厌倦，保持长期恒定的速度也只是一种理想而已。 （关键点：sprint周期要恒定，任务安排要合理）
16页，共28页，星期四。
二. 敏捷12条原则
9、不断地关注优秀的技能和好的设计会增强敏捷能力。
理解：通过回顾总结，保留项目一些好的经验技能。通过一些好的技术实践可以加强产品敏捷能力，很多原则、模式和实践也可以增强敏捷开发能力。
17页，共28页，星期四。
二. 敏捷12条原则
10、简单----使未完成的工作最大化的艺术----是根本的。
理解：通过最简单的方法完成现在需要解决的问题
18页，共28页，星期四。
二. 敏捷12条原则
11、 最好的构架、需求和设计出自自组织的团队
理解：
自组织团队的第一个要素就是必须有一个团队，而不仅仅是一群人，更不是一个团伙。团队，共同完成一个伟大的使命；自我管理；高效完成
19页，共28页，星期四。
二. 敏捷12条原则
12、 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
理解：持续改进
20页，共28页，星期四。
三. 敏捷大致流程
1. 什么是Scrum？
敏捷流程有Scrum和xp。我们公司采用的是Scrum。Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。
2. Sprint：一个Sprint就是一个迭代，从Sprint计划会议开始到Sprint回顾会议结束为一次迭代。Sprint有严格的时间控制，一般每次Sprint的周期为2-4周，时间到了Sprint就结束。
21页，共28页，星期四。
三. 敏捷大致流程
3. 三种角色
【PO】产品负责人（Product Owner）
负责维护产品待办事项列表，确保每个成员明晰列表内容、明确哪些条目具有最高优先级，从而了解下个需要开发的条目。PO是非常重要的角色，他对客户需求有着很强的敏感性，清楚什么对客户最重要，做到什么程度能让客户满意，在TEAM遇到需求问题时都能给出解答或决策。
【SM】 Scrum Master负责确保Scrum团队遵守Scrum价值、实践和规则；帮助Scrum团队和整个组织实施Scrum；通过指导和引导，教授Scrum团队更高效工作、生产出高质量的产品；帮助Scrum团队理解并采用自我管理 ---（教练）。
【TEAM】团队负责在每个迭代将产品待办事项列表转化成为潜在可交付的功能增量。TEAM是自管理的，有实际的自主权，文化上要符合，基于激发人的主动性、避免受外界干涉。他们完全有权决定如何把需求转化成产品功能，比如是否要做设计，采用什么算法，如何做缺陷预防等。PO和SM都无权指挥TEAM怎么去实现需求，但TEAM必须承诺交付的功能是PO期望的。
22页，共28页，星期四。
三. 敏捷大致流程-如何进行Scrum开发？
Sprint 计划会议
1. 迭代计划会在每个迭代第一天召开
2. 理解最终用户到底要什么
3. 目的是选