作者 | 九歌 網易智企服務端開發

敏捷開發的一個重要目標是建立持續價值交付的能力。這種能力最終必須服務于業務的創新，促進業務的成功。

面臨的問題

在互聯網行業，業務的發展通常日新月異，并且伴隨著不斷的試錯。這對研發團隊的效率和靈活性有著非常高的要求，在傳統的迭代模式中面臨很多問題，如：

• 需求相互耦合，上線交叉感染。一個版本上線出現問題時，由于上線的內容很多，定位問題就會變得更困難，不能確定是哪個需求的變更引起的問題。
• 臨時調整需求，牽一發而動全身。大家應該都碰到過版本上線前一天了，產品說有個很重要的需求必須得加急上，不上不行。這種臨時的需求調整，對版本的交付影響是很大的。
• 因為一個不重要的需求，延期整個版本的上線。上線當天，可能發現有一個不是很重要的需求有問題，整個版本都必須等這個問題解決，有時候直接回導致版本的延期，或者產生很多臨時方案。
• 整個團隊上線發布到凌晨。由于一個版本交付的內容太多了，準備工作很長，影響的范圍也很大，通常會安排在晚上做發布，而發布過程中只要遇到一兩個問題，通常發布就會搞到凌晨甚至后半夜。
• 有checklist依然不能避免遺漏。同樣也是當版本越大，內容越多時，就越容易遺漏。
• 不同價值的需求，相互影響。一個版本中通常會包含各種優先級的需求，而不同優先級的需求同時開發交付，就一定會存在相互影響的問題。
• 產研團隊交付效率上不去。所有問題最后都導致了交付效率上不去，交付質量上不去。

相信大家也有碰到過和我們類似的這些問題。這其中有很多問題，都是可以通過敏捷交付來解決。

敏捷VS迭代

那什么是敏捷呢？關于敏捷模式和迭代模式的理論知識，相信大家都已經有些了解，這里就不細說其中的理論知識了。

迭代模式中每個迭代的需求、時間、資源是確定的，三個因素相互制約。最大的優勢在于可預測性，流程簡單，有固定的時間點。但同時帶來的問題是缺乏靈活性，進入版本后，調整需求或時間的代價會非常大，并且版本越大時帶來的風險和不確定性越大。大多數研發團隊采用的都是迭代模型。敏捷模式中需求變成了變量，在固定時間和資源的情況下，靈活調整需求，從而獲得最大交付價值。

如圖所示，迭代模式中整個團隊按步驟一步步執行，最終全量交付。而在敏捷模式中，在固定的時間內（迭代周期）將一個版本拆分為一個個可以獨立交付上線的需求，優先交付高優先級（高價值）的需求，并由一個個獨立的小團隊負責交付。最大的優勢是非常靈活，可以根據實際情況隨時調整需求，同時由于交付單元限定在最小范圍內，使得上線發布的影響范圍最小，風險可控，也可以提高交付質量。目標是在盡可能短的時間內交付盡可能高的價值。

先試點再推廣

進行敏捷交付的轉型前，我們進行了很多調研和溝通工作，學習公司內部外部已經實現敏捷交付的團隊的經驗。然后制定了初步的方案，并在小范圍內進行試點，試點過程中不斷調整方案，調試工具，當試點方案執行順利以后再推廣到整個團隊。互客剛開始的時候，就是選擇其中一些比較小的簡單的需求來進行試點的。在轉型的過程中，我們總結出四個重要的要素：系統、規范、工具、組織。

需要準備什么

系統架構

首先想要進行敏捷交付，需要有能適應敏捷模型的研發環境，包括系統的合理拆分、邊界清晰的業務、可以進行獨立開發測試的環境隔離能力。要有平滑發布的能力，任何時間發布任何服務不應該因為發布動作本身引起問題。還需要有完善的監控可以實時反饋系統的異常，特別在實踐初期總會有意外情況，研發應該能第一時間獲知系統發生異常。如果研發環境本身還是非常耦合，牽一發而動全身的情況，需求的負責人都不知道影響范圍在哪里。那就很去難實現敏捷的交付方式。如果沒有準確的異常監控能力，會有很大的風險。因此合理的架構是敏捷的基礎。

流程規范

然后是流程規范。從需求拆分、時間規劃、代碼分支管理、技術方案評審、測試報告、發布審核、自動化回歸。團隊中的每個人必須嚴格按照流程進行，因為越靈活的方案，背后意味著更多的不可控。所以在轉型初期，嚴格執行流程是非常必要的。

敏捷交付的前提是需求必須是合理拆分的，而我們對合理的定義就是，可以獨立交付上線的稱為一個需求。如果兩個需求之間是相互耦合的，少了其中一個，另一個需求都不能獨立交付。那么這樣的需求就是不合理的，應該合并為一個需求。

這個是互客某一個版本的需求列表，以及分工，時間規劃等等。可以看到大部分是正常需求，黃色部分是比較大的不跟版本的需求，紅色和劃線的是延期或取消的需求。需求的交付變成了一個靈活的過程。

這個是我們的需求分支管理，非常簡單，每個需求開始時從線上分支拉一個獨立的需求分支，當需求環境提測通過后，合并到灰度分支，灰度驗證后，再合并到線上分支發布上線。其中比較重要的是一定要經常從master合最新代碼到自己的feature分支。

實施工具

工具是流程的承載，沒有合適的工具是很難把流程執行起來的。網易內部的ovemrind效能平臺可以很好的支持我們的流程，配合協作文檔，測試用例管理平臺和測試自動化平臺，基本上可以比較好的支持整個流程了。下面的截圖是某一天下午的發布單，可以看到一下午就有多次發布。

團隊組織

最后我們需要根據敏捷交付的邏輯去適當的調整團隊的組織形式，原先的團隊組織形式，邊界在于職能，所有的需求在不同的職能間流轉，最后由版本負責人負責交付上線。這種模式下，各職能團隊的人只能接觸到自己工作范圍內的東西，所以對需求的理解程度高低不等，當產生需求變更時，也更容易產生抵觸情緒，當出現調整或返工時也會付出很大的代價。

右邊是為了適應敏捷交付調整的組織形式，每個需求都會有一個臨時的虛擬小組來負責，需求只在這個小組內部流轉，最后由需求負責人交付上線。在這種模式下，團隊組織的邊界不再是職能，而在于需求。虛擬小組的成員需要關心一個需求的全生命周期，能更好的理解需求。當有需求變更時，影響范圍也相對小得多。并且通常會在方案設計過程中研發和產品一起討論調整需求。

不管是環境、流程還是工具，最后一定都是需要人去執行的，也就是團隊中的每個成員。因此團隊成員的思維轉變是敏捷轉型中的重點，在工作進行前，首先應該在團隊內進行足夠的溝通，讓每個人理解轉型的價值和意義，讓每個人都愿意為之努力。當團隊達成一致的目標時，離成功就已經不遠了。

得到了什么

這是互客過去幾個版本的需求吞吐量，缺陷密度，不管質量還是吞吐量都是有比較明顯的提升的。

當然，我覺得更重要的是，我們得到了持續快速的交付價值的能力，得到了溝通順暢，相互信任的團隊。另外從我個人做需求感覺來說，在敏捷模式下，我對需求的理解會更好，工作會變的更聚焦，會自然而然的關注需求從評審到上線的整個過程，會及時的關注自己的需求的情況等等。比如有一個客戶的成單就是因為我們上了一個數據看板的需求，需求的價值會直觀的反饋到了這個需求的負責團隊，這可以讓產研統一目標，相互促進，產生良性循環。

經驗總結

在網易互客實踐敏捷交付的過程中我們踩了許多坑，并總結了一些經驗，希望可以幫助大家少走一點點彎路。

• 不要過分追求模式，我們的目標是質量和效率，而不是模式
• 溝通，充分的溝通，要達成理解一致
• 轉型初期流程要嚴格執行
• 需求一定要有負責人
• 需求交付盡量不要合并操作，容易相互影響出錯
• 對質量負責的不是QA，是每個需求的小組
• 系統可觀測性很重要，研發團隊需要掌握系統的實時狀態

最后期望所有的研發團隊都能讓有限的資源產生最大的價值。

總結

以上是生活随笔為你收集整理的网易互客敏捷交付实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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