敏捷開發(fā)和敏捷測試這兩年自從從國外引進后，在國內很火，很多人都在談論。無論是項目延期，失敗，質量低下等等，你總能聽到分析的原因是：“看看，你沒有敏捷了吧”。所以一下子敏捷成了包治百病的靈丹妙藥。很多項目組公司開始學習敏捷，采用敏捷，轉向敏捷。但是遺憾的是很多人嘗試過后發(fā)現以前的問題并沒有被敏捷所解決掉，反而帶來了很多新的問題，于是也有人得出結論：敏捷又是一個大忽悠。讀了很多網上關于敏捷的辯論，我想起一個故事：

　　話說清朝的時候慈禧太后聽說西方有個新的交通工具，汽車，它坐在舒服跑的很快。于是叫人買了一輛回來。但是用的時候沒有人會開，于是不得不把汽車用幾根柱子綁起來做成了轎子，讓幾個人抬著。因為汽車太沉，幾個轎夫步履蹣跚，走不了幾步得歇歇。結果以前半個時辰的路走了好幾個時辰。而且到了后因為門很窄，汽車做的轎子過不去，她也不得不老遠下來自己走一段。慈禧太后很不高興得出結論：

　　1、汽車前期投入大，維護成本高。

　　2、沒有轎子走的快。

　　3、很多地方汽車都不適用。

　　4、汽車是個大忽悠的東西，根本不管用。

　　那么我們現在對敏捷的認識是不是和慈禧對汽車的認識類似呢？是因為我們不會用敏捷呢，還是因為敏捷是個忽悠？

　　在國外通常一個概念出來之前已經有很多年的實踐積累，然后為了大家交流方便或者提高普及度給其一個名字。所以是先有實踐，再有概念。但是在國內正好相反，我們先把國外“先進“的概念引進來了而把產生概念的多年實踐忽略掉了。但是概念又太虛不能當飯吃，終還是需要具體東西和具體做法。所以不得不根據概念來設計出各種各樣的做法來。這些做法聽起來不錯，非常符合概念，但是在項目中一使用不靈了，舊的問題沒有解決，新的問題一大堆。終得出汽車是個大忽悠的結論。

　　敏捷和云計算是兩個非常典型的例子。很多人為了敏捷，文檔不要了，計劃不要了，測試用例也不要了，認為幾個人站在走廊里溝通溝通把一切都搞定了，因為敏捷了嘛。但是問題并沒有因為“敏捷“了而被解決掉，于是乎得出敏捷是個忽悠的結論。云計算也一樣，很多人認為云計算是數據中心，所以大家大興土木建立數據中心。但是建完數據中心以后呢？沒啥用處呀。那大家都在吹捧云計算，不是個大忽悠嗎。 殊不知，人家是因為業(yè)務需要很多年了已有數據中心，為了提高數據中心的使用率，開始對公眾開放資源，所以才有了云計算。

　　先有概念再造實踐的做法違背了事物發(fā)展規(guī)律，不僅解決不了現有問題，而且?guī)硇碌膯栴}。敏捷是個好東西，在特定情況下。我們需要搞明白的是它要解決什么問題的？它是如何解決的。而不要在乎它叫什么名字或則防止生搬硬套。還有越是先進的東西對人和基礎設施的要求越高。比如飛機再好，沒有飛行員或則沒有機場也沒有用。高鐵跑的越快對鐵道的要求越高。

　　軟件測試也是一樣，做質量控制不是為了趕時髦。如果你的項目只做3個月徹底結束了，而且3－5個人，不會有人離開也不會有人進來，也不需要和其它任何項目打交道，或則你的產品在早期實驗階段，你可以不要文檔，不要計劃，不要記錄bug，完全靠口頭交流。否則的話：

　　● 不能沒有文檔：但是要減少不必要的文檔，避免過于詳細的文檔，使用易于更新和維護的動態(tài)文檔。

　　● 不能沒有計劃：距離現在越遠計劃越模糊，但是距離現在越近計劃越詳細。

　　● 不能沒有紀律

　　與其在琢磨如何敏捷測試，不如一步一步把自動化做好，把持續(xù)集成做起來，創(chuàng)建更多的測試工具以提高測試效率，把質量反饋系統(tǒng)做起來，把dev提交代碼前的質量檢查做起來，把在產品中測試做起來， 把測試工程師的素質提高上去。

　　等到這些都建立起來了后，你發(fā)現自己其實已經很敏捷了。