不久前我去了趟中國和澳大利亞，我發現大家都想變得“敏捷”。在這方面，也許北歐和美國稍微領先一點，但是它的趨勢已經遍佈全球、不可逆轉了。在
與CIO的圓桌會議上，我總是喜歡問問大家現在對什麼感興趣。五年前，很多人的回答是“我們在試着採納統一過程”。現在，針對同樣的問題，大家的回答變成
了“我們在向敏捷轉變”。藉此也許可以假定人們已經知道“敏捷”是什麼了。
上個月，我進行了4次演講，每次的聽衆大約有100-200人，接洽了大約12家公司。每次演講，我訊問聽衆在敏捷方面的新進展，而得到的迴應也大致是如下幾種：
快速迭代
能夠產生可用的軟件
應付變化
溝通
靈活性
適應性
消除浪費
小迭代
特性驅動
持續集成
測試驅動開發
零文檔
人優先於過程
適應變化
由團隊自主設置優先權
干係人儘早加入
絕大多數人——大約有60%——都認爲敏捷就是迭代（或是Scrum術語“sprint”）。這種情況有些令人失望，因爲他們並不知道：早在25年前，Barry Boehm就提出了迭代開發的概念，不過稱其爲螺旋式開發。
更
令人失望的是，人們並不知道Rational Unified Process
（RUP）其實不是迭代開發，而是基於瀑布式開發的模型。事實上，如果你真的要用RUP來進行瀑布式開發，那麼你還得在重組RUP上花些精力。我們明確認
爲：所有的開發者們都應該轉向迭代式開發，因爲它和人們喜歡的敏捷具有相同的特徵：快速、能夠產生可用的軟件、接受變化、靈活性、風險保障等等。
既然60%的人都認爲敏捷就是關於迭代開發，而且RUP的設計初衷就是用來支持迭代式開發的，那麼RUP就等同於敏捷嗎？我並不這麼認爲。RUP可以用敏捷的方式應用，但是它本身卻並不是敏捷。想變得敏捷，還需要更多的東西。
20%的答案與技術相關，包括特徵驅動、測試驅動、用戶故事等等。然而，這些理念不能單靠自己就引發開發的革新。
而與“輕量級”相關的答案佔了10%：易於理解、易於應用、易於生成文檔。現在我們算是要涉及到敏捷的核心內容了。我確信過去我們曾對描述過程、採納大量過程和文檔有着過分的期望。
然而事與願違，事實是即使有人寫了很多東西，也不會有多少人看。因此保持輕量級的趨勢會一直持續下去。不過，要變得“輕量級”很容易。關鍵是不要變得過分“輕量級”。在這方面，我相信你會發現我們在EssUP和EssWork上的工作非常地新穎。
最
後10%就是關於如果保證開發人員每日、每週、每月甚至更長時間地緊密工作。這關係到溝通、人和團隊，關係到如何組織團隊、如何決策、如何保護團隊不被外
界環境干擾。這些學問被我們稱爲社會工程學。敏捷早就指出，想在軟件開發上有所成就，團隊中就需要有活躍的成員和能勝任工作的員工。沒有哪個流程能夠把軟
件開發出來，工作總是要由人來做的。一直以來我們都清楚這一點，但是卻沒有把它放在心上。關注人，是敏捷獨一無二的特質，也是敏捷當初得以成功的原因。
其實，人們如何看待敏捷並不重要。它甚至已經成爲了一種哲學體系。現在看來，所有好的東西都被稱爲敏捷，因此想要說清楚敏捷是什麼並不容易。不過，人人都想變敏捷（其實人人都應該變敏捷），我們對此心知肚明。總有一天，敏捷之道將行於天下，不需贅言。
不如讓我來做個謹慎的預言吧。照現在這個趨勢，危險顯而易見：敏捷將會名聲掃地，因爲有人會用它作爲工作質量低下的藉口，有人會以敏捷之名不收集需求，有人會因爲要“敏捷”隨心所欲地開發。然而“真正的敏捷”的本質並不是這樣的，但是長此以往，敏捷也將背臭名遠場。
不管發生什麼，在將來的某一天，我們會融入一種新的潮流。我並不能明確地告訴你將會是什麼，但是有一點可以確信——它會很明智，非常明智。
本文轉自
http://sd.csdn.net/page/7457d292-1fa6-402f-9d68-e9ba7788f509