戰「疫」期，阿里云云效團隊在家高效開發實錄

【如下內容爲分享實錄，有刪節】

如何解決在家辦公時 「團隊溝通」和「研發流程」問題
軟件研發團隊在家辦公時，會遇到的兩個核心問題：團隊溝通和研發流程。由於雲效團隊本來就分佈在多個城市，平時的溝通方式也常常採用「在線會議」，因此「在家辦公」期間大團隊之間的溝通協調受到的衝擊較小。 可是小團隊之間的溝通仍是遇到一些問題，平時你們坐在一塊兒，有事情「吼一聲」就解決了，遠程辦公確定沒法作到。通過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平臺，源於阿里巴巴先進的研發理念和工程實踐，致力於成爲數字企業的研發效能引擎！雲效提供從「需求 ->開發->測試->發佈->運維->運營」端到端的在線協同服務和研發工具，經過人工智能、雲原生技術的應用助力開發者提高研發效能，持續交付有效價值。