前段時間給大家整理了敏捷開發的流程，最近在整理敏捷開發專案的流程和管理制度，其整理的專案管理規程如下，這份規程也不完全算是敏捷專屬的專案管理規程，主要是在結合我們公司實際的情況下編寫出來的，大家在實際嵌入到公司的過程中可以參考下，不能照搬。
1. 目的
規範網際網路軟體產品開發專案管理過程，指導開展專案研發、管理等活動。
2. 適用範圍
本章程的作用範圍為網際網路軟體產品開發立項至結項管理過程。
1.對專案經理開展產品規劃及設計活動以及專案管理手段和應遵循的開發流程提供了指導；
2.對專案團隊的日常管理活動及內容進行了指導；
3. 角色及職責定義
專案經理：
進行產品開發過程中的業務目標、進度、成本、質量控制。
挑選專案團隊並進行團隊建設，激發、鼓舞和改進團隊的生產效率。
識別專案干係人，定期向干係人匯報，並作為團隊和外部的介面，遮蔽外界對團隊的干擾。
確保專案中流程被遵循，組織、監督、培訓專案各實踐活動。
產品策劃
確定產品的功能，拆分使用者故事。
需求功能確定優先順序。
接受或拒絕開發團隊的工作成果。
參與產品開發過程中的有關會議。ui
根據使用者故事，負責產品的功能互動及介面設計
組織開展人機互動及使用者體驗，不斷跟蹤改進，提高產品表現力。
參與產品開發過程中的有關會議。開發
根據使用者故事，負責產品的技術架構設計及功能開發
評估、設計及維護產品相應模組，確保模組的穩定性、易用性、高效性。
參加產品開發過程中的有關會議。測試
根據使用者故事，設計產品測試標準，確保產品品質滿足市場需求。
合理分配測試資源，組織產品測試並優化測試流程及測試標準，提高測試效率。
編寫產品測試用例，提交測試問題，編寫測試總結報告，以測試角度來確定產品版本是否發布。
4. 專案管理過程
按照網際網路軟體產品專案開發過程，可將整個專案管理過程分為立項過程、規劃過程、執行與監控過程、結項過程。下面分別闡述在每個階段過程中該如何進行專案管理。
4.1 立項過程
網際網路軟體產品開發專案的立項過程，通常是指從準備專案啟動會到召開會議這個階段，在立項過程中，需要完成專案目標，需求範圍的初步確認，專案團隊成員，其他資源的安排。
確定專案的初步目標並達成共識
對於專案目標，需要和干係人在以下幾點上達成共識：
專案的背景、目標使用者、核心人員及產品定位是什麼
專案的資源投入預算是多少
專案的資源投入是多少
各人員在專案中扮演的角色和對專案的作用是什麼
準備啟動會議文件
文件內容包括：
使用者畫像
產品定位
市場策略
業務目標
技術可行性
研發成本預算
路標規劃
召開專案啟動會
參加人員包括：
管理層代表
專案經理及專案團隊
其他干係人代表
主要議題包括：
申明專案目標範圍及對組織目標的貢獻。
管理層正式任命pm，設定期望，統一思想
文件內容的宣講。
與pm小組確定專案管理要求
專案啟動會完成後，需要與pm小組成員確定專案立項機制以及公司專案管理要求。
4.2 規劃階段
在規劃階段，團隊需要共同完成產品的版本規劃，迭代計畫
版本規劃
從產品的關鍵特性列表中按照優先順序規劃產品每個版本需要完成哪些特性，在規劃完成後需要在專案干係人內達成共識。具體可參考《版本規劃樣例》
迭代如何劃分
迭代劃分是指將特性列表拆分形成使用者故事列表，並將其對應的主要任務劃分到各個迭代中去，形成粗粒度的專案迭代計畫。這個過程主要考慮以下幾個因素：
有些任務間是有依賴關係，某個任務的開始或結束是以另乙個任務的開始或結束為前提，在劃分時必須考慮這種前後依賴關係。
在安排每個迭代的任務時，需要對各種因素進行綜合考慮，如平衡每個迭代中任務的技術難度和價值差異。
除了進行初步的迭代任務劃分，還需要確定專案過程中迭代任務調整的規則，如迭代任務未完成時是將剩餘任務延至下一迭代還是延長迭代週期。
確定人員分工
專案經理需要根據每個人員的能力和特點，初步擬定大致分工。在進行任務分工時需考慮以下因素：
任務難度與人員能力相匹配，對於明顯超出能力範圍或過於簡單的任務容易造成負面影響。
耦合度高的盡量分配給同乙個人，避免不必要的溝通消耗。
鼓勵團隊內部「任務認領」，提高人員的工作積極性和主動性。
確定迭代執行模式
如一周迭代、兩周迭代，每個迭代包含的工作內容等。
具體的迭代計畫可參考《迭代計畫樣例》
制定其他輔助計畫
制定溝通計畫、風險計畫和質量計畫是必要的，溝通計畫主要包含以下幾個方面：溝通物件、溝通方式、溝通頻率即可，如：
風險計畫包括風險項、負責人、重要性、應對措施，如下：
質量計畫包括：bug分布滿足何種條件可以發布，有幾個致命bug必須停止開發新特性等。。
搭建基礎技術架構
如果是乙個全新的專案，需要重新開發系統框架，則這個工作應該在迭代0完成，否則會影響後期的工作開展。系統框架的每次改動必然會導致大量的重複工作量，從而給穩定的團隊節奏帶來很大的毛刺。
3.3 專案執行和監控過程
迭代n的執行
a、迭代n的需求細化
考慮每個迭代需要完成的使用者故事；
使用者故事需包含幾個部分，工作量評估、功能性需求、非功能性需求。具體的可參考《使用者故事模板及樣例及拆分說明》
使用者故事編寫完成後需要在團隊內部進行需求評審，一方面是為了向團隊成員解讀該需求，另一方面團隊成員也可在評審時給出指導性意見。
b、測試用例評審
測試人員根據使用者故事要求編寫對應的測試用例，並組織專案團隊進行測試用例評審。根據評審意見修改測試用例
c、開發
將使用者故事的需求開發的過程。
d、開發自測
在開發過程中，每完成乙個功能點，都需要及時的進行開發自測並通知產品策劃人員進行驗收體驗。
e、驗收
開發完成後，產品策劃需要對開發完成的成果進行驗收，驗證其是否符合使用者故事的要求，驗證通過後方可流到測試環節，否則需與開發詳細討論其不符合性，其驗收的checklist可以參考《產品驗收checklist及模板》
f、測試和回歸
提交測試時，必須要有正確的版本。測試人員根據測試用例進行測試，在it平台中提交測試bug，並根據測試的角度給出產品是否發布的意見，輸出《測試報告》
g、bug修改
在it平台中獲取分配給自己的bug進行修改。
h、showcase
階段性必須有可體驗版本進行showcase.需要
會議前1-2天發出體驗版給到參與人員
會議期間，由專案經理組織大家體驗、反饋問題、記錄問題。
專案經理根據問題情況，與開發或產品確定問題的解決時間並發出會議紀要。
i、灰度發布
迭代一定版本後，由專案經理與團隊共同決定是否需要進行灰度發布。
監控方式
每日站立會
主持人輪流擔任，負責控制節奏，記錄問題，以備會後跟蹤。
每人講自己昨天做了什麼，有什麼問題，今天的計畫是什麼；
其他人了解別人的工作情況，並發現指出可能存在的問題。
對於發現的問題，鼓勵認領，其餘由專案經理指定責任人。
時間通常控制在15分鐘內。
會議期間，更新任務牆，任務牆樣式如下：
週報反饋專案計畫的執**況，強調本週工作要達成的目標
暴露出專案的問題，特別是需要領導或其他團隊需要協助的問題。
週報可在it平台中輸出。
月報反饋專案當月的執**況，包括進度、人力及質量。
反映專案存在的問題和風險。
迭代回顧
每人講述本次迭代做的好的地方和不好的地方
回顧上個迭代不好的地方，看看改進情況。
讓每個人發言。
每次迭代回顧會議完成後，可更新燃盡圖
3.4 結項階段
專案經理指導產品策劃收集總結專案的產品運營資料，同時指導團隊成員從自身角色進行總結，包括測試、開發、ui等。
專案經理與專案團隊成員給出專案總結報告，內容可參考《專案經驗教訓總結-專案團隊》，《專案經驗教訓總結-專案經理》
召開結項會議，各成員進行結項匯報。
pm小組將過程文件和經驗教訓總結進行歸檔。
敏捷開發管理流程
敏捷開發經常遇到的問題 解決上述問題的關鍵 scrum研發流程計畫，開發測試驗證 改bug，發布 分別對應jria中計畫板，任務板 圖形板，發布版 計畫 如何控制範圍，如何做好計畫 需求 故事 通過invest原則建立與分解 要維護完整的需求 故事backlog 根據業務優先順序劃分迭代 迭代計畫會...
專案流程之敏捷開發
正常產品專案流程 可以是產品經理創造需求 可以是 靈光一現 可以是對現有產品的改進 可以是仔細體驗生活，發現潛在的市場需求。通過內外部分析，制定產品設計 研發的明確思路。內 swot分析，外 pestle分析 有了思路後，我們就開始設計產品，設計產品需要知道產品的核心三要素 使用者 需求 場景 需求...
敏捷開發bug管理流程
概述 編寫目的 對由本組負責處理的bug進行管理，通過對bug的提交 跟蹤解釋 驗證流程進行規範，提高bug處理效率。適用範圍 測試團隊以及其他團隊進行的bug提交 跟進與解釋 驗證工作。bug管理流程 bug提交要求 要求提交bug要求分類準確 描述簡潔 步驟清晰 有例項 複雜問題有據可查 日誌或...