Scrum敏捷开发模式讲解ppt课件.pptx

《Scrum敏捷开发模式讲解ppt课件.pptx》由会员分享，可在线阅读，更多相关《Scrum敏捷开发模式讲解ppt课件.pptx（73页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Scrum 敏捷敏捷目录 Scrum概览 Scrum中的角色和关键原则 Scrum流程：策划、执行跟踪、回顾 几个应用主题（发布周期、度量、大团队） We Need Scrum? 产品投放市场的时间太慢 项目失败的比例高的离谱 投资回报低，经常失败 对变化与变更的响应，难度大且成本高 客户体验及客户为导向很差 软件质量不过关 生产力需要大幅提高 员工士气，动力及责任感很低 需要普遍的微观管理 人员流失率特别高.许多企业面临的问题与挑战越来越多的企业使用Scrum解决这些问题 Google IBM Nokia Siemens Philips Accenture Sun UbisoB Bleum

2、SAP Microsoft Infosys Oracle Wipro Motorola Yahoo! Schneider Agilent Irdeto Double Click Autodesk Tencent Plenware Trendmicro Moodys StarCite哪些类型的项目已经在使用Scrum大型企业级软件项目商业软件产品消费者软件项目/大型网站美国FDA批准的应用于X射线和MRI的软件高可靠性系统（99.9999以上）财务支付系统智能家居项目战斗机项目大型数据库应用嵌入式电信系统手机项目CMMI5级的组织多地点同步开发支撑和维护项目非软件项目 Scrum在Yahoo！的

3、应用(引Scrum中文网)Yahoo! 在全球有超过200个团队（超过两千人）使用Scrum面向用户的项目关键的基础设施项目分布式项目全新产品开发维护型项目这份调查的数据是在Yahoo!采纳Scrum后18个月时采集反映80个团队的情况采用匿名方式得到84%的调查响应率与传统方法的对比：团队生产力与传统方法的对比：士气与传统方法的对比：责任感与主人翁意识与传统方法的对比：协调与合作与传统方法的对比：交付质量有多少人愿意继续使用Scrum下一章节目录 Scrum概览 Scrum中的角色和关键原则 Scrum流程：策划、执行跟踪、回顾 几个应用主题（发布周期、度量、大团队） We Need Scr

4、um?敏捷价值观之敏捷宣言（认同）过程和工具完备的文档合同谈判遵循计划重于重于重于重于个体与交互可用的软件客户协作响应变化什么是Scrum？（ 一个轻量级的软件开发方法一个轻量级的软件开发方法 ）Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。1. Scrum中项目整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。2. 使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事（UserStory）。3. 团队从产品Backlog中挑选最有商业价值的

5、需求，需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。4.在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。Scrum框架流程Scrum框架组成3三个角色 产品负责人Scrum Master团队Sprint计划会议每日站会Sprint评审会议Sprint 回顾会议四个仪式 3三个产物产品BacklogSprint Backlog 个角色燃尽图Scrum使用的几个原则 不同类型/背景的项目需要不同的管理方法 以项目成果为导向而不是过程导向 衡量项目成功与否，要看重项目成果的商业价值和ROI（投资回报），而非仅超支

6、、延期、遵循计划 20/80法则，最大可能满足涉众核心需要 及时让涉众参与，并及早展现项目进展和成果，及时调整，确保交付商业价值最大化Scrum特点 适于在不确定性高的环境中开发复杂产品； 简洁但有效； 易于学习和掌握； 能够在开发进程中不断检查，并作出相应调整； 项目信息对所有干系人高度透明； 便于快速发现问题，促使团队和组织持续改进；Scrum中的角色 Scrum Master 项目经理 ？教练 ？QA？ Product Owner 产品经理？ Team团队构成 7人，+ or - 2 偏小一些会更合适 应100%投入到迭代中 最好坐在一起 角色交叉 包含增量开发产品所需的所有技能 开发、

7、测试、UI设计、技术文档编写 团队基于技能而不是“岗位”来认领工作团队管理模式 自我管理和自我组织 团队决定要完成的工作量，相互协作进行任务管理和执行，以实现承诺的目标 只有团队失败而没有个人失败的原则Scrum软件项目分析，优点。 你有5个月时间可用；你要交付5个特性；每个月，你有100人日可用每个特性需要20人日设计、40人日开发、20人日测试、20人日返工（解决bug、优化）商业价值40单位24单位20单位12单位4单位100单位特性F1F2F3F4F5总计传统模式 根据第一页给出的信息，计算每个阶段的时间长度（考虑实际团队情况，不完整），在下图中标识出阶段划分。M1M2M3M4M5Sc

8、rum模式 根据第一页给出的信息，计划一下你的开发进度（团队拆分，细节把握，提高质量）M1M2M3M4M5下一章节目录 Scrum概览 Scrum中的角色和关键原则 Scrum流程：站会、策划和回顾 几个应用主题（发布周期、度量、大团队） We Need Scrum?Scrum Master SM帮助团队学习和应用Scrum来实现商业价值 SM尽其所能帮助团队获得成功 服务团队 保护团队 引导大家有效应用Scrum SM不是团队的“老板” 不负责为团队分配任务 不会帮团队做决定 不对团队及时完成工作负责Scrum Master做什么事情？ 服务团队 帮助团队排除障碍和问题（“绊脚石”） 促进协

9、作，包括团队内、团队和Product Owner间 保护团队 保护团队，使之免收外界干扰或威胁 教导团队 帮助团队和PO改进工作的有效性 帮助团队和PO 面对并解决困难和问题 引导Scrum的有效应用 把Scrum教给团队、PO和整个公司 确保所有标准Scrum实践得到遵循Scrum Master的选择 高效高效SM的特征的特征对团队的成功有高度的责任心良好的人缘、良好的沟通技能敏感、好的聆听者积极、乐于助人技术专家，会更有帮助但非必要 专职专职SM会有最好的成果会有最好的成果 如果不能专职，必须有一位成员担当这个角色（相应降低他的原工作负担） 避免让团队行政管理者做避免让团队行政管理者做 做

10、做SM 因为大家会指望原管理者来作规划，也就很难做到自我管理Product Owner 负责最大化项目ROI（投资回报） 实现手段： 多方收集意见，充分了解机会和风险； 确定清晰、一致的愿景及目标，明确为实现最大商业价值所需做的事情； 制订一个需求表，按照优先级列出特性和功能； 积极参加迭代计划和迭代回顾会议，在迭代中为团队提供支持； 基于日常观察和学习，持续精炼和优化PB； 对PB优先级有最终决策权Scrum给团队管理者带来哪些变化 第1步：列出管理者过去负责的事项列表（尽可能列全） 第2步：勾掉列表中： 与Scrum冲突的； 在Scrum中不必要的； 对实现团队自我管理有不良影响的；管理者

11、2.0 第3步：帮助管理者按照以上步骤，梳理一份新的工作说明； 第4步：与管理者的上级和HR沟通，争取理解和支持；迭代中不允许变更 禁止变更交付件和交付日期 一旦团队作出承诺，就不允许变更交付件 如果发生重大变化，PO可以中止当次迭代 在迭代中会出现“分解”和“澄清”，但是不允许添加新工作，或者对现有工作进行“实质变更” “变更”vs“澄清” 如果存在争议，那么将其认定为变更，放到PB中，下一次迭代再考虑。 在我们实际应用中，将较低级别的需求剔除掉。变更的影响在迭代期间，如果PO增加只需要少量工作的工作项，或替换部分工作项，会有什么影响？当前迭代当前迭代今后的迭代今后的迭代团队交PO满 付承诺

12、意度 项的能力团队对交付件的承诺PO不提变更的自律PO写PB的规则团队对 团队遵 其它团要交付 循其它 队遵循承诺内 Scrum Scrum容的关 规则的 规则的注度 自律性 自律性PO用户故事 用户故事是写PB的好方法之一； 用户故事是简短、明确的功能说明，按照用户价值和用户需要编写。迭代计划会议 团队确定在迭代结束时，能完成多少PB 对于2周迭代的项目，会议一般花3-4小时 分两部分（同一天内，连续） 第一部分 （PO召开需求评审会） ：团队评审PO想要的东西，然后与PO确认“完成”的定义 第二部分(团队拆分需求，打扑克牌)：团队决定承诺完成多少，以及如何实现承诺。迭代策划第一部分 PO介

13、绍PB中最优先PB项的细节 团队提出问题、建议，就疑问进行确认 协商对PB需要做的修改 团队驱动项增加到PB中 大粒度项拆分 任何其它提炼和优化 团队和PO评审标准的“完成定义”，就所有修订达成一致“完成”定义在迭代结束时，要“完成”的功能，必须完成以下步骤：1 开发规格说明书2 开发规格说明书评审3 开发完成4 代码review5 单元测试完成6 测试用例完成7 测试用例评审8 测试执行报告9 已提交至测试集成 缺陷标准： 不允许P1 P2缺陷，P3缺陷小于3个达到“完成”不太好的方式达到“完成”更好的方式迭代策划第二部分 团队开始将PB项分解为工作任务，并且估计需要的时间 对照团队可用资源

14、，团队承诺本迭代完成量，确保工作量适当 所有团队成员都参与会议和讨论，无论经验多少及能力高低计划纸牌燃尽图每日Scrum会议 会议目的： 保持团队内部协调顺畅，相互之间进展明晰 每天暴露困难和障碍，非团队监管 如何开展： 在Task白板处，每个工作日举行，团队所有成员参加（开会时间到，不等待其他成员，小组自定义惩罚措施。） 围成一个圈，面向圆心（而非SM） 行政管理者最好回避 每个人汇报3件事（也可以做一些调整） 会议中不允许讨论（如果确实必要，简洁一点）每日Scrum会议 Master任务： 记录并现场解答跟踪问题。 更新燃尽图。 团队个人(每个人1-3分钟陈述，讲给团队) 昨天完成的Tas

15、k。 今天将认领的Task。 需要协助解决的问题。白板迭代回顾（回顾会议） 迭代回顾的目的：产品检查和适应 参与者：团队、PO、SM、各职能组leader、其他涉众； 参考方式： 演示产品，验证迭代期内的承诺完成内容。相关人员一起讨论产品与“完成标准”的偏差。 团队向PO提出产品相关议题，或迭代中碰到的问题（例如：在后续迭代中需要解决的技术问题） PO向团队提出产品相关议题，或迭代中碰到的问题（例如：市场变化、用户新需求等）迭代总结(总结报告上传至WIKI,统一管理) 迭代总结的目的：团队工作方式检查和自适应 参考方式： 每次迭代回顾后召开，1-2小时 团队、SM参加 管理者和PO应参加，但只

16、部分时间参与，团队需要内部交谈时间 通常会邀请一位中立人员来担当会议协调人 讨论四个主题哪些做得好那些需要改善（不太好的）需要在以后尝试的事情（今后迭代中改善）要上报的问题（向管理者）迭代总结记录下一章节目录 Scrum概览 Scrum中的角色和关键原则 Scrum流程：策划、执行跟踪、回顾 几个应用主题（发布周期、度量、大团队） We Need Scrum?Scrum 中的发布周期中的发布周期Scrum发布周期 两种常见方法： 多次迭代发布： 每次迭代发布：顶层设计和架构调研，开发环境安装多次迭代发布方法之一发布前发布前SPRINT最终稳定和发布准备多次迭代发布方法之一在项目接近结束时，缩短

17、迭代期，以更快地检查/适应简介：简介：Scrum和度量和度量Scrum和度量 Scrum不会阻止你跟踪或测量你所实施的开发过程； 不过，你必须当心测量的可能不良后果 比如：个人燃烧图 测量的记录和汇报可能需要花费资源 如果确实需要消耗团队资源，应该让这些消耗在任务时间估计时明确出来，或作为一个PB或SB项常用度量 进度差异对比 用实际速度比较估计速度； 工作量差异对比 任务汇总成本（跟踪本身的工作量，及可能引发的问题和数据作弊）； 实际消耗时间 vs 预计消耗时间； 挣得值（已实现商业价值） 商业价值燃烧图简介：简介： ：Scrum自适应自适应-如何应用于不同规模组织如何应用于不同规模组织Scrum自适应 50人规模（分析师、设计师、开发、测试、文档等）Scrum自适应方法1：多团队共用一份PB方法2：多团队按照独立PB工作Scrum自适应Scrum自适应迭代期间每天/每周2-3次协调、相关性管理、问题暴露简介：简介：Scrum和和CMMI如何提高实施Scrum的成功率1、高质量的培训2、积极的管理层支持及随时关注3、清晰的高管层与组织层面的认可4、教练辅导与咨询；5、真正落实Scrum实施的纪律与承诺The End！