對Mob編程的一些觀點

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

 

來自：http://www.infoq.com/cn/news/2018/04/mob-programming-perspectives