公司裡80後的同事和我聊天時戲稱，你們那個時代是20年一個代溝，我們現在4年就一個代溝了。這些年國內各方面的進步實在是在令人目不暇接，在硬體上很多已超過歐美了，在軟體和思想上則急起直追。在1978年之前非國營企業的工作是非法的，之後有了小私營企業，但僱用人員在8人以上則被認為是資本主義的剝削。（對於剝削的這個定義，你現在是否覺得不可思議？）根據全國工商聯主編的民營經濟藍皮書資料顯示，到了2010年，中國私營企業數量佔全國企業總數的比例將達到70%以上；全部民營經濟佔全國GDP比重將達到3/4左右。管理的思想更是產生了翻天覆地的變化，從中樞控制式到分散式，從教導式到啟發式。人心思潮會在各個看似不相關的層面都表現出來。軟體研發管理則屬於其中很小一部分，但也蘊含了很多文化的因素在裡面。我個人以為，在未來幾年中，敏捷方法將會超越其他幾類軟體研發方法而成為主流。以下我從四個方向來論證我的推測。 越來越講求價效比高的商業作風，務實成為主流 - 傳統的瀑布研發模式是基於一個理想的假設：需求不會經常變動。在二三十年前，由於硬體太貴，一般軟體的大小不及現今軟體的百分之一，軟體的需求較簡單，也不會經常變動，因此瀑布研發模式相當吻合。但現在，需求不會經常變更的軟體系統已越來越少了。當使用瀑布方法開發一個龐大複雜的軟體時，若因任何原因（如經費不足）沒法全部完成，則最終得到的結果可能是每個模組都不太完整或缺陷很多，沒法給顧客使用。這導致整個系統都可能被廢棄，人力及財力的損失都非常的大。但使用敏捷方法則不然。它在開始時並不需要完整的需求，它的每個迭代都是做最核心（或最常被使用的）的功能，在每個迭代完成時都產生一個可執行的版本。到最後，若因任何原因沒法全部完成，所得到的可執行的版本很可能還是個能讓大多數人使用的軟體，因為在大多時候人們使用的就是那幾個核心功能。投資軟體開發的風險很高，使用敏捷方法開發軟體，即便最後未取得百分之百的成功，總是能得點什麼，而不是全盤皆輸。 越來越普遍的自下而上的管理模式– 傳統的管理是自上而下的，或者說是中樞控制的。它主要強調的是，高層制定制度，底層照著制度操作。封建社會以及軍隊的管理就是典型的代表。中樞控制的系統是高效的，但她的中樞一旦出問題整個系統就全崩潰。大多數的電腦軟硬體系統都有個中樞，但全球網路已完全不是中樞控制的了。在一般的情況，自上而下的操作可以滿足例行的需求。但當需求複雜或特例發生時，問題就來了。詹·卡爾森在他所寫的《關鍵時刻》裡講道，北歐航空公司的服務人員照著制度操作，但這並無法讓客戶滿意，因為只要客戶的要求不是在例行的服務範圍內，服務人員便拒絕服務。自下而上的管理模式以達到客戶滿意為目的，授權給一線人員自主的能力，讓他們更有創意地去服務顧客，並將問題回饋給上層。詹·卡爾森在試用了這新模式後一年內就讓北歐航空公司轉虧為盈。同樣地，為讓員工人盡其才並提高其參與度，越來越多的現在企業已採取了這種管理模式。她們的管理人員更像是其下屬的意見收集者及工作協調者，而非發號司令者。敏捷團隊裡的Scrum Master做的就是意見收集及工作協調，這兩種管理者非常相近。為防有的團員的意見被別人左右，敏捷方法裡更提供了敏捷撲克，當在估算某個任務所需的工作天數時，每個組員都以敏捷撲克的數目來代表他的估算值。每個人想定個數目後，先將撲克蓋住，然後同時翻開。這種對個體意見的尊重，讓每個成員都覺得他非常重要的管理方式，不也是社會的一個趨勢嗎？ 越來越多的系統自序列（Sequential）轉為並行（Concurrent） - 當你去做全身身體檢查時，如果該單位規定你一定要做了第一項，才能做第二，然後第三等等，那你一定發現很多的檢查站排滿了人，而另外也有檢查站是沒有人的。倘如這次序可以打破，每個人可以隨意做他尚未做的檢查，那排長隊的現象就可以減少，並且所有服務及被服務的人的時間都可以省下來。在工程系統及軟體設計上，這種序列和並行的情況也常發生。一旦一個系統可以從序列轉為並行，它的效率馬上能提高几倍。在研發方法論上，瀑布模式是個典型的序列式，而敏捷則為並行。 急速擴張的個人表現能力和表現慾望–有了Web2.0之後，網路部落格成了網民表達自我思想的最佳途徑。二十年前當人們在唱KTV時，許多人是被逼上去唱的，並且唱得荒腔走板；而現在，麥霸出現了，而且年輕人模仿原唱逼真到令人咂舌的地步。敏捷方法讓每個團員都有很充分的表現的機會。不僅他們天天溝通，甚至，有的團隊還讓其團員從任務列表中自行選擇他認為合適的任務去做。但許多的中國軟體開發及測試人員都比較內向，這種表現的機會對他們來說未必是件樂事。“尊重權威”及跟風也是比較常見的。或許，由於這些原因，目前敏捷方法未能很快地在國內擴散開來。但我相信，隨著個人表現能力的增強，情況很快就會變。 為了證實這推測正確，我查證了美國知名研究機構Forrester Research在2009年對100位資深經理問卷調查所釋出的資料。該資料顯示，30%的被訪者說，他們主要的軟體開發模式是敏捷方法，38%說他們使用迭代（iterative）方法,另有32%使用瀑布式之類的序列（sequential）方法。相比之下，在2年前的問卷調查中發現僅有8~10%的被訪者說他們主要的軟體開發模式是敏捷方法。 敏捷團隊對個人的能力（如程式設計、測試及表達等）的要求相對都較高。許多人認為進入圈內的軟體團隊會很多，但失敗的也會很多。是的，我也相信如此，並且失敗的多半會調整並再嘗試。我相信使用敏捷方法的企業會不斷增加，其百分比在未來幾年將不斷地提高，並會超過50%。不論在美國還是中國，它都將成為主流。 作者為TechExcel中國區總經理 蔡培堃 本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/techexcel123/archive/2010/03/15/5380382.aspx