如果有一種方法能使你的軟件缺陷率降低63%，核心缺陷率降低79%，整體投入減少62%，整個項目開發的時間縮短69%，你會采用這種新的軟件開發方法嗎？

　　在回答這個問題之前，你可能會問：是什么方法能達到這樣的效果？答案是：敏捷開發。你一定會開始質疑：這是真的嗎？或者你會說：我們也在用敏捷，但沒有以上提到的這么夸張。

　　以上提到的一些數據來自Forrester，一家善于用數字說話的咨詢公司。他們對多個采用敏捷開發的項目與傳統開發方式進行對比，得出以上數據。而這些項目來自敏捷剛剛開始起步的2002年。

　　不相信敏捷開發能夠大幅提高軟件生產效率的可能并沒接觸過敏捷方法；而懷疑以上數據的人可能已經在使用敏捷，但并沒有獲得讓人驚喜的提升。《敏捷宣言》雖然已經走過十年，但在國內，因為技術理念和文化的差異，敏捷開發要發揮出全部威力還有很長的一段路要走。

　　我們在51CTO開發頻道用戶群做過一個小范圍的調查，結果顯示，有近三成的開發者表示自己和所屬團隊正在使用敏捷開發，有七成的網友表示并沒有深入了解過敏捷開發。值得注意的是，在使用敏捷開發的團隊中有不少人感覺自己在“偽敏捷”：標榜使用敏捷開發的方式進行軟件開發，但團隊內部依然遵循著傳統的開發方式進行項目開發。

　　“偽敏捷”——起步就走歪了

　　任何新事物的深入與發展都需要一個過程，這個過程產生中，推行此項事物的出發點可能是影響新事物發展的重要因素。當51CTO記者將上述調查轉述給ThoughtWorks CEO郭曉先生時他認為：實際上偽敏捷首先有一個目的，為什么要偽敏捷，誰需要讓他做敏捷。

　　目前，國內中小型軟件企業在實施敏捷開發過程中，往往是迫于壓力。兩種常見的情況是迫于客戶的壓力和迫于上級領導的壓力。

　　比如一些軟件企業可能被客戶要求使用敏捷開發，更緊密的聯系需求，更快的迭代交付。這時候只好打敏捷開發的牌子，實際上開發過程中卻很少能正確的理解敏捷開發的思想，僅僅是簡單的照搬一些工具來進行項目。

　　第二種可能是軟件企業的高層看到了敏捷的好處，也能理解敏捷開發所能帶來的價值，希望下面的開發團隊也能使用這種方法進行開發。但落實到具體的開發團隊中，卻因為各種原因沒有很好的執行下去，最終成了只是為了完成領導的任務而敏捷。

　　事實上，“偽敏捷”的產生最根本的原因是國內開發者還沒有徹底的理解敏捷，認識敏捷。敏捷開發是一種方法，更是一種思想；在實踐敏捷開發中，不但要求團隊自上而下的“形似”，還要求我們可以充分認識敏捷思想，做到“神似”。

　　要想做到“神似”，我們還有很長的路要走。任何東西都離不開實踐，要想很好的理解敏捷開發，也要從實踐開始。那么如何從一開始就不走歪路，如何正確的推行敏捷開發？

　　嘗試敏捷——從持續集成開始

　　ThoughtWorks CEO郭曉先生建議是可以從持續集成開始實踐敏捷。持續集成是敏捷開發中最常用、最普通的做法。它的價值在于在實施過程中可以會暴露出大量的問題，比如項目的架構問題、耦合度問題和團隊溝通的問題等。

　　持續集成理念很簡單，一個軟件不要等最后一天再上線，而是爭取團隊內部的項目啟動第一天就完成上線和集成；這時候會有很多問題暴露出來，等待團隊解決。當發現問題，我們就可以去尋找其他適合的敏捷方法進行解決，這樣可以更有效的更快的獲得敏捷開發的價值。

　　當然，持續集成不是解決問題的靈丹妙藥，但卻是暴露項目和團隊中問題的最佳手段，不同團隊在面對和實踐敏捷這么大的一個知識體系的時候有不同的方法獲取價值。不斷的獲取價值，會使團隊各個成員有更多的動力持續下去。

　　需要時間和實踐

　　作為一種開發方法，敏捷開發雖然已有十年的積累，但在國內仍然有很長的一段路要走。很多觀念需要接受，很多思想需要體會，很多方法需要實踐。

　　記得與敏捷開發專家麥天志先生談及敏捷開發的發展時他曾提到，一種開發方式的普及是一個積聚的過程，一個好的開發方式是經過不斷的實踐和驗證，并行之有效的。他認為，并不會有一個明顯的分界線標志出敏捷開發到了那種普及的程度和境界，至少在目前，敏捷還在不斷發展，更多的項目在實踐敏捷，觀念的普及和成功的案例正在不斷擴大。敏捷開發，在路上。