來源：Bill Liu
敏捷開發和敏捷測試這兩年自從從國外引進後，在國內很火，很多人都在談論。無論是專案延期，失敗，質量低下等等，你總能聽到分析的原因是：“看看，你沒有敏捷了吧”。所以一下子敏捷成了包治百病的靈丹妙藥。很多專案組公司開始學習敏捷，採用敏捷，轉向敏捷。但是遺憾的是很多人嘗試過後發現以前的問題並沒有被敏捷所解決掉，反而帶來了很多新的問題，於是也有人就得出結論：敏捷又是一個大忽悠。讀了很多網上關於敏捷的辯論，我想起一個故事：
話說清朝的時候慈禧太后聽說西方國家有個新的交通工具，汽車，它坐在舒服跑的很快。於是就叫人買了一輛回來。但是用的時候沒有人會開，於是不得不把汽車用幾根柱子綁起來做成了轎子，讓幾個人抬著。因為汽車太沉，幾個轎伕步履蹣跚，走不了幾步就得歇歇。結果以前半個時辰的路走了好幾個時辰。而且到了後因為門很窄，汽車做的轎子過不去，她也不得不老遠就下來自己走一段。慈禧太后很不高興就得出結論：
1、汽車前期投入大，維護成本高。
2、沒有轎子走的快。
3、很多地方汽車都不適用。
4、汽車是個大忽悠的東西，根本不管用。
那麼我們現在對敏捷的認識是不是和慈禧對汽車的認識類似呢？是因為我們不會用敏捷呢，還是因為敏捷就是個忽悠？
在國外通常一個概念出來之前已經有很多年的實踐積累，然後為了大家交流方便或者提高普及度給其一個名字。所以是先有實踐，再有概念。但是在國內正好相反，我們先把國外“先進“的概念引進來了而把產生概念的多年實踐忽略掉了。但是概念又太虛不能當飯吃，最終還是需要具體東西和具體做法。所以不得不根據概念來設計出各種各樣的做法來。這些做法聽起來不錯，非常符合概念，但是在專案中一使用就不靈了，舊的問題沒有解決，新的問題一大堆。最終得出汽車是個大忽悠的結論。
敏捷和雲端計算是兩個非常典型的例子。很多人為了敏捷，文件不要了，計劃不要了，測試用例也不要了，認為幾個人站在走廊裡溝通溝通就把一切都搞定了，因為敏捷了嘛。但是問題並沒有因為“敏捷“了而被解決掉，於是乎得出敏捷是個忽悠的結論。雲端計算也一樣，很多人認為雲端計算就是資料中心，所以大家大興土木建立資料中心。但是建完資料中心以後呢？沒啥用處呀。那大家都在吹捧雲端計算，不就是個大忽悠嗎。 殊不知，人家是因為業務需要很多年了已有資料中心，為了提高資料中心的使用率，開始對公眾開放資源，所以才有了雲端計算。
先有概念再造實踐的做法違背了事物發展規律，不僅解決不了現有問題，而且帶來新的問題。敏捷是個好東西，在特定情況下。我們需要搞明白的是它要解決什麼問題的？它是如何解決的。而不要在乎它叫什麼名字或則防止生搬硬套。還有越是先進的東西對人和基礎設施的要求越高。比如飛機再好，沒有飛行員或則沒有機場也沒有用。高鐵跑的越快對鐵道的要求越高。
軟體測試也是一樣，做質量控制不是為了趕時髦。如果你的專案只做3個月就徹底結束了，而且就3－5個人，不會有人離開也不會有人進來，也不需要和其它任何專案打交道，或則你的產品在早期實驗階段，你可以不要文件，不要計劃，不要記錄bug，完全靠口頭交流。否則的話：
1、不能沒有文件: 但是要減少不必要的文件，避免過於詳細的文件，使用易於更新和維護的動態文件。
1、不能沒有計劃: 距離現在越遠計劃越模糊，但是距離現在越近計劃越詳細。
1、不能沒有紀律:
與其在琢磨如何敏捷測試，不如一步一步把自動化做好，把持續整合做起來，建立更多的測試工具以提高測試效率，把質量反饋系統做起來，把dev提交程式碼前的質量檢查做起來，把在產品中測試做起來， 把測試工程師的素質提高上去，。。。。
等到這些都建立起來了後，你發現自己其實已經很敏捷了。