用了敏捷實踐就是敏捷專案嗎？

採用敏捷方法學的人正在逐漸增多，在最近的調查中顯示，XP，Scrum和FDD這些方法被廣泛使用，已經達到了前所未有的程度。但其中也有反面教材——如果開發團隊只是簡單的把敏捷實踐拷貝到專案中而不是在實踐中逐步掌握，隨便把在某處獲得成功的實踐經驗就拿過來用，卻不去思考如何進行持續性的改進來讓開發過程適應於自己獨有的環境，那又如何談得上敏捷？一個敏捷實踐者將其稱之為“垂死的千份拷貝（dying the death of a thousand copies）”。

不幸的是，隨著敏捷的進一步流行，這種“壞敏捷”就有可能成為一種副作用，有些人也會依據他們自己一些軟弱無力的例子總結出一套關於“敏捷軟體開發”的理論來。比如在最近的一篇名為Egomania Itself的文章中，Steve Yegge就把他上個月扔下的東西又撿了起來。他用了“敏捷教會”這個詞，並把敏捷實踐比作了迷信：

……有些人很可能想要用魔法來幫助專案取得進展，而且有很多專案——可能是大多數——都最後成功了。

我敢保證，你要是來跳舞祈雨，連著跳上七八十天，或者更久，大不了一直跳下去，那早晚也能求到雨的。

所以我不是說敏捷不行。它確實行！但它不過是純粹的迷信而已。

當然，敏捷可以用這種方式來實現，有的時候人們也確實就是這麼幹的。但這種“基於信仰”的對敏捷實踐的應用——我們相信它能工作，我們不需要知道為什麼——卻忽略了敏捷軟體開發中最強大的工具：現實。敏捷是採用基於經驗主義的過程來“擁抱變化”的。Jim Highsmith在Agile Project Management一書中描述道：“敏捷專案是探索式的專案，所以它們的成功都是建立在現實反饋的基礎上的。”敏捷的計劃-實施-檢查-調整的短週期也正是旨在增加對專案的理解，以便確保那種低效的過程不會被無限的重複下去。實際上，在特定的場景下，這個計劃-實施-檢查-調整的週期也會讓一個團隊清楚的看到，敏捷完全不是他們所需要的那樣子。

正如Yegge所說，即使是這樣的敏捷也可以工作——但是這條路上還是發生了許多故事：一些團隊不得不使用一些不需要或者是根本就不想使用的實踐，被固定的 日期、範圍和預算捆住手腳，甚至是那些剝奪了開發人員來之不易的工作空間而只是簡單地想用更少的投入得到更多的回報的那種領導也會從中作梗。在這種情況 下，就算能造出可以工作的軟體，同時也造出了一些滿懷憤懣的開發人員——有時候他們也就把自己給毀掉了。這根本無法和敏捷宣言的第一項價值"人重於過程"保持一致。

在Yegge的部落格上，大家根據敏捷實踐如何才能工作這個話題展開了熱烈的討論。下面是從上萬字的討論中擷取的一些片段——很不幸，大多數回帖的人都是匿名的，所以我們只好憑猜測來判斷是誰留的言。

Geoff——網名"gilligan"——對Yegge錯誤的推理提出了質疑，並寫道：

有這樣一種人，他們完全就是機會主義者，直接跳到敏捷的潮流中大喊“跳進來吧，這裡包治百病！”他們不理解什麼是開發，也不知道Beck，Cockburn，Jeffries，Fowler或是其他人為什麼推薦一些實踐，他們甚至都不知道實際的問題是什麼！我把這種人稱為Agilista。……

當我第一次聽說XP的時候，我進行了快速的學習，然後寫了篇文章，名為“XP eXposed”。我希望這篇文章能夠廣為人知，所以就像對家庭作業一樣認真對待。但是當我開始實踐XP以後，我才知道XP並不像我一開始所認為的那麼 蠢。最後我發現這裡有很多好東西值得我們學習（對菜鳥來講），或是回顧（對老手來講）。我無法完成那篇文章。為啥？因為我明白了把注意力放到一件事情的優 點上要比放到它的缺點上要好。

而jiblet回覆說 (僅摘錄部分內容):

這些方法學[敏捷及其他種種]是那些有經驗的開發人員在不斷調整他們自己的開發過程中總結出來的問題是：假如普通的開發人員不理解為什麼這些方法學會出現，那麼他們就無法從中得到什麼。反之，就是無理由的盲目順從……

Cory Foy 對這種“追根溯源”的做法表示了不滿, 他在自己的一篇部落格“原則，而非過程”裡也討論過這種思想：

我覺得你應該為XP給你帶來的感受而感到羞愧。儘管你的部落格寫的實在是具有娛樂效果。

因為在我的XP世界中，開發團隊所要牢記的最重要的一點就是，這是他們的過程，不是其他任何人的，他們要確保自己能夠理解實踐背後的原則，之後才能按需剪裁。這是他們自己的責任。

敏捷團隊確實應該把敏捷實踐和敏捷價值放到一起學習，從而把開發過程真正變成屬於自己的東西，進而日趨完善。敏捷宣言中包括4個價值和補充的12項原則。它們不是建議，它們定義了敏捷軟體開發，正如Java API定義了實現這些API的應用伺服器的行為一樣。方法學只是不同的實現和解釋而已，所以，隨著時間的推移，它會不斷髮展演化。

這四個價值是：

個體與互動勝過過程與工具
可工作的軟體勝過面面俱到的文件
客戶協作勝過合同談判
響應變化勝過遵循計劃 ¹

也許現在是時候來討論一下錯誤地傳授或實踐這些基礎知識是如何把團隊最重要的資產摧毀了的，這些資產包括誠實，創造力，團隊成員的守諾以及客戶的信任。團隊中用到了哪些核心實踐無關緊要，但是，只要他們的聲音被忽略了，那麼他們創造實際價值的能力就會受到打壓，也就談不上真正的敏捷了。

¹ 這是完整的敏捷宣言中有關敏捷價值的一部分，作者們把這些價值也放到了宣言中。它是一篇十分精簡的文件，如果你過去一直都沒有時間讀的話，現在就請點一下連結看看吧。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-567144/，如需轉載，請註明出處，否則將追究法律責任。