創業公司的研發架構：規範化研發流程

國內IT公司多如牛毛，但研發流程真正作到規範化的少之又少，不少公司看上去很「大」很NB，但卻只可遠觀，細看內部做業卻驚歎於龐大的軀殼下只是一個又一個的「小做坊」，毫無團隊間協做分享可言。大中型公司如此，小公司創業公司更不用說了。

在我大天朝不少公司的產品拼的不是技術不是功能而是關係，因此研發流程規範這檔子事不是企業必需品，尤爲在傳統行業遊弋的那些國有控股公司。但隨着競爭加重、互聯網化浪潮的洗禮，「高內耗低產出」的粗獷型做業勢必會走向滅亡，「短平快」的精細型研發做業流程勢必愈來愈受重視。

有感而發，扯了些廢話L，言歸正傳，規範化研發流程的做用不言而喻，但對於創業公司來講現實的問題是要先生存再圖發展，前期沒有太多的精力在流程管控上，因此一個好的適合於創業公司的規範化研發流程必定要足夠的省事簡單且效果明顯。

梳理一下咱們的痛點就是「人少事多時間緊，需求變動快人員流動大」，一個好的研發流程要能解決以上的問題，怎麼作？

1. 免打擾：腳手架的活讓工具去作，不要讓開發管理人員被流程所累；

2. 小版本快迭代：儘早地讓領導/客戶發現需求誤差，以便及時修正；

3. 需求共享及知識庫建設：讓全部開發人員都瞭解產品的需求並創建知識庫記錄學習開發心得，最大限度減小人員流動帶來的研發不可持續性；

4. 自組織，弱化管理：不要在管理上浪費太多時間，屁大的團隊開發人員遠比純粹的管理人員重要。

綜上實際上不少人發現這些理念與Scrum多麼雷同呀，不錯，咱們實踐下來以爲用裁剪後的Scrum作爲流程規範是很好的選擇，但完整的Scrum對開發人員要求太高，創業團隊每每不具有那樣的員工，因此必定要裁剪。

拿目前我所在的公司「聚路銷科技」舉例（不一樣的公司有其個體差別，僅供參考），下圖是咱們研發流程的TOP圖：

咱們總體上基於Scrum並適度裁剪，如Scrum要求Story時間點要全部開發人員在Sprint計劃會議中投票決定，咱們試行幾回下來實際須要時間與估算時間會嚴重不符合，爲何一個本來爲更準確計算工時的作法卻獲得拔苗助長的效果？緣由在於創業期招聘的開發人員經驗不足，考慮問題不夠全面，廣泛低估了各個Task的要求，因此在Story用時上咱們每每是技術經理作評估並在Sprint計劃會議時和開發人員確認修訂。

基礎研發流程與Scrum無異，關鍵步驟以下：

步驟名	參與人	產出	涉及工具
1.設計用戶故事	產品經理	Product Backlog	Redmine 用於記錄 Product   Backlog
2.Sprint計劃會議肯定Sprint週期、人員及要完成的故事	全部人	Sprint Backlog	Redmine 用於記錄 Sprint Backlog Raneto 用於簡述產品及Sprint信息造成知識文檔
3.編碼開發	開發人員	Code	Gitlab 用於版本控制 Jenkins 用於持續繼承，自動化測試發佈 Sonarqube 用於代碼質量檢查 Redmine 用於記錄 變動
4.每日站立會議	全部人	阻礙列表、Story、Task或Code修正	Redmine 用於記錄 變動
5.Sprint回顧會議	全部人	Sprint封包代碼、版本發佈	Gitlab 創建版本 Redmine 完成Sprint Raneto 總結經驗造成知識文檔

工具選擇的幾點見解：

在Scrum管理工具上咱們嘗試過白板、Trello、Redmine With Agile Plugin，各有優劣吧，白板直接，你們都看獲得，很方便，但不便於任務收集整理，Trello是個好東西，它有個開源實現版本（http://git.libreboard.com/libreboard/libreboard），看板視圖，可定製化流程，但統計上比較弱，Redmine With Agile Plugin（http://www.redminecrm.com/projects/agile/pages/1）嘛比較重，但功能強大，用它主要是咱們的績效考覈需要記錄每一個開發人員每一個Sprint的工時、每一個Task的技術係數、Task的重要程度等指標。

版本控制上通常公司用SVN，咱們用Git，說兩者有多大的區別嘛，對小團隊而言還真看不大出來，但咱們鼓勵開源，要求員工都要發佈本身的開源做品，因此用Git比較接地氣 :)

知識庫工具這裏用Raneto，這是個很簡單的Markdown文檔web化工具，你只要指定一個有MD文檔的目錄它就能夠把這些文檔Web化顯示，用的是NodeJS驅動，它還支持"GitHub Flavored Markdown"，能夠顯示錶格：

咱們流程是在Gitlab中創建知識庫項目，你們都clone這個項目，用本身喜歡的IDE撰寫MD文檔並push回Gitlib，而後Jenkins會自動clone出變動項到workspace下，咱們又在Linux中建了定時任務把Jenkins workscpase下的文件sync到Raneto的目錄，這樣就能夠顯示修改的文檔了。

Jenkins 與 Sonarqube沒什麼可說吧，同一領域應該找到其它更好的工具了。

另外補充一點是創業團隊硬件資源也比較有限，而管控工具很多，我的推薦用Docker去虛擬化這樣環境，好處是使用方便，不用安裝一大堆基礎環境（如ROR環境），安全明瞭，作到資源隔離，不會由於一個工具的問題致使其它工具被Hack。這方面有機會再單獨討論。附咱們目前的Docker容器：

經驗有限不足之處歡迎拍磚。