項目管理體系44張課件

項目管理體系目的規(guī)范化：項目各項工作的開展，定義和管理作到有據(jù)可依。比如版本的命名標準化，文檔編輯模板化，測試通過一致化。避免工作的重復性，模糊性，無效性。流程化：各項工作的開展系統(tǒng)化，各項工作通過JIRA系統(tǒng)進行管理，控制和監(jiān)督，并通過郵件系統(tǒng)進行通知。保證工作開展的有序性和針對性。避免不必要的工作流以流控的混亂。項目管理體系目的規(guī)范化：項目各項工作的開展，定義和管理作到有1項目管理體系目的降低風險，提高質量：版本的規(guī)范化管理，工作上的流程化管理，進度上的階段性監(jiān)督管理，問題的及時化處理，使得產(chǎn)品降低風險，提高質量。降低成本，提高效率：通過標準流程化的監(jiān)控，項目開展規(guī)范化操作，減少無效溝通，減少重復性工作，快速獲取正確的信息和資料，降低單位工作時間的人力成本，提高工作效率。項目管理體系目的降低風險，提高質量：版本的規(guī)范化管理，工作上2項目管理體系內(nèi)容項目管理體系需求管理環(huán)境管理版本管理計劃管理文檔管理流程管理測試管理日常工作及會議管理績效管理項目管理體系內(nèi)容項目管理體系需求管理環(huán)境管理版本管理計劃管理3項目管理執(zhí)行流程JIRA建立各種管理模塊

JIRA上提交各項管理文檔項目經(jīng)理審核視情況召開評審評審根據(jù)評審修訂歸檔執(zhí)行。說明：1.項目經(jīng)理審核后，郵件自動通知。2.項目經(jīng)理根據(jù)提交的內(nèi)容決定是否評審。項目管理執(zhí)行流程JIRA建立各種管理模塊JIRA上提交各4項目管理執(zhí)行流程圖JIRA上提交版本或文檔項目經(jīng)理審核歸檔執(zhí)行需要評審評審修訂通過不通過項目管理執(zhí)行流程圖JIRA上提交版本或文檔項目經(jīng)理審核歸檔執(zhí)5需求管理背景目前我們項目開發(fā)中沒有明確的需求，在開發(fā)和測試過程中容易出現(xiàn)以下情況：1.沒有針對性，尤其是測試，在沒有用例和方案的時候，類似于隨機測試和驗收測試。2.沒有標準性，沒有需求說明的一些關鍵指標和數(shù)據(jù)依據(jù)，質量無法把握。3.導致所有人重復工作量，部分功能或者設計不能在需求階段確定，將會影響整個流程上的所有人的工作量和工作效率。需求管理背景6建議和規(guī)范為避免需求階段對后面流程上的影響，提出一下建議和規(guī)范：1.開發(fā)人員在接到任務時整理出一個初步需求。2.在每次新的開發(fā)任務執(zhí)行前，由本次開發(fā)人員對測試人員進行一個培訓或講解。測試人員對需求講解進行提問。（由設計到該模塊的開發(fā)人員，項目經(jīng)理，測試人員參與）3.測試人員根據(jù)講解和最終確認結果對需求進行修訂，進入準備測試方案和用例階段。4.需求變更，需要及時更新并命名為文檔名+日期，通過JIRA系統(tǒng)通知相關人員，項目經(jīng)理根據(jù)需求決定是否再次評審。建議和規(guī)范為避免需求階段對后面流程上的影響，提出一下建議和規(guī)7版本管理背景目前項目中對于版本的管理還是比較空白的，流程上，命名規(guī)范，查詢接口等方面都沒有很好控制。主要如下問題;1.命名沒有規(guī)范化。沒有區(qū)分開發(fā)版本，測試版本，還是發(fā)布版本，補丁版本，迭代版本。導致無效的反復操作增加。2.沒有查詢接口。終端設備無法通過工具或者軟件界面直接查看系統(tǒng)里面版本。3.版本的發(fā)布沒有走正規(guī)的審批流程。4.不能非常明確知道和記錄版本出現(xiàn)問題，不能有效統(tǒng)計每個版本穩(wěn)定性。5.版本沒有基線化管理，不能很好的歸檔。6.服務器版本和客戶端版本沒有緊密對應起來。版本管理背景8版本管理——建議和規(guī)范為對版本進行規(guī)范化管理以及流程上更好監(jiān)控，提出以下建議和規(guī)范：一、版本命名規(guī)則版本類型：1.主版本號和子版本號。2.服務器版本和客戶端版本。3.階段性版本。4.發(fā)布版本。5.補丁版本。版本管理——建議和規(guī)范為對版本進行規(guī)范化管理以及流程上更好監(jiān)9版本管理——建議和規(guī)范1.主版本和子版本命名主版本為：產(chǎn)品名稱+1.0如：云碼頭IcloudI_1.0云碼頭IIcloudII_1.0子版本在主版本的基礎上遞增。子版本的產(chǎn)生可以以一個迭代或者一個時間段作為周期云碼頭I:cloudI_1.0,cloudI_1.1,cloudI_1.2…云碼頭II:cloudII_1.0,cloudII_1.1,cloudII_1.2…版本管理——建議和規(guī)范1.主版本和子版本命名10版本管理——建議和規(guī)范2.服務器版本和客戶端版本。服務器和客戶端版本號可以在主版本或者子版本號前面加上標識。如：s_cloudI_1.0,c_cloudII_1.0.原則希望每次發(fā)布版本客戶端版本和服務器版本一一對應起來。如：如云碼頭II第二次迭代版本。服務器版本：s_cloudII_1.1,客戶端版本:c_cloudII_1.1.版本管理——建議和規(guī)范2.服務器版本和客戶端版本。11版本管理——建議和規(guī)范3.階段性版本命名規(guī)則在同一開發(fā)周期內(nèi)或者迭代周期內(nèi)，出現(xiàn)需要進行一些小的改動，時間周期比較短。如：s_cloudII_1.2_201909204.發(fā)布版本命名規(guī)則子版本測試，評估完成最終版本。（基線化）如：s_cloudIII_1.1_release5.補丁版本命名規(guī)則對于售后產(chǎn)品需要升級的產(chǎn)品且可以直接通過補丁形式安裝的。針對于發(fā)布后的版本如：c_cloudII_1.2_update版本管理——建議和規(guī)范3.階段性版本命名規(guī)則12版本管理——建議和規(guī)范二、版本存放規(guī)則版本的存放通過JIRA系統(tǒng)或者SVN管理工具進行存放管理一級目錄為產(chǎn)品名稱，如：cloudI,cloudII,cloudII.二級目錄為版本名稱，如：cloudI_1.0,cloudI_1.1,cloudI_1.2_release,cloudI_1.3_update三級目錄為服務器和客戶端目錄，包含各種環(huán)境安裝文檔。如：s_cloudII_1.1,c_cloudII_1.1版本管理——建議和規(guī)范二、版本存放規(guī)則13版本管理——建議和規(guī)范三、版本變更版本變更可以按照原定計劃迭代進行，也可以根據(jù)修復的BUG之后變更，但需要一個流程上和周期性的控制1.版本變更需要提供變更原因，由于軟件重新開發(fā)，新功能增加，BUG修復。2.版本變更需要要提供變更列表。3.版本變更需要周期性控制和經(jīng)過審核，不能隨意變更版本，需要評估變更時間，特殊情況，需要備注。版本管理——建議和規(guī)范三、版本變更14版本管理——建議和規(guī)范四、版本的提交與審核。1.版本的提交走測試申請流程。2.確認版本的命名規(guī)范。3.確認版本，安裝文件，配置文件等各種資料齊全。4.確認安裝文件，配置文件等各種資料為最新狀態(tài)。版本管理——建議和規(guī)范四、版本的提交與審核。15環(huán)境管理背景環(huán)境管理，包括硬件環(huán)境，軟件環(huán)境，設備環(huán)境，IP及虛擬機資源，系統(tǒng)資源，測試或演示文檔等。目前我們的環(huán)境存在以下問題：1.開發(fā)，測試，演示環(huán)境在一起，相互影響。2.測試環(huán)境，尤其是后臺不能自行維護，每次需要等待開發(fā)配置，影響開發(fā)，等待浪費時間。3.IP地址和虛擬機沒有一個相對固定的地址。4.設備的狀態(tài)（比如版本），不良品沒有分類和注明。5.各個版本的良品系統(tǒng)沒有備份，維修時，找不到良品系統(tǒng)。6.演示材料沒有事先準備，演示效果有一定影響。環(huán)境管理背景16環(huán)境管理建議和規(guī)范1.將開發(fā)環(huán)境，測試環(huán)境和演示環(huán)境分別單獨管理。2.開發(fā)提供服務器、客戶端環(huán)境安裝及驗證方法，安裝過程盡力簡單化，能讓測試快速安裝，能實現(xiàn)腳本安裝最好。3.IP地址（虛擬機）和產(chǎn)品及數(shù)據(jù)庫對應固定化，沒有特殊情況，盡可能不改變。4.產(chǎn)品需要專門的存儲柜進行管理，產(chǎn)品需要實時更新和標注版本及狀態(tài)。5.對于基線化的版本的系統(tǒng)需要專門的備份，為產(chǎn)品維修提供標準版本。6.針對演示時需要更好的效果，比如視頻效果，收集換面清晰，流暢。聲音效果好的素材作為演示材料。環(huán)境管理建議和規(guī)范17項目計劃管理目的：為了合理利用資源，分配任務，把握項目整體進度，降低項目風險對項目實施進行一個科學的安排和部署。優(yōu)勢：1.目標針對性，項目計劃明確了需要完成的各項功能和性能要求，以及人員分配。2.工作有序性，項目計劃對項目任務進行階段性的劃分，明確了每個周期內(nèi)各個人員的具體工作，使工作有序開展。3.進度監(jiān)控，根據(jù)項目計劃安排與實際工作反饋對比，可以監(jiān)控每項工作的完成進度，及時做出調(diào)整。4.工作協(xié)調(diào)配合，開發(fā)和測試人員可以根據(jù)項目計劃對各自工作同時進行安排及相互溝通。項目計劃管理目的：18項目計劃管理項目計劃內(nèi)容項目計劃建議采用EXCEL模版進行設計，簡單明了，主要內(nèi)容包括：1.項目目標和范圍描述進行項目的背景和意義，項目的基本框架，項目實現(xiàn)的主要功能和指標。（詳細功能清單）2.項目進度計劃說明項目劃分幾個階段完成，每個階段開發(fā)和測試各項工作的開展順序，開展時間，完成時間3.項目資源準備環(huán)境，設備，人員4.項目風險評估

對項目可能存在的風險進行說明。（詳細見模版）

項目計劃管理項目計劃內(nèi)容19文檔管理文檔管理主要對各種工具，文件，資料進行一個分類備份以及共享，方面查找資料和學習提高。文檔管理和分類文檔管理項目資料培訓資料學習資料開發(fā)測試碼頭I碼頭II碼頭III需求，方案，計劃，工具等碼頭I碼頭II碼頭III需求，方案，計劃，工具等文檔管理文檔管理主要對各種工具，文件，資料進行一個分類備份以20測試及相關流程管理測試概述一般而言，軟件測試從項目確立時就開始了，前后要經(jīng)過以下一些主要環(huán)節(jié)：需求分析→測試計劃→測試設計→測試環(huán)境搭建→測試執(zhí)行→測試記錄→缺陷管理→軟件評估→發(fā)布申請.測試及相關流程管理測試概述21需求分析輸入條件軟件需求文檔、軟件規(guī)格書以及開發(fā)人員的概要設計文檔內(nèi)容：測試環(huán)境和資源需求分析功能需求分析，包括1.硬件及接口定義分析2.用戶使用界面分析3.系統(tǒng)支持軟件分析4.通訊協(xié)議分析5.可靠性，穩(wěn)定性分析6.用戶場景分析輸出開發(fā)：詳細設計文檔測試：測試思維導向圖.需求分析輸入條件22測試計劃輸入條件需求文檔，詳細設計，測試計劃模版內(nèi)容1.測試背景2.通過標準3.測試輸入項目4.測試資源5.測試策略6.日程安排7.風險分析輸出：測試計劃書測試計劃輸入條件23測試設計輸入需求文檔，詳細設計，測試思維導向圖，測試計劃內(nèi)容1.硬件及接口2.用戶界面3.應用軟件4.自帶軟件5.協(xié)議測試6.可靠性，穩(wěn)定性測試7.案例評審輸出基本測試用例，用戶場景用例，修訂后的案例。測試設計輸入24環(huán)境搭建與測試準備輸入安裝軟件及文檔（包括客戶端及服務器），配置文檔，燒錄系統(tǒng)及工具，IP分配內(nèi)容搭建測試環(huán)境，用戶演示環(huán)境測試安裝文檔，記錄安裝過程問題準備測試需要的工具，資料。安裝逐步實行腳本化。輸出安裝腳本，安裝過程反饋表環(huán)境搭建與測試準備輸入25測試執(zhí)行與記錄輸入基本測試用例，場景設計用例內(nèi)容1.確保執(zhí)行環(huán)境的正確性2.按優(yōu)先級順序執(zhí)行用例。3.檢查用例執(zhí)行條件4.記錄每個用例的執(zhí)行結果，通過，不通過，鎖定。5.對測試不通過的，詳細記錄問題重現(xiàn)的路徑，現(xiàn)象，以及日志等相關內(nèi)容。6.與開發(fā)確認BUG，并在系統(tǒng)上及時提交反饋。7.考慮測試的覆蓋率，測試過程中思考是否需要補充測試用例，是否需要增加用戶場景。8.統(tǒng)計BUG缺陷率，（BUG總數(shù)，致命的，嚴重的，一般的，建議的。）及用例執(zhí)行結果?？偟挠美龜?shù)，未執(zhí)行的，通過的，未通過，鎖定的，BUG數(shù)）9.對于需要回歸測試，統(tǒng)計回歸不過的問題。輸出測試用例執(zhí)行反饋表，BUG統(tǒng)計表測試執(zhí)行與記錄輸入26缺陷管理輸入BUG統(tǒng)計表內(nèi)容1.與開發(fā)確認BUG，有爭議的反饋PM2.編寫B(tài)UG的情況，類型，緊急情況，問題描述和詳細步驟，期望結果。3.提交BUG，指定任務分派。輸出BUG系統(tǒng)跟蹤缺陷管理輸入27軟件評估輸入測試用例執(zhí)行反饋表，BUG統(tǒng)計表內(nèi)容1.測試評價：總體評價，新功能情況小結，重點BUG列表，bugfix情況，穩(wěn)定性測試，2.開發(fā)改進點3.測試改進點4.風險點5.測試數(shù)據(jù)：回歸數(shù)據(jù)反饋，新增BUG統(tǒng)計，用例執(zhí)行情況統(tǒng)計。6.測試資源輸出測試報告軟件評估輸入28測試流程匯總常見的測試相關流程主要有以下幾種：1.測試案例評審流程2.測試計劃評審流程3.測試申請流程4.測試執(zhí)行流程5.內(nèi)測試反饋流程6.客戶BUG反饋流程7.BUG處理流程8.測試報告提交流程測試流程匯總常見的測試相關流程主要有以下幾種：291.測試用例評審流程

測試人員準備測試用例發(fā)起評審項目經(jīng)理查閱測試用例郵件通知相關人員進行用例評審根據(jù)評審結果修訂用例用例歸檔1.測試用例評審流程

測試人員準備測試用例發(fā)起評審項目經(jīng)理查302.測試計劃評審流程

測試人員編制好測試計劃發(fā)起評審項目經(jīng)理查閱測試計劃無需評審召開評審需要測試計劃修訂歸檔2.測試計劃評審流程測試人員編制好測試計劃發(fā)起評審項目經(jīng)理313.測試申請流程研發(fā)自測完畢，提交測試申請項目經(jīng)理檢查軟件，文檔是否齊全，規(guī)范否測試人員檢查軟件，文檔是否齊全，規(guī)范否是執(zhí)行測試3.測試申請流程研發(fā)自測完畢，提交測試申請項目經(jīng)理檢查軟件，324.測試執(zhí)行流程測試人員按照測試用例執(zhí)行測試發(fā)現(xiàn)BUG并提交開發(fā)人員確認BUG否打回確認關閉存在爭議項目經(jīng)理評審確認是是關閉處理否提單跟蹤4.測試執(zhí)行流程測試人員按照測試用例執(zhí)行測試發(fā)現(xiàn)BUG并提交335.內(nèi)測試反饋流程測試人員提供反饋模版和驗證需求測試人員收集并確認內(nèi)測問題拋棄否提單跟蹤是開發(fā)人員確認BUG否打回確認關閉存在爭議項目經(jīng)理評審確認是是關閉處理否提單跟蹤5.內(nèi)測試反饋流程測試人員提供反饋模版和驗證需求測試人員收集346.客戶BUG反饋流程客戶反饋BUG測試人員確認內(nèi)測問題拋棄否提單跟蹤是開發(fā)人員確認BUG否打回確認關閉存在爭議項目經(jīng)理評審確認是是關閉處理否提單跟蹤6.客戶BUG反饋流程客戶反饋BUG測試人員確認內(nèi)測問題拋棄357.BUG處理流程項目經(jīng)理分派任務或者測試指派BUG處理開發(fā)確認BUG開發(fā)修復BUG提交修復版本給項目經(jīng)理確認項目經(jīng)理確認并分派測試任務測試人員驗證BUG是否通過否關閉是7.BUG處理流程項目經(jīng)理分派任務或者測試指派BUG處理開發(fā)368.測試報告提交流程測試人員整理并提交測試報告項目經(jīng)理查閱審核，評估是否需要評審評審討論是問題跟蹤，文檔歸檔否8.測試報告提交流程測試人員整理并提交測試報告項目經(jīng)理查閱審37日常工作及會議管理日常工作管理包括1.日報管理2