第六節 將變化進行到底——自適應模型

自適應模型是PMBOK第5版最新引進的，PMBOK把普遍流行的敏捷開發方法包含到體系中來了。

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

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

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

1.業務和管理

這里我們不妨從兩個角度來看待這種方法。在項目管理中，一直有兩個相互不同的視角在影響著項目。一個是管理本身的需要，那就是可以精確控制，我們姑且稱之為管控視角。另外一個是項目的工作本身需要，我們不妨稱之為業務視角。

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

業務視角則不同，這個視角完全是站在實際工作需要的角度上進行。例如項目的設計方案和需求分析無論是不是以文檔的方式表現出來，如果沒有這些工件是不可能完成項目的。這些文檔就成為業務視角上的文檔。而技術開發人員最反感的往往就是那些管控文檔。業務視角文檔，因為是工作必需的，所以他們不會產生多大的抵觸情緒。

這兩種視角之間的矛盾也會體現在某個具體的文檔中，管控要求的文檔要面面俱到，業務的角度要求滿足業務要求即可。所以在公司中，大量的技術人員在填寫文檔的時候往往就會出現為了填寫文檔而到處復制。或者把原來的文檔進行修改交付了事。

知道了這兩種視角的差別，也就深刻地理解了在實施這種自適應開發方法過程中，不同的人所持的心理。

管理者們總有管控的需求，因此永遠希望過程可視化。技術開發人員則更希望拋棄這些影響，只做和業務直接相關的文檔編寫。以下的幾個心理學技巧，可以根據情況參考使用。

（1）在實施的時候，為了避免一味地關注小塊功能的開發而失去了整體的協調，可以在開發空間懸掛一個整個模塊的邏輯圖形，把不同模塊按照完成程度畫上不同的顏色。

（2）團隊中完全可以照搬團隊軟件開發過程（TSP）方法，建立公共角色，鼓勵共享，形成“人人為我，我為人人”的文化氛圍。要注意這種文化氛圍的建立關鍵點在于第一步，就是如何讓每個人感覺到他收到了其他人的幫助。這一步需要管理者人為的設計。

（3）和語言口號相比，圖形更有說服力。如果你想讓項目小組成員更關注用戶的需求和體驗。你可以借鑒用戶中心設計（UCD）的一些方法。

2.虛擬用戶的方法

這種方法要求你在項目需求采集的時候，和自己的團隊為自己項目的最終用戶虛擬未來的用戶人物。

人物要有足夠的代表性，可以是現實人物的翻版，也可以是幾個人物性格的綜合。

為這個人物取一個名字，注明年齡、性別和職業等。為了讓人物更加真實，你可以編寫一段此任務的傳記。在網上搜索一個相關的頭像，建立人物的相關檔案。

下面是一個例子，你可以參考。

姓名：王志強

英文名字：David Wang

出生日期：1978年12月

座右銘：勤能補拙！

職務：信息中心主任

個人簡介：

王志強畢業于上海交通大學金融專業。參加工作后兢兢業業，從普通的技術人員干起一直到信息中心主任。負責了中心的幾個重大項目的實施。

王志強性格比較倔強，有的時候太過喜歡據理力爭，導致同事關系都不怎么好。他的口頭禪是：如果這樣可以的話，別人早這么干了！

上周王志強剛剛買了新房，搬家累壞了。導致最近的聊天話題總離不開他的房子。

王志強有個小女兒，今年四歲了。王太太是他的大學同學，在一家銀行工作，夫妻感情一直很好。

當然，你可以根據項目的實際情況，編寫你的虛擬人物檔案。這個人物一定不要照搬實際用戶的名字和真實信息，這樣會讓當事人在項目中十分不舒服。

編寫完個人檔案后，用一張大紙打印出來，懸掛在項目小組公共區域。大家在討論問題的時候，可以這樣直接用這個虛擬人物。可以想象一下這個人物會做出什么樣的反應。

這樣做的好處就是會讓開發人員把注意力轉移到關注用戶的需求本身。比用文字或者用一個類似于“用戶說好才是真的好”的口號效果要好得多。