《項(xiàng)目管理心理學(xué)實(shí)戰(zhàn)》之項(xiàng)目生命周期模型（三）

申請免費(fèi)試用、咨詢電話：400-8352-114

　　自適應(yīng)模型是PMBOK第5版最新引進(jìn)的，PMBOK把普遍流行的敏捷開發(fā)方法包含到體系中來了。項(xiàng)目管理者聯(lián)盟

　　這種模型是針對原來的計(jì)劃、設(shè)計(jì)、實(shí)施、測試、交付這樣的流水線的工作模式的各種缺陷而提出的。其鼓勵(lì)變革，反對機(jī)械的文檔控制，反對教條的軟件工程方法。這種方法的提出對于過去那些飽受項(xiàng)目管理部門折磨的技術(shù)人員來講是一個(gè)福音，一經(jīng)問世便得到了廣大技術(shù)人員的追捧。所以在敏捷開始的時(shí)候，更像是一種程序員的宗教，其被追捧的狂熱程度可窺一斑。而一些中小軟件開發(fā)企業(yè)，因?yàn)楸籆MMI等重量級的體系實(shí)施的成本、周期和其復(fù)雜性所嚇倒，從而轉(zhuǎn)向這種輕量級的開發(fā)模型。最近幾年，敏捷方法已經(jīng)開始大行其道，好多原來的重量級的大型企業(yè)也紛紛引入這種方法。項(xiàng)目管理者聯(lián)盟

　　那么這種方法為什么會得到普遍的認(rèn)可?這其實(shí)也是軟件企業(yè)一直以來面對的一種困惑，那就是，軟件到底可不可以當(dāng)做一個(gè)工程來進(jìn)行管理?軟件工程的提法到底是否合適?軟件開發(fā)和傳統(tǒng)行業(yè)最大的區(qū)別就是它可以把程序員的思想直接變成固化的代碼，從而成為產(chǎn)品的一部分。這種把思想直接轉(zhuǎn)化為人類使用的產(chǎn)品是人類以前除了創(chuàng)作藝術(shù)作品之外從來沒有過的工作。人的思想如此復(fù)雜，難以量化和精確控制。所以連如何來衡量程序員的工作量這個(gè)在傳統(tǒng)工程領(lǐng)域都稱不上困難的事情在軟件開發(fā)領(lǐng)域卻都成了幾乎無法完成的事情。從上個(gè)世紀(jì)50~60年代的軟件工程危機(jī)開始，研究學(xué)者們一直試圖通過工程的方法，把軟件開發(fā)變成一個(gè)可以按照計(jì)劃精確控制的行為。以此觀點(diǎn)為中心開辟了軟件工程這個(gè)學(xué)科，提出了許多種解決方案，但是都存在著各種各樣的問題。我們熟知的軟件產(chǎn)品，例如MS-Office、Visual Studio、Oracle數(shù)據(jù)庫等，幾乎沒有哪個(gè)產(chǎn)品是在計(jì)劃時(shí)間內(nèi)完成的，延期半年完成都是十分常見的事情。而敏捷方法的提出，第一次從非傳統(tǒng)工程的領(lǐng)域來看待這個(gè)過程。從軟件本身的特點(diǎn)來看待這個(gè)問題。這在現(xiàn)在軟件逐漸向移動終端轉(zhuǎn)移，講求碎片化、逐步完善的產(chǎn)品，“永遠(yuǎn)的測試版”的環(huán)境下，便迅速成為了主流開發(fā)方法。bbs.mypm.net

　　這種方法最初鼓吹不要規(guī)范教條的文檔，不要機(jī)械嚴(yán)格的設(shè)計(jì)，不要板起臉嚇人的規(guī)矩或者合同，要的是靈活性、用戶的體驗(yàn)和良好的用戶合作關(guān)系。但是如何解決軟件中需求變化，程序員經(jīng)驗(yàn)不豐富，質(zhì)量難以保證的難題呢?這種方法其實(shí)一開始只是提供了幾個(gè)技術(shù)上的解決方案。例如，采用軟件重構(gòu)方法來解決代碼需要中途改動的問題，采用測試工具(JUnit)來解決質(zhì)量問題，采用用戶故事卡片來解決需求準(zhǔn)確表達(dá)問題，采用用戶關(guān)心的特性點(diǎn)來解決用戶體驗(yàn)問題等等，其他還有許多類似的方法。這些方法在技術(shù)上已經(jīng)有了現(xiàn)成的實(shí)現(xiàn)框架，例如Martin Fowler寫的一本書《企業(yè)架構(gòu)設(shè)計(jì)模式》堪稱經(jīng)典。受其影響，軟件架構(gòu)師成為了一種時(shí)髦職業(yè)。關(guān)于測試，更是有人提出了測試驅(qū)動的開發(fā)方法?？梢哉f，這些技術(shù)的發(fā)展，反過來也深刻地影響了敏捷方法的推廣。好多設(shè)計(jì)模式成為了程序員的常用詞匯。例如，工廠模式、面向切片開發(fā)(AOP)、反轉(zhuǎn)控制(IOC)等。項(xiàng)目管理者聯(lián)盟

　　1 業(yè)務(wù)和管理項(xiàng)目管理者聯(lián)盟

　　這里我們不妨從兩個(gè)角度來看待這種方法。在項(xiàng)目管理中，一直有兩個(gè)相互不同的視角在影響著項(xiàng)目。一個(gè)是管理本身的需要，那就是可以精確控制，我們姑且稱之為管控視角。另外一個(gè)是項(xiàng)目的工作本身需要，我們不妨稱之為業(yè)務(wù)視角。項(xiàng)目管理者聯(lián)盟

　　管理者有個(gè)本能，那就是希望知道項(xiàng)目中發(fā)生的每件事情，例如工作效率怎么樣，有什么錯(cuò)誤產(chǎn)生，如果有可能，他們一定喜歡知道你現(xiàn)在心情怎么樣，昨天睡覺睡得好嗎?現(xiàn)在工作的“戰(zhàn)斗力”是多少?成為管理者這個(gè)事實(shí)意味著他們心里永遠(yuǎn)有那種一切事情我都想知道，一切事情我都可以控制這樣的沖動。所以，當(dāng)管理者站在管理的角度上來看的時(shí)候，他們會認(rèn)為所有那些報(bào)告文檔都很重要，所有詳細(xì)的計(jì)劃都必不可少。例如質(zhì)量計(jì)劃、風(fēng)險(xiǎn)計(jì)劃、溝通計(jì)劃、評審報(bào)告和項(xiàng)目進(jìn)展情況報(bào)告等。在那些控制要求比較高的領(lǐng)域，這種現(xiàn)象就會變得更為嚴(yán)重，例如，ISO9000。當(dāng)管理者覺得需要在某個(gè)環(huán)節(jié)加一個(gè)控制點(diǎn)，來檢驗(yàn)這個(gè)節(jié)點(diǎn)的狀態(tài)，進(jìn)行管理控制的時(shí)候，這里往往就會產(chǎn)生一個(gè)管理文檔。作者曾經(jīng)和許多公司高層管理者討論過一套國家軟件開發(fā)文檔標(biāo)準(zhǔn)指南里面提到的文檔需不需要在公司中采用，這套文檔有72個(gè)。我驚訝地發(fā)現(xiàn)，凡是關(guān)于管控的文檔他們的回答出奇地一致，那就是如果這個(gè)不需花費(fèi)很多力氣的話，那么最好還是采用這個(gè)文檔。這就是管理者最本能的沖動。而傳統(tǒng)的重量級的體系，往往就是站在這樣的一種管控視角。因此，讓廣大技術(shù)開發(fā)人員深受其害。