【以下内容為分享實錄，有删節】
如何解決在家辦公時 “團隊溝通”和“研發流程”問題
軟體研發團隊在家辦公時，會遇到的兩個核心問題：團隊溝通和研發流程。因為雲效團隊原本就分布在多個城市，平時的溝通方式也經常采用“線上會議”，是以“在家辦公”期間大團隊之間的溝通協調受到的沖擊較小。 但是小團隊之間的溝通還是遇到一些問題，平時大家坐在一起，有事情“吼一聲”就解決了，遠端辦公肯定無法做到。經過10多天的磨合，我們逐漸解決了這個問題，提升了溝通效率。下面以雲效團隊為例，簡單介紹下在公司辦公和在家辦公之間的差異。
“晨會”和“周會”上溝通的内容基本沒有變化，主要是會議形式不同。在公司我們都是面對面交流，而在家辦公，會采用電話會議和視訊會議的形式。同時為了提升溝通效率，我們在會前需要同步個人工作項、明确會議主題。在家辦公期間，除“周報”外，我們增加了“日報”，主要是為了在每天下班前披露個人工作進度和可能存在的風險。
在“研發流程”方面，如果你的團隊不是采用“線上化”“白屏化”這種标準流程的話會遇到比較大的挑戰。一旦在釋出過程中遇到問題或故障，在家辦公時，不像在公司可以很友善的找到人，這會造成問題的放大。阿裡巴巴在研發流程方面一直是做得比較好的，我們主要通過“Aone”（雲效是阿裡巴巴自研的DevOps平台，内部名稱為Aone）這個研發工具來承載整個研發流程的，包含了開發、建構、部署和安全生産等流程。
在家辦公期間，我們主要是通過“靈活研發”和“持續傳遞”來解決的“團隊溝通”和“研發流程”這兩個問題，接下來，會詳細介紹一下我們是怎麼做的。
以疊代為核心的靈活研發
“靈活研發”其實是一套非常成熟的方法論，但是所謂“一千個人心中有一千個哈姆雷特”，每個研發團隊都應該“理論結合實際”磨合出一套符合自己團隊的方法和機制。通過雲效團隊的實踐，我們認為：靈活研發應該以疊代為核心，其中的關鍵是要進行“異步溝通”。
為什麼這麼說呢？因為“疊代”是長期或者最終目标的拆解，當大的目标變成小的目标之後，我們的團隊會對這些“小目标”更有感覺。當以疊代為中心後，我們會将這些“小目标”再拆解成“工作項”或者“看闆”上的“卡片”，并落實到每個人身上，這也就形成了“異步溝通”的基礎。
“異步溝通”相對于“同步溝通”，優勢在哪裡呢？首先，能夠積累“上下文”。異步溝通時，我們溝通的内容都會記錄到工作項上；而同步溝通，更多的是以口頭傳達。其次，這也讓每個人能明确自己的目标，讓大家保持專注，減少打擾，進而提高效率。
雲效團隊會将“工作項”分成三類：日常缺陷、項目需求、産品需求。“日常缺陷”很好了解，主要是對已上線産品的維護性工作，缺陷來自使用者回報或自測。“項目需求”一般比較複雜，傳遞周期較長，有明确的傳遞時間，來自企業客戶或者企業自身内部需求。“産品需求”更多是面向大衆，需要持續演進。接下來，我們介紹針對這三種不同的工作項，雲效團隊是如何進行實踐的。
如何處理“日常缺陷”。首先，雲效團隊會将“日常缺陷”分成四個類别：緊急缺陷立刻修複；一周内修複缺陷；兩周内修複缺陷；不修複缺陷。為什麼這麼做呢？因為“缺陷”相比于“需求”來說，是更加“明确”的，變化比較少，大家在認領的時候，基本可以确認什麼時間可以完成。
第二，缺陷不會占用“故事點”。背後的含義是，不會把修複缺陷的時間計算到你正常的工作時間裡，要求大家利用空閑時間去完成。這其實建立了一套正向激勵的機制，因為“任務”和“需求”的工作項會帶來一定的缺陷，當你的工作項完成的品質越高的時候，相應的，你的缺陷就會越少。反之亦然。這個機制就鼓勵大家盡可能的把自己的工作項做到最好。
第三，晨會不過缺陷，而是在周會核查上周缺陷進度，确認新增缺陷分類和指派人。
這套機制非常簡單，而簡單的機制其實更利于執行。雲效在踐行這套機制處理日常缺陷後，我們自己的産品品質也得到了很大的提升和保障。
如何處理“項目需求”。 項目需求一般有确定的完成時間點，且需求明确。我們會根據确定完成時間點，倒推關鍵時間，明确裡程碑。這樣做主要是為了更好的把控風險。需要注意的是，裡程碑的内容一定是可量化的、可觀測的。然後我們會根據裡程碑形成疊代，每個疊代開始前做需求澄清和故事點評估。這樣做跟靈活研發方法論實際上是一緻的。需要注意的是，在團隊培養方面，每個人的技能應該是盡可能均衡的。這樣我們從疊代拆解出來的“工作項”或“卡片”， 任意一個開發者都可以做，而不會和特定的人綁定。這樣就不會因為某一位開發者技能的不足而形成瓶頸。
如何處理“産品需求”。 産品需求和項目需求工作項上的處理比較類似，都需要做需求澄清、故事點評估，然後在“站會”上進行“卡片”認領，風險預警等工作。主要的差異點是産品需求的疊代周期相對固定，這有益于保持産品穩健的延續性。如果疊代周期有時長有時短，這意味着在同樣的研發周期中開發者處理的“卡片”數量是有稀疏的，這就可能造成傳遞品質的差異。另外一個不同點是，産品需求的疊代目标一般是根據使用者、市場和資料的回報而産生的，存在一定的不确定性。這就要做一些“需求澄清”，在需求評審上也會更細緻一些。
雲效在踐行靈活研發的過程中取得了很好的效果，團隊成員也比較有成就感。我們的一個心得體會就是：找到團隊的節奏非常重要。希望大家也能夠在靈活研發的實踐中，找到自己團隊的節奏，探索出一套适合自己團隊的靈活研發機制。
如何通過“持續傳遞”實作研發流程标準化
下面給大家介紹一下雲效團隊如何通過如何通過“持續傳遞”實作研發流程标準化。我們常見的持續內建、繼續傳遞都是通過“流水線”去完成的，今天主要給大家介紹一下雲效除流水線外，比較有特色的一些實踐，包括測試環境：微服務架構下，開發測試環境隔離方案，實作雲端開發； 分支管理：多人研發協同下代碼分支和靜态配置項流程化管理；安全生産：軟體傳遞保障，過程标準化，傳遞可追溯。
測試環境。先介紹一下我們做這個解決方案的背景，之前我們開發的都是“巨型應用”，随着微服務架構的演進，巨型應用開始拆分成很多小的應用。微服務架構帶來益處的同時，對開發過程也帶來新的挑戰。首先，應用越來越多，應用鍊路就會變得很長，整體的開發資源有限，并且不穩定，導緻整個開發調試過程比較困難。而在開發過程中，你又需要一套獨占的環境。用什麼方法能夠解決這個問題呢？
第一種方法，當我需要一套獨占的環境時， 就把整個環境全部的應用都拉起來。這個方案有一些弊端，第一，随着應用越來越多，如果每個應用的開發者都希望把整個環境的全部應用拉起來，在開發資源有限的條件下，是無法實作的；第二，随着應用的增多，整個微服務架構就已經變得“難以描述”了，即使是一次完整的拉起也很難實作。
第二種方法是目前大家采用比較多的，我們首先建立一些公共的基礎環境，比如測試環境、預發環境等。當我需要開發的時候，我在本地起一個服務或應用，跟公共基礎環境進行聯調。這個方案也存在一些弊端，首先，在開發一個功能的時候，你要改動的應用可能不止一個，你需要把這些應用都部署到公共基礎環境中。但是開發過程中的服務或應用又是不穩定的，進而會造成公共基礎環境的不穩定。此外，這樣操作也會形成一種對公共基礎環境的搶占。這種“搶占”使公共基礎環境成為了開發過程中的瓶頸，非常影響開發效率。
通過對以上經驗的總結和實踐的積累，阿裡巴巴設計出一套“隔離環境”的解決方案。如上圖中所示，當你需要做一些有特性的開發時，你不需要把應用或服務部署到公共基礎環境中，而是單拉出來一部分資源為你的特性開發做部署，同時把這個“特性環境”和“公共基礎環境”做一個打通并且隔離。大家可以共用一套資源，但是互相的請求又是隔離開的。這樣操作的好處是，第一你不會占用大量的開發資源；第二，不會影響公共基礎環境的穩定性。
“特性環境”其實是一套虛拟的環境，從表面上看，每個特性環境都是一套獨立完整的測試環境，由一系列服務組成叢集；而實際上，除了個别目前使用者想要測試的服務，其餘服務都是通過路由系統和消息中間件虛拟出來的，指向公共基礎環境的相應服務。
這套測試技術在阿裡巴巴内部已經經過幾代的演進，最開始是對要使用到的中間件（微服務中間件、消息隊列中間件等）進行改造，使中間件支援這樣的隔離機制。随着雲原生技術的發展，我已經在使用Service Mesh的能力進行隔離。同時，我們也開發了一款産品KT Virtual Environment，目前已經開源，歡迎大家在上面提缺陷。
分支管理。雲效團隊以及阿裡巴巴内部研發團隊基本都是采用“AoneFlow”這種分支管理模式。這個分支管理模式是經過多年實踐積累而産生的，它通過變更模型，管理了Feature分支和靜态配置項；代碼分支和靜态配置項合并、沖突解決都是通過白屏化來處理的；它和我們常見的固定分支管理模式不同，它的釋出分支是動态的，可以實作Feature靈活組合，快上快下。為什麼要用“動态釋出分支”？第一，我們發現相比于傳統的“巨型應用”，在微服務架構下，整個內建驗證會變得非常困難。因為你需要在公共環境中與其它應用一起進行內建驗證，即使在單體驗證時你的代碼是OK的，也很難確定與其它應用一起內建驗證時你的Ferture分支是可靠的，一旦出現問題就需要從釋出分支中退下來。第二，當多人協作共同開發一段代碼分支時，你很難確定跟其他人內建時不出現問題， 而且釋出頻率越高，這種不穩定性就越大。特别是我們的網際網路企業，整個疊代速度非常快，開發頻率也非常快，相應的出現沖突的可能性也會非常大。在這種情況下，你就很難確定在內建驗證時你的代碼分支是可靠的。這兩種情況，都要求代碼分支要“快上快下”。
安全生産。剛才我們提到的“測試環境”和“分支管理”主要是從效率的角度考慮如何讓持續傳遞做得更好，其實還有更重要的一點是怎樣讓傳遞品質得到保障，做到釋出過程0故障。
首先，我們要建立起一系列安全機制，比如安全掃描、Code Review等， 讓“測試左移”，在開發階段就發現問題。第二，這些機制不能僅僅是口頭約定，我們需要有效的工具來管理這些機制。雲效團隊将這些機制變成“卡點”“紅線”內建到研發流程中，通過“雲效流水線”來承載。同時為了平衡“效率”問題，雲效團隊更多的是對“增量”進行品質要求，對“增量”設定單元測試、代碼靜态掃描、內建測試、覆寫率等品質紅線卡點。第三，是要做到人工稽核和變更封網的全局次元管控，通過人工的方式與前面介紹的技術手段相結合，形成互補，來確定安全生産。
全新雲效即将上市 敬請期待
近期，阿裡雲·雲效會有一個全新的版本上線，帶來全新的産品功能和使用體驗。這是我們聆聽了來自各個管道開發者的回報，和衆多中小企業開發者共創，用心打磨的一款産品。大家可以加入雲效開發者交流群（釘釘群号：23362009）進行内測申請和讨論。
【下期預告】
【直播日期】4月15日 16:00
【直播主題】阿裡的Kubernetes測試環境開源工具箱
【直播講師】林帆 阿裡巴巴技術專家
【觀看方式】雲效開發者交流群直播（釘釘群号：群号：23362009）
【直播預告】 https://yq.aliyun.com/live/2618
【關于雲效】
雲效，企業級一站式DevOps平台，源于阿裡巴巴先進的研發理念和工程實踐，緻力于成為數字企業的研發效能引擎！雲效提供從“需求 ->開發->測試->釋出->運維->營運”端到端的線上協同服務和研發工具，通過人工智能、雲原生技術的應用助力開發者提升研發效能，持續傳遞有效價值。