scrum敏捷模式

1、scrum敏捷开发模式2012年07月24日by wangrb主要内容 什么是敏捷开发 敏捷开发宣言 敏捷开发原则 敏捷实践模式 敏捷中的异味 如何避免异味 采用敏捷的好处 什么是scrum scrum角色 scrum构件 scrum活动 敏捷常见误解 团队合作之道什么是敏捷开发 是一种以人为核心、迭代、循序渐进的增量式开发方法以人为核心、迭代、循序渐进的增量式开发方法 在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征 简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。什么是敏捷开发

2、 常用敏捷开发方法常用敏捷开发方法 XP极限编程(Extreme Programming) Scrum 特征驱动开发(Feature Driver Development) 动态系统开发(Dynamic Systems Development Method) 透明水晶开发(Crystal Clear)什么是敏捷开发 瀑布模型瀑布模型 采用结构化的分析和设计方法 逻辑实现与物理实现分离 按工序将问题简化 固定的、没有弹性 很困难去达到互动 项目周期较长 敏捷方法敏捷方法 完整地开发，每少数几周或是少数几个月里可以测试功能。 强调在获得最简短的可执行功能的部分，能够及早给予企业价值。 在整个项目的

3、生命周期里，可以持续的改善、增加未来的功能。 什么是敏捷开发 瀑布模型瀑布模型 scrum敏捷模型什么是敏捷开发 传统项目管理：传统项目管理： 事先对整个项目进行估计、计划、分析 反对变更; 变更需要重新估计、重新规划 严密的合同来减少风险, 如果改变需求要走 CR 流程. 项目作为一个“黑盒子” ，对客户与供应商的可视性差. 文档和计划驱动的方法. 软件交付时间晚, 意识到风险的时间晚. WBS,甘特图,关键路径分析 敏捷项目管理敏捷项目管理: 对整个项目做一个粗略的估计,每一次迭代都有详细的计划. 鼓励变化, 客户价值驱动开发. 信任和赋予权力;合约使变更变得简单，增加价值. 客户和开发人

4、员之间是紧密的连续的合作关系 每次迭代都产生可交付的软件 专注于交付软件. 第一次迭代就可交付能工作的版本，风险发现的早. 敏捷开发宣言个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划敏捷开发宣言-1 个体和交互胜过过程和工具个体和交互胜过过程和工具 人是软件项目获得成功最为重要的因素 合作、沟通能力以及交互能力比单纯的软件编程能力和工具更为重要 方法和工具是死的，人是活的，人要是太“面”或者协作不好，再强大的方法和工具都是白扯； 敏捷开发宣言-2 可以工作的软件胜过面面俱到的文档可以工作的软件胜过面面俱到的文档 过多的面面俱到的文档往往比过少的

5、文档更糟 软件开发的主要和中心活动是创建可以工作的软件 直到迫切需要并且意义重大时，才进行文档编制 编制的内部文档应尽量短小并且主题突出 敏捷开发宣言-3 客户合作胜过合同谈判客户合作胜过合同谈判 客户不可能做到一次性地将他们的需求完整清晰地表述在合同中 为开发团队和客户的协同工作方式提供指导的合同才是最好的合同 敏捷开发宣言-4 响应变化胜过遵循计划响应变化胜过遵循计划 变化是软件开发中存在的现实 计划必须有足够的灵活性与可塑性 短期的迭代的计划比中长期计划更有效 敏捷开发原则1.最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意2.即使到了开发的后期，也欢迎改变需求。敏捷过程利用

6、变化来为客户创造竞争优势。3.经常性的交付可以工作的软件，交付的时间间隔可以从几周到几个月，交付的时间间隔越短越好4.在整个项目开发期间，业务人员和开发人员必须天天在一起工作敏捷开发原则5.围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能够完成工作。6.在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈（而不是文档）7.工作的软件是首要的进度度量标准。8.敏捷过程提倡可持续开发进度，责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度敏捷开发原则9.不断地关注优秀的技能和好的设计会增强敏捷能力10. 简单化是根本11. 最好的架构、需求和设计

7、出自于自组织的团队12. 每隔一段时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整敏捷实践模式反馈实践模式技术实践模式辅助实践模式敏捷实践模式-反馈实践模式迭代迭代 在一个固定时间周期内，由团队完成系统中一部分功能的开发 设定目标、启动会、演示和回顾启动会启动会 同步团队之间的工作，计划迭代要完成的工作 设定目标，做出承诺待办工作事项待办工作事项 需要完成的工作即需求，有优先级规划规划“扑克扑克” 快速估计实现需求所要付出的工作量站立会议站立会议 迭代中的见面交流会：完成了什么，要做什么，有什么问题 一般不超过15分钟敏捷实践模式-反馈实践模式完成状态完成状态 迭

8、代中每个需求的完成目标以及对完成的定义 尽可能的接近部署或发布演示演示 迭代结束是向项目的相关负责人进行系统功能展示回顾回顾 迭代结束或者发布后举行，总结经验，优化流程频繁发布频繁发布 条件允许的情况下，尽可能经常的发布软件给用户 前提需要做到持续集成“联合驻扎联合驻扎”团队团队 团队成员在同一个物理空间工作，便于相互交流敏捷实践模式-反馈实践模式自组织团队自组织团队 不需要外部过多的指导和干预，团队成员自己推进目标的实现 需要经常回顾改进工作方法，提升团队的效率跨职能团队跨职能团队 类似外科手术团队，具备完成一个系统所需要的各种成员 scrum团队客户作为团队成员客户作为团队成员 客户加入团

9、队一起工作，需要客户对所需要解决的业务问题理解非常透彻唤醒式文档唤醒式文档 唤起人们的记忆，比传统的文档更有意义 花更多的时间进行面对面的交流，较少的时间编写和维护文档敏捷实践模式-反馈实践模式用户故事用户故事 为需求创建一个唤醒式文档，对需求的概要描述 一般包括需求描述以及完成定义用例用例 描述对客户有重要价值的业务流程 描述系统行为的一种需求表现形式信息辐射器信息辐射器 提高透明度，便于信息的交流 重要数据、进度、问题等敏捷实践模式-技术实践模式自动化测试自动化测试 测试可被轻松的执行 促进系统设计不断的趋向于松耦合测试后行开发测试后行开发 开发完代码后再进行测试测试先行开发测试先行开发

10、先编写测试，然后开发产品代码 必须有良好的设计，结构松耦合重构重构 保持系统原有功能的同时，改进系统设计和代码结构 发现问题，马上动手，经常性的重构敏捷实践模式-技术实践模式持续集成持续集成代码变更提交后，执行完整的构建、集成运行并通过所有的测试简单设计简单设计设计复杂程度满足当前需求即可，不要画蛇添足持续改进设计功能测试功能测试满足客户验收需求的测试确保系统输出使用户所想要的集体代码所有权集体代码所有权开发团队中的任何人都有权利和责任修改任何一部分代码结对编程结对编程两个人一起工作，相互合作，提升产品质量，减少对专家的依赖敏捷实践模式-辅助实践模式教练教练 有经验的敏捷开发实践者，作为顾问加

11、入团队，帮助团队进步融入敏捷社区融入敏捷社区 获取知识、建议和经验的地方读书会读书会 大家一同学习、分享一本好书研讨会研讨会课堂培训课堂培训敏捷中的异味僵化：僵化： 很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动脆弱：脆弱： 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。牢固：牢固： 很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。粘滞：粘滞： 做正确的事情比做错误的事情要困难。敏捷中的异味复杂：复杂： 设计中包含有不具任何直接好处的基础结构。重复：重复： 设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。晦涩：晦涩： 很

12、难阅读、理解。没有很好地表现出意图如何避免异味单一职责原则（单一职责原则（SRP) 就一个类而言，应该仅有一个引起它变化的原因。开放开放-封闭原则（封闭原则（OCP) 软件实体应该是可以扩展的，但是不可修改。里氏替换原则（里氏替换原则（LSP) 子类型必须能够替换掉它们的基类型。如何避免异味依赖倒置原则（依赖倒置原则（DIP) 抽象不应该依赖于细节。细节应该依赖于抽象。接口隔离原则（接口隔离原则（ISP) 不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。重用发布等价原则（重用发布等价原则（REP) 重用的粒度就是发布的粒度。如何避免异味共同封闭原则（共同封闭原则（C

13、CP) 包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。共同重用原则共同重用原则(CRP) 一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。如何避免异味无环依赖原则（无环依赖原则（ADP) 在包的依赖关系图中不允许存在环。稳定依赖原则（稳定依赖原则（SDP) 朝着稳定的方向进行依赖。稳定抽象原则（稳定抽象原则（SAP) 包的抽象程度应该和其稳定程度一致。采用敏捷的好处缩短产品上市时间增强产品实用性提高产品质量提高灵活性增强透明度降低成本延长产品生命周期业务价值是组织的目

14、标.什么是scrum是一种敏捷开发框架，一个迭代式、增量开发过程，属于敏捷开发的一种，它由一个开发过程、几种角色以及一套规范的实施方法组成： 角色：product owner，scrum master，scrum team，stake holder 构件：product backlog，sprint backlog，burn-down chart 活动：sprint planning meeting，daily standup meeting，sprint review meeting，retrospective meetingscrum敏捷流程scrum角色-product ownerpro

15、duct owner 产品利益相关方的代表，负责产品相关业务，给出明确的、可度量的、合理的产品backlog职责： 确定产品的功能。 决定发布的日期和发布内容。 为产品的profitability of the product (ROI)负责。 根据市场价值确定功能优先级。 每个Sprint，根据需要调整功能和优先级（每个Sprint开始前调整）。 接受或拒绝接受开发团队的工作成果。 scrum角色-scrum masterscrum master 为scrum过程负责的人，整个团队的导师和组织者，确保scrum的正确使用并使得Scrum的收益最大化职责职责 保证团队资源完全可被利用并且全部是

16、高产出的。 保证各个角色及职责的良好协作。 解决团队开发中的障碍。 做为团队和外部的接口，屏蔽外界对团队成员的干扰。 保证开发过程按计划进行，组织每日站立会议、演示会、回顾会scrum角色-scrum teamscrum team 自组织的跨职能团队，以完成目标为己任职责职责 一般情况下人数在5-9个左右 团队要跨职能 （包括开发人员、测试人员、用户界面设计师等） 团队成员需要全职（有些情况例外，比如架构师） 在项目向导范围内有权利做仸何事情已确保达到Sprint的目标 高度的自我组织能力 向Product Owner演示产品功能 团队成员构成在sprint内不允许变化scrum角色- sta

17、ke holdern项目组有关的成员,但并不专注于项目n以观察者的形式参加Scrum meeting火腿鸡蛋！三思过后我决定不和你开餐馆了。因为我全身心投入，而你只牵涉入内！scrum构件-product backlog一个关于产品的需求列表。 一般情况使用用户故事(user story)来表示backlog条目 backlog条目按照商业价值排列优先级，理想情况每个需求项都对产品的用户有价值，优先级由产品负责人来排列 在每个Sprint结束的时候要更新优先级的排列 scrum构件-sprint backlog一次迭代计划要完成的需求，来自product backlog进入sprint bac

18、klog的需求都是清楚的，没有歧义每个需求已有团队成员认领，并估计了完成工作量每项sprint backlog有合理的任务拆解，有些任务可以并行scrum构件-burn-down chartscrum活动-计划会scrum活动-计划会计划会议要有足够的时间，至少4个小时 取出部分产品需求做成sprint需求，并制成卡片 确定并细分每一个卡片的故事（Story） 通过认领分配工作 确定每日站立会议的时间和地点 确定好演示会议和回顾会议的日期 scrum活动-站立会议团队每日例会，在同样的时间和地点举行，所有成员站立开会 最好每日上班开始或者临近下班时开，一般15分钟左右，严格控制时间只有团队成员可以在例会上发言，其他人员有兴趣可以参加，但只能旁听，不能发言 每日Scrum会议由Scrum Master主持， Scrum团队所有成员轮流回答以下3个问题： 昨天我完成了什么工作？ 今天我打算做什么？ 我在工作中遇到了什么困难？ 更新燃尽图 scrum活动-演示会演示会用来演示在这个Sprint中开发的产品功能给Product Owner. Product Owne