混合型項目管理實踐案例

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

某主題App業(yè)務(wù)介紹

1、產(chǎn)品

致力于為消費者提供精品原創(chuàng)的個性化手機主題、表盤、字體、壁紙、AOD、鈴聲、美化等業(yè)務(wù)，秉持“匠心設(shè)計，靈感點亮生活”的品牌理念，助力全球優(yōu)秀設(shè)計師、藝術(shù)家、開發(fā)者等內(nèi)容生產(chǎn)者的優(yōu)質(zhì)作品獲得全球曝光及豐厚回報。

2、服務(wù)

能夠為用戶提供主題商店和主題內(nèi)容管理服務(wù)、會員服務(wù)、造字服務(wù)、評論、社區(qū)和互動服務(wù)、活動及福利服務(wù)。

3、結(jié)構(gòu)

從設(shè)計架構(gòu)上看，該應(yīng)用可分為服務(wù)器端（即云端）和客戶端，其中客戶端可裝在手機、平板、車機等電子產(chǎn)品上。

某主題App項目所處的環(huán)境

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

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

Uncertainty（不確定性）：市場環(huán)境、行業(yè)環(huán)境和顧客需求的不確定高；

Complexity（復(fù)雜性）：項目面臨的諸多條件間的相互關(guān)系導(dǎo)致的復(fù)雜性越來越高；

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

2、內(nèi)部環(huán)境:

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

利益沖突：相關(guān)方因位置不同導(dǎo)致的利益不一致；

客戶、合作方

角色：項目經(jīng)理、SE（系統(tǒng)設(shè)計師）、開發(fā)、測試

VUCA環(huán)境下某主題App項目怎么做？

VUCA時代的不確定性和復(fù)雜性模型

不確定性和復(fù)雜性，導(dǎo)致不同的項目生命周期類型；

• 預(yù)測型：這是一種更為傳統(tǒng)的方法，提前進行大量的計劃工作， 然后一次性執(zhí)行?！酒俨夹?、基建工程項目為例】；
• 迭代型：這種方法允許對未完成的工作進行反饋，從而改進和修改該工作。【軟件開發(fā)、管理咨詢】；
• 增量型：這種方法向客戶提供各個已完成的，可能立即使用的可交付成果?！镜禺a(chǎn)開發(fā)樣板間】；
• 敏捷型：這種方法既有迭代，也有增量，便于完善工作，頻繁交付?！拒浖_發(fā)、管理咨詢】；

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

一、預(yù)測模式：

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

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

二、敏捷模式：

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

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

三、DevOps模式：

《DevOps實踐指南》；

基于精益原則、約束理論、豐田生產(chǎn)系統(tǒng)、學(xué)習(xí)型組織等知識體系的集大成者；

DevOps三步工作法：流動原則、反饋原則、持續(xù)學(xué)習(xí)與實驗原則；

三張模式詳解

1、預(yù)測模式（軟件開發(fā)生命周期，也稱為瀑布模式）

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

2、敏捷模式

1）迭代型生命周期

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

2）增量型生命周期

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

3）敏捷型生命周期

3.1 基于迭代的敏捷

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

3.2 基于流程的敏捷

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

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

3.3 敏捷方式

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

什么是敏捷？

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

2001年，軟件行業(yè)思想領(lǐng)袖共同發(fā)表《敏捷宣言》，正 式宣告敏捷開發(fā)運動的開始。

2018年，項目管理協(xié)會（PMI ）和敏捷聯(lián)盟攜手發(fā)布 《敏捷實踐指南》，敏捷方法的應(yīng)用逐漸從軟件行業(yè)向各行業(yè)擴展。

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

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

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

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

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

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

DevOps模式是什么？

DevOps概念模型

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

DevOps顯著特征：

1、必須擁有共同的目標(biāo)；

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

3、打通業(yè)務(wù)、架構(gòu)、代碼、測試、部署、監(jiān)控、安全、性能等各領(lǐng)域工具鏈；

關(guān)于DevOps咱們也分享過很多相關(guān)內(nèi)容，供大家參考：

終于有人把DevOps講明白了

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

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

DevOps如何幫助PM構(gòu)建數(shù)字化的項目管理？

圖解DevOps流程體系全景圖–構(gòu)建敏捷 持續(xù)交付的體系平臺

一文全面精通DevOps

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

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

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

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

實施框架：融合預(yù)測-敏捷-DevOps

該框架是以版本（基線或補丁）為最小可實施單元（DevOps單元），分為持續(xù)規(guī)劃、持續(xù)開發(fā)、持續(xù)部署發(fā)布、持續(xù)運維、持續(xù)反饋等5個階段，每個階段的主要關(guān)鍵活動和工具如下：

全價值流中敏捷理念、工具和技術(shù)的應(yīng)用：

端到端全流程的敏捷DevOps

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

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

1、架構(gòu)解耦，最小可行產(chǎn)品是敏捷的保障；

2、系統(tǒng)拆分為顆粒度合適的可DevOps的單元，是架構(gòu)支持DevOps的基礎(chǔ)；

3、全面支持應(yīng)用的一站式微服務(wù)管理平臺；

4、面向云服務(wù)/微服務(wù)的架構(gòu)，向敏捷/DevOps全功能團隊轉(zhuǎn)型；

5、重塑角色設(shè)置，實現(xiàn)快速自我決策；

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

7、支持服務(wù)/微服務(wù)DevOps的工具鏈及環(huán)境；

8、工具：自動化運維-基于數(shù)據(jù)分析的全方位故障監(jiān)控；

01

架構(gòu)解耦，最小可行產(chǎn)品是敏捷的保障；

1）架構(gòu)與系統(tǒng)解耦，做到組件化，乃至微服務(wù)化：

實現(xiàn)松耦合，可并行開發(fā)、構(gòu)建、測試、部署、運行的最小可運行產(chǎn)品/特性。

2）需求分解的原則：

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

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

02

系統(tǒng)拆分為顆粒度合適的可DevOps的單元，是架構(gòu)支持DevOps的基礎(chǔ)；

? 盡量垂直劃分服務(wù)；

? 比較獨立的新業(yè)務(wù)優(yōu)先采用微服務(wù)架構(gòu)；

? 優(yōu)先抽象通用服務(wù)；

? 優(yōu)先抽象比較容易識別的，邊界比較明顯的服務(wù)；

? 優(yōu)先抽象核心服務(wù)；

? 采用絞殺者模式。

03

全面支持應(yīng)用的一站式微服務(wù)管理平臺；

04

面向云服務(wù)/微服務(wù)的架構(gòu)，向敏捷/DevOps全功能團隊轉(zhuǎn)型；

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

05

重塑角色設(shè)置，實現(xiàn)快速自我決策；

由“集團軍作戰(zhàn)”轉(zhuǎn)變?yōu)椤鞍嚅L的戰(zhàn)爭”，按照特性/微服務(wù)組建<10人的全功能團隊，“Two Pizza團隊“，實現(xiàn)業(yè)務(wù)快速開發(fā)、決策與上線。

06

軟件分層、專業(yè)聚焦，平臺化，避免小團隊全棧能力構(gòu)建，使能DevOps ；

充分使用云基礎(chǔ)設(shè)施和平臺服務(wù)（IaaS/PaaS）,基于IaaS/PaaS動態(tài)分配資源。

分工細化，專業(yè)團隊提供專業(yè)云服務(wù)；

自治云服務(wù)承載架構(gòu)復(fù)雜度；

07

支持服務(wù)/微服務(wù)DevOps的工具鏈及環(huán)境；

支持微服務(wù)DevOps獨立并行開發(fā)、測試，經(jīng)過Gamma類生產(chǎn)環(huán)境驗證，實現(xiàn)灰度發(fā)布和頻繁快速上線，并持續(xù)反饋與演進。

08

工具：自動化運維-基于數(shù)據(jù)分析的全方位故障監(jiān)控；

系統(tǒng)能夠自動化部署、升級和擴縮容，支持自動化監(jiān)控、告警、故障的定界定位和故障自愈。

業(yè)務(wù)/服務(wù)的顆粒度更小，交付部署更頻繁迫切需要增強對服務(wù)、服務(wù)所部署的軟硬件環(huán)境的全方位監(jiān)控、評估能力；構(gòu)建針對各類日志、KPI數(shù)據(jù)、告警事件等的數(shù)據(jù)采集分析平臺。

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

1、持續(xù)交付：持續(xù)交付核心實踐

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

解讀：

1. 每天晚11：00，由流水線觸發(fā)，從每個服務(wù)的代碼倉庫Release分支獲取代碼。進行靜態(tài)檢查、下載代碼、編譯構(gòu)建、歸檔發(fā)布。

2. 每天凌晨0:00，觸發(fā)自動部署。流水線調(diào)用部署服務(wù)實現(xiàn)版本包的自動化部署。

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

流水線的質(zhì)量控制

? 源碼版本控制

? 分支策略

? 靜態(tài)掃描

? > 80% 代碼覆蓋率

? 漏洞掃描

? 開源掃描

? 制品版本控制

? 自動化環(huán)境準(zhǔn)備

? 不可變的服務(wù)器

? 集成測試

? 性能測試

? 每次提交觸發(fā)自動化構(gòu)建、部署、測試

? 自動變更單

? 低風(fēng)險發(fā)布

? 特性開關(guān)

3、持續(xù)反饋：灰度發(fā)布策略驅(qū)動自動化部署與回滾

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

4、持續(xù)反饋：灰度發(fā)布，友好/公測完備流程，產(chǎn)品、運營、運維配合

5、持續(xù)反饋：VoC 驅(qū)動，持續(xù)規(guī)劃，數(shù)據(jù)分析，動態(tài)調(diào)整，有錯就改

PS：VoC : Voice of Customer 客戶聲音

項目實踐全景

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

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