敏捷開發項目管理規程

最近在整理敏捷開發項目的流程和管理制度，其整理的項目管理規程以下，這份規程也不徹底算是敏捷專屬的項目管理規程，主要是在結合咱們公司實際的狀況下編寫出來的，所以名字都叫成互聯網軟件產品開發項目管理規程，你們在實際嵌入到公司的過程當中能夠參考下，不能照搬。

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.須要

肯定showCase時間：某個迭代開發、自測完成，準備提交測試前

會議前1-2天發出體驗版給到參與人員

會議期間，由項目經理組織你們體驗、反饋問題、記錄問題。

項目經理根據問題狀況，與開發或產品肯定問題的解決時間併發出會議紀要。

 I、灰度發佈

       迭代必定版本後，由項目經理與團隊共同決定是否須要進行灰度發佈。

 

監控方式 

每日站立會

    主持人輪流擔任，負責控制節奏，記錄問題，以備會後跟蹤。

    每人講本身昨天作了什麼，有什麼問題，今天的計劃是什麼；

    其餘人瞭解別人的工做狀況，並發現指出可能存在的問題。

    對於發現的問題，鼓勵認領，其他由項目經理指定責任人。

    時間一般控制在15分鐘內。

    會議期間，更新任務牆，任務牆樣式以下：

 

週報

    反饋項目計劃的執行狀況，強調本週工做要達成的目標

    暴露出項目的問題，特別是須要領導或其餘團隊須要協助的問題。

    週報可在IT平臺中輸出。

月報

    反饋項目當月的執行狀況，包括進度、人力及質量。

    反映項目存在的問題和風險。

迭代回顧

    每人講述本次迭代作的好的地方和很差的地方

    回顧上個迭代很差的地方，看看改進狀況。

    讓每一個人發言。

    每次迭代回顧會議完成後，可更新燃盡圖

3.4    結項階段

項目經理指導產品策劃收集總結項目的產品運營數據，同時指導團隊成員從自身角色進行總結，包括測試、開發、UI等。

項目經理與項目團隊成員給出項目總結報告，內容可參考《項目經驗教訓總結-項目團隊》，《項目經驗教訓總結-項目經理》

召開結項會議，各成員進行結項彙報。

PM小組將過程文檔和經驗教訓總結進行歸檔。