对 Mob 编程的一些观点

  • Rafiq Gemmail
  • 盖磊

2018 年 4 月 7 日

话题:语言 & 开发文化 & 方法

看新闻很累?看技术新闻更累?试试下载 InfoQ 手机客户端,每天上下班路上听新闻,有趣还有料!

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

语言 & 开发文化 & 方法