这个游戏一共分两轮
这个是一个非常简短而有力的游戏，快速地体会命令控制和自组织团队的差别。总结的时候可以结合Richard Hackman写的《Leading Teams》里面授权矩阵，介绍自组织（自管理）团队的职责，以及自指导和自统治团队是什么样子的。
本文谈及的均为Scrum中的估算行为，这些方法不是Scrum原创的。
谈估算，我想先从为什么要做估算谈起。
每次在我的培训课上，学员们会给出各种各样的答案。比如为了估计成本、为了设定发布日期、为了知道什么时候可以做完、为了……。但我认为估算最重要的目的是为了
达成共识
如果没有进行估算，关于需求或任务会有一些假设或者背景被忽略掉。因此在Scrum中，估算是一个集体行为，而不是某个专家拍拍脑袋出来的结果。
估算的方式分为两大类，绝对估算和相对估算。绝对估算耗时更长，并且需要依赖上下文，最后的结果也会产生较大误差。而与之相对，相对估算更快，结果容易达成一致。Scrum中对产品列表（product backlog）的估算常常使用的就是相对估算，估算单位为故事点（没有意义的单位）。【注意：不要将故事点和小时数做一一对应！】最常用的方法就是计划扑克。
计划扑克是由斐波那契数列组成的一串数字扑克，如下图：
对产品列表条目（product backlog item）进行估算的步骤，简单描述如下：
相对估算还有另外一种方法，称为三角估算法。
Scrum系列：
产品列表梳理会议是Scrum中非常重要，而很容易被忽略的一个会议。说它重要，是因为Scrum开始之前就需要有准备就绪的输入，这个输入就来自于产品列表梳理会议的结果，即初始的产品列表。而对于刚开始转型敏捷的团队，往往会忽略掉产品列表梳理会（需求梳理），从而造成迭代计划会时间过长，或者无法准时开始迭代等等问题。要想解决这个问题，需要首先明确为什么在迭代开始之前要进行梳理会议，以及谁需要参加这个会议，在这个会议都有哪些活动等。
产品列表梳理会议，是迭代就绪的很好的指示，即只有产品列表准备好了，才可以进入迭代。另外，梳理会议是由产品负责人发起或负责，可以召集开发团队参与，也可以只有相关的开发团队成员或相关的利益干系人参与。
产品列表梳理会议的内容可以总结为如下几个字：增删改。首先需要明确一点的是产品列表不是固定不变的，它是可以随着新需求的出现而变化的（即好的产品列表符合DEEP原则，参加博文产品待办列表和用户故事）。
Scrum入门基础系列：
Scrum工件主要包含一下3种：
在Scrum中，主要由产品负责人[参见Scrum入门基础系列之Scrum角色]整理和维护产品Backlog。产品Backlog是Scrum中维护需求的主要工件，也是做好Scrum的第一步。一个好的产品Backlog，是要符合DEEP原则的，即，产品Backlog是详略得当的（Detailed Appropriate），涌现的（Emergent），估算的（Estimated）和排序的（Prioritised）。详情参考参考之前我发的博文“产品Backlog和用户故事的原则”。
一般来讲，产品Backlog里面都可能包含哪些内容呢？新特性、改进项、缺陷修复、文档需求等。
Sprint Backlog主要由挑选的当前Sprint要完成的产品Backlog条目，以及根据这些条目进行拆分后的任务组成的，在Sprint Backlog中还有一个很重要的东西就是当前Sprint的目标，团队根据这个目标以及产品Backlog的排序来进行挑选。 Sprint Backlog的内容是由团队来决定的，具体的工作方法和实现方式，也是团队自己来决定的。在这一点上，充分体现了团队的自组织能力。
产品增量是Scrum中非常重要的工件，因为产品增量才是最终交付给客户的内容。因此每个Sprint团队必须交付产品增量，以符合如下原则：
另外，产品增量也是团队进展的一个标识。开发团队通过不断地交付产品增量，给团队本身和利益相干人以信心，促使产品最终发布。团队进展还有其他常用的标识是燃尽图和任务板。一般使用燃尽图和任务板时，是为了使当前的进度公开给更多的其他团队或干系人。
完成定义，指的是当产品增量完成的时候，必须是团队成员共同理解的完成，而不会出现歧义。并且产品增量需要是高质量的，潜在可以发布的。也就是说，当产品负责人要发布当前的产品增量的时候，马上可以发布出去。完成的定义，是团队根据团队当前的情况，共同协商制定的，共同同意并理解的。还有，完成的定义也不是一成不变的，随着时间的推移，团队倾向于更加严格的定义，比如把更多的内容添加到完成定义中。
Scrum入门基础系列：
Here I would like to talk about product backlog refinement meeting, including what activities should be in this meeting, who should join this meeting and why we need refinement meeting.
As the figure above, it occurs during sprint for product backlog refinement meeting, and normally no more than 5% total time of sprint. E.g during sprint 1, Product Owner (PO) will conduct refinement meeting for sprint 2 and sprint 3. So refinement is like beam of a car, normally we should choose low-beam model, otherwise we would like to watch something far away ahead, we need to switch the headlights to high-beam model. Refinement is the high-beam model for team. (Thank Daniel Teng for above metaphor)
Scrum会议包含Sprint计划会、每日例会、Sprint评审会、Sprint回顾会。下面分别介绍这几个会议，按照一个简单模板进行介绍：
WHY、WHAT、WHEN、WHO、HOW，即为什么要有这个会议，这个会议的输入和输出是什么，什么时间开这个会，谁来参加，如何开好这个会议。
Sprint计划会是为当前Sprint做计划的会议。
Sprint计划会的输入为产品Backlog，最新的产品增量，团队的能力和开发速率；输出为Sprint Backlog和Sprint目标。
Sprint计划会议发生在Sprint开始的时候。对于一个4周的Sprint，计划会时间应该小于8小时，2周Sprint，计划会时间小于4小时，以此类推。
Scrum团队（产品负责人、开发团队、ScrumMaster）都应该参加Sprint计划会。
Sprint计划会议有两种方式。
方式一：传统的两段式会议 - 第一部分由产品负责人和开发团队一起决定要完成什么（What），第二部分由开发团队来决定如何完成（How）。
方式二：循环式 - 1 产品负责人和开发团队选择产品Backlog最上面的那个用户故事，2 开发团队根据团队能力和以往的速率决定是否可以完成这个用户故事， 3 如果可以完成，那么拆分用户故事为任务，否则选择结束Sprint计划会议。4 重复上述1，2，3直到团队无法承诺更多的用户故事。
团队每天同步信息
团队会根据每日例会的情况，1. 调整燃尽图（如果有的话） 2. 调整Sprint Backlog或Sprint Backlog中的任务。
强烈建议每天固定时间和地点开始
开发团队、ScrumMaster、产品负责人（可选）、其他利益干系人（可选）
团队围成圈，面对彼此，回答如下3个问题：1. 从上次例会到现在我完成了什么？ 2.从现在到下次例会我将会完成什么？ 3. 有什么障碍或问题？在整个每日例会过程中，只有猪（隐喻投身Scrum的角色）才可以发言。
在Sprint结束前，产品负责人接收或拒绝开发团队的Sprint目标。团队检视和调整开发的产品增量。
输入为Sprint目标和Sprint Backlog，输出为潜在可交付的产品增量和调整的发布计划。
Sprint结束前
开发团队、ScrumMaster、产品负责人、其他利益干系人（建议邀请，尤其是有关联工作的）
Sprint评审会是一个非正式会议，即这个会议上不需要准备幻灯片来进行完美的表演，团队需要展示出他们的工作成果。另外产品负责人应该不是第一次看到Sprint的成果，也就是说很可能在平时，开发团队每完成一个用户故事，产品负责人就已经评审一个。最后不过是一个仪式，可以让团队拥有成就感。
Sprint结束前，团队一起为开发流程做出改进而努力。
输入为各类主观和客观数据，输出为行动计划，有可能放在专门的改进Backlog，也可能放在下一个Sprint的Backlog中。
Sprint结束前，一般在Sprint评审会之后。
开发团队、ScrumMaster、产品负责人。（一般不建议经理参加）
具体细节请参考《敏捷回顾》一书（Agile Retrospectives）
Scrum中定义有三个角色
另外还会提到两个常见角色（经理和项目经理）在Scrum当中的职责。
根据上述的职责，作为产品负责人需要以下技能：
简单的回答，可以完成上述职责并拥有上述技能的人都可以来担任产品负责人。较常见的是产品经理担任。我见过的还有项目经理、架构师等不同岗位转型为产品负责人的。
常常问道的一个问题是，ScrumMaster是全职工作吗，可以兼职吗？对于一个新组建的团队，我强烈建议全职的ScrumMaster。因为有很多的事情需要ScrumMaster来做，参考上面的职责。如果是成熟的团队，ScrumMaster可以兼职，但不建议既做ScrumMaster又做开发工作；但可以同时是两个团队的ScrumMaster，因为工作类型是相似的。
读过几本Scrum书的人，想必对于Scrum框架都可以如数家珍，如Scrum的3个角色，5个会议，3个工件。在展开这些内容之前，我想先介绍一下Scrum的价值观以及敏捷宣言。
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体与互动 胜于 流程与工具
可工作的软件 胜于 详尽的文档
客户协作 胜于 合同谈判
响应变化 胜于 遵循计划
也就是说，尽管右项有其价值，我们更看重左项。
专注：一段时间内只专注于少数几件事情。Stop Starting, Start Finishing。团队的能力（精力）是有限的，在有限能力和有限时间范围内，专注于最有价值的事情，以取得更好的成果。
勇气：我们需要勇气去迎接各种挑战。
公开：在团队中公开进展（Progress），即可视化、透明，这样可以很容易的暴露出风险问题和障碍。并且透明也是尊重、信任的基础。
承诺：自组织团队开始的时候做出承诺，并在迭代期间尽全力完成履行承诺。
尊重：团队是坐在一起的，长期稳定的，这有助于加深彼此的尊重和了解。
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之父 - 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入门基础系列：
游戏规则
游戏手册
计分用的表格
总结的要点
洞察（Insight）
游戏规则的例子
游戏手册的例子
戴明环
我在QCon 2013北京上带领大家做的抛球游戏。
抛球游戏的创始人链接bor!sgloger。
