從IT項(xiàng)目管理看待PMBOK和敏捷開發(fā)

陶思俊

?

從IT項(xiàng)目管理看待PMBOK和敏捷開發(fā)

陶思俊

（中國(guó)人民大學(xué)信息學(xué)院，北京 100872）

PMBOK是項(xiàng)目管理界的“圣經(jīng)”，堅(jiān)持與時(shí)俱進(jìn)，作為項(xiàng)目管理的基礎(chǔ)課程多年以來保持長(zhǎng)盛不衰。與此同時(shí)，從01年敏捷宣言的發(fā)布以來，IT領(lǐng)域掀起了一場(chǎng)“敏捷開發(fā)”的變革，它通過適應(yīng)性的開發(fā)和管理模式，試圖對(duì)40多年來的軟件工程進(jìn)行重新的梳理和流程再造。兩者之間是什么樣的一種關(guān)系呢？敏捷開發(fā)對(duì)于PMBOK來說，究竟是一種補(bǔ)充，還是一種顛覆，并就此證明PMBOK在IT領(lǐng)域已經(jīng)失效。通過對(duì)兩者理論背后的邏輯進(jìn)行深入剖析，試圖揭開面紗背后真正的答案。

PMBOK；敏捷開發(fā)；Scrum；極限編程

1 PMBOK

1.1 PMBOK的目的

項(xiàng)目管理作為一門專業(yè)，已得到認(rèn)可，這表明知識(shí)、過程、技能、工具和技術(shù)的應(yīng)用，對(duì)于項(xiàng)目的成功有顯著影響。PMBOK?指南收錄項(xiàng)目管理知識(shí)體系中被“普遍認(rèn)可”為“良好做法”的那一部分?！捌毡檎J(rèn)可”指這些知識(shí)和做法在大多數(shù)時(shí)候適用于大多數(shù)項(xiàng)目，并且其價(jià)值和有效性已獲得一致認(rèn)可?！傲己米龇ā保瑒t指人們普遍認(rèn)為，使用這些知識(shí)、技能、工具和技術(shù)，能夠大幅提高項(xiàng)目成功的可能性，但并不意味著這些知識(shí)和做法總應(yīng)一成不變地應(yīng)用于所有項(xiàng)目；組織或項(xiàng)目管理團(tuán)隊(duì)負(fù)責(zé)確定哪些知識(shí)適用于具體的項(xiàng)目。

由此我們可以得出：PMBOK是一門以具體的實(shí)踐歸納出的“最佳實(shí)踐”的集合，而并非是演繹出的科學(xué)。我們知道：越是所謂“普遍認(rèn)可”的概念，其抽象層級(jí)就越高，因?yàn)樵骄唧w的概念和實(shí)踐，其適用性就越受到上下文和情境的制約，而從PMBOK提供的項(xiàng)目管理框架，我們也可以了解到，即PMBOK提供了一系列框架和接口，而并沒有提供具體的實(shí)現(xiàn)方法。假如在我們做IT項(xiàng)目時(shí)，到底選擇傳統(tǒng)的瀑布模型，還是CMMI模型，或是敏捷開發(fā)模型來實(shí)現(xiàn)這套框架，PMBOK并不關(guān)心。

1.2 PMBOK中的核心概念：十大領(lǐng)域、五大管理過程組

PMBOK核心的概念莫過于十大領(lǐng)域、五大管理過程組，47個(gè)管理過程被歸納在內(nèi)。其內(nèi)容如圖1所示。

圖1

PMBOK中非常直接地指明了“任何項(xiàng)目都必須的五大管理過程組”，這個(gè)說法從邏輯上可推論出：（1）五大管理過程組對(duì)于所有項(xiàng)目來說都是必須的；（2）IT軟件項(xiàng)目也是項(xiàng)目；（3）五大管理過程組對(duì)于IT項(xiàng)目也是必須的?？梢娢宕蠊芾磉^程組的概念在PMBOK中的核心地位。

2 敏捷開發(fā)

2.1 傳統(tǒng)瀑布模式下的問題

傳統(tǒng)的瀑布模式開發(fā)，起源于1970年溫斯頓·羅伊斯的一篇論文，論文中指出了非常分明的幾個(gè)階段，正由于此，從概要設(shè)計(jì)完成的時(shí)候開始，后續(xù)對(duì)于需求的修改都會(huì)充滿痛苦。作為項(xiàng)目經(jīng)理，無法自如地調(diào)整需求；作為開發(fā)團(tuán)隊(duì)，對(duì)于上游的需求修改也是叫苦連天。因此就產(chǎn)生了一種趨勢(shì)，在項(xiàng)目開始階段，雙方會(huì)對(duì)項(xiàng)目的范圍進(jìn)行一場(chǎng)拉鋸戰(zhàn)，項(xiàng)目經(jīng)理希望范圍更大一些，因?yàn)橐坏╅_始開發(fā)，再做調(diào)整就是不可能的事情，而那個(gè)時(shí)候再發(fā)現(xiàn)當(dāng)初少了什么，都是項(xiàng)目經(jīng)理的責(zé)任；而開發(fā)團(tuán)隊(duì)因?yàn)樽陨淼纳a(chǎn)力有限，不可能承受比自己產(chǎn)能更多的需求，于是希望盡可能地減需求。直到項(xiàng)目范圍討論的Dead line臨近，或者雙方都已經(jīng)筋疲力盡的時(shí)候，博弈才會(huì)取得一個(gè)暫時(shí)的一致。如果項(xiàng)目出了問題，雙方又會(huì)對(duì)責(zé)任劃分進(jìn)行新的一輪爭(zhēng)吵。這難道真的就是我們想要的結(jié)果嗎？最終的結(jié)果就是程序員們付出了自己的青春年華和無數(shù)個(gè)不眠之夜，生產(chǎn)出了大量的沒有人用的代碼，據(jù)統(tǒng)計(jì)，真正投入使用的代碼其實(shí)數(shù)量不過半。

所有軟件開發(fā)的過程都是為了一個(gè)目的：盡可能將問題發(fā)現(xiàn)在前期，而面對(duì)著一堆文檔，我們真的可能把程序的問題都發(fā)現(xiàn)在紙堆中嗎？

值得多說一句的是，任何一個(gè)返回頭來看一下溫斯頓·羅伊斯那篇論文的人，都會(huì)為羅伊斯叫一聲屈，因?yàn)楹笕说娜嗽埔嘣谱屗倪@篇論文飽受爭(zhēng)議。這篇論文在開篇提到了軟件開發(fā)的階段，但下面的一段話卻是：“我相信這種方式，但上面列出的這種方法其實(shí)是會(huì)導(dǎo)致失敗的?！闭撐闹兴f，原因就在于我們總是一廂情愿地認(rèn)為在下一個(gè)階段就能把這個(gè)階段的問題全部修訂，列車總會(huì)一直向前開，但實(shí)際上我們總是在項(xiàng)目的中后期發(fā)現(xiàn)設(shè)計(jì)的問題，在編碼完成之前，我們是看不到軟件運(yùn)行的樣子的。為了解決這個(gè)問題，他提出應(yīng)當(dāng)把交付分開來完成，一個(gè)12個(gè)月的項(xiàng)目，至少應(yīng)當(dāng)在3-4個(gè)月的時(shí)候交付一版，干系人看過之后再繼續(xù)進(jìn)行，另外應(yīng)該加強(qiáng)和客戶的聯(lián)系和合作。他的這個(gè)觀點(diǎn)其實(shí)是和2001年敏捷宣言的內(nèi)容是不謀而合的。

2.2 敏捷開發(fā)的起源

正是由于以上提到的種種問題，在上世紀(jì)90年代，各種先鋒者的嘗試和方法百家爭(zhēng)鳴，Scrum、Crystal、RUP、極限編程都提出了自己的方法。在各家嘗試了近10年之后，2001年有十幾位大師級(jí)的程序員相聚在美國(guó)的雪鳥滑雪場(chǎng)，在進(jìn)行了幾輪討論之后，大家發(fā)現(xiàn)雖然我們的方式不盡相同，但核心理念是一致的：我們希望更有效地生產(chǎn)代碼，所以這次大會(huì)上產(chǎn)生了在這十幾年中熠熠生輝的敏捷宣言：

我們一直在實(shí)踐中探尋更好的軟件開發(fā)方法，身體力行的同時(shí)也幫助他人。由此我們建立了如下價(jià)值觀：

（1）個(gè)體和互動(dòng) 高于 流程和工具

（2）工作的軟件 高于 詳盡的文檔

（3）客戶合作 高于 合同談判

（4）響應(yīng)變化 高于 遵循計(jì)劃

也就是說，盡管右邊的項(xiàng)目有其價(jià)值，但我們更重視左邊的項(xiàng)目?jī)r(jià)值。

敏捷開發(fā)以Scrum、極限編程為代表。

Scrum是一種輕量級(jí)的產(chǎn)品開發(fā)框架，它將一個(gè)發(fā)布分為若干個(gè)迭代，每一個(gè)迭代完成之后都會(huì)生產(chǎn)出“潛在可交付”的軟件，整個(gè)的項(xiàng)目都在不斷地和客戶溝通、演示、確定優(yōu)先級(jí)中進(jìn)行。

極限編程是一個(gè)輕量級(jí)的、靈巧的軟件開發(fā)方法，同時(shí)也是一個(gè)非常嚴(yán)謹(jǐn)和周密的方法。它體現(xiàn)的價(jià)值觀是：交流、樸素、反饋和勇氣。任何一個(gè)軟件項(xiàng)目都可以從四個(gè)方面入手進(jìn)行改善：加強(qiáng)交流；從簡(jiǎn)單做起；尋求反饋；勇于實(shí)事求是。極限編程是一種近螺旋式的開發(fā)方法，它將復(fù)雜的開發(fā)過程分解為一個(gè)個(gè)相對(duì)比較簡(jiǎn)單的小周期；通過積極的交流、反饋以及其它一系列的方法，開發(fā)人員和客戶可以非常清楚開發(fā)進(jìn)度、變化、待解決的問題和潛在的困難等，并根據(jù)實(shí)際情況及時(shí)地調(diào)整開發(fā)過程。其中包括13種具體的實(shí)踐，諸如：團(tuán)隊(duì)協(xié)作，規(guī)劃策略，結(jié)對(duì)編程，測(cè)試驅(qū)動(dòng)開發(fā)，重構(gòu)，簡(jiǎn)單設(shè)計(jì)，代碼集體所有權(quán)，持續(xù)集成，客戶測(cè)試，小型發(fā)布，每周40小時(shí)工作制，編碼規(guī)范，系統(tǒng)隱喻等。

2.3 敏捷開發(fā)的主要理念和框架

敏捷開發(fā)主要以迭代式增量交付為基礎(chǔ)，小批量地交付可工作的軟件，其基本框架如圖2。

圖2

其中一切都是從產(chǎn)品待辦事項(xiàng)列表開始的，我們都知道，大批量的工作同時(shí)展開是浪費(fèi)之源，所以從源頭就需要將大塊頭的任務(wù)進(jìn)行拆解，借助persona、場(chǎng)景分析、MVP梳理等過程進(jìn)行用戶故事的拆分，并進(jìn)行排序和評(píng)估，從而安排每一個(gè)迭代的工作。迭代增量式交付一開始看上去總會(huì)很美，但很快就會(huì)遇到問題，其一是增量式的交付會(huì)帶來無止境的回歸測(cè)試，其二是不可避免的代碼腐化，其三是盡管需求可以拆分得很小，但由于固定的人只能做固定的事，在調(diào)配資源的時(shí)候就會(huì)捉襟見肘，這也是很多大公司面臨的問題。

對(duì)于這三個(gè)問題，敏捷開發(fā)都給出了自己的解決方案，它倡導(dǎo)將質(zhì)量?jī)?nèi)嵌在開發(fā)過程中，質(zhì)量保障工作是貫穿始終的，技術(shù)水平的提升也讓自動(dòng)化測(cè)試、持續(xù)集成成為可能,同時(shí)敏捷開發(fā)認(rèn)為代碼總是動(dòng)態(tài)修改的，所以我們應(yīng)當(dāng)掌握的技能就是重構(gòu)和測(cè)試驅(qū)動(dòng)開發(fā)，好的架構(gòu)是生長(zhǎng)出來的，而非幾個(gè)架構(gòu)師用PPT畫出來的,最后提倡學(xué)習(xí)型組織，技能擴(kuò)展，一專多能的人才是現(xiàn)代軟件開發(fā)中最需要的，所以以特性團(tuán)隊(duì)的方式取代老的組件團(tuán)隊(duì)，一切以交付優(yōu)先，而這也就是PMBOK中提到過的強(qiáng)矩陣和弱矩陣之間的關(guān)系。

3 PMBOK的十領(lǐng)域，五大過程和敏捷項(xiàng)目管理的對(duì)比

這里其實(shí)有一個(gè)問題，即敏捷開發(fā)模型并沒有直接提到PMBOK中所述的十大領(lǐng)域、五大管理過程，只是提出了一系列的實(shí)踐方法，那這套實(shí)踐方法究竟和PMBOK之間是否存在著什么關(guān)聯(lián)呢？換句話說，敏捷開發(fā)模型這只“孫猴子”究竟有沒有跳出PMBOK的“五指山”呢？

PMBOK中并沒有規(guī)定適用的項(xiàng)目生命周期，階段式（瀑布）和敏捷所倡導(dǎo)的迭代增量式的兩種生命周期在POBOK中都被提及，PMBOK中所述適用迭代增量的項(xiàng)目特征是這樣的：“組織需要管理不斷變化的目標(biāo)和范圍，組織需要降低項(xiàng)目的復(fù)雜性，或者，產(chǎn)品的部分交付有利于一個(gè)或多個(gè)干系人，且不會(huì)影響最終或整批可交付成果的交付。大型復(fù)雜項(xiàng)目通常采用迭代方式來實(shí)施，這使項(xiàng)目團(tuán)隊(duì)可以在迭代過程中綜合考慮反饋意見和經(jīng)驗(yàn)教訓(xùn)，從而降低項(xiàng)目風(fēng)險(xiǎn)?！?/p>

只能說PMBOK中描述的具有這種特征的項(xiàng)目，目前看來軟件開發(fā)是最合適不過的，它的目標(biāo)和范圍變化速度很快，復(fù)雜性很高，最重要的是采用迭代、增量式的交付“不會(huì)影響最終或整批可交付成果的交付”，這恰恰是軟件中的“軟”所具備的特征。

我們可以逐項(xiàng)去看一下，敏捷項(xiàng)目管理是采用了什么樣的方式來實(shí)現(xiàn)了PMBOK的框架，見表1。

表1

PMBOK敏捷項(xiàng)目管理敏捷開發(fā)典型實(shí)踐 整合以迭代方式進(jìn)行開發(fā)，小步快跑迭代 范圍價(jià)值驅(qū)動(dòng)；根據(jù)市場(chǎng)、技術(shù)變化及時(shí)增減需求，并對(duì)需求進(jìn)行優(yōu)先級(jí)排序。產(chǎn)品/迭代backlog、用戶故事、迭代計(jì)劃會(huì)議 時(shí)間開發(fā)過程被分割成1～4周的迭代；發(fā)布在迭代交付上按需定義。燃盡圖、累積流圖、迭代、持續(xù)交付 成本評(píng)估為預(yù)算服務(wù)；隨時(shí)都需要對(duì)投入產(chǎn)出作出衡量。迭代、用戶故事、精益需求管理 質(zhì)量?jī)?nèi)嵌質(zhì)量于開發(fā)過程中：只有業(yè)務(wù)人員驗(yàn)收了才算開發(fā)完成；持續(xù)提升軟件的可上線成熟度。質(zhì)量驅(qū)動(dòng)開發(fā)、持續(xù)集成、持續(xù)交付 人力資源和最好的人、團(tuán)隊(duì)合作；鼓勵(lì)追求卓越。建設(shè)學(xué)習(xí)型組織、回顧會(huì)議、讀書會(huì) 溝通通過讓團(tuán)隊(duì)一地工作來消除溝通隔閡；經(jīng)?？焖俳o客戶展示成果；簡(jiǎn)單化管理報(bào)告。每日站會(huì)、驗(yàn)收和展示、結(jié)對(duì)編程 風(fēng)險(xiǎn)交付風(fēng)險(xiǎn)高的優(yōu)先考慮；軟件可上線成熟度提升減少交付風(fēng)險(xiǎn)。風(fēng)險(xiǎn)驅(qū)動(dòng)開發(fā)

4 結(jié)論

任何一種理論框架我們都應(yīng)當(dāng)辯證地去看，沒有放之四海而皆準(zhǔn)的所謂“銀彈”，我們既不能把前人總結(jié)的理論拋之不顧，也不能照搬生套所謂的理論框架，前者會(huì)讓我們重復(fù)造輪子而無法站在前人的肩膀之上，后者的行為無異于刻舟求劍、按圖索驥。

既然是管理項(xiàng)目，我們應(yīng)當(dāng)因地制宜，每一個(gè)項(xiàng)目因?yàn)樗?guī)模大小、產(chǎn)品面對(duì)的市場(chǎng)都有所不同，例如移動(dòng)APP和大型通信類產(chǎn)品，300人的項(xiàng)目和10人的項(xiàng)目，在項(xiàng)目立項(xiàng)之時(shí)我們就應(yīng)當(dāng)確定項(xiàng)目管理的策略，究竟應(yīng)當(dāng)采取什么樣的管理方式、工具、過程，而這個(gè)過程恰恰是在PMBOK所處的理論層面上進(jìn)行，進(jìn)一步我們可以采用敏捷開發(fā)所提供的工具庫(kù)來實(shí)現(xiàn)我們的管理框架和策略，雙方應(yīng)當(dāng)是一個(gè)和諧共生的關(guān)系。PMBOK為敏捷開發(fā)提供了前人的知識(shí)結(jié)晶，敏捷開發(fā)為PMBOK提供了價(jià)值驅(qū)動(dòng)、靈活應(yīng)變的思維方式，我相信在未來一段時(shí)間當(dāng)中，兩者在軟件項(xiàng)目管理中只能進(jìn)一步融合，雙方都會(huì)吸納對(duì)方的觀點(diǎn)和理論，因?yàn)閮烧吒灸康氖且恢碌摹?/p>

[1](美)Project Management Institute.項(xiàng)目管理知識(shí)體系指南(PMBOK指南 第5版)[M].北京:電子工業(yè)出版社,2013.46-61.

[2](美)肖爾(Shore,J.),活登(Warden,S.).敏捷開發(fā)的藝術(shù)[M].南京:東南大學(xué)出版社,2008.26-38,431-439.

[3]張海藩.軟件工程導(dǎo)論(第5版)[M].北京:清華大學(xué)出版社,2012.15-16,25-28.

2014-11-19

陶思?。?981-）,男,遼寧大連人,中國(guó)人民大學(xué)信息學(xué)院IT項(xiàng)目管理專業(yè)碩士研究生,研究方向?yàn)镮T項(xiàng)目管理.

TP311.5

A

1672-4658(2015)02-0180-04