scrum

Scrum会议包含Sprint计划会、每日例会、Sprint评审会、Sprint回顾会。下面分别介绍这几个会议，按照一个简单模板进行介绍： WHY、WHAT、WHEN、WHO、HOW，即为什么要有这个会议，这个会议的输入和输出是什么，什么时间开这个会，谁来参加，如何开好这个会议。 Sprint计划会 WHY Sprint计划会是为当前Sprint做计划的会议。 WHAT Sprint计划会的输入为产品Backlog，最新的产品增量，团队的能力和开发速率；输出为Sprint Backlog和Sprint目标。 WHEN Sprint计划会议发生在Sprint开始的时候。对于一个4周的Sprint，计划会时间应该小于8小时，2周Sprint，计划会时间小于4小时，以此类推。 WHO Scrum团队（产品负责人、开发团队、ScrumMaster）都应该参加Sprint计划会。 HOW Sprint计划会议有两种方式。 方式一：传统的两段式会议 - 第一部分由产品负责人和开发团队一起决定要完成什么（What），第二部分由开发团队来决定如何完成（How）。 方式二：循环式 - 1 产品负责人和开发团队选择产品Backlog最上面的那个用户故事，2 开发团队根据团队能力和以往的速率决定是否可以完成这个用户故事， 3 如果可以完成，那么拆分用户故事为任务，否则选择结束Sprint计划会议。4 重复上述1，2，3直到团队无法承诺更多的用户故事。 每日例会 WHY 团队每天同步信息 WHAT 团队会根据每日例会的情况，1. 调整燃尽图（如果有的话） 2. 调整Sprint Backlog或Sprint Backlog中的任务。 WHEN 强烈建议每天固定时间和地点开始 WHO 开发团队、ScrumMaster、产品负责人（可选）、其他利益干系人（可选） HOW 团队围成圈，面对彼此，回答如下3个问题：1. 从上次例会到现在我完成了什么？ 2.从现在到下次例会我将会完成什么？ 3. 有什么障碍或问题？在整个每日例会过程中，只有猪（隐喻投身Scrum的角色）才可以发言。 Sprint评审会 WHY 在Sprint结束前，产品负责人接收或拒绝开发团队的Sprint目标。团队检视和调整开发的产品增量。 WHAT 输入为Sprint目标和Sprint Backlog，输出为潜在可交付的产品增量和调整的发布计划。 WHEN Sprint结束前 WHO 开发团队、ScrumMaster、产品负责人、其他利益干系人（建议邀请，尤其是有关联工作的） HOW Sprint评审会是一个非正式会议，即这个会议上不需要准备幻灯片来进行完美的表演，团队需要展示出他们的工作成果。另外产品负责人应该不是第一次看到Sprint的成果，也就是说很可能在平时，开发团队每完成一个用户故事，产品负责人就已经评审一个。最后不过是一个仪式，可以让团队拥有成就感。 Sprint回顾会 WHY Sprint结束前，团队一起为开发流程做出改进而努力。 WHAT 输入为各类主观和客观数据，输出为行动计划，有可能放在专门的改进Backlog，也可能放在下一个Sprint的Backlog中。 WHEN Sprint结束前，一般在Sprint评审会之后。 WHO 开发团队、ScrumMaster、产品负责人。（一般不建议经理参加） HOW 设置环境 收集数据 产生洞察 确定行动 结束会议 具体细节请参考《敏捷回顾》一书（Agile Retrospectives）

Scrum中定义有三个角色 产品负责人 ScrumMaster 开发团队 另外还会提到两个常见角色（经理和项目经理）在Scrum当中的职责。 产品负责人 职责 产品负责人最大的职责是为产品的投入产出比（ROI）负责，即最大化团队的投入产出比。在Scrum当中，由于Sprint是时间盒（即时间是固定的），且成本（软件开发中人力成本是最大的成本，其他忽略不计）也是固定的，那么最大化投入产出比就是如何做出最有价值的产品增量。 创建产品愿景 创建与维护产品Backlog（插播一句，Jeff Patton同学很不喜欢Backlog这个词，听起来产品还没有开始开发就落后了，如果谁有更好的词我们可以一起交流） 主持产品Backlog优化会（增加、删除、修改或细化用户故事，并根据需要进行排序） 协调干系人与开发团队之间的沟通 参加团队的Scrum会议 在Sprint计划会上和团队一起决定当前Sprint的开发内容 接受或拒绝团队的产品增量 决定何时发布 所需技能 根据上述的职责，作为产品负责人需要以下技能： 业务能力 - 产品负责人首先要对产品以及所在行业有较深的认识和理解。这样才能根据业务价值来对不同的需求进行排序，或者对产品的整体方向有感觉。 技术能力 - 虽然产品负责人不必是技术专家（SME），但懂一些技术对于需求排序、拆分、优化是有很大帮助的，特别是在参加Sprint计划会的时候，可以很容易的理解开发团队。 决策力 - 产品负责人接受或拒绝产品增量，那么对于产品负责人他就要有授权，可以决策哪些是可以接受，哪些要拒绝。以及决定什么时候发布，什么特性优先级高等等重要事项。 沟通协调能力 - 产品负责人需要有很强的沟通协调能力，因为他是干系人与团队之间的润滑剂。 谁来担任 简单的回答，可以完成上述职责并拥有上述技能的人都可以来担任产品负责人。较常见的是产品经理担任。我见过的还有项目经理、架构师等不同岗位转型为产品负责人的。 ScrumMaster 职责 Scrum权威 - ScrumMaster是团队中最熟悉和了解Scrum框架的，并可以根据实际情况对团队进行指导。 辅导团队和产品负责人 - 如果产品负责人或团队不知道该怎么办，ScrumMaster需要提供相应的辅导、培训或支持。 保护团队 - 在一个Sprint中，ScrumMaster要保护团队不受打扰，可以专注于Sprint目标和承诺。 移除障碍 - ScrumMaster要善于发现障碍，并可以帮助团队移除障碍，包含但不限于个人障碍，团队障碍以及组织级的障碍。 变革大师 - ScrumMaster不仅要在团队内实行Scrum，还要能够影响并促进组织或整个公司内的变革。 所需技能 热情 - 首先ScrumMaster需要是一个有热情（Passion）的人。热爱并喜欢自己的工作，充满激情，并且可以感染周围的人。 主动学习 - 学习是永无止境的，作为ScrumMaster，需要主动的学习，补充自己的短板，刻意的练习，成为真正的master（大师）。 善于提问 - ScrumMaster不一定是所有问题（尤其是技术上的）的大师，但他一定要能善于启发团队思考并行动。这往往是通过提问来实现的。好的问题可以让团队清晰的认识到自己。 耐心 - 对于变革要有耐心，可以容忍团队犯错误。让团队在错误中学习并成长。 协作沟通 - ScrumMaster需要和团队沟通，了解个人障碍和团队障碍。也需要和团队外的干系人沟通，来排除障碍或了解他们的期望。总体说，ScrumMaster需要较强的沟通能力（和产品负责人类似）。 公开透明 - Scrum的三大支柱之一就是透明。因此作为ScrumMaster也需要公开透明，不仅仅是团队的进展要透明，所有的沟通交流也需要是透明的。只有信息透明，才能产生信任与尊重。详情可以参考《克服团队协作的五种障碍》 谁来担任 常常问道的一个问题是，ScrumMaster是全职工作吗，可以兼职吗？对于一个新组建的团队，我强烈建议全职的ScrumMaster。因为有很多的事情需要ScrumMaster来做，参考上面的职责。如果是成熟的团队，ScrumMaster可以兼职，但不建议既做ScrumMaster又做开发工作；但可以同时是两个团队的ScrumMaster，因为工作类型是相似的。

Scrum入门基础系列之Scrum框架 读过几本Scrum书的人，想必对于Scrum框架都可以如数家珍，如Scrum的3个角色，5个会议，3个工件。在展开这些内容之前，我想先介绍一下Scrum的价值观以及敏捷宣言。 敏捷宣言[1] 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 个体与互动 胜于 流程与工具 可工作的软件 胜于 详尽的文档 客户协作 胜于 合同谈判 响应变化 胜于 遵循计划 也就是说，尽管右项有其价值，我们更看重左项。 Scrum价值观[2] 专注：一段时间内只专注于少数几件事情。Stop Starting, Start Finishing。团队的能力（精力）是有限的，在有限能力和有限时间范围内，专注于最有价值的事情，以取得更好的成果。 勇气：我们需要勇气去迎接各种挑战。 公开：在团队中公开进展（Progress），即可视化、透明，这样可以很容易的暴露出风险问题和障碍。并且透明也是尊重、信任的基础。 承诺：自组织团队开始的时候做出承诺，并在迭代期间尽全力完成履行承诺。 尊重：团队是坐在一起的，长期稳定的，这有助于加深彼此的尊重和了解。 Scrum框架 Scrum框架是不是银弹，也不是灵丹妙药。实行Scrum不需要团队成员都是精英。因为Scrum只是快速的把问题暴露出来，以至于我们无法忽视和忍受它。Scrum框架是一个团队的流程框架，由自组织的团队进行改进完善。该框架主要包含角色，会议和工件三大部分。 角色 产品负责人（Product Owner） - Scrum中对产品负有全部责任的唯一人。产品负责人需要创建和维护产品Backlog，并需要参加必须的Scrum会议，如Sprint计划会、Sprint评审会等。详情可以期待下一篇博文（Scrum角色）。 ScrumMaster - 这个角色是Scrum框架提出的新角色。他需要对整个Scrum框架非常熟悉，还需要是一个变革大师。在Scrum中，ScrumMaster没有授权，而还需要完成很多的工作，如移除风险等。 开发团队 - 开发团队指的是跨职能的自组织团队。开发团队中可能包含开发人员、测试人员、用户体验工程师、数据库专家等。开发团队负责完成端到端的工作，从而在Sprint结束的时候可以完成产品增量。 会议 Sprint计划会 - Sprint计划会主要分为2部分：做什么和如何做。Scrum团队一起决定他们要做什么，以及如何构建、测试承诺的工作。在计划会议过程中，产品负责人的重要职责之一是解释澄清模糊的需求。最后的产出为Sprint目标和Sprint Backlog。详情敬请期待后续博文。 每日例会（Daily Scrum） - 每天的15分钟站立会议。Scrum团队一起回答三个问题：从上一次例会到现在我完成了什么（重点在于是否完成承诺，以及暴露风险）？从现在到下一次例会我计划完成什么（重点在于承诺）？有什么风险或障碍（尽早暴露问题风险）？ Sprint评审会（Review） - 在Sprint评审会上，产品负责人接受或拒绝团队完成的用户故事。（注：产品负责人应该在平时的工作中进行评审，而不是只在评审会上进行这些工作）这是一个非正式的会议，准备时间不要超过1小时。（注：但必备的准备工作还是需要的） Sprint回顾会（Retrospective） - Scrum团队一起检视和调整他们的工作方法，以达到成熟高效的自组织团队。 产品Backlog梳理会（Product Backlog Refinement） - 由产品负责人组织协调干系人或团队一起进行产品Backlog梳理，包含但不限于新增需求，删除需求，修改需求，拆分需求，改变需求顺序等等。 工件 产品Backlog - Scrum中需求存放的清单，常见的格式为用户故事，也可以包含其他类型的内容，如缺陷、用例、史诗故事等。 Sprint Backlog - 由Sprint中承诺的故事和相应的任务组成。在Sprint过程中，团队每天都会更新Sprint Backlog，在每日例会上讨论并同步有关Sprint Backlog的信息。

Scrum入门基础系列之Scrum起源 说起Scrum就不得不提Scrum之父 - Jeff Sutherland和Ken Schwaber，Jeff在1993年结合他的工作实践创建了Scrum框架，1995年Ken在OOPSLA会议上第一次发表Scrum的论文。此后Scrum之父的两位分别撰写过多篇文章，并联合发布了《Scrum Guide》（Scrum指南）。有关具体的Scrum起源可以参考我之前的一篇博文 - Scrum起源。 说到Scrum的起源，让我们再来看看Scrum的3大支柱：Inspect Adapt Transparent。 其中transparent（即透明性）为基础。离开了透明性（公开）的话，团队成员之间就没有信任和尊重的基础，也很容易发生更多的问题。 另外两个支柱经常一起提到，Inspect and Adapt，即检视与调整。检视与调整组成一个循环。检视，就是查看当前的可交付产品、流程等一切可见的内容；然后根据检视的结果进行反思，下一步如何调整工作计划、流程等等。说到这里，有没有觉得很耳熟呢？检视与调整，PDCA（Plan Do Check Act）环。计划、执行、检查、处理。是的，这就是著名的戴明环，是美国的质量大师在1950年提出的质量改进循环。 然而，PDCA环是戴明原创的吗？让我们往前推20年，看看1930年另一位美国的质量大师沃特 休哈特提出一个PDS（Plan Do See）的概念，和PDCA是不是很相似呢？是的，没错。戴明就是从休哈特的PDS中进一步发扬光大而提出的PDCA环的。 再一次发散一下，这让我想起我读过的一本书《偷师学艺》，书中开篇第一句就是“没有什么是原创的”。大师就是读很多很多书，然后能够吸收消化这些内容，把它们变成自己的再写出来。 怎么样，你有什么感想呢？ Scrum入门基础系列： Scrum入门基础系列之Scrum起源 Scrum入门基础系列之Scrum框架 Scrum入门基础系列之Scrum角色 Scrum入门基础系列之Scrum会议 Scrum入门基础系列之Scrum工件 Scrum入门基础系列之Scrum需求梳理 Scrum入门基础系列之Scrum估算

游戏规则 一组或者多组都可以（每组建议5-9人——你懂得） 从哪个人开始，到那个人结束 不允许把球传给相邻的人 球必须有滞空时间 所有人都参加 每个迭代2分钟 迭代后有1分钟做回顾和下一迭代的估算 一共5个迭代（可以酌情删减） 游戏手册 介绍游戏（2分钟） 介绍游戏规则（2分钟） 团队准备时间（2分钟） 估算能传递几个球 开始第1个迭代 回顾和下一个迭代的估算（1分钟） 重复4次 总结（15分钟） 计分用的表格 总结的要点 在游戏里发生了哪些事情？ 哪个迭代是最好的？为什么？ 哪个地方能体现出Scrum工作流的好处？ 洞察（Insight） Scrum工作流=PDCA（戴明环） 系统都会有一个固有速度（类似于系统有上限、瓶颈） 只有挑战是可行的时候，才会有工作流 游戏规则的例子 游戏手册的例子 戴明环 我在QCon 2013北京上带领大家做的抛球游戏。 抛球游戏的创始人链接bor!sgloger。

译者注：本文虽然是在辩解“sprint评审会议”和“sprint演示会议”的字面含义，但需要更深入了解其背后的原因，这其实才是作者的初衷。 （sprint评审会议=sprint review；sprint演示会议=sprint demo） 几乎每周我都会拜访一到两家公司，在现场教Scrum课程或者进行敏捷指导。最近，在上课前参加敏捷培训的人很可能有一些Scrum经验或（通过书或视频）接触过——大多数情况下，这是件好事。 但我得吐吐槽。当人们把“sprint审查会议”实践当做“sprint演示会议”或只是“演示”的时候，我是有所担忧的。这看起来只是一个语法问题，然而把评审叫做演示的结果是，它破坏了sprint评审会议的真正目的。 尽管演示是sprint评审会议中很有用的一部分，但这不是评审会议的目的。sprint评审会议最重要的方面是深度交谈和参与者之间的协作，以及使产品知识浮现出来并开发。 已经构建好的内容演示，只是一种激发围绕具体事情交谈的、非常有效的方式。而忽略了关于产品是如何工作的交谈。 下图会澄清我是如何看待sprint评审会议活动。 在图的中间，你会看到sprint评审会议图标。这个活动的关键是检视与调整sprint过程中产出的产品增量。这个图标的下边你会注意到一种举办sprint评审会议的方法。 第1步是回顾sprint目标和承诺的特性集，并和实际完成的进行对比。第2步是演示和讨论完成的特性，并对产品backlog或者发布计划做出必要的调整，以反应讨论中新的认知，然后重复这个步骤。这个循环直到所有完成的特性讨论完才结束。 在这个方法中，演示只是sprint评审会议中的一个活动，它不是sprint评审的目的。这就是为什么我认为这个很重要，应该叫sprint评审会议，而不是sprint演示会议。 再次重申，sprint评审会议的目标是检视与调整构建的产品。成功的评审结果是双向的信息流动。不属于Scrum团队的人也可以得知开发的成果并帮忙指出方向。 同时，Scrum团队成员通过频繁的反馈而加深了对产品的业务和市场认识。所以，sprint评审会议是一个检视和调整产品的预定机会。 应该叫做sprint评审会议，而不是sprint演示会议，对于这个观点，您同意吗？请留下您的建议。 原文链接：You can view the original content here. 原文作者：Ken Rubin 译者：姜信宝Bob Jiang

在《Essential Scrum》一书第3章（敏捷原则）中，描述了Scrum的基本原则，以及和传统的、计划驱动的、顺序式产品开发方式的对比。许多人要求分享一下本章最后的对比表格。请看下面：请提宝贵意见！ 主题 计划驱动的原则 敏捷原则 产品开发和制造业的相似性 两者都遵循既定的流程 开发不是制造。开发为产品创造方法。 流程框架 开发是分阶段和顺序的。 开发是迭代和增量的 流程和产品可变性的程度 试图消除流程和产品可变性 通过检视, 适应, 和透明性来平衡可变性。 不确定性管理 先消除结果不确定性，在消除方法不确定性 同时减少两个不确定性。 决策 在合适的阶段作出相应的决策。 保持选择开放。 一次做对 假设我们开始之前有全部正确的信息，从而创建需求和计划。 我们无法预先做对。 探索和开发 开发当前已知的并预测未知。 赞成适应的、探索的方法。 变更、涌现 变更对于计划而言是具有破坏性和代价昂贵的，因此应该避免。 用经济合理的方式拥抱变化。 预测性和适应性 高度预测性 平衡预言性的前期工作和适应性的及时工作。 假设（未经验证的知识） 容忍长时间的假设 快速验证重要的假设。 反馈 关键学习发生在主要的分析、设计、编码、测试循环之后。 充分利用多个并发的学习环优势 快速反馈 容忍交完的认知。 组织好工作流以获得快速反馈 批量大小（在下个活动开始前完成了多少工作） 批量较大，通常100%一股脑式的。适用于规模经济。 使用较小的、经济合理的批量大小 库存、在制品 库存不是信仰体系的一部分，因此不是重点。 识别并管理库存以达到较好的流动 人员浪费和工作浪费 分配人员以达到较高水平的利用率。 关注于空闲工作，而不是空闲人员 延误成本 几乎不考虑延误成本 一直考虑延误成本。 与计划的一致性 与计划保持一致被认为是达到较好结果的首要方法。 适应并调整计划而不是遵循计划。 进度 通过阶段性进展显示进度。 通过验证可工作的成果衡量进度。 中心性 流程为中心——遵循流程。 价值为中心——交付价值。 速度 遵循流程；一次做对并快速推进。 快速推进但从不匆忙。 获得高质量的时间 在漫长的测试-修复阶段后，最后达到质量。

翻硬币游戏在Scrum培训中很常用，因为它是一个很简单，但能揭示很多道理的游戏。下面我会介绍一下这个游戏的规则和所揭示的一些道理。 道具 1元硬币5枚 5角硬币10枚 1角硬币5枚 共计20枚硬币 游戏规则 只能用左手 一次只能翻一枚硬币 一个人翻完N个硬币后，才能把硬币传递给下一个人 数量N由游戏引导师指定 全场评选一名最快的人，提供礼品（可选） 游戏概述 翻硬币游戏，在网上查到最早是由Joe Little提出来的，后来Jeff Sutherland还有Crisp公司的咨询师都大力推广。我在学习这个游戏后，深入发掘发现它不仅可以用于Scrum培训，还可以用于Lean、Kanban等。 现在大多数公司都重视效率，重视时间线，而忽视了队列和批量的大小。在这个游戏中，正是通过改变批量的大小，从而改善了排队情况，进而大大提高了效率，也加快了进入市场的时间。 具体描述 游戏每组需要8-12人，每组的布局如上图。游戏里一共有5个角色： 游戏引导师 工程师（实际干活，翻硬币的人） 经理（不干活，负责计时他面前的工程师从开始翻第一枚硬币到翻完最后一枚硬币的时间） 客户（负责根据批量分发硬币，以及计时收到的第一批硬币的时间） 客户的老板（负责计时收到所有硬币的时间） 一共4轮游戏： 第一轮，批量大小是20 第二轮，批量大小是10 第三轮，批量大小是5 第四轮，批量大小是1 第一轮 客户把20枚硬币分给工程师1，工程师1翻完20枚硬币后，一起传给工程师2，2翻完后传给3,3传给4,4传给客户。第一轮结束。 经理1,在工程师1开始翻第一枚硬币时计时，翻完最后一枚时结束，记录时间。其他经理同理。 客户记录收到的第一批硬币时间。 客户的老板记录收到所有硬币时间。（第一轮应该和上面的时间一样） 第二轮 第二轮，客户把10枚硬币分给工程师1，工程师1翻完10枚硬币传给工程师2，在1翻完10枚硬币时，客户再次给10枚硬币。2翻完10枚后传给3，一直传到客户。 经理1,在工程师1开始翻第一枚硬币时计时，翻完最后一枚时结束，记录时间。其他经理同理。 客户记录收到的第一批10枚硬币时间。 客户的老板记录收到所有硬币时间。 第三轮 第三轮的批量大小是5，其他同上。 第四轮 第四轮的批量大小是1，其他同上。 反思点 批量减小，上市时间（Time To Market）缩短了 批量减小，交付时间（Lead Time）缩短了 为什么批量减小，上面的两个时间缩短了？ 当批量减小后，客户有什么变化？ 个人绩效和团队绩效的联系？