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

（我原本計劃將研發環境和管理流程分開來說的，最後仍是放在一塊兒便於理解。）

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

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

 

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

 

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

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

 

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

 

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

 

1、研發環境的搭建

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

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

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開發人員調試。

 

2、代碼管理

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

有兩點我以爲須要關注的：

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

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

 

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

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

傳送門：SVN版本管理

3、需求在研發中的生命週期管理

對於開發人員來講，開發工做通常是圍繞着具體的功能需求進行的，而 "清晰的需求定義"就是研發的主要輸入，由負責的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，則按照版本計劃，可能須要固定時間發佈或者等待幾個功能完成後一塊兒發佈上架（部分公司可能會有灰度發佈的過程）。

因爲這裏講的是單個功能需求的研發週期，而測試和上線更可能是在整個項目這個 範圍 上來討論，因此針對測試和上線的部分在後面持續集成和發佈的部分會來細說。

4、項目進度的管理

順着上面的思路，當你有單個需求研發的流程後，整個項目的管理就是管理全部的需求，安排優先級和迭代計劃，而後對全部需求進行一樣的研發流程管理。敏捷開發裏把一個迭代週期稱爲一個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的實踐後面我單獨寫一篇文檔來介紹。

 

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

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

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

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

6、持續集成和持續發佈

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服務器上，通知測試團隊下載測試。
• 生產的正常的流程就是當測試經過以後，按照確認要上線的功能進行發佈。