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