遠程敏捷團隊的7個最佳實踐

Isaac Sacolick

團隊的所有人都聚在一個地方工作時，敏捷方法最有效。團隊在同一個工作場地時，成員們很容易提問題、結對處理編程任務并解決問題，無需安排會議。使用互聯網會議、群組聊天和電子郵件之類的技術根本不如面對面直接交流來得有效。

話雖如此，企業組織也可以讓敏捷方法在遠程分布式團隊中大有作為，但是這需要一些工作和試驗。團隊成員必須找到使用技術的最合理方式，并適應溝通方式，以確保團隊的生產力、協作和質量。

新冠疫情爆發后，許多敏捷團隊只好由在辦公室工作改為遠程工作。對于在職業生涯中大部分時間沒有在家工作過的許多人以及習慣于面對面交流的團隊來說，這將是一種全新體驗。此外，由于疫情日益嚴峻，一些團隊成員可能生病或面臨其他困境，因此敏捷團隊必須適應新的工作方式。

本文是一份簡單的指南，旨在幫助團隊成員、團隊和企業組織由面對面為主的敏捷團隊改為高度分布式的團隊。

選擇合適的設備、工具和辦公空間

如果你要遠程工作，請確保有適合你、貴公司及團隊的工作環境。可以視之為辦公室搬家，事先抽時間評估各種選擇或方案，確保你擁有所需的一切東西，以保持工作效率、舒適度以及待在盡量避免分心的辦公空間。

較長期遠程工作時，請考慮所有的注意事項，包括工作紀律、辦公空間、設備、網絡和工具等方面的建議。

你需要進行的一些變化在開始入手后才會一目了然。如果網絡連接很差，可能需要重新放置無線路由器或換成有線連接。如果你經常需要開視頻會議，就可能需要調整辦公桌的位置。你可能要告訴家人在工作時保持距離，以免分心。

人要在場，與團隊成員交流

敏捷團隊的成功之道在于，平衡好專用于協作的時間與專用于編寫代碼及其他開發活動所需的協力工作的時間。在辦公室，更容易看到團隊成員關注的事情，訓練有素的敏捷團隊要想方設法避免分心和環境切換。

遠程工作時，團隊必須在線，但也要向他人表明是否在場。Slack和Microsoft Teams等工具讓你可以設置是否在場的狀態，而其他協作工具可以使用通知靜音。如果團隊樂意接受靈活的工作時間，使用狀態設置至關重要。

敏捷團隊必須為正式的協作交流安排時間，并做好工作以完成用戶故事，但團隊成員還應該可以閑聊。人們對壓力大的時期和遠程工作的反應各不相同，因此相互聯系非常重要。此外，人們在網上和面對面的交流方式也各不相同，現在有新的機會可以讓更多的人參與網上對話。

敏捷專家（scrum master）、技術主管和產品負責人應定期詢問團隊，摸清他們對需求和阻礙工作進展的因素了解的程度，以及是否需要設法提高生產力和幸福感。

最后，來自多個團隊的敏捷專家和技術主管應定期相互聯系。他們在管理遠程團隊方面的經驗和問題可能有普遍性。如何讓敏捷團隊在遠程協作方面進行探討和交流，無疑會使所有人受益。

審核敏捷儀式的方法

改而采用遠程協作的敏捷團隊不必重新設計流程或擯棄敏捷儀式。但是遠程工作可能需要敏捷專家重新考慮如何開會，具體取決于團隊的規模和可用的協作工具。

比如說，面對面的團隊在每日例會時查看敏捷開發白板，因此需要設計這種儀式的數字版。如果團隊規模小，過去在完成用戶故事方面遇到的障礙比較少，那么他們可以擯棄會議，換成預定的聊天聚會。

對遠程敏捷團隊的其他幾點建議：

·? 使用數字白板工具用于迭代規劃和設計討論

·? 為承諾會議安排視頻互聯網會議

·? 選擇一個人在迭代審核期間負責屏幕共享

·? 回顧時使用調查或低代碼應用程序征集反饋

致力于實際的團隊和個人任務

由面對面改為遠程協作的敏捷團隊必須重新調整迭代速度，審核他們可以實際承諾并完成的工作數量和復雜性。敏捷專家和敏捷主管應采用類似于新組建敏捷團隊的做法，讓團隊可以適應新的工作方式。

比如說，由于一些團隊成員可能會在疫情期間無法參與開發，因此完成需要多個團隊成員貢獻的復雜用戶故事是不明智的。如果可能，應將這類故事分解成小故事，或者如果產品負責人不再優先考慮它們，就推遲。

同樣，敏捷團隊可能需要避免完成依賴其他團隊工作的故事。額外的協作可能需要幾個sprint才能為新組建的遠程團隊定義。

提高文檔詳細程度

相比前期說明文檔，敏捷開發團隊更注重切實可行的代碼，但這并不意味著沒有必要為架構、API和代碼編制文檔。

長時間遠程工作的團隊可能希望討論文檔標準，看看是否需要做出更大的努力。有時，如果為代碼編制文檔，不大需要面對面討論代碼模塊如何工作或團隊成員如何處理技術債務等內容。

關注探針（spike）、CI/CD和解決技術債務

希望長時間遠程工作的團隊可能會發現，更容易專注于技術性更強的故事，而不是需要與產品負責人和利益相關者進行交互的故事。比如說，測試多步驟用戶體驗需要產品負責人、設計人員、開發人員和測試人員之間的協作。團隊剛開始遠程工作時，協調討論或讓大家共同了解最終用戶的需求可能比較難。

還有其他機會可以優先考慮這類工作：需要較少的協作，需要更多的個人專注和創新。優先考慮小的探針試驗（spike，定義研究開發故事的一種方法）以測試新想法是一個例子，如果開發人員可以在干擾或環境切換較少的情況下開發簡短的概念驗證，更是如此。另一個方法是優先考慮處理代碼層面的技術債務，尤其是重構代碼模塊、添加單元測試或改進異常處理。第三種方法是花時間開發或改進持續集成/持續交付（CI/CD）自動化。

這些更具技術挑戰性的任務還可以幫助開發人員專心致志地在可直接看到效益的方面完成工作。

審查部署策略，并降低風險

高度協作的敏捷團隊要學會像優秀的冰球球隊一樣協同工作。在冰球比賽中，即使冰球飛速移動、不規則地彈跳，球員們還是會結合運用既定的打法和靈活的應對，確保既有強大的防守，又有凌厲的進攻。

現在，將這支隊伍從室內競技場拉到室外湖泊，球隊需要一些時間來適應環境。他們會采取一段時間的保守防御，直到逐漸適應新環境、恢復節奏。

敏捷團隊和多個團隊組成的敏捷組織也是如此。無論團隊在維護舊系統，還是使用最新的DevOps實踐構建云優先的應用程序，都是如此。

要求敏捷團隊遠程工作的條件可能會影響公司的其他方面，包括業務運營、客戶期望和供應鏈狀況。

客戶和最終用戶可能希望不一樣的部署頻率，如果這種頻率有損于應用程序的可靠性或性能更是如此。如果你的API用于銜接企業的供應商，那些供應商可能較難參與測試變更。如果應用軟件受到法規遵從或監管部門的監督，那就可能更難得到所需的審核和批準。

敏捷團隊須認識到一系列更廣泛的變化在影響本組織的業務模式、客戶和工作環境。需要從新的運營角度來審核組織原則，而組織原則決定了從部署的速度和頻率到優先考慮的工作類型和用戶故事。

要做到敏捷、而不僅僅遵循敏捷實踐，關鍵是要認識到何時變化、如何變化。

原文網址

https：//www.infoworld.com/article/3532286/7-best-practices-for-remote-agile-teams.html