【以下內容為分享實錄，有刪節】

如何解決在家辦公時 “團隊溝通”和“研發流程”問題
軟件研發團隊在家辦公時，會遇到的兩個核心問題：團隊溝通和研發流程。因為云效團隊原本就分布在多個城市，平時的溝通方式也經常采用“在線會議”，所以“在家辦公”期間大團隊之間的溝通協調受到的沖擊較小。 但是小團隊之間的溝通還是遇到一些問題，平時大家坐在一起，有事情“吼一聲”就解決了，遠程辦公肯定無法做到。經過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平臺，源于阿里巴巴先進的研發理念和工程實踐，致力于成為數字企業的研發效能引擎！云效提供從“需求 ->開發->測試->發布->運維->運營”端到端的在線協同服務和研發工具，通過人工智能、云原生技術的應用助力開發者提升研發效能，持續交付有效價值。

?

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的战“疫”期，阿里云云效团队在家高效开发实录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。