淺談基于PRINCE2及PMP的IT項目管理與DevSecOps管理相結(jié)合

張瀚文

在這個“互聯(lián)網(wǎng)+”的時代，在中小型企業(yè)中，傳統(tǒng)的瀑布型（Waterfall）的項目管理模式已經(jīng)無法滿足快速發(fā)展的企業(yè)需求。許多企業(yè)的IT部門甚至業(yè)務(wù)部門都走向了敏捷轉(zhuǎn)型及DevOps的轉(zhuǎn)型。其中，有些企業(yè)更是把信息安全與開發(fā)運維相互結(jié)合，形成了DevSecOps的管理模式。那么，如何把既有的PMP或者PRINCE2的項目管理的金科玉律與新型的開發(fā)安全運維相互有機地結(jié)合起來，是非常值得探討的問題。只有把傳統(tǒng)的項目管理與IT的管理融合起來，才能讓項目經(jīng)理和IT經(jīng)理更好的控制項目的各階段交付成果。

一、引言

在項目管理的領(lǐng)域中，PRINCE2及PMP被眾多項目經(jīng)理奉為指導(dǎo)理論的寶典。在IT領(lǐng)域，現(xiàn)在越來越多的IT部門開展了DevSecOps的轉(zhuǎn)型。那么，對于IT項目經(jīng)理而言，使用什么工具可以很好地管理IT開發(fā)項目呢？對于一個傳統(tǒng)的IT開發(fā)項目而言，IT項目經(jīng)理會經(jīng)常遇見溝通、進度、資源、范圍、質(zhì)量、干系人、項目資產(chǎn)、風(fēng)險等問題。而對于IT內(nèi)部而言，許多項目經(jīng)理會發(fā)現(xiàn)，項目內(nèi)部IT團隊對于職責(zé)角色（Roles and Responsibility）的不明確會導(dǎo)致整個項目出現(xiàn)各種風(fēng)險。同時，很多項目經(jīng)理會由于不清楚IT開發(fā)項目各階段的注意事項而導(dǎo)致無法有效把控各個關(guān)鍵點（Gate Check Point）。那么，對于IT軟件開發(fā)項目生命周期各階段及各個角色應(yīng)該做什么、交付什么需要有明確的定義，這樣可以極大地幫助項目經(jīng)理把控整個IT軟件開發(fā)項目。

二、總覽

項目管理的各個階段，發(fā)起、啟動、計劃、需求、設(shè)計、開發(fā)、測試、上線、運營交付、試運行、結(jié)束等若干個階段，每個階段IT團隊都需要做些什么，由誰去做，誰去審核等等都需要明確定義。只有把這些都定義清晰，職責(zé)明確，這樣才能構(gòu)建一個完整的項目IT團隊。

三、項目發(fā)起階段

（一）無論是業(yè)務(wù)部門還是IT內(nèi)部發(fā)起一個新的項目需求的時候，發(fā)起項目的申請人都必需提交項目發(fā)起的申請，包括背景、利益、目標(biāo)、期望交付物、時間等。項目管理部門（有些企業(yè)是PMO，有些企業(yè)可能是IT部門）則根據(jù)已有的評估模型對其進行評估。該評估主要是測算該需求是否已經(jīng)構(gòu)成一個立項的必備條件。

（二）另外，如果項目管理部門確認該項目可以立項，那么應(yīng)該在企業(yè)的項目管理系統(tǒng)上對該項目進行注冊。一般常用的DevOps工具會是Atlassian 的JIRA作為項目的管理工具及Confluence作為項目資產(chǎn)管理工具。

（三）在明確開展項目之前，需要與項目管理部門確認該項目是否已經(jīng)成功立項。包括項目組織架構(gòu)，項目的資源，項目的費用，項目的關(guān)鍵里程碑是否已經(jīng)獲得項目委員會的確認。

四、項目計劃階段

（一）在初期計劃的時候，IT項目經(jīng)理需要安排一次高階的系統(tǒng)影響分析，該分析是用于一些項目前期的高階方案評估。該分析需要與相關(guān)的IT專家或者在開發(fā)項目委員會及技術(shù)委員會達成一致。

（二）同時，IT項目經(jīng)理需要在計劃階段把相關(guān)的IT團隊人員定義清晰。一般來說，一個軟件開發(fā)項目的IT角色會包括但是不限于，IT項目經(jīng)理（Project Manager）、業(yè)務(wù)分析師（Business Analyst）， 測試人員、質(zhì)量保證人員、開發(fā)人員、架構(gòu)師（軟件/硬件）、系統(tǒng)工程師、數(shù)據(jù)分析師、流程工程師、信息安全人員、IT財務(wù)人員、運維工程師等。

（三）如果是借助供應(yīng)商能力來完成項目，則需要對供應(yīng)商進行技術(shù)及價格的評估，一般來說，技術(shù)評估包含公司規(guī)模，人力資源需求，業(yè)務(wù)功能需求，技術(shù)層面需求，信息安全能力、項目管理水平，售后服務(wù)等大的方面。具體選擇供應(yīng)商的流程，則按各企業(yè)自己的商務(wù)采購流程管理則可，這里不展開敘述。

（四）這里需要注意的是，IT項目經(jīng)理必須按照企業(yè)的文化或者規(guī)定，把商務(wù)采購流程所需要的準(zhǔn)備時間放到項目計劃中。

（五）當(dāng)項目經(jīng)理準(zhǔn)備好項目計劃后，該計劃必須要與關(guān)鍵的干系人溝通并且確定。項目計劃的形成不是項目經(jīng)理憑空想象出來的，而是項目經(jīng)理與各關(guān)鍵干系人溝通后而制定出來的。

（六）當(dāng)相關(guān)材料準(zhǔn)備妥當(dāng)后，該項目需要正式地在項目管理委員會（Project Board/Project Steering Committee）上進行啟動（Kick-off）。

（七）注意事項：在一些歐美企業(yè)，信息安全的審查在供應(yīng)商能力評估的時候就已經(jīng)引入。這也是DevSecOps的其中一環(huán)。

五、項目需求階段

（一）關(guān)于需求說明書，需要注意的是，我們必須要包含業(yè)務(wù)需求及IT需求，即是平常說的功能性需求和非功能性需求。

（二）需求的收集和分析，可以按照PRINCE2的作為基礎(chǔ)，結(jié)合DevSecOps的思想，得出F-O-C-U-S T-B-D 的業(yè)務(wù)分析框架。所謂FOCUS TBD框架，即使Functionality， Operativeness， Compliance， Usability， Security， Time Requirement， Budget Requirement ， Documentation， Maintenance and Support. ?F-O-C-U-S T-B-D 是一個框架，每項展開都會包含若干小巷，我在這里就不一一詳述。

（三）需要注意的是，在需求階段，必須要記得包含非功能性的需求，因為這些很多業(yè)務(wù)部門不會提出來的。例如，可用性、兼容性、擴展性、容量、移動性、吞吐量、性能、災(zāi)備、數(shù)據(jù)治理、信息安全等。從項目管理角度來看，這些非功能性的需求對項目的影響非常大。從IT治理的角度來看，這些非功能性的需求對整體IT治理影響非常大。我個人的建議是，IT項目經(jīng)理更需要從IT管理者的角度去看待項目整體的影響，而不是僅僅從項目交付的角度去看。

（四）需求分析必須要連系到各個關(guān)鍵的干系人并與關(guān)鍵干系人達成一致，并最終在項目委員會上獲得審批。

（五）這里多說一點，在敏捷類的項目（Agile Project）中，我們會需要到需求管理委員會對項目的需求進行優(yōu)先級處理，從而排進Sprint backlog 中。

六、項目設(shè)計階段

（一）項目的設(shè)計階段，項目經(jīng)理需要關(guān)注的是，設(shè)計階段的交付物是否齊備，以及質(zhì)量是否過關(guān)。設(shè)計是需求的延申，是開發(fā)的基礎(chǔ)。劣質(zhì)的設(shè)計文檔會導(dǎo)致開發(fā)團隊“想當(dāng)然”地進行開發(fā)，最終導(dǎo)致需求變形或者需求質(zhì)量不及格。

（二）在需求說明書的基礎(chǔ)上，需要有功能說明書進一步細化需求說明，把業(yè)務(wù)語言轉(zhuǎn)換為IT語言便于開發(fā)者來看法。

（三）同時，需要關(guān)心該項目是否有影響整體的IT系統(tǒng)架構(gòu)。項目的架構(gòu)設(shè)計（包括應(yīng)用架構(gòu)、硬件架構(gòu)、數(shù)據(jù)架構(gòu)等）需要在技術(shù)委員會中進行討論及審核。

（四）信息安全的設(shè)計需要進行審核。最常見的例如，權(quán)限矩陣、權(quán)限設(shè)置、身份驗證、職責(zé)角色等。

（五）如果是多系統(tǒng)對接的項目，那么接口設(shè)計是否已經(jīng)確定。

（六）系統(tǒng)應(yīng)用及服務(wù)的監(jiān)控是否已經(jīng)設(shè)計確定。

（七）數(shù)據(jù)變更或合并、數(shù)據(jù)字典的更新是否已經(jīng)確定。

（八）在設(shè)計階段，需要準(zhǔn)備好后續(xù)的開發(fā)環(huán)境、測試環(huán)境、生產(chǎn)環(huán)境的相關(guān)軟件及硬件。

（九）最終，設(shè)計文檔需要在技術(shù)委員會中通過方可進入下一階段。

我們可以參考以下圖片，了解到軟件開發(fā)項目中常用的DevOps的管理工具。了解這些功能有助于IT項目經(jīng)理明白到IT內(nèi)部風(fēng)險可能出自于哪一環(huán)節(jié)。

七、項目開發(fā)階段

（一）需要確保供應(yīng)商的開發(fā)是否在企業(yè)IT要求的開發(fā)框架下進行。這點很重要，否則在未來隨著業(yè)務(wù)的發(fā)展及IT系統(tǒng)越來越多的時候，這個影響就會非常大。

（二）對于供應(yīng)商開發(fā)的質(zhì)量把控是項目經(jīng)理需要注意的。對于多項目、生產(chǎn)故障修復(fù)、其他項目變更等高耦合的情況以及項目周期過長導(dǎo)致版本過多的情況，需要明確開發(fā)版本的控制。在該版本中是否包含了相關(guān)項目、生產(chǎn)故障修復(fù)、相關(guān)聯(lián)生產(chǎn)變更的內(nèi)容。

（三）需要要求供應(yīng)商提供單元測試報告并要求質(zhì)量部門進行檢驗。

（四）對于多系統(tǒng)的開發(fā)，需要確保系統(tǒng)間的聯(lián)調(diào)通過。

（五）在合同允許的情況下，項目經(jīng)理最好要求供應(yīng)商提供源代碼。同時，需要組織相關(guān)開發(fā)人員對供應(yīng)商的代碼進行code review以保證項目質(zhì)量。

（六）IT項目經(jīng)理需要組織IT內(nèi)部相關(guān)人員對開發(fā)進行回顧及審批。

八、系統(tǒng)兼容性測試

（一）在開始系統(tǒng)兼容性測試 （SIT – System Integration Testing） 之前，確保相關(guān)準(zhǔn)備工作已經(jīng)完成，避免影響項目的進度，例如系統(tǒng)配置、數(shù)據(jù)導(dǎo)出導(dǎo)入、中間庫準(zhǔn)備、系統(tǒng)連通性檢驗。

（二）SIT的測試案例是否已經(jīng)完成。一般來說，SIT測試案例需要明確測試范圍、測試工具（最好是DevOps自動化測試工具，如Jenkins， Jemeter）， 測試平臺、監(jiān)控工具、被測試的系統(tǒng)環(huán)境、測試環(huán)境與生產(chǎn)環(huán)境的差異、性能參數(shù)分析、測試策略、測試場景、測試結(jié)果及分析等。

（三）根據(jù)項目具體情況安排壓力測試及回歸測試。

（四）最后，測試結(jié)果的報告需要在IT內(nèi)部進行回顧并獲得審批方可進入下一階段。

九、用戶測試

（一）在用戶測試（UAT – User Acceptance Testing）開始之前，IT項目經(jīng)理需要確保UAT環(huán)境的準(zhǔn)備情況以確保UAT的開展可順利進行。例如： 配置、數(shù)據(jù)導(dǎo)出導(dǎo)入、中間庫準(zhǔn)備、系統(tǒng)連通性檢驗。

（二）UAT 測試案例及測試場景及配置定義是否已經(jīng)包含？一般來說，我會建議UAT的測試案例需要包括 測試案例序號、測試部門（如果是多部門項目）、測試系統(tǒng)、案例名稱、測試內(nèi)容、測試步驟、預(yù)期結(jié)果、實際結(jié)果以及對應(yīng)的BUG/ISSUE 單號。對于BUG/Issue管理， 可以用已經(jīng)定義好的項目管理工具，例如JIRA/Confluence。

（三）UAT的測試案例最好由業(yè)務(wù)部門自己首先定義，IT部門提供協(xié)助和指導(dǎo)。測試案例是基于需求說明書而來的，并且是需求說明的實際操作化。

（四）需要注意的是，在UAT的測試中，除了業(yè)務(wù)部門的功能性測試，IT項目經(jīng)理必須注意安排非功能性的測試。

（五）UAT的測試案例必須是業(yè)務(wù)部門與IT部門達成一致的結(jié)果。

（六）UAT測試完畢后，需要在項目管理委員會上審核UAT測試報告。該報告需要包含UAT的測試結(jié)果、相關(guān)BUG/ISSUE的處理結(jié)果等。

十、項目上線階段

（一）在項目上線之前，必須提前準(zhǔn)備好包括部署手冊，操作手冊，支持安排、變更申請。并且確認生產(chǎn)環(huán)境是否已經(jīng)準(zhǔn)備妥當(dāng)。

（二）相關(guān)上線的支持的培訓(xùn)、支持流程是否已經(jīng)準(zhǔn)備妥當(dāng)。

（三）上線的溝通計劃是否已經(jīng)準(zhǔn)備妥當(dāng)。對于那些大范圍影響的項目，需要提前有明確的溝通計劃、培訓(xùn)計劃甚至是差旅計劃等。

（四）上線后的試運營階段，IT項目經(jīng)理需要完成項目的監(jiān)控以及項目的運維交付（Operation Transition），具體交接時間按照項目的規(guī)模而定。

（五）需要有一個正式的結(jié)項會議，可以包含經(jīng)驗教訓(xùn)、項目上線后的運營情況分析、故障分析、優(yōu)化分析、需要幫助等內(nèi)容。

（六、）最后，需要履行結(jié)束合同并完成相應(yīng)財務(wù)流程。

十一、最后，我以一張圖來總結(jié)基于PRINCE2及PMP的項目管理理論與DevSecOps管理理論相結(jié)合

十二、結(jié)語

這篇文章是對傳統(tǒng)的IT項目管理與開發(fā)運維的結(jié)合的嘗試的一個簡單的概括，不同企業(yè)會有不同的實際情況，也有不同的技術(shù)策略、IT策略和管理策略。希望這篇文章可以給讀者一些啟發(fā)，在IT項目的管理上提供幫助。（作者單位：中國人民大學(xué)）