（我本來計劃將研發環境和管理流程分開來講的，最後還是放在一起便於理解。）
軟體研發最重要的場景就是在有限的時間和資源下把需求落地為產品/專案，也就是研發和專案管理，毫無疑問，這個階段的主角是開發人員。
是不是應該多思考下怎麼面向開發人員來優化整個研發過程和專案管理流程？
本文將介紹如何通過優化開發環境搭建、程式碼管理來提高研發過程中開發人員效率，並通過持續整合和交付讓開發中的問題更早暴露，通過合理的測試反饋工具讓開發人員更早定位和解決問題。
說到團隊的研發和專案管理的實踐，就逃不開先要說一下筆者所在公司研發和專案管理中的工具作為背景：
-
即時交流和協作：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)的時間線上可以看出來其分為下面幾個狀態：
可以劃分為需求確認，需求開發，需求測試和上線三個階段：
|
PM建立後協作編寫需求文件(New) -> 需求確認(Confirmed) -> 開發中(In Progress) -> 待測試(Wait for test) -> 已完成,可以上線(Finished) -> 完成,可以關閉(Closed) |
1. 需求確認
對於需求文件的編寫和確認，不同團隊方式不一樣，我的理解是包括功能需求的前置條件和後置條件，使用者流程和規則，完整的產品互動原型，評審確認的設計稿。
2. 需求開發
在需求定義清晰後，開發前需要整個開發團隊的參與確認任務的分配。任務分配的原則就是將功能需求對應的任務按樹形結構分解，敏捷開發裡的學名是"Work Breakdown Structure (WBS)"，保證其中每個任務都是可以開發，並且是可以測試的。
具體到其中一個單獨的任務項(Task)，裡面會有它所屬的功能需求(User Story)，當前的狀態，優先順序，任務指派的開發者，任務所屬的產品線，一個簡單的任務描述的，所屬的里程碑，預計開發時間和結束時間，任務當前的狀態和進度等等。
從上文中"需求在研發中的生命週期"的時序圖上可以看出其對應的任務的生命週期是如何管理的，包括前端和後臺之間的任務協作是如何完成的，簡單來總結的話Task有下面幾種狀態：
|
新建 -> 開發中 -> 待程式碼複查(目前僅junior developer需要被code review) -> 待測試 -> 反饋 -> 完成(可以上線) -> 關閉(上線以後可以關閉) |
開發人員主要負責的就是開發的同時更新自己任務的狀態，狀態蠻多，如果開發需要每次登入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伺服器上，通知測試團隊下載測試。
-
生產的正常的流程就是當測試通過之後，按照確認要上線的功能進行釋出。