（我本來計劃將研發環境和管理流程分開來講的，最後還是放在一起便於理解。）

軟件研發最重要的場景就是在有限的時間和資源下把需求落地為產品/項目，也就是研發和項目管理，毫無疑問，這個階段的主角是開發人員。

是不是應該多思考下怎麽面向開發人員來優化整個研發過程和項目管理流程？

本文將介紹如何通過優化開發環境搭建、代碼管理來提高研發過程中開發人員效率，並通過持續集成和交付讓開發中的問題更早暴露，通過合理的測試反饋工具讓開發人員更早定位和解決問題。

說到團隊的研發和項目管理的實踐，就逃不開先要說一下筆者所在公司研發和項目管理中的工具作為背景：

• 即時交流和協作：QQ
• 辦公信息平臺:諾明
• 代碼管理：SVN
• Jar管理：Nexus
• 項目管理：Redmine
• 持續集成：Jenkins、ansible

切入正題，本篇分享涵蓋的是在研發過程和項目管理流程，以及當中在DevOps上做的一些努力去優化開發人員的體驗，就試著從各個環節總結一下：

• 研發環境的搭建：包括如何kick off新開發者，如何搭建日常開發環境
• 代碼的管理：包括源碼管理，Code Review和組織公共庫
• 需求在研發中的生命周期管理：包括功能需求清單，功能需求定義和其中的開發任務項分配和狀態管理
• 項目進度的管理：包括如何通過Redmine有效的執行敏捷開發
• 研發階段的產品測試和反饋：包括在產品測試和反饋中的一些經驗和工具分享
• 持續集成和持續發布：包括如何針對Web, Android和iOS分別搭建持續集成和發布

一、研發環境的搭建

如何讓團隊新的開發者盡快上手

對新的開發人員，一般都會有開賬號，裝系統，配環境，跑代碼這些過程，我自己發現每次都低估這些工作的耗時，以前就發現有時候不小心就一兩天過去了還沒跑起來代碼，一兩周還沒搞清楚目前產品的功能，我總結了幾點加快這個進度的方法：

1.加快賬戶開通和權限分配的速度。

筆者公司的帳號包括OA，svn，nexus，redmine，ftp，jenkins，Sonar。這些系統的用戶管理和權限無非基本都是通過數據庫或者xml進行管理，那麽是否可以梳理規則然後通過自動化來實現呢？

• 整理各系統，角色、權限對應的sql表和字段或xml鍵值對
• 開發同步小程序，建立
  OA同步至其他系統的相應場景(創建、禁用、密碼修改、職位調整等等)
  

2.加快開發IDE環境搭建的速度

同一產品部門或同一工種日常所使用研發IDE環境，基本都是一樣的，難道要每一個新入職的同事如果都自行去確認IDE，下載和安裝？我們可以統一研發所需使用的IDE組件和版本組裝成一鍵安裝包。

• 收集研發IDE工具及版本。如svn，Eclipse、maven、ant、xshell及其他
• 統一組件安裝目錄。如：D:/develop
• 編寫環境插入bat文件
• 編寫環境檢查，開發指引文件，開發標準規範配置說明
• 通過Winrar創建自解壓包，自動安裝相應軟件，執行bat配置環境變量

(註：環境插入的bat文件，部分windows系統版本無法插入，需手動添加)

3.加快能讓代碼跑起來的速度

有很多可以加速的環節，一個比較重要的就是自動構建代碼，就是指開發人員checkout代碼後通過簡單的構建腳本就能完成代碼依賴安裝，代碼編譯，單元測試運行，也就是我們常說的跑起來。以Web為例，可以通過maven的pom完成依賴的安裝、代碼的構建和版本提交，這也是持續集成的基礎。

4.對產品功能需求和目前進度的了解

保持盡量清晰的需求定義，新的開發人員可以通過瀏覽產品的需求文檔來了解產品功能。

可以知道以前每個版本都做了什麽功能，未來有什麽功能正在排期中：

如何方便開發人員進行日常開發調試

目前對於Web開發來說，一般構建的過程中代碼都會進行環境文件DLL/SO,CDN地址等替換、CSS Sprite生成等等操作，造成配置切換很不方便，我們采取的解決方法是在web的maven構建流程中分不同的Build Target，自動構建切換至對應環境配置，連接對應數據庫，方便Web開發人員調試。

二、代碼管理

首先最重要的就是代碼必須用源碼管理工具，我們一直用的SVN。代碼的查看和管理都在SVN服務器上，可以查看代碼，code review，合並分支，打版本tag之類的。

有兩點我覺得需要關註的：

1.怎麽讓開發人員高效的使用第三方庫

項目開發的過程中去抽象公共組件，使用第三方庫或開發工具都可以提高開發效率，但需要做好模塊和版本管理，有時候碰到一個開發人員引入了一個不合理的依賴，或者學習成本陡峭的組件，每個參與開發人員都要增加學習成本。這個一般都是根據不同的技術棧有相應的一套工具可以使用，在java開發上我們使用的是Nexus來管理， iOS、Android上面也有自己習慣的選擇，需要加新的組件或者替換正在使用的通過專家小組評審討論之後加入，以免發生重復或者後期的分歧。

2.如何做新功能開發的代碼管理

只要多人開發，而且多功能並行開發都避免不了要考慮如何管理代碼。一般有Brunch和Trunk開發兩種

傳送門：SVN版本管理

三、需求在研發中的生命周期管理

對於開發人員來說，開發工作一般是圍繞著具體的功能需求進行的，而 "清晰的需求定義"就是研發的主要輸入，由負責的PM來主導需求(User Story)的狀態更新，本節以一個功能需求(User Story)為例，先上一個時序圖來說明單個功能在研發中的生命周期是什麽樣的：

從功能需求(User Story)的時間線上可以看出來其分為下面幾個狀態：

可以劃分為需求確認，需求開發，需求測試和上線三個階段：

1. 需求確認

對於需求文檔的編寫和確認，不同團隊方式不一樣，我的理解是包括功能需求的前置條件和後置條件，用戶流程和規則，完整的產品交互原型，評審確認的設計稿。

2. 需求開發

在需求定義清晰後，開發前需要整個開發團隊的參與確認任務的分配。任務分配的原則就是將功能需求對應的任務按樹形結構分解，敏捷開發裏的學名是"Work Breakdown Structure (WBS)"，保證其中每個任務都是可以開發，並且是可以測試的。

具體到其中一個單獨的任務項(Task)，裏面會有它所屬的功能需求(User Story)，當前的狀態，優先級，任務指派的開發者，任務所屬的產品線，一個簡單的任務描述的，所屬的裏程碑，預計開發時間和結束時間，任務當前的狀態和進度等等。

從上文中"需求在研發中的生命周期"的時序圖上可以看出其對應的任務的生命周期是如何管理的，包括前端和後臺之間的任務協作是如何完成的，簡單來總結的話Task有下面幾種狀態：

開發人員主要負責的就是開發的同時更新自己任務的狀態，狀態蠻多，如果開發需要每次登錄redmine來改也確實蠻累，在實踐的過程中我們可以引入一些優化的方法：

• 為Redmine自定義一些SVN hooks來更新狀態。通過自定義SVN提交語法，讓SVN提交能自動更新在Redmine相應的版本更新上。
  • 參考資料：SVN提交後自動更新Redmine版本庫
    
• Server端接口文檔自動生成。在需求定義裏可以將規則和邏輯寫的很清楚，但在前端和服務端協作開發的過程中，如果服務端沒有文檔可能會經常被前端打斷，詢問接口具體參數的名稱或參數類型，也是比較煩的事情，可以考慮用工具來統一管理和自動生成文檔，我們使用的""。
• 開發中的持續集成和交付。這個後面會專門來講如何操作，具體的意義就是開發人員提交代碼之後，在服務器上進行自動構建和發布，這樣一方面每次提交都做Sonar檢查，有單元測試的做單元測試，降低代碼最後集成的時候出現問題的風險，另一方面讓PM可以盡早的接觸到成品，盡早進行反饋。

3. 需求測試和上線

當單個功能需求下面對應的所有任務都開發完成後，由PM進行測試和反饋，在確認與PRD一致後可以由PM更新為"待測試(Wait for test)"。這裏"待測試(Wait for test)"的意義就是該功能需求可以在發布到測試服務器(Test Server)，由業務及測試團隊參與測試。當測試沒有問題後，如果是Web功能則根據上線計劃上線到Production Server；如果是Native App，則按照版本計劃，可能需要固定時間發布或者等待幾個功能完成後一起發布上架（部分公司可能會有灰度發布的過程）。

由於這裏講的是單個功能需求的研發周期，而測試和上線更多是在整個項目這個 範圍 上來討論，所以針對測試和上線的部分在後面持續集成和發布的部分會來細說。

四、項目進度的管理

順著上面的思路，當你有單個需求研發的流程後，整個項目的管理就是管理所有的需求，安排優先級和叠代計劃，然後對所有需求進行同樣的研發流程管理。敏捷開發裏把一個叠代周期稱為一個Sprint，每個Sprint做一次產品發布，然後回顧Sprint內的問題，規劃下一個Sprint的開發任務，如下圖：

筆者公司的的實踐並非Scrum，但比較接近，我們的叠代比較頻繁，通常每周至少都往Production上做一次同步。項目的進度管理推薦參考Scrum的實踐裏的三個Meeting：

• Sprint Planning Meeting：從整個產品的Product Backlogs裏一起規劃出下一個Sprint要完成的功能，可能對應著很多團隊的需求評審會
• Daily Standup Meeting：在一個Sprint裏每天和開發人員一起回顧昨天的開發進度，討論碰到的問題和確認當天的工作計劃，其實對應著為開發人員詬病的項目日報
• Sprint Review Meeting：在一個Sprint結束回顧項目進度，問題和下一個Sprint的計劃，一般對應著PM要做的項目周報

在這三個Meeting上PM會和開發人員或者產品負責人進行接觸，如果這裏體驗不好就會影響項目的管理。其實我們試點的優化方案也比較簡單，就是通過項目管理工具Redmine去實現的功能需求和開發任務的"看板"：

關於redmine的實踐後面我單獨寫一篇文檔來介紹。

五、研發階段的產品測試和反饋

產品發布到測試渠道後的反饋

當產品發布到測試渠道就是希望在正式發布前得到業務和測試團隊的反饋，對比開發人員的測試反饋，業務和測試團隊的反饋會更專業、清晰、充分，這些反饋需要通過相應的工具來進行管理：

• 我們使用的BUG反饋工具是禪道，可以明確缺陷的類型，等級，可記錄具體的場景並添加貼圖，並有指派和BUG跟進報表等相關功能。需要了解的可以百度"禪道"（我並沒有收他們的廣告費）。

六、持續集成和持續發布

Native App因本身業務和市場占有的需求，一個重要的痛點就是不停叠代業務、發測試版、進行測試，但對於移動app來講之前每次打包都需要打斷開發人員，等待編譯，改文件名加版本號，上傳等一系列繁瑣的過程，然後還經常因為客戶沒有裝最新版而造成溝通時間的浪費，所以早期我們就開始著手建立持續集成和持續發布體系來避免這些問題。

一個完善的持續集成應該包括代碼提交後的構建->部署->測試->發布幾個階段，兩張圖對比應用持續集成和持續集成之後的研發過程：

然後這張圖是我們目前實現的持續集成過程：

自動構建

Jenkins支持定期檢測SVN代碼更新，會在代碼提交成功後能在持續集成服務端(CI Server)觸發相應的Server，Web，iOS或android端的自動構建。

持續部署

部署分為客戶端部署和服務端部署兩種，就是構建以後要把可運行的代碼發布到相應的服務器和手機端。

持續測試

分為單元測試和集成測試，理論上來說能在持續集成的過程中執行測試，是對產品質量極大的提升，不過對團隊的規模和時間要求比較高，一般還是按自己的實際情況來，非長期維護產品慎用，建議做產出分析。

持續交付

持續集成後的持續發布是我們主要需要解決的痛點，發布的對象分別是給開發和測試人員的Dev版，給測試團隊的Test版和給最終線上用戶的Production版，發布的渠道又分為Web端和Mobile端，需要分別來考慮：

將發布的dev,test和production分為三個不同的服務器：

• Dev服務器由Jenkins檢測來觸發，每次代碼提交都會觸發構建，然後Redmine發郵件給相關負責人，同時集成新版本到Dev上。
• 對於Test服務器就是當有新功能測試完成，準備上線的時候，就先同步到Test服務器上，通知測試團隊下載測試。
• 生產的正常的流程就是當測試通過之後，按照確認要上線的功能進行發布。

產品團隊管理 - 統一研發環境，提效研發過程