Isaac Sacolick

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

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

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

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

選擇合適的設(shè)備、工具和辦公空間

如果你要遠程工作，請確保有適合你、貴公司及團隊的工作環(huán)境?？梢砸曋疄檗k公室搬家，事先抽時間評估各種選擇或方案，確保你擁有所需的一切東西，以保持工作效率、舒適度以及待在盡量避免分心的辦公空間。

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

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

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

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

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

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

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

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

審核敏捷儀式的方法

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

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

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

·? 使用數(shù)字白板工具用于迭代規(guī)劃和設(shè)計討論

·? 為承諾會議安排視頻互聯(lián)網(wǎng)會議

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

·? 回顧時使用調(diào)查或低代碼應(yīng)用程序征集反饋

致力于實際的團隊和個人任務(wù)

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

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

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

提高文檔詳細程度

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

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

關(guān)注探針（spike）、CI/CD和解決技術(shù)債務(wù)

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

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

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

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

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

現(xiàn)在，將這支隊伍從室內(nèi)競技場拉到室外湖泊，球隊需要一些時間來適應(yīng)環(huán)境。他們會采取一段時間的保守防御，直到逐漸適應(yīng)新環(huán)境、恢復節(jié)奏。

敏捷團隊和多個團隊組成的敏捷組織也是如此。無論團隊在維護舊系統(tǒng)，還是使用最新的DevOps實踐構(gòu)建云優(yōu)先的應(yīng)用程序，都是如此。

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

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

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

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

原文網(wǎng)址

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