Scrum精讲.ppt

《Scrum精讲.ppt》由会员分享，可在线阅读，更多相关《Scrum精讲.ppt（89页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、目录 Scrum概览 Scrum中的角色和关键原则 Scrum流程：策划、执行跟踪、回顾 几个应用主题（发布周期、度量、大团队）非敏捷 - 瀑布式开发 软件开发的经典模型传统项目流程瀑布模型的主要缺陷：程序的维护成本会越来越高（需要很多人）团队氛围压抑（感受不到激情）不方便做需求变更（引起客户不满）需求，设计阶段的问题开发，维护阶段的问题什么是Scrum？PB几个原则 不同类型/背景的项目需要不同的管理方法 以项目成果为导向而不是过程导向 衡量项目成功与否，要看重项目成果的商业价值和ROI，而非仅超支、延期、遵循计划 20/80法则，最大可能满足涉众核心需要 及时让涉众参与，并及早展现项目进展

2、和成果，及时调整，确保交付商业价值最大化敏捷开发宣言个体和交互胜于过程和工具可以工作的软件胜于面面俱到的文档客户合作胜于合同谈判响应变化胜于遵循计划Scrum特点 适于在不确定性高的环境中开发复杂产品； 简洁但有效； 易于学习和掌握； 能够在开发进程中不断检查，并作出相应调整； 项目信息对所有干系人高度透明； 便于快速发现问题，促使团队和组织持续改进；Scrum中的角色 Scrum Master 项目经理 ？教练 ？QA？ Product Owner 产品经理？ Team团队构成 7人，+ or - 2 偏小一些会更合适 应100%投入到迭代中 最好坐在一起 角色交叉 包含增量开发产品所需的所

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

4、目的不确定性减少20%100%80%60%40%20%0M1M2M3M4M5商业价值对比 当一个特性完成设计、开发和测试之后，你就实现了75%的潜在商业价值； 当一个特性完成设计、开发、测试和返工之后，你就实现了100%的潜在商业价值； 用蓝笔画出Scrum项目的商业价值曲线1009080706050403020100M1M2M3M4M5目录 Scrum概览 Scrum中的角色和关键原则 Scrum流程：站会、策划和回顾 几个应用主题（发布周期、度量、大团队）鸡和猪的经典故事Scrum角色Scrum Master SM帮助团队学习和应用Scrum来实现商业价值 SM尽其所能帮助团队获得成功 服

5、务团队 保护团队 引导大家有效应用Scrum SM不是团队的“老板” 不负责为团队分配任务 不会帮团队做决定 不对团队及时完成工作负责Scrum Master做什么事情？ 服务团队 帮助团队排除障碍和问题（“绊脚石”） 促进协作，包括团队内、团队和Product Owner间 保护团队 保护团队，使之免收外界干扰或威胁 教导团队 帮助团队和PO改进工作的有效性 帮助团队和PO面对并解决困难和问题 引导Scrum的有效应用 把Scrum教给团队、PO和整个公司 确保所有标准Scrum实践得到遵循Scrum Master的选择 高效高效SM的特征的特征对团队的成功有高度的责任心良好的人缘、良好的沟

6、通技能敏感、好的聆听者积极、乐于助人技术专家，会更有帮助但非必要 专职专职SM会有最好的成果会有最好的成果 如果不能专职，必须有一位成员担当这个角色（相应降低他的原工作负担） 避免让团队行政管理者做避免让团队行政管理者做SM 因为大家会指望原管理者来作规划，也就很难做到自我管理Product Owner 负责最大化项目ROI（投资回报） 实现手段： 多方收集意见，充分了解机会和风险； 确定清晰、一致的愿景及目标，明确为实现最大商业价值所需做的事情； 制订一个需求表，按照优先级列出特性和功能； 积极参加迭代计划和迭代回顾会议，在迭代中为团队提供支持； 基于日常观察和学习，持续精炼和优化PB； 对

7、PB优先级有最终决策权迭代中不允许变更 禁止变更交付件和交付日期 一旦团队作出承诺，就不允许变更交付件 如果发生重大变化，PO可以中止当次迭代 在迭代中会出现“分解”和“澄清”，但是不允许添加新工作，或者对现有工作进行“实质变更” “变更”vs“澄清” 如果存在争议，那么将其认定为变更，放到PB中，下一次迭代再考虑。变更的影响在迭代期间，如果PO经常增加工作的工作项，或替换部分工作项，会有什么影响？当前迭代当前迭代今后的迭代今后的迭代团队交PO满 付承诺意度 项的能力团队对交付件的承诺PO不提变更的自律PO写PB的规则团队对 团队遵 其它团要交付 循其它 队遵循承诺内 Scrum Scrum容

8、的关 规则的 规则的注度 自律性 自律性Product Backlog优先级优先级1234567说明说明让所有用户能把书装入购物车（模拟品和相关细节在此）升级交易处理模块（必须能支持每秒500条交易以上）调查加快信用卡确认过程的解决方案（参见目标性能度量在此）将所有服务器升级到Apache2.2.3诊断并解决订单处理脚本错误（bugzillaID18168）允许所有用户创建/保存wishlist（意愿清单）允许所有用户在wishlist中增加和删除商品项规模规模513132054020价价值值2020132032010用户故事 用户故事是写PB的好方法之一； 用户故事是简短、明确的功能说明，按

9、照用户价值和用户需要编写。格式范例As aI wantSo that作为客户，我希望能在我的wishlist中放入物品，这样，我可以在以后决定是否购买作为一名航空常旅客，我可以通过我的常旅客帐户查，看我已获得的公里数，以便我决定是否兑换机票123467Product Backlog优先优先级级浏览时钟搜索某种时钟注册帐户将时钟放入购物篮说明说明当用户想购买时钟而不确定型号时，我希望能浏览Clockazon在售的时钟，按照(a)时钟类型和(b)价格范围进行过滤。在用户查找某款时钟时，我希望能进行不限格式的文本搜索，按照短语或关键字（比如：“原子钟”）作为Clockazon的新顾客，我希望注册并设

10、置一个帐户，包括用户名、密码、信用卡和送货信息；作为Clockazon的顾客，我希望能将时钟放入购物车（在稍后购买）、查看我的购物车内的商品、移除我不想要的物品5结账上传/编辑规格查看订单作为Clockazon的顾客，我希望能完成我购物车内所有商品的购买过程。作为Clockazon的员工，我希望能够添加和编辑我们销售钟表的详细信息（介绍、规格说明、价格等）作为Clockazon的员工，我希望能登录，并查看一段时间内完成的所有订单；目录 Scrum概览 Scrum中的角色和关键原则 Scrum流程：站会、策划和回顾 几个应用主题（发布周期、度量、大团队）Sprint计划会议在每个Sprint开始

11、之前召开Sprint计划会议，计划会议要有足够的时间，会议量般为4-8小时。参加人员有产品负责人、Scrum Master、Scrum团队和其他感兴趣的人。Product Owner从产品Backlog中挑选高优先级的任务，并与Scrum团队一起决定在这个Sprint中需要完成多少功能。将任务分解成小的功能模块。团队成员详细讨论如何按需求完成这些功能模块，并估计完成每个功能模块所需的大概时间SCRUM计划会议迭代计划会议 团队确定在迭代结束时，能完成多少PB 对于2周迭代的项目，会议一般花3-4小时 分两部分（同一天内，连续） 第一部分：团队评审PO想要的东西，然后与PO确认“完成”的定义 第

12、二部分：团队决定承诺完成多少，以及如何实现承诺123467Product Backlog优先优先级级浏览时钟搜索某种时钟注册帐户将时钟放入购物篮说明说明当用户想购买时钟而不确定型号时，我希望能浏览Clockazon在售的时钟，按照(a)时钟类型和(b)价格范围进行过滤。在用户查找某款时钟时，我希望能进行不限格式的文本搜索，按照短语或关键字（比如：“原子钟”）作为Clockazon的新顾客，我希望注册并设置一个帐户，包括用户名、密码、信用卡和送货信息；作为Clockazon的顾客，我希望能将时钟放入购物车（在稍后购买）、查看我的购物车内的商品、移除我不想要的物品5结账上传/编辑规格查看订单作为C

13、lockazon的顾客，我希望能完成我购物车内所有商品的购买过程。作为Clockazon的员工，我希望能够添加和编辑我们销售钟表的详细信息（介绍、规格说明、价格等）作为Clockazon的员工，我希望能登录，并查看一段时间内完成的所有订单；迭代策划第一部分 PO介绍PB中最优先PB项的细节 团队提出问题、建议，就疑问进行确认 协商对PB需要做的修改 团队驱动项增加到PB中 大粒度项拆分 任何其它提炼和优化 团队和PO评审标准的“完成定义”，就所有修订达成一致“完成”定义在迭代结束时，要“完成”的功能，必须完成以下步骤：1 编码完成2 代码评审完成3 单元测试完毕4 集成完毕5 文档工作完毕67

14、8 缺陷标准：不允许P1 P2缺陷，P3缺陷小于3个达到“完成”不太好的方式达到“完成”更好的方式迭代策划第二部分 团队开始将PB项分解为工作任务，并且估计需要的时间 对照团队可用资源，团队承诺本迭代完成量，确保工作量适当 所有团队成员都参与会议和讨论，无论经验多少及能力高低迭代周期2周迭代迭代内可支配时间迭代时长迭代内的工作日2周8天团队成员迭代内可工 每天可工作 可用时间总作日 小时 计（小时）张三李四王五赵六8785455532352425每天时间使用分解（按小时）一天8小时有效工作时长迭代计划会议 从PB中的第一项开始 分解PB项为任务（理想情况下，1-10小时的工作量），建议使用黄色

15、便签辅助；浏览时钟浏览时钟浏览时钟任务白板迭代计划会议 从PB中的第一项开始； 分解PB项为任务（理想情况下，1-10小时的工作量），使用黄色便签辅助； 将任务转化为SB，并估计每项任务的时间 SB = Sprint Backlog迭代计划会议 从PB中的第一项开始； 分解PB项为任务（理想情况下，1-10小时的工作量），使用黄色便签辅助； 将任务转化为SB，并估计每项任务的时间； 确认总工作量不超过可用量迭代可用时间迭代计划会议 从PB中的第一项开始； 分解PB项为任务（理想情况下，1-10小时的工作量），使用黄色便签辅助； 将任务转化为SB，并估计每项任务的时间； 确认总工作量不超过可用量

16、； 重复以上循环，直到可用时间耗尽 留出缓冲量开始时可以试试10%剩余小时数燃烧图每日例会最好在每天早上开，时间一般控制在15分钟之内条件允许的话，会议最好每天都在同一时间同一地点举行谁都可以参加这个会议，但只有团队成员发言，其它人员只能旁听所有出席者都应站立（有助于保持会议简短）确定更新燃尽图会议由Scrum Master主持，在会上每个团队成员需要问3个问题： 1我昨天完成了哪些工作 2我今天将要做什么 3我遇到哪些障碍。每日Scrum会议每日Scrum会议 会议目的： 保持团队内部协调顺畅，相互之间进展明晰 每天暴露困难和障碍，非团队监管 如何开展： 每个工作日举行，团队所有成员参加 围

17、成一个圈，面向圆心（而非SM） 行政管理者最好回避 每个人汇报3件事（也可以做一些调整） 会议中不允许讨论（如果确实必要，简洁一点）每日Scrum会议剩余小时数燃烧图燃尽图燃尽图Sprint评审会议在Sprint结束时召开，会议时间控制在两小时以内开发团队展示这个Sprint中完成的功能，不需要PPT，一般是已经完成的功能DEMO客户、管理层、Product Owner以及其它开发人员都可以参加主要是对项目开发的进度通过对实际已完成产品功能的审核进行控制，由产品负责人断定实际所发两点的功能是否与既定的Sprint目标一致，Sprint评审会议Sprint回顾会议Sprint结束后，时间在1-3

18、个小时回顾刚结束的Sprint，对其进行总结和反思，审视和适应的能力是Scrum的基础，在Sprint回顾会议期间，项目团队会分析Sprint中的成功经验和所遇到的阻碍，产品负责人、Scrum团队和Scrum Master参加迭代回顾迭代回顾 迭代回顾的目的：产品检查和适应 参与者：团队、PO、SM、各职能组leader、其他涉众； 参考方式： 演示产品，验证迭代期内的承诺完成内容。相关人员一起讨论产品与“完成标准”的偏差。 团队向PO提出产品相关议题，或迭代中碰到的问题（例如：在后续迭代中需要解决的技术问题） PO向团队提出产品相关议题，或迭代中碰到的问题（例如：市场变化、用户新需求等）迭代

19、总结 迭代总结的目的：团队工作方式检查和自适应 参考方式： 每次迭代回顾后召开，1-2小时 团队、SM参加 管理者和PO应参加，但只部分时间参与，团队需要内部交谈时间 通常会邀请一位中立人员来担当会议协调人 讨论四个主题哪些做得好那些需要改善（不太好的）需要在以后尝试的事情（今后迭代中改善）要上报的问题（向管理者）度好的： 团队感到在实现目标时比以前更加聚焦、清晰 团队使用燃烧图后，对迭代进展有更清晰的了解 每日Scrum会议改善了团队在迭代中的沟通 迭代回顾涌现出不少好的想法今后要开始做的： 估计不要太乐观，现实一些 关注开发和测试之间的协作 换一家餐饮服务公司待改善： 在既定时间内，我们没

20、有完成承诺的内容 估计偏差较大 没有考虑清楚任务相关性 开发和测试之间的协作不太好 茶歇时间的食品很糟糕上报问题： 网络非常不稳定，影响了工作进 需要测试驱动开发培训Backlog积压的待处理事务Sprint本意“冲刺”，指迭代周期，通常2-4周为一个周期迭代总结目录 Scrum概览 Scrum中的角色和关键原则 Scrum流程：策划、执行跟踪、回顾 几个应用主题（发布周期、度量、大团队）Scrum 中的发布周期中的发布周期Scrum发布周期 两种常见方法： 多次迭代发布： 每次迭代发布：多次迭代发布方法之一发布前发布前SPRINT顶层设计和架构调研，开发环境安装最终稳定和发布准备多次迭代发布

21、方法之一在项目接近结束时，缩短迭代期，以更快地检查/适应简介：简介：Scrum和度量和度量Scrum和度量 Scrum不会阻止你跟踪或测量你所实施的开发过程； 测量的记录和汇报可能需要花费资源 如果确实需要消耗团队资源，应该让这些消耗在任务时间估计时明确出来，或作为一个PB或SB项常用度量 进度差异对比 用实际速度比较估计速度； 工作量差异对比 任务汇总成本（跟踪本身的工作量，及可能引发的问题和数据作弊）； 实际消耗时间 vs 预计消耗时间； 挣得值（已实现的软件的商业价值） 商业价值燃烧图简介：简介：Scrum自适应自适应-如何应用于不同规模组织如何应用于不同规模组织Scrum自适应 50人规模（分析师、设计师、开发、测试、文档等）Scrum自适应方法1：多团队共用一份PB方法2：多团队按照独立PB工作Scrum自适应Scrum自适应迭代期间每天/每周2-3次协调、相关性管理、问题暴露目录 Scrum概览 Scrum中的角色和关键原则 Scrum流程：策划、执行跟踪、回顾 几个应用主题（发布周期、度量、大团队）Q&A