便士游戏汇报 – 搞英语 → 看世界

介绍

这是对流行的演示流程的便士游戏的汇报。主持人在汇报期间可以提出的问题多种多样。一些示例如下：

个人时间与交货时间有何关系？
合作受到怎样的影响？
什么时候质量最高？
什么时候返工率最低？
返工什么时候最便宜/最贵？
团队什么时候最专注/最不专注？
等待时间有何变化？

关键概念

1. 个人表现并不代表团队表现

个人绩效对团队绩效影响很小。个人最多只能通过两人在迭代中发现的改进而略有提高，但这并不是团队成果和速度的驱动因素。当系统以及团队如何协作决定产出和结果时，我们往往过于关注个人效率。

4. 开销不一定是坏事

当批量较小时，我们会给每个人带来开销。例如，我们必须在批量大小为 1 的情况下传递 20 次，而在批量大小为 20 的情况下只需传递一次。引入这种开销可能看起来有害且违反直觉，但实际上它有助于团队维持系统中的流程。以较小的批量工作确实会带来开销，例如更多的拉取请求、更多的代码审查、更多的部署等。但是，当这些步骤有效完成时，它会增加团队交付的量。

3. 错误成本较低，允许进行实验

随着批量大小的减小，个人纠正错误的空间就更大，并且可以在不影响系统的情况下花更多时间完成个人工作。如果有人犯了错误（例如，掉落了硬币），他们有时间捡起并修复它，而无需队友等待很长时间。如果批量大小很大（例如，故事很大，PR 很大），那么一个团队成员的任何延迟都会影响另一个团队成员，因为空闲时间与批量大小成正比增加。等待你的队友越少，个人的压力就越小，因为你不会阻碍每个人。这也让您可以自由地进行实验，因为错误并不昂贵。

4. 提高专注力可以提高质量

较小的批量大小可以增加注意力 – 一次只做一件事可以减少上下文切换（这会对生产力产生负面影响）。我们可能认为一次用一只手翻转四个硬币更有效，但由于焦点分散在四个项目上，因此增加了出错的机会。当我们争先恐后地完成所有事情而不是专注于高质量地完成一件事时，这会增加出错的机会并降低质量。这类似于同时处理多个故事并在它们之间进行上下文切换。

5. 协作变得必要且自然

较小的批量可以改善协作，因为人们必须更加了解邻居正在做的事情。一个人将与邻居“同步”他们的工作，因为两者之间有更多的交互（即更多的传递）。这种互动的增加改善了协作，让每个人都能感受到彼此。在大批量中，这种协作需求就会消失，因为交互需求很低。

6. 早期客户反馈

大批量假定该批次中的所有工作都是客户需要的。小批量允许客户更早地看到产品，从而使他们能够决定是否需要更多工作以及交付的产品是否满足客户需求。敏捷团队的成本节省主要来自于最大限度地增加未完成的工作量，而较小的批量规模提供了这个机会。

7. 更好地处理紧急请求

较小的批量可以更好地处理紧急请求。例如，如果正在处理批量大小为 2 的数据，并且收到完成某个项目的紧急请求，则最多只需要暂停 2 件事情即可让紧急项目通过。在批量大小为 20 的情况下，必须暂停 20 件事。

8.更多检查和适应的机会

小批量工作时，通过检查和调整周期进行改进的机会会增加。随着团队更频繁地尝试工作，他们就有更多机会进行回顾来改进流程。回顾的焦点也较小，因为我们讨论的是如何抛一枚硬币，而不是如何抛全部 20 枚硬币。这会带来更多可行的改进。

9. 在制品少，产量高

减少在制品量可以提高吞吐量。这与利特尔定律是一致的，利特尔定律指出：

举个例子，随着 WIP（每个工人同时工作的数量）减少，吞吐量（完成的工作量）增加。或者换句话说，随着在制品的增加，前置时间（一个项目从开始到完成所需的时间）也会增加。

这里的教训可以是少做多做。这对许多人来说是违反直觉的，但实验证明了这一点。

批评

与任何模拟练习一样，也存在对其适用性的批评。主要的一个问题是，软件开发团队的工作本质上比抛硬币的同质工作更具变化性。这个问题可以在游戏中通过使用不同大小的硬币来解决，但批评仍然存在。个人效率不如系统吞吐量重要的概念仍然存在。

硬币游戏被批评为泰勒主义，因为它试图通过科学管理概念收集见解，将工人视为可以编程以创造某些结果的机器。这种批评是有道理的，但并不能剥夺一分钱游戏的教训，它较少依赖于正在完成的工作类型，而更多地依赖于人与工作之间的互动。

介绍