Working with Agile in a Distributed Team Environment 1/2

2012 年一月份的 MSDN 雜誌有一篇文章，標題是「Working with Agile in a Distributed Team Environment」，作者是 Sandeep Joshi。拜讀之餘，想想好久沒翻譯了，就順便練習一下。我僅取部分摘譯，預計分成兩篇發布。這是上集。

註：由於當作是練習，有些地方我也就沒有花太多時間斟酌詞彙和計較譯文的「精確度」了（但也不至於信口胡謅啦）。如有任何謬誤，還請各方不吝指正（別太兇就好）。再次提醒這不是完整翻譯，略過的段落或句子並不會在譯文中特別註明喔。

集中式團隊 vs. 分散式團隊

在同一間辦公室工作，是所有敏捷方法的要點，包括 scrum 也是如此。《The Enterprise and Scrum》的作者 Ken Schwaber 說：「面對面是最佳的溝通方式，因為雙方能透過臉部表情、肢體動作、詞彙、和語調來輔助溝通。當你把團隊成員拉到白板面前一同討論如何設計，定能引發熱烈的溝通。」

既然溝通在軟體開發實務中如此重要，為何分散式團隊還那麼普遍呢？這反映了目前商業環境的現實：企業需要招募全球菁英，並考慮委外策略。

分解敏捷

我所說的分解敏捷（de-Agile），意思是針對團隊的需要做適當的調整，把不合用的程序拿掉。在一個分散的工作環境裡，分解敏捷的重點就是盡量減少分散的感覺。你必須讓每個團隊成員了解，在與遠方同事合作時，多花一些心力在溝通上面的確有其必要。同時，你也應該要強調開放與分享的重要性。

理想的團隊人數與配置

分散式敏捷開發要有成效，就得盡量減少人員分散所帶來的衝擊。主流的敏捷方法適用於 10 到 15 人的團隊，但如果你的團隊人數比這大得多怎麼辦？當團隊規模大到某種程度，成員分散於世界各地且橫跨不同時區，以紙本傳遞和面對面為主的溝通方式自然就行不通了。當然，你還是可以在大型的分散式團隊中使用敏捷方法－－只要你願意依團隊的實際狀況調整流程。

當團隊成員分散各處，為每個地點找出最佳的人才配置就顯得相當重要。如果你採取的策略是把某一種工作類型的人員全部集中於一處，那你就很可能會錯失當地的某些優秀人才。比如說，你可能明知有一位程式開發高手，卻因為將開發團隊放在不同的國家而無法聘用他。錯失人才就是增加公司的招募成本。

將開發流程與工作分而散之，也是個重要關鍵。前面提到的集中式模型還有個缺點：如果公司的某個分店需要擴張或縮減規模，就會碰到一些問題。例如，把程式開發人員全都集中在某個國家，而把專案經理集中在另一個國家，測試人員又放在另一個國家，這種做法並非最有效率的配置。這樣的安排往往會導致單向資訊傳遞，產生混亂，而且當問題出現時互踢皮球，交相指責。還有一個問題是，當公司想要將某個地區的分店關掉，特定專長的人才（例如產品經理）就會立刻短缺，因為公司把所有同類專長的員工都放在同一個地點了。

工作均分

在分散式團隊裡，工作分配不均很可能會導致專案進度落後。工作分配不均也可能造成瓶頸，令整個團隊無法前進。

公平分配並不容易，但你可以嘗試採用 SWAT（Subjective Workload Assessment Technique；主觀工作負荷評估術），與每一位成員討論，以找出最佳安排。SWAT 對分散式團隊來說較不易實施，因為 SWAT 需要一對一面談，而分散式團隊的成員卻分散在各處。我曾經與分散於美國和澳洲的開發團隊一起工作，當時我發現一種情況：位於澳洲的開發人員所寫的程式碼大都容易閱讀，而且有適當的註解和單元測試，美國的開發人員在這方面則明顯不足。我和每一位團隊成員討論之後，發現美國的團隊被指派負責大部分的工作，而澳洲的團隊卻只負責一小部分的工作，因此他們比美國團隊有更多時間精雕細琢。

保持團隊間的工作平均分配也是讓團隊持續前進的要素之一。如果發現某人因為工作量過高而難以負荷時，應盡快將一些工作分給其他成員。若某人的工作量太少，則想辦法讓他多參與專案的開發工作。工作量過多或過少都會令人無法專注，終致離去。

還有一點也很重要：別把遠方團隊視為本地「主要」團隊成員的「助手」（helpers）。如果讓遠方的團隊成員覺得自己只是傭兵，他們可能很難對專案盡心盡力。

譯注：我把 hired hands 侈譯為「傭兵」，似乎太過....先這樣吧。

搭檔寫程式

搭檔寫程式（pair programming）指的是兩個團隊成員並肩而坐，撰寫同一個程式。這對分散式團隊來說並不容易。如果無法做到搭檔寫程式，還是可以用其他方式達到「並肩作戰」的效果。比如說，使用 Skype 或 LiveMeeting 之類的視訊會議軟體。

若此法仍不可行，你得找到其他可以取代搭檔寫程式的等效方法，例如舉辦小型的心得交流或研討會，或者每日例行的開發人員 scrum 會議。在心得交流會議當中，每一位團隊成員都要（透過螢幕分享工具）向其他團隊成員展示其個人的工作成果，並蒐集回饋意見。在日常的開發人員 scrum 會議中，開發人員可以利用很短的時間，簡單扼要地討論技術問題或解題的方法。此作法不僅可以促進團隊成員彼此分享並重複使用程式碼，在凝聚團隊共識方面通常也很有幫助。

碎碎念

順便分享一點個人最近的感想：相較於集中式團隊（同一辦公室工作），自動建置和自動部署對於分散式團隊來說可能更重要。舉例來說，開發人員完成某個 issue 時，到 issue tracker 系統中更新其狀態為 Checked In 或 Ready for Test。由於測試機位在不同國家，若沒有自動建置與部署機制，測試人員可能得自行去版本庫裡面拉新版的應用程式檔案到測試機上，要不然就是開發人員每次完成一個 issue 就要發布一次新版的檔案。這對開發人員來說實在太花時間了。一個比較好的作法是，開發人員只需專注在處理 issues 和 work items，下班前不用去擔心到底要再 rebuild 一次，並且發布給測試小組。因為專案每天都有一點進展，都可能有一次以上的 build。如果每天都要花時間要去處理這些瑣碎重複的動作，不如交給排程去自動處理，把寶貴時間拿去做更有價值的事，例如實作新功能、閱讀新的技術文章、按讚、寫網誌等。

剛剛講的排程，可能是 daily 或 nightly build，也可能是 weekly build，視團隊的開發節奏和專案需求而定。排程負責的工作涵蓋自動建置專案和自動部署，當然後者不見得能夠完全自動化，可能要看應用程式部署的複雜度。我覺得如果無法做到自動化部署，可能要考慮一下是不是組態過於複雜了，可趁這個時候檢視一下架構的設計有無改進和簡化的空間。自動化建置和部署的目的，主要是讓整個「修改程式 > 建置 > 部署 > 測試」的流程盡量平順，跨國團隊成員不用常常陷入「你等我、我等你」的窘境。

對 test team 來說，由於每天晚上已經有 script 自動建置甚至自動部署到測試機上，他們只要發現 issue tacker 上面有新完成的待測項目，便可直接上去測試機進行測試。最清楚解哪些檔案該部署的人，自然是實際負責寫程式的開發人員。所以最理想的狀況，就是把部署程序做成 script 自動執行，而不用人工介入（或讓人工介入的部分減到最少），以免每次部署時還要擔心漏掉那些檔案或步驟。若有新增加的部署檔案或組態，只要修改建置和部署的 script 即可。

建置腳本通常是純文字檔，可以納入版本控管，成為專案的資產之一。新進同仁藉由閱讀部署腳本的 script 檔案，也能大致了解整個部署動作的完整步驟。對開發人員來說，撰寫 build script 時可以促使他們仔細把整個程序想一遍，從而完善或簡化部署程序。對 tester 來說，如果發現版本不對勁，只要再跑一次建置或部署腳本，若確認腳本有問題，便可反饋給開發小組來修正建置腳本。

第一次做自動化建置會花比較多時間，有一點陣痛期。麻煩一次之後，之後的成效就會開始顯現，整個 coding > build > deploy > testing 的流程也會平順許多，開發速度會顯著提升。整體來看，成本效益比應該是很划算的。

我好像把《軟體構築美學》裡面的東西又拉哩拉雜地重複一遍了 XD

待續....