译者语：尽管我们处于一个追求团队合作的时代，将工作分配给个人去独立完成的情况却随处可见。批量处理的思想运用在开发项目的各个环节。开发人员从Sprint Backlog中挑选需要开发的功能或者需要修复的缺陷，测试人员从已经完成的功能待测列表中进行测试，部署人员将所有测试成功的代码批量部署。从每个团队成员去看，似乎大家都在高效的完成各自的工作。然而当我们从单个SBI的角度去看，就不难发现在整个过程中，等待随处可见。完成的代码等待测试人员进行测试，测试失败的缺陷需要等待开发人员修复，测试通过的代码需要等待批量部署。“蜂拥而上”的模式从提高产品生产速度的角度出发，提供了一种新的团队合作方式，将效率评估从个人转向团队，转向产品。文章向我们详尽的解释了，为何蜂拥而上的方式，可以将团队效率最大化，并引用了丰田的案例，向我们介绍了如何将该方式运用到Scrum中，将生产的流速度提高到极致。
正文：
组织，团队和个人共同协作，将工作项拉动到完成状态。尽管为产品待办列表（Product Backlog）排序，从而使交付价值得到最大化是PO的职责，开发团队应该负责为迭代待办列表（Sprint Backlog）的实施进行排序，从而使生产流得到最大化。
同一时间处理太多事情会从根本上降低个人效率，团队速度或企业活力。它会削弱速率，有时甚至可以将其减少为零。如果每个人都独立的只做自己的事情，他们不可能去互相帮助。而从长远来看，他们也不可能去互相学习。
团队成员的个人喜好和工作环境中的障碍通常会导致分散的工作量。一个团队同时处理多个项目，往往会导致过多的在制品（WIP），低效的流程，以及伴随而来的延迟交付。
· 在制品（WIP）是公司里那些正在等待完成，等待最终销售，或者是等待发挥价值的半成品。这些物品有些是刚刚被组装好的，有些是正在队列或者缓冲仓库里等待进一步的处理。
· 最佳的生产管理旨在最大程度地减少在制品。在制品不仅需要存储空间，约束了资本不可用于投资，同时还减短了产品的保质期。当某一个生产步骤前出现了队列，代表它能很好的应对上游供应链可能出现的供应短缺，但也可能是因为它处理上游输出的能力不足。
考虑如下场景，一个团队试图通过并行工作来提高生产量，每个成员一次处理一个产品待办事项（PBI）。开发团队的成员在单独工作时，可能会更专注于构建而不是进行测试。因为相对于富有创造性的设计和构建，开发人员对测试的专业知识和兴趣都更小。如果在一个迭代期间延迟了多个工作项，那么迭代结束时无法将PBI拉动到完成状态的风险就会增加。更糟糕的是，在硅谷和欧洲，一些复杂软件的开发团队发现，如果无法在同一个Sprint中识别和修复当前代码产生的缺陷，那么三周后，原本只需要一小时的测试工作会变成24小时的测试工作量。如果团队选择推迟测试而非蜂拥而上的完成，那么原本一个月内可以交付的产品可能需要推迟到两年。
围绕这一问题，Jerry Weinberg提供了一种实用模型，描述了多任务如何导致任务延迟：
更糟糕的是，最近的大脑研究表明，一心多用不仅能使人既愚蠢又缓慢，同时还增加了压力并加速了衰老。
有那么一种幻想是，一次处理很多事情可以让事情进展得更快，从而满足了管理层对员工高效率的渴望。然而，这增加了团队在后期必须修复和测试的缺陷数量，提高了开发成本，并最终拖延了发布日期。
团队可以将工作划分为不同的小组，但是只有在工作之间完全独立的情况下，每个小组才能自主工作。在复杂的系统中，工作项之间往往会相互耦合。在为工作排序时，即使很少遇到必须的循环依赖关系，处理一般的依赖关系依然可能会阻碍项目进度并增加项目的延迟。开发团队成员通常希望独立工作，以避免彼此的代码相互干扰。而这种干扰恰恰是失败的流程和工程实践，导致团队失能的征兆。Google通过召开每日例会并蜂拥而上完成任务，从而解决了这个问题。
因此：
集中最大化的团队精力去完成产品待办事项列表中的一项，尽可能快的完成该项目下所有已知的工作。负责这项工作的人作为团队的队长。团队中的每个人都必须尽力帮助队长，没有人可以打断队长。当队长完成了当前项目，负责下一个项目的人则成为新的队长。
· 1947年，我们平行或L型地布置了机器，并尝试让一名工人沿着加工路线操作三到四台机器。但是，即使工作量或工作时长都没有增加，我们遇到了来自生产工人的强烈反对。我们的工匠不喜欢这种要求他们担任多项技能操作员的新安排。他们不喜欢从“一个操作员，一台机器”变成“一个操作员，多台机器，不同的生产过程”的体系。大野耐一，《丰田生产系统》，1988年，第1章。丰田生产系统：超越大规模生产 - 图片来自Liker，《丰田的方式》：世界上最大的制造商的14条管理原则，2004年，第8章，图8-4。
这种模式是通过使团队共同工作来最大程度地提高交付业务价值的速度。它需要人们转变思维方式，从专注于提高特定任务的效率，转换成专注于蜂拥而上完成待办事项（PBI）的生产流。个人效率并不能提高生产速度，而松弛却可以让生产加速。
矛盾的是，尽管“蜂拥而上”意味着团队一次专注于一个PBI，但它也意味着各种开发活动同时进行，快速的相互穿插。团队可能需要进行几分钟的实施，然后进行短而快的增量测试，增量测试又可能导致新增的分析和进一步的开发，直到PBI完成。
一次执行一个开发阶段是避免团队合作的另一种方式，而当所有团队成员始终发挥自己的才能时，蜂拥而上是最有效的。
这是一种多维度的模式，它适用于企业级别，投资组合级别，团队级别和个人级别。它能带来更快乐的团队，也能带来组织文化上的成功。
你需要专注于每个团队成员对自己团队作为一个整体的认同感，而非认同个人的身份，并以此来鼓励团队蜂拥而上。这需要限制或消除针对个人杰出成就的奖励。需要致力于反对“英雄文化”，消除加班，消除加班费，以及反对重视努力工作这样的职业道德。每次一个PBI，整个团队协力完成，可以拓宽团队成员的技能组合，并产生更多的多技能人才。它还可以激励团队在每个有着清晰目标的迭代中做一些出色的事情。
只处理Scrum任务板上优先级最高的PBI往往会使个人和团队进行自我组织，从而最大程度地提高迭代的流速。丹麦的A / S系统公司展示了如何通过实施这种模式，从而使公司中每个团队的生产率提高一倍。
Citrix Online在企业级别应用了这种模式，将发布周期从42个月缩短到不到10个月，进而大大提高了其产品的市场份额。
实施此模式将团队带向单件持续流。丰田汽车证明了这可以优化产能：
· 在这种理念中，单件流意味着零件从一个增值步骤直接移至下一个增值步骤，最后再移至客户。在这些步骤之间，产品无需等待时间或等待批量处理。多年以来，我们称其为“持续流生产”。丰田现在将其称为“逐件生产”，这也许是因为许多制造商会无视一堆零件正在增值步骤之间排队，却指着一条正在移动的生产线，错误地说：“我们有持续流，因为一切都在前进” 。而当我们使用“逐件生产”这个词时，这样的误解就很难产生了。
一次处理一个产品待办事项，团队无需在进行中的工作项之间进行协调。相反，团队可以首先处理最少依赖的项目。
团队在由开发人员排序的工作计划中不断调整其方针。他们每天聚集在一起，共同在Daily Scrum中调整这个方向。但是，所有方向调整都要在迭代目标的范围内进行，而迭代目标本身就是一个凝聚点，可以帮助引导团队的流动。经验丰富的执行经理兼技术投资人Mark Gillett表示：“那些给个人一系列任务（或交接）的团队所能看到的产品价值，似乎远低于那些可以识别出需求并不断变化合作伙伴，直至共同完成PBI的团队。” 紧密合作的团队可以建立共同的愿景，即产品是什么，同时能够增加其对产品和获得成就的自豪感。Scrum社区的成员们也一直在谈论Swarming。参见，例如， Dan Rawsthorne的著作（《探索Scrum：基础知识》，第二版[RS11]）。
——译者：Emma
校对：Suzzi
参考资料：
（1）A Scrum Book：25 Swarming: One-Piece Continuous Flow
