本節課程為《研發工具鏈介紹》，我們將主要學習三個工具。項目管理工具—iCafe、代碼管理工具—iCode、交付平臺—iPipe。
此外我們知道，管理實踐具有以下三個特點：①用“精益”指引產品規劃；②用“敏捷”加速迭代開發；③用“數據”驅動持續改進。而本節課程學習的這三個工具，就是對管理實踐三個特點的完美覆蓋。

項目管理工具——iCafe

01 需求管理

需求管理是一個項目的基石。在互聯網行業中，因為產品需求迭代快速這一特點，需求管理一直非常令人頭疼。所以如何對需求進行更好的管理，更好的做出產品規劃對互聯網行業的項目來說是一個重要的問題。

傳統的需求管理方法有以下幾種：

①直接將需求寫在文檔上面，

②將需求制作成需求卡片，通過這樣的方式讓研發人員與需求人員保持信息的一致。

③使用Excel進行需求管理和排序。

這三種方法都存在很多的缺點，如撰寫文檔耗時長、文檔編寫需求較多人力、文檔維護成本高、文檔使用過程中溝通不暢等等。文字因為其閱讀特性，不方便對任務進行直觀的展現。所以在很多項目開發過程中，經常會出現文檔交給研發人員后，開發出的產品與文檔設計不一致的問題。

互聯網的需求管理需要具有需求完整性、溝通高效性、表達準確性，溝通便捷性等特點。

研究表明，不同的溝通方式產生的溝通效果各有不同。在所有的溝通方式中，文檔溝通是最低效的溝通方式，而面對面使用白板溝通是最高效的溝通方式。結合多種高效溝通方式，就產生了用戶故事地圖這種新穎的需求管理、排序的方式。

用戶故事地圖是敏捷項目管理中一種重要的管理方式。

首先使用卡片在白板上將所有的需求列出來，這樣有助于展現產品全貌，而且將需求轉化為可視的卡片能更好的根據用戶反饋對任務需求進行排序；

然后使用不同的顏色對卡片進行分層。藍色卡片是第一層，黃色卡片是第二層，白色卡片是第三層。將顆粒度最小的需求放在白色卡片這一層，低顆粒度的需求更容易被研發人員接受。

最后通過橫向的分組，把迭代計劃每一期的每一版本的需求進行歸類分組。這樣有利于打通產品視圖和研發計劃視圖。

通過以上步驟可以得到一個較為完整的用戶故事地圖。

用戶故事地圖是一種非常高效需求管理方式，目前所有的研發團隊都可以在效率云上不受物理條件限制的直接使用它進行需求管理和追蹤。

02 迭代計劃

在完成產品的版本規劃后，研發團隊需要制定相應的迭代計劃。敏捷、快速、合理地迭代計劃能夠更高效地促進項目的迭代。

基于用戶故事地圖，可以在制定迭代計劃的過程中中直接對需求進行上下拖拽修改優先級，左右拖拽更改計劃。這樣可以更清晰的展現迭代計劃，使開發團隊更好定位到的里程碑，完善整個迭代計劃。

03 進度追蹤

進度跟蹤，有三大法寶，他們分別是：站會、卡片墻、燃盡圖。

站會同卡片墻相結合，在站會過程中可以直接通過電子看板共享項目進度和項目問題，提升站會溝通效率。

通過燃盡圖和統計數據，團隊就能直接得知開發進度及遇到的問題。

04 持續改進

針對持續改進，我們提供了卡片狀態時長散點圖和卡片狀態累積流圖這兩種工具。

卡片狀態時長散點圖能夠精確展示團隊工作速率，從需求提出到需求上線的單個周期時長和平均周期時長，精確的展示團隊在每一個狀態的工作速率及工作速率的變化。

卡片狀態累積流圖能夠宏觀展示項目各流程效率趨勢，顏色的色塊寬表示該流程積壓的需求和任務比較多，色條變窄表明團隊狀態流動速率提高。

基于這兩幅圖工具，研發團隊可以周期性地進行自檢，對過去一段時間的工作進行自我審視，然后持續改進。

代碼管理工具——iCode

iCode是一個代碼管理工具，圍繞它我們主要講解兩個實踐集：工作流和評審。

01 工作流

運轉無序，開發混亂是困擾很多團隊的一個問題，它嚴重影響產品的交付。典型的問題有：代碼處理隨意、bug重復發生、測試不完善、發布版本混亂等。

面對種種問題，我們同時支持兩種標準的工作流，用來保障團隊有序協作。

（1）基于主干的工作流

在基于主干的工作流中，整個團隊維護一條主干分支。為了保證主干分支的質量，需要配套嚴格的準入機制，變更點在合入前需要經過機器、人工的雙重評審，通過后才能合入主干。

需要發布的時候，會基于主干拉取發布分支，這個分支其實是主干特定點的快照，單純用于發布，如果發布問題過程中發現問題，回到主干修復Bug或進行功能增強，必要時再將主干提交揀選到相應的發布分支上。

分支發布和主干并行不悖，不用擔心開發中的功能被帶到線上，發布完成后恢復到一條主干的簡明模式。

基于主干的工作流優點有：

①主干質量高，隨時可以發布。

②模型簡單，只有一條主干，節省分支合并的成本。

但是該工作流也有一定的缺點。在開發高質量的工程項目時，團隊需要建設完備的測試用例，在提交環節要求提交人保持原子提交，即功能和提交一一對應。

（2）基于分支的工作流

在基于分支的工作流中，主干用于存儲線上代碼，需要變更時，基于主干最新代碼開分支完成功能的開發、測試和發布；分支發布前，需要先同步主干的更新；上線之后，需要將分支合并回主干。

基于分支的工作流的優點有：

①分支并行，獨立開發，分支不會相互影響；

②對團隊而言，使用門檻低，分支貫穿一個獨立功能開發、測試、發布的整個過程，給予團隊充分的時間完善測試用例及完成人工測試；

③容易上手，系統會引導開發人員完成新建分支、同步主干、合會主干等全部操作。

但是基于分支的工作流也存在一定的缺點，如：需要花費分支合并的成本、需要不斷地同步主干，來發現分支的沖突風險點并提前解決。

02 評審

評審是保證團隊工程質量的一個重要的過程。如果不經過評審直接提交代碼，可能會污染代碼歷史，增加后期維護成本，嚴重時可能還會產生代碼質量問題。

在項目開發過程中，可能會出現本地運行正常的代碼，在測試環境或者線上環境突然崩潰的情況。針對這樣的問題，可以使用質量防護網。質量防護網包括代碼掃描、持續集成、人工評審三個層次。

代碼掃描能夠找出不符合代碼規范的地方，在行間距中插入代碼評論，同時出具一個風格報告，方便工程師對代碼風格問題進行修改。

持續集成會配置一個云端構建，通過云端構建，快速探測出代碼初期Bug，幫助開發人員提早修復。

在前兩步做好后，團隊的資深成員就可以就架構、邏輯、設計等問題進行深入評審。

通過這三步，實現了機器、人工雙重評審，層層遞進，確保團隊的工程質量。

交付平臺——iPipe

iPipe是一個交付平臺，圍繞它我們主要講解三個實踐集。

01 固化端到端的交付流程

標準的軟件交付的過程包括以下幾點：

首先會有一個明確的發布版本的輸入，

然后基于這個發布版本，會進行代碼提交。

代碼提交之后會進行編譯、測試。其中測試環節可能包含模塊級的測試和系統級的測試。

最后進行發布。發布上線的過程可能會分為預上線、生產灰度、生產全量幾個環節。

為了使代碼變更流程標準化，需要使用交付流水線的方式來落地。通過標準化交付過程從而達到可靠、可重復的作用。交付流水線是串行執行的，上一個階段成功執行后，就會觸發下一個階段。執行階段由任務組成，這些任務可以是穿行的也可是并行的。任務的執行狀態決定階段執行狀態。

iPipe這一工具目前包含了標準的交付流水線，用戶可以在iPipe中看到流水線的構建情況。在使用交付流水線的過程中，如果當前階段失敗，后面的階段就不會繼續進行，這樣可以節省資源并且快速的發現問題，及時修復問題。

02 插件化現有工具和服務

在交付流水線中執行各種任務時需要依賴很多工具和服務，比如maven，docker、jenkins、git等工具和服務。

我們通過一套標準的插件化開發規范將這些工具和服務集成到了流水線中，用戶在使用流水線的過程中就可以很方便的使用這些插件和服務。如果流水線中沒有想使用的插件、服務或工具，可以根據效率云提供的插件規范，自行擴展以滿足項目需求。

03 數據度量驅動過程改進

通過交付流水線，可以快速獲取項目所有的數據和信息，如：一個版本從代碼提交到交付上線的周期或者一個項目各個階段發現的缺陷數量等等。

用戶可以通過調用API獲取數據來進行數據的度量，從而推動交付過程的改進。在后續的發展中，平臺會識別項目中關鍵的數據指標并且自動化的形成更加鮮明的數據報表。這樣就可以持續的進行數據度量，給個人及團隊提供一個維度豐富的平臺。

點擊進入了解更多技術資訊~~

總結

以上是生活随笔為你收集整理的研发工具链介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

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