配对和分组的工作方式以及为什么它们会改善您的产品

如果您一直在关注敏捷，那么您会听到以下术语：配对和蜂拥而至。 但是它们是什么意思呢？ 有什么不同？

当您配对时，两个人一起工作以完成一项工作。 传统上，两个开发人员配对。 “司机”写了这件作品。 另一人，即“导航员”，在工作完成时观察了工作并进行了审查。

我最初是在1982年作为开发人员结对的（踢和尖叫）。 后来，我在1980年代后期配对为几个开发人员-测试人员对中的测试人员。 我与Esther Derby一起写了《闭门造车：伟大管理的秘密》 。

有一些数据表明，当我们配对时，实际编码大约需要15-20％的时间。 但是，由于我们具有内置的代码检查功能，因此最后的调试要少得多。

当我和埃丝特（Esther）撰写本书时，我们扔掉了最初的两个（很无聊的）草稿，并在六周内重新编写了整本书。 我们在身体上在一起。 我必须学会停止说话。 （当她谈论这件事时，她很可笑。）我们俩在写作时都必须学习彼此关于缩进和删除的特质。 配对时就是这样。

但是，我们编写和出版的这本书与原始草案完全不同。 没有。 我们做了配对的工作：我们讨论了本节的外观。 我们一个人写了几分钟。 那个人停了下来。 我们改变了。 另一个人写道。 也许我们在讨论时就进行了讨论，但我们结成了对。

大约五个小时后，我们完成了一天的工作。 做完了 我们已经花了所有的精力。

那是配对。 两个开发人员。 一种工作产品。 不限于代码，好吗？

现在，让我们谈谈蜂拥而至。

整个团队都在大声疾呼：“让我们一起讲这个故事，并把它做好。” 您可以将蜂拥视为类固醇的配对。 每个人都在解决相同的问题。 但是如何？

有人将不得不编写代码。 有人将不得不编写测试。 问题是：以什么顺序和谁导航？ 其他人都在做什么？

当我教授敏捷和精益的讲习班时 ，我要求参与者选择团队可以在一小时内完成的一项功能。 大家吟。 然后他们这样做。

一些团队通过让产品负责人详细解释功能来做到这一点。 然后，开发人员和测试人员结对编写自动和手动的测试。 他们全都在大约45分钟的时间在一起。 他们查看自己所做的工作是否有效。 （通常没有。） 然后 ，团队开始共同努力，真正蜂拥而至。 “如果我们在这里这样做怎么办？ 如果去那里怎么样？”

一些团队从一开始就一起工作。 “我们要做增值的第一件事是什么？” （这是一个很好的问题。）如有必要，它们可能会分成较小的对。 也许。 也许他们每15-20分钟需要一个接触点来重新定向自己，说：“我们在哪里？” 他们发现，如果他们要求产品负责人提供反馈，那么效果很好。

如果您首先问：“增加价值并完成这个故事，我们要做的第一件事是什么？” 您可能在正确的轨道上。

为什么配对和分组工作这么好？

配对和蜂拥而至：

• 将反馈收集到手头任务的开发中。 没有人独自工作。 从事这项工作的人还能犯错吗？ 当然。 但是可能性较小。 有人会发现错误。
• 建立团队合作精神。 与他人紧密合作时，您会很好地认识某个人。
• 公开工作。 你知道你在哪里。
• 减少正在进行的工作。 您不太可能执行多任务，因为您正在与其他人一起工作。
• 至少在我看来，鼓励您不要走捷径。 因为有人在看着我，所以我处于最佳职业状态。 （这也发生在你身上吗？）

配对和分组如何改善您的产品？

配对和群集的效果是改善您的产品的原因。 内置反馈可以减少下游调试的次数。 改进的团队合作有助于人们一起工作。 当您公开进行中的工作时，可以对其进行衡量，查看，也就不足为奇了。 通过减少正在进行的工作，您可以提高吞吐量。 您有更好的手Craft.io机会。

您不必敏捷地尝试配对或蜂拥而至。 您可以在任何项目上配对或聚集。 我敢打赌，如果您曾经在“老虎”团队工作过，则需要为“非常重要的客户”修复某些问题，或者您必须尽快提供“关键修复”。 如果您全神贯注于一个问题，那么您可能已经配对或拥挤了。

如果您敏捷，并且没有配对或蜂拥而至，请现在考虑将一个或两个都添加到您的曲目中。

翻译自: https://www.javacodegeeks.com/2014/07/how-pairing-swarming-work-why-they-will-improve-your-products.html