艾偉也談專案管理，敏捷開發，在路上

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

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

　　以上提到的一些資料來自Forrester，一家善於用數字說話的諮詢公司。他們對多個採用敏捷開發的專案與傳統開發方式進行對比，得出以上資料。而這些專案來自敏捷剛剛開始起步的2002年。

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

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

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

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

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

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

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

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

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

　　嘗試敏捷——從持續整合開始

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

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

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

　　需要時間和實踐

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

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