重点：指派多名工程师完成同一任务

您是否注意到 Jira（以及大多数（如果不是全部））SWE 工作跟踪系统只允许将一个人分配给给定的任务？整个行业（至少在我见过的地方）都围绕着这样一个假设，即在底部“一项任务 == 一个人”。这些年来，我越想越有信心，这是一件非常低效的事情，我们应该默认两个人同时完成一项给定的任务。在复杂的领域中，有时甚至可能是三个。可能在某个时候，您已经体验过事情可以完成得有多快，尤其是在紧急情况下（例如“天哪，生产出了点问题”），其中具有不同技能和知识的多个人一起跳到一个“房间”？我最近读了《目标》，强烈推荐给大家。我最喜欢它的一个方面是它在说明复杂系统（尤其是由人类组成）的性能问题方面是多么的脚踏实地。令人惊讶的是，它的许多发现与两者都非常相关：我强烈建议您阅读它，但简而言之：单独优化每个单元的性能是有害的，而不考虑对整个组织的影响，这就是实际上很重要。我有机会观察到的大多数软件公司都陷入了这个陷阱：他们认为他们想要尽可能多地完成任务，因此他们将尽可能多的人分配给尽可能多的人，认为这可以优化整体吞吐量.通常情况下，分配的工作总是比以往任何时候都糟糕（“每个 sprint”），而根据历史证据实际完成的工作却比实际可能完成的要多，有时“每个人都在一张票上工作，但每个人都在不同的票上工作，因此我们可以取得进展”。尽可能多的东西”。从单个任务的角度来看，往往会发生的是：分配给任务的人并不知道如何很好地完成它。在 SWE，没有人可以成为所有方面的专家。一个人更了解系统的架构，另一个人没有数据库查询性能的经验，另一个人是所使用的编程语言的专家，等等。通常，他们要么不得不放慢脚步，通过在线阅读一些内容和内部提问来学习这个和那个。这是一种放缓，它通常会给每个人带来很多干扰和延迟。所有其他人都忙于工作，因此获得答案通常很慢。有时必须安排会议与分配给其他人的其他相关任务进行同步和交叉协调，每个人都在浪费大量时间，因为其他人的一些相对较小的事情被阻止了。

最终，有一些结论：通常要审查 PR。然后一些其他人——通常只是稍微熟悉正在完成的工作，必须进行巨大的上下文切换并审查新代码。根据定义，此人不可能像更改的作者那样熟悉任务。这就是事情往往以一种非常明显的方式变坏的地方。审稿人对问题很熟悉，作者做得很好，一切都很顺利。那是唯一的幸福之路。审稿人对这个问题有点熟悉，实际上给出了很好的反馈，不幸的是让作者退回重做部分或整个更改。审稿人不是很熟但不知道，善意但错误的审稿人之间有很大的争论，浪费大家的时间。审阅者不是很熟悉，只是橡皮图章，可能是次优或完全糟糕的方法，以返回他们目前分配的任何任务。从组织的整体角度来看，它的样子是有大量的工作正在进行中，但几乎没有任何事情可以得出结论。或者至少：实际结果的交付速度比预期的要慢得多，这通常会导致管理层下意识地试图并行化并同时承担更多工作，使事情变得更糟。让我们与将两名（甚至更多）具有不同技能的工程师分配给一项任务的方法进行对比：

他们保持紧密的同步，互相碰撞想法，成为一个真正的、反应迅速的橡皮鸭。这在工作开始之前有效地作为预代码审查工作。他们的总知识和技能是每个成员技能的总和。他们想出一个整体上好的方法的机会要高得多。他们不必对尽可能多的缺失部分进行自我教育，因为它们涵盖了更多的部分。他们可以利用这个机会交流知识和经验，从而永久地丰富每个参与者。它们对团队其他成员的干扰更少。他们需要更少的会议，因为他们一直保持同步。即使需要与其他人/团队进行同步或其他会议，也可能只有他们中的一个人可以参加，而另一个人可以继续编码或从事有形的工作。到工作结束时，最终的代码审查几乎是不必要的，因为从想法、方法到实现的一切都可能已经由两个或更多人多次审查。注意：结对编程有点像这样，通常使用相同的参数来证明是合理的。但是，我认为“在 IDE 中编码”部分并不重要。重要的部分是多人深入了解问题，讨论解决方案和方法，并花时间和责任来解决它。编码部分可能是也可能不是结对编程。这完全取决于人们在解决方案上的共同努力。如果一个人执行实施并推动 WIP 提交供其他人审查和讨论，可能会更好。他们可以切换，他们可以拆分子任务，例如研究和提问。他们可以并行很多。目标只是让他们所有人都在正在做的事情的背景下全面参与。是的，总体上同时处理的任务较少，但如果您阅读《目标》，您会意识到这实际上可能是另一个好处，而不是真正的弱点。从长远来看，每个任务的配对（或我喜欢称之为：联合）将导致：更好的团队凝聚力，因为人们在解决同一问题时更紧密地工作和互动，实际分配的工作完成得更快，因为人们一起工作可以更快地完成它。