BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

对Mob编程的一些观点

| 作者 Rafiq Gemmail 关注 6 他的粉丝 ,译者 盖磊 关注 2 他的粉丝 发布于 2018年4月8日. 估计阅读时间: 9 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

看新闻很累?看技术新闻更累?试试下载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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT