混合型項目管理實踐案例

瀑布、敏捷和DevOps等等管理方法各有優劣，很多公司在推進項目管理體系的時候，由于不同的環境選擇的方法也各不相同，很多時候需要綜合運用多種方法的實際上形成了混合型項目管理，今天為大家分享一個混合型項目管理實際案例，供大家借鑒參考。

某主題App業務介紹

1、產品

致力于為消費者提供精品原創的個性化手機主題、表盤、字體、壁紙、AOD、鈴聲、美化等業務，秉持“匠心設計，靈感點亮生活”的品牌理念，助力全球優秀設計師、藝術家、開發者等內容生產者的優質作品獲得全球曝光及豐厚回報。

2、服務

能夠為用戶提供主題商店和主題內容管理服務、會員服務、造字服務、評論、社區和互動服務、活動及福利服務。

3、結構

從設計架構上看，該應用可分為服務器端（即云端）和客戶端，其中客戶端可裝在手機、平板、車機等電子產品上。

某主題App項目所處的環境

1、外部環境(VUCA 烏卡)：

Volatility（易變性）：移動端用戶欲望的變化，催生更多的需求變化；

Uncertainty（不確定性）：市場環境、行業環境和顧客需求的不確定高；

Complexity（復雜性）：項目面臨的諸多條件間的相互關系導致的復雜性越來越高；

Ambiguity（模糊性）：對現實的模糊，是各相關方誤解的根源，各種條件和因果關系的混雜；

2、內部環境:

組織沖突：制定決策的管理者與受這些決策影響的人之間存在的組織沖突；

利益沖突：相關方因位置不同導致的利益不一致；

客戶、合作方

角色：項目經理、SE（系統設計師）、開發、測試

VUCA環境下某主題App項目怎么做？

VUCA時代的不確定性和復雜性模型

不確定性和復雜性，導致不同的項目生命周期類型；

• 預測型：這是一種更為傳統的方法，提前進行大量的計劃工作， 然后一次性執行。【瀑布型、基建工程項目為例】；
• 迭代型：這種方法允許對未完成的工作進行反饋，從而改進和修改該工作?！?span id="t9ctkxq" class="candidate-entity-word" data-gid="1079938">軟件開發、管理咨詢】；
• 增量型：這種方法向客戶提供各個已完成的，可能立即使用的可交付成果?！镜禺a開發樣板間】；
• 敏捷型：這種方法既有迭代，也有增量，便于完善工作，頻繁交付?！拒浖_發、管理咨詢】；

某主題App項目生命周期的選擇

一、預測模式：

PMBOK指南（第六版/第七版）（PMI）；

在項目生命周期的早期階段確定項目范圍、時間和成本；

二、敏捷模式：

敏捷實踐指南（PMI-ACP）；

需求范圍在迭代開始之前就得到了定義、評估和批準；

三、DevOps模式：

《DevOps實踐指南》；

基于精益原則、約束理論、豐田生產系統、學習型組織等知識體系的集大成者；

DevOps三步工作法：流動原則、反饋原則、持續學習與實驗原則；

三張模式詳解

1、預測模式（軟件開發生命周期，也稱為瀑布模式）

預測型生命周期：預計會從高確定性的明確的需求、穩定的團隊和低風險中獲益。因此項目活動通常以順序方式執行，如下圖：

2、敏捷模式

1）迭代型生命周期

迭代型生命周期通過連續的原型或概念驗證來改進產品或成果。每一個新的原型都能帶來新的相關方新的反饋和團隊見解。然后，團隊在下一周期重復一個或多個項目活動，在其中納入新的信息。迭代有利于識別和減少項目的不確定性。

2）增量型生命周期

有些項目優化是為了加快交付速度。許多企業和項目無法等待所有的事情全部完成；這種情況下，客戶愿意接受整個解決方案的一個部分。這種少量可交付成果的頻繁交付稱為增量型生命周期。

3）敏捷型生命周期

3.1 基于迭代的敏捷

團隊以迭代（相等持續時間的時間盒）形式交付完整的功能。

3.2 基于流程的敏捷

團隊根據自身能力，從待辦事項列表中提取若干功能開始工作，而不是按照基于迭代的進度計劃開始工作。

基于迭代和基于流程的敏捷生命周期

3.3 敏捷方式

以最小可行性產品，交付給客戶，不斷的得到客戶的反饋， 不停的迭代，改進，完善，最終交付客戶的滿意成果

什么是敏捷？

一句話概括敏捷：敏捷就是“以人為本→化繁為簡→快速迭代→持續交付價值”的過程。

2001年，軟件行業思想領袖共同發表《敏捷宣言》，正 式宣告敏捷開發運動的開始。

2018年，項目管理協會（PMI ）和敏捷聯盟攜手發布 《敏捷實踐指南》，敏捷方法的應用逐漸從軟件行業向各行業擴展。

敏捷宣言、價值觀、原則和通用實踐之間的關系

敏捷典型實踐–Scrum，咱們以前分享過很多可以查閱：

圖解通俗易懂Scrum敏捷項目管理精華

圖解Scrum敏捷項目管理知識地圖【附知識地圖下載鏈接】

Scrum 敏捷項目管理精華PPT【文末可編輯PPT下載】

一圖掌握Scrum敏捷項目管理方法

DevOps模式是什么？

DevOps概念模型

通過開發(Dev）、IT運維（Ops）和質量保證（QA）的溝通和和協同，使得構建、測試、發布軟件能夠更加的敏捷、頻繁和可靠；

DevOps顯著特征：

1、必須擁有共同的目標；

2、打通用戶、PMO、需求、設計、開發（Dev）、測試、運維(Ops)等各上下游部門或不同角色；

3、打通業務、架構、代碼、測試、部署、監控、安全、性能等各領域工具鏈；

關于DevOps咱們也分享過很多相關內容，供大家參考：

終于有人把DevOps講明白了

TOP30個DevOps面試問題及如何解答？

學了敏捷，但你還不知道DevOps，就Out了【管理有度5】

DevOps如何幫助PM構建數字化的項目管理？

圖解DevOps流程體系全景圖–構建敏捷 持續交付的體系平臺

一文全面精通DevOps

如何構建基于瀑布、敏捷和DevOps混合模式項目管理框架？

為什么可以在某主題App項目中運用”預測 敏捷 DevOps“方法？

• 烏卡時代，該App開發需求不確定性和復雜程度增加，交付周期變短，需要快速做出反應，應對變化。
• 該App項目具備使用敏捷方法的基本條件，可以提高開發團隊的工作效率。
• 該App項目具備使用DevOps方法的技術條件，如架構解耦，系統支持拆分為可DevOps的單元，有微服務管理平臺支持，平臺服務支持和工具鏈支持等。

基于“瀑布”、“敏捷”和”DevOps”模式，以客戶（HW）的軟件工程能力為支撐，應用混合（也可稱為集成）開發生命周期，具體來說就是端到端的項目管理實施框架。

實施框架：融合預測-敏捷-DevOps

該框架是以版本（基線或補?。樽钚】蓪嵤﹩卧―evOps單元），分為持續規劃、持續開發、持續部署發布、持續運維、持續反饋等5個階段，每個階段的主要關鍵活動和工具如下：

全價值流中敏捷理念、工具和技術的應用：

端到端全流程的敏捷DevOps

1215敏捷項目管理模型：1個鐵三角，2個端到端交付環，15個實踐；

端到端DevOps框架可以有效實施的前提條件如下：

1、架構解耦，最小可行產品是敏捷的保障；

2、系統拆分為顆粒度合適的可DevOps的單元，是架構支持DevOps的基礎；

3、全面支持應用的一站式微服務管理平臺；

4、面向云服務/微服務的架構，向敏捷/DevOps全功能團隊轉型；

5、重塑角色設置，實現快速自我決策；

6、軟件分層、專業聚焦，平臺化，避免小團隊全棧能力構建，使能DevOps ；

7、支持服務/微服務DevOps的工具鏈及環境；

8、工具：自動化運維-基于數據分析的全方位故障監控；

01

架構解耦，最小可行產品是敏捷的保障；

1）架構與系統解耦，做到組件化，乃至微服務化：

實現松耦合，可并行開發、構建、測試、部署、運行的最小可運行產品/特性。

2）需求分解的原則：

需求分解遵循小步快跑，同一個特性可以由多個迭代Story逐步演進，從簡單 可用、到功能完善。

由橫向分層的大系統 ->縱向解耦的小系統演進 / 各個微服務/特性，可由獨立團隊并行開發交付。

02

系統拆分為顆粒度合適的可DevOps的單元，是架構支持DevOps的基礎；

? 盡量垂直劃分服務；

? 比較獨立的新業務優先采用微服務架構；

? 優先抽象通用服務；

? 優先抽象比較容易識別的，邊界比較明顯的服務；

? 優先抽象核心服務；

? 采用絞殺者模式。

03

全面支持應用的一站式微服務管理平臺；

04

面向云服務/微服務的架構，向敏捷/DevOps全功能團隊轉型；

對特性/部件/服務，完整的實施規劃/需求/設計/開發/測試并獨立部署、交付、運維（DevOps場景）的項目型團隊。

05

重塑角色設置，實現快速自我決策；

由“集團軍作戰”轉變為“班長的戰爭”，按照特性/微服務組建<10人的全功能團隊，“Two Pizza團隊“，實現業務快速開發、決策與上線。

06

軟件分層、專業聚焦，平臺化，避免小團隊全棧能力構建，使能DevOps ；

充分使用云基礎設施和平臺服務（IaaS/PaaS）,基于IaaS/PaaS動態分配資源。

分工細化，專業團隊提供專業云服務；

自治云服務承載架構復雜度；

07

支持服務/微服務DevOps的工具鏈及環境；

支持微服務DevOps獨立并行開發、測試，經過Gamma類生產環境驗證，實現灰度發布和頻繁快速上線，并持續反饋與演進。

08

工具：自動化運維-基于數據分析的全方位故障監控；

系統能夠自動化部署、升級和擴縮容，支持自動化監控、告警、故障的定界定位和故障自愈。

業務/服務的顆粒度更小，交付部署更頻繁迫切需要增強對服務、服務所部署的軟硬件環境的全方位監控、評估能力；構建針對各類日志、KPI數據、告警事件等的數據采集分析平臺。

某App開發項目的混合敏捷管理實踐方案

1、持續交付：持續交付核心實踐

2、持續交付：DevCloud實踐，每日持續交付流水線

解讀：

1. 每天晚11：00，由流水線觸發，從每個服務的代碼倉庫Release分支獲取代碼。進行靜態檢查、下載代碼、編譯構建、歸檔發布。

2. 每天凌晨0:00，觸發自動部署。流水線調用部署服務實現版本包的自動化部署。

3. 每天凌晨3:00，觸發自動化RF接口測試。

流水線的質量控制

? 源碼版本控制

? 分支策略

? 靜態掃描

? > 80% 代碼覆蓋率

? 漏洞掃描

? 開源掃描

? 制品版本控制

? 自動化環境準備

? 不可變的服務器

? 集成測試

? 性能測試

? 每次提交觸發自動化構建、部署、測試

? 自動變更單

? 低風險發布

? 特性開關

3、持續反饋：灰度發布策略驅動自動化部署與回滾

一鍵回滾；在線驗收測試；A/B測試；重要新特性友好用戶先體驗；

4、持續反饋：灰度發布，友好/公測完備流程，產品、運營、運維配合

5、持續反饋：VoC 驅動，持續規劃，數據分析，動態調整，有錯就改

PS：VoC : Voice of Customer 客戶聲音

項目實踐全景

PMO前沿《一杯咖啡談項目》專欄

特約作者介紹：張永彬，PMP/PMI-ACP，項目管理專業碩士，某軟件科技集團公司質量部總監；15 年消費電子和IT軟件兩大行業工程實踐者，現代項目管理方法的踐行者和推廣者。