CODING 如何使用 CODING 研發管理系統來敏捷開發

以前咱們分享過《CODING 如何使用 CODING 開發 CODING》的文章，時過境遷，如今 CODING 研發管理系統已經上線瞭如持續集成、缺陷管理、測試管理等 DevOps 中的重要功能，並增長了對 SVN 的支持。藉此機會咱們以自身的研發流程爲例，來展現一下 How CODING uses CODING to build CODING 2.0。

企業級一站式軟件研發協做平臺

CODING 如今的團隊有 100 多人，分佈在全球各地（深圳、北京、成都、西雅圖等），均使用 CODING 研發管理系統做爲雲端協做平臺。在 CODING，不只研發相關的團隊使用 CODING 來進行研發管理，市場、運營、行政的部門也一樣使用 CODING 進行任務分配與追蹤、文件分享等平常工做。

同時經過 CODING 的企業微信/微信小程序，還能實現隨時隨地同步與協同任務，小程序能夠直接查看任務詳情、評論任務，還能實現代碼合併（MR）等功能，真正作到 Coding Anytime Anywhere。

CODING 研發管理系統是基於項目進行的，咱們依據組織架構創建了相關項目並使用【成員管理】添加相應部門的人員。經過項目這種扁平化的管理形式，幫助企業加快反應速度，提升自身敏捷性。

下週即將上線的 CODING 權限管理功能，能夠幫助項目管理員方便地根據項目成員角色來分配相應的權限，減小誤操做帶來的安全隱患。同時支持自定義用戶組，增長研發管理的靈活性。

Push Everything,Review Everything,CI Everything

workflow

CODING 研發部門的工做流都是在項目內進行：咱們使用任務功能來管理需求，使用文件來保存產品原型，使用代碼功能進行開發，使用持續集成來進行自動化測試，使用缺陷管理來收集反饋，同時還使用 wiki 模塊對知識進行儲存與共享。經過在任務中添加關注者的方式來方便相關同事隨時 follow 和 review 任務動態。

CODING 強大的任務系統支持標籤、跨項目引用、版本控制等多項功能，並會實時記錄用戶的每一次操做。同時 CODING 需求管理功能也即將上線，將在任務系統以外爲用戶提供更細分更場景化的使用方式。

產品

CODING 的產品經理在正常的產品功能排期以外，會按期在缺陷管理中查看用戶的使用反饋並對相關問題的修復進行排期。

當產品經理研究決定咱們要實現某一個功能/修復缺陷時，會以任務的形式發佈該需求。可是在發佈需求以前有幾件事情須要先作。

給任務定性

產品經理會把任務放入「需求反饋池」看板，並給任務定性：

• 純技術問題（含純技術 Bug），則指派給研發負責人進行跟進。
• 純設計問題，則指派給設計負責人進行跟進。
• （真）產品問題，則準備與發任務的源頭溝通分析此問題。

問題分析

• 僞需求，或者反饋方理解有誤，則直接在相關任務中回覆，並關閉任務便可。
• 真需求，則完善對應的背景信息，並將任務拖入「已分析需求池」。
• Bug 類，能夠內部請測試人員來嘗試復現此問題。若是可復現，則給此任務打上「Bug 池」、「已確認」標籤，再將任務放入「已分析需求池」。

分析完需求後便可建立任務，如該任務涉及大型產品改動，則會由相應產品經理撰寫完整的產品說明文檔和必要的原型圖等文件；方案完成以後，產品經理會根據任務的緊急程度給任務設定優先級，方便後續設計和開發的同事更方便的安排工做。

在產品設計過程當中，咱們使用 CODING 的文件管理功能對產品進行原型管理和版本管理。

功能開發完成後，產品經理還會配合研發進行 Staging 環境的驗收。如在 Staging 環境中發現問題，則須要與發佈負責人協商回退或是從新發版，成功完成驗收則通知運維上生產環節。

開發

在產品經理完成原型圖和產品說明後，便會把任務移交給研發負責人，進行評估和排期，完成排期後研發負責人會根據任務狀況安排里程碑。

開發人員開始基於本身的里程碑任務進行開發，其後的代碼評審也是經過項目內提交 MR （合併請求）進行的。

CODING 使用了 Feature Branch Workflow，即團隊成員共用一個私有項目倉庫進行管理協做，開發者在各自的 feature-branch 中進行開發。

Code Review

開發完成後經過提交 Merge Request 進行代碼評審，經過代碼評審後 merge 進入 master 分支（master 分支是可部署到 staging/生產環境的分支）。

持續集成

當開發人員 push 代碼時，將會自動觸發已設置好的持續集成，CODING 的持續集成會自動編譯並測試該 commit。CODING 持續集成支持在任意階段觸發並支持 cvm 模式。

當測試經過後，咱們會更新代碼到 Staging 環境。

測試

更新 Staging 的代碼後，測試人員開始進行相關測試。如今 CODING 的測試管理功能由 18 年收購的專業測試工具飛蛾（ FEIE.WORK）承載，已實現了企業帳號打通，可直接在測試管理中點擊跳轉到飛蛾的工做界面。

接到測試任務後，測試的同時會先在飛蛾中制定相應的測試計劃。

制定好測試計劃後，便可開始編寫相關測試用例並開始執行測試計劃。

Staging 環境測試無問題後，該功能會以 Feature Flags（內部測試新功能）的形式發佈其到生產環境，通知相關的產品或設計人員開啓 Feature Flags 進行內部 Review，若是存在問題或缺陷，咱們會新建一個任務進行產品反饋，確保功能及設計細節的正確性。

運營

產品正式上線後，CODING 的運營同事會開始收集用戶反饋，經過各個渠道反饋的問題都會在 CODING 缺陷管理功能中以建立缺陷的方式進行概括。

運營會按期將收集來的缺陷進行分析，將 Bug 類的缺陷轉給產品經理進行排期。如在生產環節發現重大 Bug 則會當即和產品經理溝通並通知運維，協商回退版本或者臨時修復。

市場

在確認功能順利上線後，產品經理會在 CODING Wiki 中更新 Roadmap，提示功能已經上線。方便市場部進行 Campaign 的計劃。

市場部的同事使用 CODING 任務管理中的討論功能，能夠實時討論和跟蹤項目進度。

讓開發更簡單

工欲善其事，必先利其器，在如今數字化的商業環境中，企業對於軟件的依賴已經達到了史無前例的高度。如何選擇一套適合中國軟件研發團隊的開發工具和高效的研發流程，以解放開發人員的效能，打造更好的產品，已經成爲每一個企業必需要思考的問題。逆水行舟，不進則退，咱們自身使用 CODING 進行開發，旨在不斷完善 CODING 的功能，優化提高 CODING 的使用體驗，讓 CODING 成爲最適合中國式敏捷的研發管理系統，真正作到讓中國的軟件研發團隊開發更簡單！

歡迎試用 CODING 研發管理系統，同時咱們也歡迎各類反饋，若是你有任何需求或建議，請不要忘了提交給咱們 :D

官方反饋渠道： 聯繫電話：400-930-9163 郵箱：enterprise@coding.net