張瀚文



在這個“互聯網+”的時代,在中小型企業中,傳統的瀑布型(Waterfall)的項目管理模式已經無法滿足快速發展的企業需求。許多企業的IT部門甚至業務部門都走向了敏捷轉型及DevOps的轉型。其中,有些企業更是把信息安全與開發運維相互結合,形成了DevSecOps的管理模式。那么,如何把既有的PMP或者PRINCE2的項目管理的金科玉律與新型的開發安全運維相互有機地結合起來,是非常值得探討的問題。只有把傳統的項目管理與IT的管理融合起來,才能讓項目經理和IT經理更好的控制項目的各階段交付成果。
一、引言
在項目管理的領域中,PRINCE2及PMP被眾多項目經理奉為指導理論的寶典。在IT領域,現在越來越多的IT部門開展了DevSecOps的轉型。那么,對于IT項目經理而言,使用什么工具可以很好地管理IT開發項目呢?對于一個傳統的IT開發項目而言,IT項目經理會經常遇見溝通、進度、資源、范圍、質量、干系人、項目資產、風險等問題。而對于IT內部而言,許多項目經理會發現,項目內部IT團隊對于職責角色(Roles and Responsibility)的不明確會導致整個項目出現各種風險。同時,很多項目經理會由于不清楚IT開發項目各階段的注意事項而導致無法有效把控各個關鍵點(Gate Check Point)。那么,對于IT軟件開發項目生命周期各階段及各個角色應該做什么、交付什么需要有明確的定義,這樣可以極大地幫助項目經理把控整個IT軟件開發項目。
二、總覽
項目管理的各個階段,發起、啟動、計劃、需求、設計、開發、測試、上線、運營交付、試運行、結束等若干個階段,每個階段IT團隊都需要做些什么,由誰去做,誰去審核等等都需要明確定義。只有把這些都定義清晰,職責明確,這樣才能構建一個完整的項目IT團隊。
三、項目發起階段
(一)無論是業務部門還是IT內部發起一個新的項目需求的時候,發起項目的申請人都必需提交項目發起的申請,包括背景、利益、目標、期望交付物、時間等。項目管理部門(有些企業是PMO,有些企業可能是IT部門)則根據已有的評估模型對其進行評估。該評估主要是測算該需求是否已經構成一個立項的必備條件。
(二)另外,如果項目管理部門確認該項目可以立項,那么應該在企業的項目管理系統上對該項目進行注冊。一般常用的DevOps工具會是Atlassian 的JIRA作為項目的管理工具及Confluence作為項目資產管理工具。
(三)在明確開展項目之前,需要與項目管理部門確認該項目是否已經成功立項。包括項目組織架構,項目的資源,項目的費用,項目的關鍵里程碑是否已經獲得項目委員會的確認。
四、項目計劃階段
(一)在初期計劃的時候,IT項目經理需要安排一次高階的系統影響分析,該分析是用于一些項目前期的高階方案評估。該分析需要與相關的IT專家或者在開發項目委員會及技術委員會達成一致。
(二)同時,IT項目經理需要在計劃階段把相關的IT團隊人員定義清晰。一般來說,一個軟件開發項目的IT角色會包括但是不限于,IT項目經理(Project Manager)、業務分析師(Business Analyst), 測試人員、質量保證人員、開發人員、架構師(軟件/硬件)、系統工程師、數據分析師、流程工程師、信息安全人員、IT財務人員、運維工程師等。
(三)如果是借助供應商能力來完成項目,則需要對供應商進行技術及價格的評估,一般來說,技術評估包含公司規模,人力資源需求,業務功能需求,技術層面需求,信息安全能力、項目管理水平,售后服務等大的方面。具體選擇供應商的流程,則按各企業自己的商務采購流程管理則可,這里不展開敘述。
(四)這里需要注意的是,IT項目經理必須按照企業的文化或者規定,把商務采購流程所需要的準備時間放到項目計劃中。
(五)當項目經理準備好項目計劃后,該計劃必須要與關鍵的干系人溝通并且確定。項目計劃的形成不是項目經理憑空想象出來的,而是項目經理與各關鍵干系人溝通后而制定出來的。
(六)當相關材料準備妥當后,該項目需要正式地在項目管理委員會(Project Board/Project Steering Committee)上進行啟動(Kick-off)。
(七)注意事項:在一些歐美企業,信息安全的審查在供應商能力評估的時候就已經引入。這也是DevSecOps的其中一環。
五、項目需求階段
(一)關于需求說明書,需要注意的是,我們必須要包含業務需求及IT需求,即是平常說的功能性需求和非功能性需求。
(二)需求的收集和分析,可以按照PRINCE2的作為基礎,結合DevSecOps的思想,得出F-O-C-U-S T-B-D 的業務分析框架。所謂FOCUS TBD框架,即使Functionality, Operativeness, Compliance, Usability, Security, Time Requirement, Budget Requirement , Documentation, Maintenance and Support. ?F-O-C-U-S T-B-D 是一個框架,每項展開都會包含若干小巷,我在這里就不一一詳述。
(三)需要注意的是,在需求階段,必須要記得包含非功能性的需求,因為這些很多業務部門不會提出來的。例如,可用性、兼容性、擴展性、容量、移動性、吞吐量、性能、災備、數據治理、信息安全等。從項目管理角度來看,這些非功能性的需求對項目的影響非常大。從IT治理的角度來看,這些非功能性的需求對整體IT治理影響非常大。我個人的建議是,IT項目經理更需要從IT管理者的角度去看待項目整體的影響,而不是僅僅從項目交付的角度去看。
(四)需求分析必須要連系到各個關鍵的干系人并與關鍵干系人達成一致,并最終在項目委員會上獲得審批。
(五)這里多說一點,在敏捷類的項目(Agile Project)中,我們會需要到需求管理委員會對項目的需求進行優先級處理,從而排進Sprint backlog 中。
六、項目設計階段
(一)項目的設計階段,項目經理需要關注的是,設計階段的交付物是否齊備,以及質量是否過關。設計是需求的延申,是開發的基礎。劣質的設計文檔會導致開發團隊“想當然”地進行開發,最終導致需求變形或者需求質量不及格。
(二)在需求說明書的基礎上,需要有功能說明書進一步細化需求說明,把業務語言轉換為IT語言便于開發者來看法。
(三)同時,需要關心該項目是否有影響整體的IT系統架構。項目的架構設計(包括應用架構、硬件架構、數據架構等)需要在技術委員會中進行討論及審核。
(四)信息安全的設計需要進行審核。最常見的例如,權限矩陣、權限設置、身份驗證、職責角色等。
(五)如果是多系統對接的項目,那么接口設計是否已經確定。
(六)系統應用及服務的監控是否已經設計確定。
(七)數據變更或合并、數據字典的更新是否已經確定。
(八)在設計階段,需要準備好后續的開發環境、測試環境、生產環境的相關軟件及硬件。
(九)最終,設計文檔需要在技術委員會中通過方可進入下一階段。
我們可以參考以下圖片,了解到軟件開發項目中常用的DevOps的管理工具。了解這些功能有助于IT項目經理明白到IT內部風險可能出自于哪一環節。
七、項目開發階段
(一)需要確保供應商的開發是否在企業IT要求的開發框架下進行。這點很重要,否則在未來隨著業務的發展及IT系統越來越多的時候,這個影響就會非常大。
(二)對于供應商開發的質量把控是項目經理需要注意的。對于多項目、生產故障修復、其他項目變更等高耦合的情況以及項目周期過長導致版本過多的情況,需要明確開發版本的控制。在該版本中是否包含了相關項目、生產故障修復、相關聯生產變更的內容。
(三)需要要求供應商提供單元測試報告并要求質量部門進行檢驗。
(四)對于多系統的開發,需要確保系統間的聯調通過。
(五)在合同允許的情況下,項目經理最好要求供應商提供源代碼。同時,需要組織相關開發人員對供應商的代碼進行code review以保證項目質量。
(六)IT項目經理需要組織IT內部相關人員對開發進行回顧及審批。
八、系統兼容性測試
(一)在開始系統兼容性測試 (SIT – System Integration Testing) 之前,確保相關準備工作已經完成,避免影響項目的進度,例如系統配置、數據導出導入、中間庫準備、系統連通性檢驗。
(二)SIT的測試案例是否已經完成。一般來說,SIT測試案例需要明確測試范圍、測試工具(最好是DevOps自動化測試工具,如Jenkins, Jemeter), 測試平臺、監控工具、被測試的系統環境、測試環境與生產環境的差異、性能參數分析、測試策略、測試場景、測試結果及分析等。
(三)根據項目具體情況安排壓力測試及回歸測試。
(四)最后,測試結果的報告需要在IT內部進行回顧并獲得審批方可進入下一階段。
九、用戶測試
(一)在用戶測試(UAT – User Acceptance Testing)開始之前,IT項目經理需要確保UAT環境的準備情況以確保UAT的開展可順利進行。例如: 配置、數據導出導入、中間庫準備、系統連通性檢驗。
(二)UAT 測試案例及測試場景及配置定義是否已經包含?一般來說,我會建議UAT的測試案例需要包括 測試案例序號、測試部門(如果是多部門項目)、測試系統、案例名稱、測試內容、測試步驟、預期結果、實際結果以及對應的BUG/ISSUE 單號。對于BUG/Issue管理, 可以用已經定義好的項目管理工具,例如JIRA/Confluence。
(三)UAT的測試案例最好由業務部門自己首先定義,IT部門提供協助和指導。測試案例是基于需求說明書而來的,并且是需求說明的實際操作化。
(四)需要注意的是,在UAT的測試中,除了業務部門的功能性測試,IT項目經理必須注意安排非功能性的測試。
(五)UAT的測試案例必須是業務部門與IT部門達成一致的結果。
(六)UAT測試完畢后,需要在項目管理委員會上審核UAT測試報告。該報告需要包含UAT的測試結果、相關BUG/ISSUE的處理結果等。
十、項目上線階段
(一)在項目上線之前,必須提前準備好包括部署手冊,操作手冊,支持安排、變更申請。并且確認生產環境是否已經準備妥當。
(二)相關上線的支持的培訓、支持流程是否已經準備妥當。
(三)上線的溝通計劃是否已經準備妥當。對于那些大范圍影響的項目,需要提前有明確的溝通計劃、培訓計劃甚至是差旅計劃等。
(四)上線后的試運營階段,IT項目經理需要完成項目的監控以及項目的運維交付(Operation Transition),具體交接時間按照項目的規模而定。
(五)需要有一個正式的結項會議,可以包含經驗教訓、項目上線后的運營情況分析、故障分析、優化分析、需要幫助等內容。
(六、)最后,需要履行結束合同并完成相應財務流程。
十一、最后,我以一張圖來總結基于PRINCE2及PMP的項目管理理論與DevSecOps管理理論相結合
十二、結語
這篇文章是對傳統的IT項目管理與開發運維的結合的嘗試的一個簡單的概括,不同企業會有不同的實際情況,也有不同的技術策略、IT策略和管理策略。希望這篇文章可以給讀者一些啟發,在IT項目的管理上提供幫助。(作者單位:中國人民大學)