1、敏捷開發項目的管理流程導語：對于敏捷開發項目的管理流程，相關人員要清楚。下面是收集的敏捷開發項目管理流程，供各位閱讀和參考。前段時間給大家了敏捷開發的流程，最近在敏捷開發項目的流程和管理制度，其的項目管理規程如下，這份規程也不完全算是敏捷專屬的項目管理規程，主要是在結合我們公司實際的情況下編寫出來的，大家在實際嵌入到公司的過程中可以參考下，不能照搬。1. 目的規范互聯網軟件產品開發項目管理過程，指導開展項目研發、管理等活動。2. 適用范圍本章程的作用范圍為互聯網軟件產品開發立項至結項管理過程。1. 對項目經理開展產品規劃及設計活動以及項目管理手段和應遵循的開發流程提供了指導；2. 對項目團隊的

2、日常管理活動及內容進行了指導；3. 角色及職責定義項目經理：進行產品開發過程中的業務目標、進度、成本、質量控制。挑選項目團隊并進行團隊建設，激發、鼓舞和改進團隊的生產效率。識別項目干系人，定期向干系人匯報，并作為團隊和外部的接口，屏蔽外界對團隊的干擾。確保項目中流程被遵循，組織、監督、培訓項目各實踐活動。產品策劃確定產品的功能，拆分用戶故事。需求功能確定優先級。接受或拒絕開發團隊的工作成果。參與產品開發過程中的有關會議。UI根據用戶故事，負責產品的功能交互及界面設計組織開展人機交互及用戶體驗，不斷跟蹤改進，提高產品表現力。參與產品開發過程中的有關會議。開發根據用戶故事，負責產品的技術架構設計及

3、功能開發評估、 設計及維護產品相應模塊，確保模塊的穩定性、易用性、高效性。參加產品開發過程中的有關會議。測試根據用戶故事，設計產品測試標準，確保產品品質滿足市場需求。合理分配測試資源，組織產品測試并優化測試流程及測試標準，提高測試效率。編寫產品測試用例，提交測試問題，編寫測試總結報告，以測 試角度來確定產品版本是否發布。4. 項目管理過程按照互聯網軟件產品項目開發過程，可將整個項目管理過程分為立項過程、規劃過程、執行與監控過程、結項過程。下面分別闡述在每個階段過程中該如何進行項目管理。4.1 立項過程 互聯網軟件產品開發項目的立項過程，通常是指從準備項目啟動會到召開會議這個階段，在立項過程中，

4、需要完成項目目標，需求 范圍的初步確認，項目團隊成員，其他資源的安排。確定項目的初步目標并達成共識 對于項目目標，需要和干系人在以下幾點上達成共識： 項目的背景、目標用戶、核心人員及產品定位是什么 項目的資源投入預算是多少 項目的資源投入是多少 各人員在項目中扮演的角色和對項目的作用是什么準備啟動會議文檔 文檔內容包括：用戶畫像 產品定位 市場策略 業務目標技術可行性 研發成本預算路標規劃召開項目啟動會參加人員包括：管理層代表項目經理及項目團隊其他干系人代表主要議題包括：申明項目目標范圍及對組織目標的貢獻。管理層正式任命PM設定期望，統一思想文檔內容的宣講。與PM小組確定項目管理要求項目啟動會

5、完成后，需要與PM小組成員確定項目立項機制以及 公司項目管理要求。4.2 規劃階段在規劃階段，團隊需要共同完成產品的版本規劃，迭代計劃版本規劃從產品的關鍵特性列表中按照優先級規劃產品每個版本需要完成哪些特性，在規劃完成后需要在項目干系人內達成共識。具體可參考版本規劃樣例迭代如何劃分迭代劃分是指將特性列表拆分形成用戶故事列表，并將其對應的主要任務劃分到各個迭代中去，形成粗粒度的項目迭代計劃。這個過程主要考慮以下幾個因素：有些任務間是有依賴關系，某個任務的開始或結束是以另一個任務的開始或結束為前提，在劃分時必須考慮這種前后依賴關系。在安排每個迭代的任務時，需要對各種因素進行綜合考慮，如平衡每個迭代

6、中任務的技術難度和價值差異。除了進行初步的迭代任務劃分，還需要確定項目過程中迭代任務調整的規則，如迭代任務未完成時是將剩余任務延至下一迭代還是延長迭代周期。確定人員分工項目經理需要根據每個人員的能力和特點， 初步擬定大致分工。在進行任務分工時需考慮以下因素：任務難度與人員能力相匹配，對于明顯超出能力范圍或過于簡單的任務容易造成負面影響。耦合度高的盡量分配給同一個人，避免不必要的溝通消耗。鼓勵團隊內部“任務認領”，提高人員的工作積極性和主動性。確定迭代運行模式如一周迭代、兩周迭代，每個迭代包含的工作內容等。具體的迭代計劃可參考迭代計劃樣例制定其他輔助計劃制定溝通計劃、風險計劃和質量計劃是必要的，

7、溝通計劃主要包含以下幾個方面：溝通對象、溝通方式、溝通頻率即可，如：風險計劃包括風險項、負責人、重要性、應對措施，如下：質量計劃包括：bug 分布滿足何種條件可以發布，有幾個致命bug必須停止開發新特性等。搭建基礎技術架構如果是一個全新的項目，需要重新開發系統框架，則這個工作應該在迭代0 完成， 否則會影響后期的工作開展。系統框架的每次改動必然會導致大量的重復工作量，從而給穩定的團隊節奏帶來很大的毛刺。4.3 項目執行和監控過程迭代N的執行A 、迭代N的需求細化考慮每個迭代需要完成的用戶故事；用戶故事需包含幾個部分，工作量評估、功能性需求、非功能性需求。具體的可參考用戶故事模板及樣例及拆分說明

8、用戶故事編寫完成后需要在團隊內部進行需求評審，一方面是為了向團隊成員解讀該需求，另一方面團隊成員也可在評審時給出指導性意見。B 、測試用例評審測試人員根據用戶故事要求編寫對應的測試用例，并組織項目團隊進行測試用例評審。根據評審意見修改測試用例C 、開發將用戶故事的需求開發的過程。D 、開發自測在開發過程中，每完成一個功能點，都需要及時的進行開發自測并通知產品策劃人員進行驗收體驗。E 、驗收開發完成后，產品策劃需要對開發完成的成果進行驗收，驗證其是否符合用戶故事的要求，驗證通過后方可流到測試環節，否則需與開發詳細討論其不符合性，其驗收的checklist 可以參考 產品驗收 checklist

9、及模板F 、測試和回歸提交測試時，必須要有正確的版本。測試人員根據測試用例進行測試，在IT平臺中提交測試bug,并根據測試的角度給出產品是否發布的意見，輸出測試報告G 、 bug 修改在IT平臺中獲取分配給自己的bug進行修改。H 、 showCase階段性必須有可體驗版本進行showcase.需要確定showcase時間：某個迭代開發、自測完成，準備提交測試前會議前 1-2 天發出體驗版給到參與人員會議期間，由項目經理組織大家體驗、反饋問題、記錄問題。項目經理根據問題情況，與開發或產品確定問題的解決時間并發出會議紀要。I 、灰度發布迭代一定版本后，由項目經理與團隊共同決定是否需要進行灰度發布

10、。監控方式每日站立會主持人輪流擔任，負責控制節奏，記錄問題，以備會后跟蹤。每人講自己昨天做了什么，有什么問題，今天的計劃是什么；其他人了解別人的工作情況，并發現指出可能存在的問題。對于發現的問題，鼓勵認領，其余由項目經理指定責任人。時間通?？刂圃?5 分鐘內。會議期間，更新任務墻，任務墻樣式如下：周報反饋項目計劃的執行情況，強調本周工作要達成的目標暴露出項目的問題，特別是需要領導或其他團隊需要協助的問題。周報可在IT 平臺中輸出。月報反饋項目當月的執行情況，包括進度、人力及質量。反映項目存在的問題和風險。迭代回顧每人講述本次迭代做的好的地方和不好的地方 回顧上個迭代不好的地方，看看改進情況。讓每個人發言。每次迭代回顧會議完成后，可更