最近在整理敏捷開發(fā)項目的流程和管理制度,，其整理的項目管理規(guī)程如下，這份規(guī)程也不完全算是敏捷專屬的項目管理規(guī)程,，主要是在結(jié)合我們公司實際的情況下編寫出來的,，因此名字都叫成互聯(lián)網(wǎng)軟件產(chǎn)品開發(fā)項目管理規(guī)程，大家在實際嵌入到公司的過程中可以參考下,，不能照搬,。

1.  目的

規(guī)范互聯(lián)網(wǎng)軟件產(chǎn)品開發(fā)項目管理過程，指導(dǎo)開展項目研發(fā),、管理等活動,。

2.  適用范圍

本章程的作用范圍為互聯(lián)網(wǎng)軟件產(chǎn)品開發(fā)立項至結(jié)項管理過程。

1.對項目經(jīng)理開展產(chǎn)品規(guī)劃及設(shè)計活動以及項目管理手段和應(yīng)遵循的開發(fā)流程提供了指導(dǎo),；

2.對項目團隊的日常管理活動及內(nèi)容進行了指導(dǎo),；

3.  角色及職責(zé)定義

項目經(jīng)理：

進行產(chǎn)品開發(fā)過程中的業(yè)務(wù)目標(biāo),、進度、成本,、質(zhì)量控制,。

挑選項目團隊并進行團隊建設(shè)，激發(fā),、鼓舞和改進團隊的生產(chǎn)效率,。

識別項目干系人，定期向干系人匯報,，并作為團隊和外部的接口,，屏蔽外界對團隊的干擾。

確保項目中流程被遵循,，組織,、監(jiān)督、培訓(xùn)項目各實踐活動,。

產(chǎn)品策劃

確定產(chǎn)品的功能,，拆分用戶故事。

需求功能確定優(yōu)先級,。

接受或拒絕開發(fā)團隊的工作成果,。

參與產(chǎn)品開發(fā)過程中的有關(guān)會議。

UI

根據(jù)用戶故事,，負(fù)責(zé)產(chǎn)品的功能交互及界面設(shè)計

組織開展人機交互及用戶體驗,，不斷跟蹤改進，提高產(chǎn)品表現(xiàn)力,。

參與產(chǎn)品開發(fā)過程中的有關(guān)會議,。

開發(fā)

根據(jù)用戶故事，負(fù)責(zé)產(chǎn)品的技術(shù)架構(gòu)設(shè)計及功能開發(fā)

評估,、設(shè)計及維護產(chǎn)品相應(yīng)模塊,，確保模塊的穩(wěn)定性、易用性,、高效性,。

參加產(chǎn)品開發(fā)過程中的有關(guān)會議。

測試

根據(jù)用戶故事,，設(shè)計產(chǎn)品測試標(biāo)準(zhǔn),，確保產(chǎn)品品質(zhì)滿足市場需求。

合理分配測試資源,，組織產(chǎn)品測試并優(yōu)化測試流程及測試標(biāo)準(zhǔn),，提高測試效率。

編寫產(chǎn)品測試用例,，提交測試問題,，編寫測試總結(jié)報告,，以測試角度來確定產(chǎn)品版本是否發(fā)布。

4. 項目管理過程

按照互聯(lián)網(wǎng)軟件產(chǎn)品項目開發(fā)過程,，可將整個項目管理過程分為立項過程,、規(guī)劃過程、執(zhí)行與監(jiān)控過程,、結(jié)項過程,。下面分別闡述在每個階段過程中該如何進行項目管理。

4.1 立項過程

    互聯(lián)網(wǎng)軟件產(chǎn)品開發(fā)項目的立項過程,，通常是指從準(zhǔn)備項目啟動會到召開會議這個階段,，在立項過程中，需要完成項目目標(biāo),，需求范圍的初步確認(rèn),，項目團隊成員，其他資源的安排,。

     確定項目的初步目標(biāo)并達成共識

     對于項目目標(biāo),，需要和干系人在以下幾點上達成共識：

     項目的背景、目標(biāo)用戶,、核心人員及產(chǎn)品定位是什么

     項目的資源投入預(yù)算是多少

     項目的資源投入是多少

     各人員在項目中扮演的角色和對項目的作用是什么

     準(zhǔn)備啟動會議文檔

     文檔內(nèi)容包括：

       用戶畫像

       產(chǎn)品定位

       市場策略

       業(yè)務(wù)目標(biāo)

       技術(shù)可行性

       研發(fā)成本預(yù)算

       路標(biāo)規(guī)劃

    召開項目啟動會 

     參加人員包括：

       管理層代表

       項目經(jīng)理及項目團隊

       其他干系人代表

     主要議題包括：

       申明項目目標(biāo)范圍及對組織目標(biāo)的貢獻,。

       管理層正式任命PM，設(shè)定期望,，統(tǒng)一思想

       文檔內(nèi)容的宣講,。  

     與PM小組確定項目管理要求

       項目啟動會完成后，需要與PM小組成員確定項目立項機制以及公司項目管理要求,。

4.2  規(guī)劃階段

在規(guī)劃階段,，團隊需要共同完成產(chǎn)品的版本規(guī)劃，迭代計劃

版本規(guī)劃

從產(chǎn)品的關(guān)鍵特性列表中按照優(yōu)先級規(guī)劃產(chǎn)品每個版本需要完成哪些特性,，在規(guī)劃完成后需要在項目干系人內(nèi)達成共識,。具體可參考《版本規(guī)劃樣例》

迭代如何劃分

迭代劃分是指將特性列表拆分形成用戶故事列表，并將其對應(yīng)的主要任務(wù)劃分到各個迭代中去,，形成粗粒度的項目迭代計劃。這個過程主要考慮以下幾個因素：

    有些任務(wù)間是有依賴關(guān)系,，某個任務(wù)的開始或結(jié)束是以另一個任務(wù)的開始或結(jié)束為前提,，在劃分時必須考慮這種前后依賴關(guān)系。

    在安排每個迭代的任務(wù)時,，需要對各種因素進行綜合考慮,，如平衡每個迭代中任務(wù)的技術(shù)難度和價值差異。

    除了進行初步的迭代任務(wù)劃分,，還需要確定項目過程中迭代任務(wù)調(diào)整的規(guī)則,，如迭代任務(wù)未完成時是將剩余任務(wù)延至下一迭代還是延長迭代周期,。

確定人員分工

項目經(jīng)理需要根據(jù)每個人員的能力和特點，初步擬定大致分工,。在進行任務(wù)分工時需考慮以下因素：

    任務(wù)難度與人員能力相匹配,，對于明顯超出能力范圍或過于簡單的任務(wù)容易造成負(fù)面影響。

    耦合度高的盡量分配給同一個人,，避免不必要的溝通消耗,。

    鼓勵團隊內(nèi)部“任務(wù)認(rèn)領(lǐng)”，提高人員的工作積極性和主動性,。

確定迭代運行模式

        如一周迭代,、兩周迭代，每個迭代包含的工作內(nèi)容等,。

       具體的迭代計劃可參考《迭代計劃樣例》

制定其他輔助計劃

    制定溝通計劃,、風(fēng)險計劃和質(zhì)量計劃是必要的，溝通計劃主要包含以下幾個方面：溝通對象,、溝通方式,、溝通頻率即可，如：

    風(fēng)險計劃包括風(fēng)險項,、負(fù)責(zé)人,、重要性、應(yīng)對措施,，如下：

質(zhì)量計劃包括：bug分布滿足何種條件可以發(fā)布,，有幾個致命bug必須停止開發(fā)新特性等。,。

   搭建基礎(chǔ)技術(shù)架構(gòu)

    如果是一個全新的項目,，需要重新開發(fā)系統(tǒng)框架，則這個工作應(yīng)該在迭代0完成,，否則會影響后期的工作開展,。系統(tǒng)框架的每次改動必然會導(dǎo)致大量的重復(fù)工作量，從而給穩(wěn)定的團隊節(jié)奏帶來很大的毛刺,。

3.3    項目執(zhí)行和監(jiān)控過程

迭代N的執(zhí)行

A,、迭代N的需求細(xì)化

考慮每個迭代需要完成的用戶故事；

    用戶故事需包含幾個部分,，工作量評估,、功能性需求、非功能性需求,。具體的可參考《用戶故事模板及樣例及拆分說明》

    用戶故事編寫完成后需要在團隊內(nèi)部進行需求評審,，一方面是為了向團隊成員解讀該需求，另一方面團隊成員也可在評審時給出指導(dǎo)性意見,。

B,、測試用例評審

    測試人員根據(jù)用戶故事要求編寫對應(yīng)的測試用例,，并組織項目團隊進行測試用例評審。根據(jù)評審意見修改測試用例

C,、開發(fā)

    將用戶故事的需求開發(fā)的過程,。

D、開發(fā)自測

    在開發(fā)過程中,，每完成一個功能點,，都需要及時的進行開發(fā)自測并通知產(chǎn)品策劃人員進行驗收體驗。

E,、驗收

    開發(fā)完成后,，產(chǎn)品策劃需要對開發(fā)完成的成果進行驗收，驗證其是否符合用戶故事的要求,，驗證通過后方可流到測試環(huán)節(jié),，否則需與開發(fā)詳細(xì)討論其不符合性，其驗收的checklist可以參考《產(chǎn)品驗收checklist及模板》

F,、測試和回歸

        提交測試時,，必須要有正確的版本。測試人員根據(jù)測試用例進行測試,，在IT平臺中提交測試bug,，并根據(jù)測試的角度給出產(chǎn)品是否發(fā)布的意見，輸出《測試報告》

G,、bug修改

    在IT平臺中獲取分配給自己的bug進行修改,。

H、showCase

    階段性必須有可體驗版本進行showCase.需要

確定showCase時間：某個迭代開發(fā),、自測完成,，準(zhǔn)備提交測試前

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

會議期間，由項目經(jīng)理組織大家體驗,、反饋問題,、記錄問題。

項目經(jīng)理根據(jù)問題情況,，與開發(fā)或產(chǎn)品確定問題的解決時間并發(fā)出會議紀(jì)要,。

 I、灰度發(fā)布

       迭代一定版本后,，由項目經(jīng)理與團隊共同決定是否需要進行灰度發(fā)布,。

監(jiān)控方式 

每日站立會

    主持人輪流擔(dān)任，負(fù)責(zé)控制節(jié)奏,，記錄問題,，以備會后跟蹤,。

    每人講自己昨天做了什么,，有什么問題,，今天的計劃是什么；

    其他人了解別人的工作情況,，并發(fā)現(xiàn)指出可能存在的問題,。

    對于發(fā)現(xiàn)的問題，鼓勵認(rèn)領(lǐng),，其余由項目經(jīng)理指定責(zé)任人,。

    時間通常控制在15分鐘內(nèi),。

    會議期間,，更新任務(wù)墻，任務(wù)墻樣式如下：

周報

    反饋項目計劃的執(zhí)行情況,，強調(diào)本周工作要達成的目標(biāo)

    暴露出項目的問題,，特別是需要領(lǐng)導(dǎo)或其他團隊需要協(xié)助的問題。

    周報可在IT平臺中輸出,。

月報

    反饋項目當(dāng)月的執(zhí)行情況,，包括進度、人力及質(zhì)量,。

    反映項目存在的問題和風(fēng)險,。

迭代回顧

    每人講述本次迭代做的好的地方和不好的地方

    回顧上個迭代不好的地方，看看改進情況,。

    讓每個人發(fā)言,。

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

3.4    結(jié)項階段

項目經(jīng)理指導(dǎo)產(chǎn)品策劃收集總結(jié)項目的產(chǎn)品運營數(shù)據(jù),，同時指導(dǎo)團隊成員從自身角色進行總結(jié),，包括測試、開發(fā),、UI等,。

項目經(jīng)理與項目團隊成員給出項目總結(jié)報告，內(nèi)容可參考《項目經(jīng)驗教訓(xùn)總結(jié)-項目團隊》,，《項目經(jīng)驗教訓(xùn)總結(jié)-項目經(jīng)理》

召開結(jié)項會議,，各成員進行結(jié)項匯報。

PM小組將過程文檔和經(jīng)驗教訓(xùn)總結(jié)進行歸檔,。