近期根據我們DevOps開發團隊敏捷開發項目的實踐經驗，將完整流程整理如下，這份規程也不完全算是敏捷專屬的項目管理規程，主要是在結合我們公司實際的情況下編寫出來的，大家在實際過程中可以參考。
1. 目的
規范軟件產品開發項目管理過程，指導開展項目研發、管理等活動。
2. 適用范圍
本章程的作用范圍為軟件產品開發立項至結項管理過程。
1.對項目經理開展產品規划及設計活動以及項目管理手段和應遵循的開發流程提供了指導；
2.對項目團隊的日常管理活動及內容進行了指導；
3. 角色及職責定義
Scrum Master——項目負責人、項目經理
保護團隊不受外界干擾，是團隊的領導和推進者，負責提升 Scrum 團隊的工作效率，控制 Scrum 中的“檢視和適應”周期過程。與 Product Owner 一起將投資產出最大化，他確保所有的利益相關者都可以理解敏捷和尊重敏捷的理念。
Product Owner——產品負責人、產品經理
確定產品的功能，拆分用戶故事。
需求功能確定優先級。
接受或拒絕開發團隊的工作成果。
參與產品開發過程中的有關會議。
UI
根據用戶故事，負責產品的功能交互及界面設計
組織開展人機交互及用戶體驗，不斷跟蹤改進，提高產品表現力。
參與產品開發過程中的有關會議。
開發
根據用戶故事，負責產品的技術架構設計及功能開發
評估、設計及維護產品相應模塊，確保模塊的穩定性、易用性、高效性。
參加產品開發過程中的有關會議。
測試
根據用戶故事，設計產品測試標准，確保產品品質滿足市場需求。
合理分配測試資源，組織產品測試並優化測試流程及測試標准，提高測試效率。
編寫產品測試用例，提交測試問題，編寫測試總結報告，以測試角度來確定產品版本是否發布。
4. Scrum中的產出物
Product Backlog——Backlog 待開發項，積壓的任務。
產品 Backlog 包括了所有需要交付的內容，其內容根據業務需求的價值順序排列，每個 Backlog 的優先級是可以調整的，需求是可以增減的，因此產品 Backlog 將根據不斷增長來持續驅動維護。
Sprint Backlog——Sprint 本意為“沖刺”，指迭代周期，長度通常是一至兩周。
在 Sprint 開始前，定義本次 Sprint 要討論的“Sprint Backlog”，從中產生本次 Sprint 要完成的 “已定 Product Backlog”。
已定 Product Backlog是 Sprint 計划會議的產物，它定義了團隊所接受的工作量，在整個 Sprint 過程中它將保持不變。
User Story、Task——用戶故事、任務
用 User Story 來描述 Sprint Backlog 里的項目，User Story 是從用戶的角度對系統的某個功能模塊所作的簡短描述。一個 User Story 描述了項目中的一個小功能，以及這個功能完成之后將會產生什么效果，或者說能為客戶創造什么價值。一個 User Story 的大小和復雜度應該以能在一個 Sprint 中完成為宜。如果 User Story 太大，可能會導致對它的開發橫跨幾個Sprint，此時就應該將這個 User Story 分解。為了能夠及時，高效地完成每個 Story，Scrum 團隊會把每個 Story 分解成若干個 Task。每個Task 的時間最好不要超過8小時，保證在1個工作日內完成，如果 Task 的時間超過了8個小時，就說明Task的划分有問題，需要特別注意。
障礙 Backlog——問題列表，積壓的待處理事務。
列舉了所有團隊內部和團隊相關的和阻礙項目的進度的問題，Scrum Master 需要確保所有的障礙 Backlog 中的問題都已分配並可以得到解決。
5. 項目管理過程
按照產品開發過程，可將整個過程分為項目啟動、需求設計、開發測試、上線、運營跟進。下面分別闡述在每個階段過程中該如何進行。
5.1 需求啟動
通常是從准備項目啟動會到召開會議這個階段，需要完成項目目標，需求范圍的初步確認，項目團隊成員，其他資源的安排。
確定本次開發的初步目標並達成共識
對於項目目標，需要和干系人在以下幾點上達成共識：
項目的背景、目標用戶、核心人員及產品定位是什么
各人員在項目中扮演的角色和對項目的作用是什么
5.2 需求設計
將確定的需求整理並輸出WIKI文檔及產品原型
召開需求啟動會，參加人員包括：項目經理及項目團隊、其他干系人代表
主要議題包括：申明本期開發目標范圍及對組織目標的貢獻。
設定期望，統一思想
文檔內容的宣講。
5.3 開發測試
A、迭代N的需求細化
考慮每個迭代需要完成的用戶故事；
用戶故事需包含幾個部分，工作量評估、功能性需求、非功能性需求。
用戶故事編寫完成后需要在團隊內部進行需求評審，一方面是為了向團隊成員解讀該需求，另一方面團隊成員也可在評審時給出指導性意見。
B、測試用例評審
測試人員根據用戶故事要求編寫對應的測試用例，並組織項目團隊進行測試用例評審。根據評審意見修改測試用例
C、開發
將用戶故事的需求開發的過程。
D、開發自測
在開發過程中，每完成一個功能點，都需要及時的進行開發自測並通知產品策划人員進行驗收體驗。
代碼提交可通過更新Jira任務的狀態來關聯Gitlab中代碼的提交及狀態更新。
E、驗收
開發完成后，產品策划需要對開發完成的成果進行驗收，驗證其是否符合用戶故事的要求，驗證通過后方可流到測試環節，否則需與開發詳細討論其不符合性，其驗收的checklist可做比較。
F、測試和回歸
提交測試時，必須要有正確的版本。測試人員根據測試用例進行測試，在Jira中提交測試bug，並根據測試的角度給出產品是否發布的意見。
G、bug修改
在Jira中獲取分配給自己的bug進行修改。
H、預生產發布
迭代一定版本后，在發布生產之前進行預生產測試。
5.4 上線
預生產測試通過后發布生產。
5.5 運營跟進
每日站立會
組織者輪流擔任，負責控制節奏，記錄問題，以備會后跟蹤。
每人講自己昨天做了什么，有什么問題，今天的計划是什么；
其他人了解別人的工作情況，並發現指出可能存在的問題。
對於發現的問題，鼓勵認領，其余由項目經理指定責任人。
時間通常控制在15分鍾內。
會議期間，更新任務牆。
周報：（1、反饋項目計划的執行情況，強調本周工作要達成的目標；2、暴露出項目的問題，特別是需要領導或其他團隊需要協助的問題。周報可在IT平台中輸出。）
迭代回顧：每人講述本次迭代做的好的地方和不好的地方，回顧上個迭代不好的地方，看看改進情況。
6. 總結階段
項目經理指導產品經理收集總結項目的產品運營數據（度量指標），同時指導團隊成員從自身角色進行總結，包括測試、開發、UI等。
由PM將過程文檔和經驗教訓總結進行歸檔並制定改進產品計划。