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