分布式敏捷組織與傳統敏捷組織的管理方式在核心上其實并無本質區別，但在“分布式”這一嚴苛條件的前提下，在日常敏捷實踐中的那些只重“形”不重“神”的環節所引發的問題則會暴露無遺，嚴重時甚至會阻礙團隊的正常運轉，這是對團隊是否真正掌握了“思想敏捷”的一次深度考驗。
??庚子年初，荊楚大疫，眾惶恐，皆閉戶，舉國防之。位于疫情風暴中心的我們在第一時間成立了專班小組奮斗在“科技戰疫”的一線，與湖北省防疫指揮部開展密切協作，全力保障醫療物資在生產計劃、分配、儲運、簽收到貨等各個環節的準確與效率，為政府防疫工作的順利開展提供了有力的支撐。
??每一個光明前途背后，都有一條曲折的道路，2020年1月23日武漢封城，隨后疫情一天天加劇，政府也相繼出臺了愈來愈嚴格的防控隔離措施，身在抗疫一線的我們，如何即確保質量與效率又能保障日常工作協作與落實的順利開展，“分布式敏捷組織”成為了我們的必由之路。
分布式敏捷組織面臨的挑戰
??我平常開玩笑說IT研發更像是“一場大型線下社交活動”，團隊協作中的溝通無處不在，但因為人的多樣性和語言表達的豐富性，團隊中“與人溝通”的難度常常遠超過“與代碼溝通”。而分布式之后，團隊協作則變成了“一場大型線上社交活動”，這對團隊的溝通和管理都無疑是更艱難的挑戰：
- 溝通效率極大下降。溝通介質從“空氣”變成了協同工具、終端設備、網絡等多個節點串聯起來的通道，而任意一個節點出現故障都會導致溝通不暢甚至中斷；效率下降也意味著成本上升，大半夜開會成了家常便飯，遠程辦公成了一直辦公；
- 目標管理容易失控。由于成員不能處于同一空間，缺少了相互督促的同儕工作環境氛圍，由于一些或主觀或客觀的干擾因素，工作效率不如現場辦公；受限于溝通條件，主動詢問進度經常會演變成“干預性打擾”，容易引發信任危機；
- 研發效率面臨瓶頸。研發流水線本身在敏捷團隊中就尤為重要，其穩定性和擴展性直接決定了團隊的整體研發效能；如果平常沒有花足夠的成本去持續改進和積累，在面臨突發的遠程協同工作時勢必會嚴重影響團隊效率。
分布式敏捷組織的實踐
??在這次的省醫療物資保障管理系統項目中，由于項目的特殊性和緊迫性，我們不得不采用大規模的分布式敏捷組織架構，同時一些既有的基礎設施也無法完全利用，但結合團隊在敏捷實踐中的深厚積累，以及在項目中高強度的磨合和迭代改進，我們的團隊基本克服了上述困難，得到以下幾點實踐經驗。
看板是第一要義
??看板應該是一個組織進行敏捷實踐最先使用到的工具，但同時也極有可能是第一個流于形式的工具，移動卡片的新鮮感通常在“蜜月期”過后即消散于無形，淪為了敏捷教練一個人的小把戲。現場辦公的團隊之所以可以不使用看板繼續工作的本質原因是因為溝通成本低，隨便喊一嗓子就能得到回應，如果喊一遍解決不了那就再喊一遍。但高昂的溝通成本是分布式團隊不能承受之重，所以此時將看板作為項目信息及狀態同步的工具，極大地確保了團隊中的每一位成員，在任何時刻都能從看板上獲取目前團隊的最新進展，同時將自己的狀態在看板上予以更新，看板信息的呈現與反饋全員協同并行，才能節約大量的溝通成本，將看板打造成全團隊的“唯一信息輻射源”是一個分布式團隊能成功運轉的關鍵所在。
??同時，利用電子看板的優勢，因地制宜的進行改良以適配分布式協作。要實現看板“唯一信息輻射源”功能，需要盡可能多的將重要信息發布在看板上，對齊團隊的“溝通語言”。例如上圖，我們在看板中添加了“分支名稱”和“依賴”兩列，這是因為我們在團隊運轉過程中發現，對于研發人員而言，常常是知道了自己要做什么，但是不知道應該在哪里做即不知道其任務所處分支及分支狀態，在聊天記錄中搜索“分支”關鍵字可以發現相當一部分比例都是在詢問分支在哪里或者分支狀態；而“依賴”則是在版本發布時，根據每個任務的“優先級”和“階段”即可準確迅速地決定發版策略，從而極大節省信息同步的時間及決策時間。
站會無處不在
??團隊在剛開始實行分布式辦公的一段時間里，每天依然堅持傳統集中站會制度，但運轉一段時間之后，我們發現每天大集中式的站會變得不太可行且必要性不強，現階段不是特別適配團隊。一是確實有各種客觀原因導致個別成員無法按時參加；二是在分布式下日常的溝通變得相對正式且重要。
??現場辦公中，團隊成員之間會靠“混沌的、自發的、隨機的面對面交流來湊合解決問題”（程序員練功房,熊節）。而分布式組織里，通過視頻會議工具發起的每一次會議和討論，因為會強制中斷會議參與人的工作而變得相對正式；同時由于較高的溝通成本，討論主題必須清晰，討論過程必須聚焦。因此，我們將站會的核心要素：”控制時間“、”聚焦問題“、”明確下一步“等帶入每一次會議，而且每一次會議中都會自發誕生一個臨時的Scrum Master來提醒大家。這樣每一次會議都能高效起來，聚沙成塔，團隊整體效率才能得以顯著提升。
優先級的玄機
??backlog梳理本是需求管理的重要的環節之一，但為了匹配項目進度，我們將“backlog梳理”與“點數估算”的工作合成為了確定“優先級”，同時“backlog梳理”中的內核“梳理客戶價值”，與“點數估算”的內核“計算研發成本”，依然保留了下來。
??我們將優先級分為了“極高”、“高”、“中”、“低”四個級別，這四個級別是對應了“時間管理四象限”：“極高”對應重要且緊急，“高”對應不重要但緊急，“中”對應重要但不緊急，“低”不重要且不緊急。其中需要重點討論的是 “高” 和 “中”。在 “高” 和 “中” 里，可以把“重要”與否看成研發成本高低，“緊急”與否看成客戶急迫程度高低。
- 標記為“不重要”即“研發成本較低”，而“緊急”即客戶很急迫的任務，是研發組給產品組的底氣，從而讓產品組與客戶協商時保有充分的余地；
- 標記為 “重要”即“研發成本較高”，而“不緊急”即客戶不急迫的任務，是產品組對客戶不做出時間上的明確承諾，從而讓研發組能有更多時間把重要的事情做好。
??這樣直觀且清晰的劃分，能充分發揮團隊成員的主觀能動性：
- 怎么樣把“研發成本高”的事情變成“研發成本低”，這是研發組自己的課題；
- 怎么樣把“客戶急迫高”的事情轉成“客戶急迫低”，這是客服組自己的課題。
??基于此，團隊成員之間各自努力把自己的課題做好，形成了相互信任，公開透明的協作文化。
“合適的才是最好的”：代碼管理的藝術
??我們項目組起初需要在48小時內為客戶交付一個滿足基本需求的版本，這是一個典型任務型階段，那么主干開發主干發布即可滿足有求。在滿足客戶的初步需求之后，產品組開始主動思考如何更好的協助客戶時，項目由任務型階段轉變成了功能型階段，即會根據客戶使用情況，按天釋放功能。此時我們的代碼管理策略隨即轉換為了下圖所示的分支開發主干發布的方式。
??在渡過了需求井噴階段之后，產品組開始構思更加長遠的需求、研發組開始進行部分功能的重構時，我們的代碼管理策略則轉變為標準的gitflow策略(A successful Git branching model, Vincent Driessen)，以適配功能特性的差異化釋放需求。
??我們并沒有在一開始使用“最好”的代碼管理方式，是因為越精細復雜的分支策略，也會帶來管理成本上升，根據項目的進展階段，選擇合適的代碼管理方式才是最好。同時，在代碼管理方式變得精細化之后，code view的重要性和必要性也日漸突出。流于形式的code view導致我們經歷了幾次大型的代碼沖突，最終我們將合并權限收口到幾位經驗豐富的研發組長之后，問題才得以解決。慢即是快，code view看似是成本，實際上是提升研發能力和交付質量的一劑良藥。
自動化一切能自動化的
??搭建研發流水線，將研發中流程化的工作沉淀為自動化任務，是一個敏捷組織的基本必備能力。而在分布式敏捷組織里，這種能力已然成為團隊的效率基石，每天上百次的持續集成和2到3次的產品發布，全都依賴著一條穩定且擴展性良好的流水線。
??同時，我們不僅僅只局限在代碼集成自動化上。分布式協作中高昂的溝通成本，不斷的推動著我們去斷梳理工作流程并實現更多的自動化場景從而輔助團隊提升效率。例如根據不同條件觸發應用版本和數據版本的備份或回滾，自定義數據清洗及同步，基于協同工具機器人實現流水線各階段進展通知，人員工時統計，報表自動化生成等等諸如此類的小自動化設計在工作場景中比比皆是，這些改進都可以極大地減少不必要溝通，同時最大化工作信息的透明度。
總結
??傳統組織的項目管理的核心工作內容為：需求管理，目標管理，配置管理。敏捷組織則是在圍繞“交付質量”為核心的前提下，將傳統的項目管理工作映射成敏捷管理實踐的三部分：產品實踐、管理實踐、工程實踐。而分布式敏捷組織與傳統敏捷組織的管理方式在核心上其實并無本質區別，但在“分布式”這一嚴苛條件的前提下，在日常敏捷實踐中的那些只重“形”不重“神”的環節所引發的問題則會暴露無遺，嚴重時甚至會阻礙團隊的正常運轉，這是對團隊是否真正掌握了“思想敏捷”的一次深度考驗。
??在VUCA時代我們總會遇到一些小概率的黑天鵝事件，而我們的敏捷組織在遇到這樣的風浪和危機時，如何依然能夠比較順利地前進，是非常值得探究的事情。此次突發的疫情就是一只不折不扣的“黑天鵝” ，成為了檢驗我們敏捷轉型成果的“試金石”，我們相信在經受住此次極限壓力測試的考驗之后，我們的敏捷組織能力必將再上一個臺階。
