自適應軟件模型——敏捷模型

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

　　這是PMBOK第五版最新引入來的一種模型，這是PMBOK把普遍流行的敏捷開發方法包含到體系中來了。

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

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

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

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

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

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

　　這兩種視角之間的矛盾也會體現在某個具體的文檔中，管控的要求文檔要面面俱到，業務的角度要求滿足業務要求即可。所以在公司中，大量的技術人員在填寫文檔的時候往往就會出現為了填寫文檔而到處拷貝?；蛘甙言瓉淼奈臋n進行修改交付了事。

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

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

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

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

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

原文轉自：http://blog.sina.com.cn/s/blog_43ec0f600101q4sq.html#bsh-24-248512253