我一直從事云信業務中臺的后端開發工作。云信的業務發展迅速，產品的需求層出不窮，團隊成員不斷壯大。如何快速滿足產品需求，同時保證線上系統的穩定迭代，以及小團隊如何協同？接下來我會從開發規范、開發流程、項目管理、如何敏捷等方面講述一些我的心路歷程，以供參考。

開發規范

云信業務中臺團隊由最開始的2人，發展到最多時6人。前期階段只關注需求如何快速迭代上線，沒有過多關注代碼規范。隨著代碼數量增加，逐漸發現迭代和維護的難度越來越大，每位程序員都有自己的編碼習慣，十幾萬行的系統代碼，看起來就像一堆“屎山”。此時，必須引入代碼規范，讓寫代碼和讀代碼的程序員都能夠心情愉悅。

代碼規范，直接借鑒的《阿里巴巴java開發手冊》，手冊里詳細制定了編碼、異常日志、單元測試、安全規約、MYSQL數據庫、工程結構等的相關規范，大家可以網上下載閱讀。

有了規范，大家如何有效地執行？

統一IDE代碼模板

約定了IDEA/Eclipse IDE代碼的統一模板，新建類、方法，格式化全部統一。避免不同的開發同學使用不同的模板帶來的差異化，以及增加merge的成本。可以使用eclipse-java-google-style模板。在提交代碼時使用Alibaba Java Coding Guidelines插件，對不符合規范的代碼進行提醒，修改后再提交。

分支管理

最開始，團隊使用的SVN來管理源碼，隨著git的流行，后來全部切換到git。針對分支開發，制定了以下規范：

分支的定義（master、develop、release、hotfix、feature），不同分支會有不同的權限。

checkout、merge request流程，merge時還可以做一次code review；

提測、上線流程，不同階段使用不同的分支測試和發布，上線完成后打tag，方便回滾；

統一工具與框架

對于業務中使用到的公共工具類和方法，統一抽象和封裝到二方庫，比如JedisUtil、httpClient、日期格式的轉換、文件讀寫導出等。所有系統統一框架和版本，比如spring、spring boot，mybatis、dubbo、MQ等，讓開發同學能將主要精力放在業務模塊的開發上。

注釋和文檔

讓程序員既要寫得一手好代碼，又要寫得一手好文檔，并且保證代碼和文檔的同步，面對時間緊、需求多的情況下，實現起來不現實。那如何做到文檔與代碼同步？作為程序員，簡單直接的方法的就是寫好注釋。在類、方法、屬性前加上適當的注釋，對于難以解釋的代碼加上必要的注釋。Controller層的api可以使用spring-swagger來保持同步，減少因修改代碼而維護文檔的成本。

如何做到敏捷？

敏捷這個詞早在90年代初就提出了，據統計，2018年90%的軟件開發都采用了敏捷開發。下面這段話很好的解釋了什么是敏捷？

敏捷開發（agile development）是非常流行的軟件開發方法，敏捷開發的核心是迭代開發，

迭代開發其實就是"重復開發"。它將開發過程拆分成多個小周期，即一次"大開發"變成多次"小開發"，每次小開發都是同樣的流程。

其實這里所謂的同樣的流程，就是傳統的瀑布開發模式，包括幾個重要的環節。我在實際的開發過程中，主要有以下幾個重要的里程碑節點：

需求評審

我們的需求主要來源于產品經理，產品經理通過給開發、測試講解本次版本的需求背景、詳細說明、完成后的效果，讓相關同學理解需求。同時，開發評估需求的合理性、可行性，可以對需求有所調整。這個環節必不可少。當然，需求也可以來自開發，測試，也需要與相關人員溝通。

設計評審

這里的設計評審，不是視覺和交互評審，是技術實現的設計評審。

如果本次迭代的需求在技術方案上需要評估，則需要對詳細設計做一個評估，避免開發過程或上線后造成缺陷和遺漏。如果只是常規迭代，則可以省略這一步。

編碼

實現本次迭代的需求

測試用例評審

測試用例和編碼應該是同步的，對測試寫的用例進行評估，可能會發現測試遺漏點，并將其補充完整。

發布計劃評審

如果本次迭代涉及的變更復雜或需要跨部門合作，有前后依賴的關系，需要寫一個發布計劃，寫清楚上線的時間、步驟、注意事項，以免造成上線混亂。同時，要有發布失敗的回滾方案。

上線

按照發布計劃，進行系統的發布上線。

復盤

如果本次迭代有發生重大失誤，造成發布失敗或發布后引起嚴重的線上問題，則需要產品、測試、開發等相關同學一起復盤本次迭代，總結經驗，避免下次再發生同樣的事情。

按照這個瀑布模式進行迭代，覺得步驟是不是有點多？太浪費時間?和所謂的敏捷相違背？但實際是，多少實踐經驗告訴我，這些流程避免不了。比如沒有需求評審，開發完成了，發現效果不是產品想要的。沒有測試評審，開發有修改的地方，測試沒有測試到，導致測試遺漏。

除了這些重要的里程碑，其實還有一些關鍵節點，比如視覺、交互評審，產品走查，冒煙測試，預發布驗證等。

根據敏捷開發的價格觀和十二條原則，我們團隊做了如下調整：

少開會

讓產品、測試、開發盡量坐在一起，如果有任何問題，直接使用面對面交流的方式，解決問題。避免使用郵件、即時通訊軟件帶來的信息滯后。如果要開會，可以使用站會的形式，簡潔溝通。如果必須開會，則盡量控制開會時間，說重點和問題，高效解決。

控制迭代節奏

每次迭代主要解決優先級最高或比較緊急的需求，控制一次迭代的周期在2~3周，從而達到不斷可持續的交付。

定期復盤

針對一段時間內，系統出現的問題，流程的問題等進行復盤和總結。技術實現上，如果用合理的方案快速實現。流程上，如何優化，才能更高效。

如何用好敏捷，打造高效團隊，以上均是本人工作實踐總結，純屬個人見解，如有疑問，歡迎拍磚。

總結

以上是生活随笔為你收集整理的【网易中台实践】云信业务中台的敏捷开发的全部內容，希望文章能夠幫你解決所遇到的問題。

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