遠距離Swarming
查看英文原文：Swarming Across Distance
我們知道配備齊全的團隊如何圍繞某個功能進行 swarm 。但是如果你是分布在不同地方的敏捷團隊成員之一，又該如何呢？這就取決于成員分布的方式以及所跨時區有多少。
團隊如何分布？
太多跨區域分布式團隊都是按功能劃分的。比如說，所有或部分開發人員會分布在一些地區，所有或部分測試人員會在其他一些地區。產品所有者/用戶在另一個不同的地方，如果團隊配有業務分析人員，這些人通常又會在另一個不同的地方。
這種情況很容易用一個故事來描述。我曾經遇到過一位項目負責人叫 Stefan，他在我的工作室任職。他本人在德國，當時就很擔心其中一個項目。那個項目有兩位開發人員在英國，一位在法國，還有兩位在德國，另外有兩位測 試人員在印度的班加羅爾。產品所有人在德國，而且該用戶還想要管理另外兩個團隊積壓的工作。
這種情況真是雜亂無章。但是這個故事正是我時時聽聞的區域式分布團隊的典型代表。而且，因為團隊不是圍繞特征來進行 swarm，產品所有者認為他有足夠的時間在各個團隊之間進行多任務管理。
集中工作
Stephan 提出的第一項建議是讓開發人員減少在制品（WIP），并且大家集中關注在同一件事情上。而之前他們每個人都有各自的事。現在，他們都在討論的是“我們如何一起開始這個事情？”
結對進行實驗
他們不會同一時間一起開始。首先是在英國的兩位開發人員一起開始。他們想，既然是在同一時區，那么他們應該一起開始。這么做也是比較合理的，因為不存在時差的問題。
兩位身在英國的開發人員其實并不是在同一地點一起工作，所以他們同分布在其他地區的人面臨同樣的問題。他們試著通過架構來組合 Google 文檔、共享屏幕、做結對、進行工作。他們必須實踐多種場景。然后發現原先設置的“故事”都太大了。將“故事”范圍調整小一些之后，swarm 會變得簡單許多。
再加入一位開發人員
當英國的兩位開發人員開始實踐某一“故事”之后，他們打算再讓另一名開發人員加入進來。在接下來的故事中，他們召集了德國開發人員中的一人。三個人所在區域存在一個小時的時差，上下班和午餐時間也是如此。
不過他們還是努力一起交付了這個“故事”，并決定再加入一名測試人員。但他們還是對時差的問題有點擔心。
加入測試人員
兩位英國開發人員分別位于曼徹斯特和倫敦，還有一位開發人員在德國慕尼黑，現在又有一位測試人員在印度班加羅爾，這個項目小組分布在跨 4 個半小時的時區內。更糟的是他們一天能一起工作的時間最多只有 5 個小時，前提還是測試人員要加會兒班，開發人員要晚點兒吃午飯。而且這樣做也只能偶爾為之，不可能一直這樣。
所以，他們決定按照各自的時間工作，而不是 5 個小時大家一起工作。
按各自時間工作
現在我們明白了按各自時間工作的價值——這也是敏捷的大致含義所在。不過我們沒必要按照一周或兩周這樣劃分時間段。我們還可以劃分更小的時間段。
該團隊決定利用分時間段的方法集中精力做 swarm，這樣他們就可以盡各自所能利用的時間來一起解決問題。
在第一個 90 分鐘內，開發人員和測試人員一起工作，分享屏幕、遠距離結對，一切你所能想象的一般團隊的工作場景都在這支團隊中得以實現。
第一時段之外的安排就由每個人自行決定了。
大家能午餐同步嗎？或者他們犧牲下午的剩余時間來吃午餐？團隊成員需要自己決定找出解決問題的辦法。該團隊嘗試了多種方法，主要還是取決于其他事情的進展程度。
手動測試減慢了團隊的速度
當團隊剛開始 swarming 的時候，測試人員只能進行手動測試。這就意味著團隊每次都有一步滯后，即測試人員總是晚一步了解目前的狀況。當測試人員與開發人員一起工作時，測試人員能夠理解功能是什么，但還是不能開發出自動測試。
通過 swarming，開發人員能夠為測試人員構建代碼使部分測試得以自動化。這雖說不是完美的解決方案，但又有哪種是呢。
隨著不斷的溝通，測試人員對自動化的擔心越來越少，并開始對團隊做出越來越有效的貢獻。
加入看板使進度更直觀
由于該團隊成員分散在太多不同的時區中，且時間重疊很少，于是成員們使用了看板管理來觀察所有“ kanban board ”的進度。這樣的話，每位成員就可以根據情況選擇早來或晚走。
像這樣團隊成員分布在不同區域的，大家對調班都習以為常。不需要每個人每天都調班，只要你發現你可以在某一天或兩天調整個一兩小時就能對團隊起到幫助，你可能就會這么做。看板管理可以幫助大家判斷這么做是否有必要。
該團隊很快發現他們一起 swarm 的頻率越來越高，他們需要各自調整時間以便一起 swarm。由于彼此相隔太遠，如果想要加上測試人員一起的話，swarm 變得沒那么容易。
“我們需要更多的故事”
Swarm 的成效之一就是團隊能更快地完成工作。因為他們的在制品更少，所以故事就完成得更快。現在壓力轉移到了產品所有者身上，他們已經為其提供了編寫完好而簡練的故事。產品所有者很訝異甚至還沒心理準備團隊能夠如此又快又好地完成任務。
起初，產品所有者想要自己搞定所有的故事。后來，他意識到項目太多了，根本忙不過來。于是他尋求幫助，將工作移交給另外一個產品所有者的兩支隊伍，并將注意力集中在這支團隊上。
你擁有更多選擇
相比這支團隊的選擇，其實還可以有更多的選擇。如果你打算實驗一下，或許可以選擇另一種方法。這支團隊選擇的方法是：
- 先從最近的人那里起頭。
- 加入下一個人進來。
- 使用時間分段來克服時差問題。
其他方法可以是：
- 先從各個架構層某個人開始再加上一名測試人員
- 使用時間分段來克服時差問題。
還有一種方法是：
- 使用看板管理來觀察進度。
- 不要試圖進行實時 swarm，而是只要有誰有空就出來解決問題。
我個人不傾向于第三種方法，因為那樣會導致多任務操作。
當你們分散太開而不能一起 swarm 時怎么辦
有時候，作為跨職能的團隊，你們會因為各自分散在不同區域而無法一起 swarm。我有位同事叫 Tim,我就經常在他的項目中發現這樣的情況。Tim 團隊的開發人員分布在美國的好幾個地方：Cambridge、 MA、 Denver、還有 San Jose。所有測試人員都在印度的 Pune。由于時差問題，他們沒法兒選擇合適的時間一起開會，但是這并不妨礙他們選擇正常時間之外的時段一起工作。
在 Tim 的項目中，開發人員可以在差不多的時間里一起 swarm。然后，完成他們的部分之后加入測試，再將代碼交接給在印度 Pune 的測試人員。
這并不是理想狀態。但是，他們使用了看板管理來跟蹤進度并提出相關問題。所以，如果 Pune 的測試人員有任何問題，他們就會在看板上創建卡片，這樣開發人員就能看到并做相應回復。
可視化管理益處多
跨越不同時空進行 swarm 并非易事。如果可以用工具來看到對方的工作區域就太好了。然而，更有幫助的是能夠看到工作進度。
Swarming 幫助團隊減少在制品，這使得整個團隊能更好更快地完成工作。它可以幫助你理清方向。它有助于團隊成員之間的關系得以促進。
當然，有時候不管怎樣，這項工作就是沒法兒完成。那么索性就放棄吧。但是，但凡你有機會，就請嘗試一下看看會有什么結果。一定要告訴你嘗試的結果，好嗎？
關于作者
Johanna Rothman 與很多公司有合作，幫助他們改進產品開發管理——最大化管理人員和技術人員的效率，并提高產品質量。Johanna 是 2009 敏捷大會的主席。她還撰寫了以下多本著作：
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
- Behind Closed Doors: Secrets of Great Management
- Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People
她還為 Stickyminds.com 撰寫專欄，并為 Gantthead.com 撰寫“極限項目管理”，并在其主頁 jrothman.com 上寫有兩篇博客。最近她開始在 www.createadaptablelife.com 撰寫博文。她還是 Amplifying Your Effectiveness 會議的主持人。