对Mob编程的一些观点

文化&方法

摘要： 《Mob Programming Guidebook》一书的合著者Maaret Pyhäjärvi最近撰文介绍了她在Mob测试上的经历，以及Mob是如何使她的团队在转变为多功能团队的道路上取得进展。Woody Zuill近期也在Agile Uprising播客上探讨了Mob编程是如何以小规模、可发布的增量方式，为软件交付提供了一种有效的协作模型。

作者： Rafiq Gemmail

正文：

Maaret Pyhäjärvi是F-Secure的一名测试人员，她也是《Mob Programming Guidebook》的合著者之一。最近，她撰文介绍了自己在Mob测试上的经历，以及她的团队是如何使用多功能团队技能集，使团队从持怀疑态度发展为个人及团队具备胜任能力的过程。Woody Zuill是“#NoEstimates”运动的发起者，也是Mob编程实践的共同创造者之一。在Zuill看来，Mob编程不仅为团队成员提供了实时提升，而且通过一系列小规模、可发布的增量方式，提供了一种有效的协作模型。

在2月份播出的两集Agile Uprising播客中，Zuill将Mob编程实践描述为：

团队中的每位成员开展精诚合作，意在解决“我们在做什么？”，以及“如果要将我们在做的事情变成可交付的成果，我们需要怎样做？”等问题。正是这样的群策群力，使得团队可以同时同地在同一计算机上解决同一问题。

Zuill在GOTO哥本哈根大会上演讲指出，Mob编程的一个主要特征在于“源源不断的思想融合”。存在于其中的主视角，会使反馈循环自然而然地发生左移。他在播客中给出了进一步的解释，指出为使Mob实现工作软件的增量可交付，需要补充一组技能：

不仅是编码人员，而且包括测试人员、数据库专家、产品负责人或产品专家，这些人明白自己希望做什么。此外，还应包括其他任何使软件从概念转变为客户可使用产品所需的人。

Zuill对此做了进一步解释。为了有效地开展合作，团队应采用小步骤、可发布的工作方式。其中的小步骤将支持快速交付，实现尽快给出反馈：

当我们开始做某工作时，应选取其中的一小部分去完成。我们希望能有始有终地完成这一小部分工作。对此应采取凝聚团队的方式做事，即必须整体对待事情，而非相互分离。正是在开展工作期间，我们才能发现那些必须要做的工作。无论我们认为自己对某事是多么地了解，希望某事在设想上应该是怎样的，我们仍需要逐步去完成一件事情。如果我们善于将事物分解成各个可能可用的部分，那么我们就尽可能直接地、有始有终地处理各个部分，并使每个部分都可被用户使用。这样做，才会为我们是否正在朝着正确的方向迈进给出反馈。

Pyhäjärvi在讲述她自身的经历时写道，她一直专注于如何掌握测试技能这一过程，她“并不想成为一名编程人员，并非因为自己缺乏天赋，而是因为对此缺乏兴趣和时间“。在她最初接触Mob编程时，她确信唯一有价值的是“编程人员与测试人员间的沟通”。但是她“认定现在就应该离开自己所喜爱的事物（主要指测试）”。回顾自己的历程，她写道：

“我当时并没有认识到，在一年后，有人会说服我会去学习编程，并真正地成为一名编程人员。”

Pyhäjärvi介绍了她的团队所采用的协作方式：

Mobbing（指Mob编程或Mob测试）从一组人的想法开始。同组成员使用同一台计算机，以此强制实现一种真正的单体流程。组中每位成员轮流操作计算机，并使用定时器每隔几分钟轮换一次，继续进行同一任务，直到任务完成。我们所采用的循环机制并非是让每位成员轮流工作时其他人在围观，而是通过使用一种增强的导航方式让所有人一起工作。

Pyhäjärvi所采用的Mob方式类似于结对编程。她介绍了如何将“驾驶员-导航者”模式应用于Mob：

我们不允许操作键盘者（即驾驶员）决定键盘输入。键盘的操作指令来自于组中其他成员（即导航者）。导航者尽可能在最高抽象层次上做出指引。这个想法并非为了最大限度地使用组中的每位成员，而是为了将最好的想法融入到团队正开展的工作中，使每个人能及时提供自己的想法，以免必须回头重做工作。

Zuill介绍，他的团队在一开始采用Mob编程时，是通过“以重构阅读代码”的方式：

我们通过开始重构，了解需处理的代码。重构使我们以更完整的方式去阅读代码。只要开始重构，并且导航者在导航代码，就会有人加入其中。我们开始去尝试不同的想法，并实时分享这些想法。一个小时后，我们看到了我们一直在做的事情上取得了巨大的进步。我们实现了团队整体分享理解。

据Pyhäjärvi介绍，她的团队为有效地对驾驶员进行导航，选取使用了他们所认识到的三种抽象层次进行沟通：

• 意图：“意图是第一步，用于解释我们所需要的”；
• 定位：“如果意图本身并不足以使行动按我们的意图进行，这时需要在下一步使用定位。例如，使用键盘快捷搜索，而非菜单”；
• 细节：“如果我们依然不能在所希望的方向上取得进步，这时应该采取何种低层解释。例如，输入Ctrl+F键”。

Pyhäjärvi介绍了Mob场景鼓励去采取行动，并阐述了沟通的必要性：

小组通常以一项明确的任务为开始。对于编程活动，在Mob中做简单的代码重构无疑值得鼓励。任何编码套路（Kata）或实战操练也值得鼓励。测试活动可能包括一个自动化脚本，或一部分专用于探索性测试的代码块。无论我们选择何种做法，沟通问题通常是首个挑战。

Pyhäjärvi详细介绍了在沟通上的挑战，这些挑战会在团队协同高效工作时出现：

一旦Mobbing过程开始，就会难以找到要沟通的话。有人可能并不知道应该如何称呼位于IDE行号旁边内容（即“gutter”）。我们可以使用文字清楚地说明我们想要做什么。同样，有些人不习惯于耐心地倾听，并试图遵循他人的想法。虽然Mobbing支持驾驶者做出回应，并给出更好的建议，但接下来要做什么的决定权在于导航者。

尽管沟通在一开始会遇到挑战，Zuill给出了有效Mob在序列化工作流中的优点，即单个团队成员的沟通开销独立于后期汇集意见的开销：

一旦我们将全部的智力、技能和能力集中于某件事上，有趣的事情就会发生。我们非常直接并且非常迅速地采用了我们可使用的东西。如果我们对工作做了分割，考虑到在沟通、协调和每个人在不同的事情上工作的成本，这时可能需要一两个星期才能完成工作。如果我们可以用一个星期完成工作，甚至是两到三个小时，那么我们就在快速反馈循环中取得了巨大的收益。

Pyhäjärvi还介绍了在面对分歧时，她所使用的Mob过程是如何通过采取倾向于采取行动的方式设法解除阻碍。她给出了在此情况下应用的两条Mob规则：

1. “是的，进一步”-规则：“小组工作于同一个思想分享中。事情一旦开始，就已经完成，但我们依然可以对其添砖加瓦。”

2. “两者都做”-规则：“如果给定两种做事的方式，先列出它们，然后再做两件事。以我们认为不太可能的事情开始，或者是随机选择，目标是表现出对每种方式的认可态度。”

Pyhäjärvi强调指出，这些规则明确了做事方式的责任，因为“正如团队所做的那样，这项工作是以他们先前从未见过的方式开展的。”

Pyhäjärvi认识到，作为一名测试人员，Mob的驱动力使她能够通过提出一些严格围绕测试的问题，进而证明这些问题验证了解决方案的成熟度，支持并确保在解决方案中应用了适当的思维和质量等级。

Zuill指出，这可以通过提问如下问题决定Mob的规模：

如果我们不能从始至终地使用这组团队的知识，这意味着在团队中缺失了某人。

Zuill将协助今年四月在马萨诸塞州Burlington召开的实际动手操作Mob编程大会。

查看英文原文： Perspectives on Mob Programming