一個流行的概念，往往大部分人都不懂

對于敏捷的定義，維基百科上如下說也：

敏捷軟件開發（英語：Agile software development），又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對于“非敏捷”，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發過程中人的作用。

敏捷宣言如下：

個體和互動高于 流程和工具

工作的軟件高于 詳盡的文檔

客戶合作高于 合同談判

響應變化高于 遵循計劃

上面的定義和宣言，相比傳統的瀑布，核心思想是響應變化、小步構建、不斷驗證以快速尋求反饋，做出高價值產物。一切都是為了提高軟件的可視性，從而讓客戶能更早的審視產品價值，從而快速調整，所以我覺得尋求反饋是敏捷的核心思想。

我的敏捷之路

在沒有加入ThoughtWorks之前，我大概聽到過敏捷，但是當時覺的Pair很邪乎，老板怎么能讓兩個人干一份活呢。4年前，有幸加入ThoughtWorks，開始了對于敏捷的“守、破、離”。

守

剛加入公司，我還是一個開發，在北京的一個項目上，和團隊一起Iteration Plan Meeting、站會、Kick Off、Pair編碼、Sign Off、Showcase、Retrospective。

給我最深震撼的是Retrospective和Pair。在Retrospective過程中，團隊的所有人一起說團隊哪些做的好，哪些做的不好，哪些可以改善。對于做的不好的和待改善的點，通過大家一起討論從而產出若干Action，以便讓項目的各個方面都朝好的方面發展。

在Pair過程中，兩人一起澄清問題、思考解決方案、編碼，整個過程思維高度集中，且“三個豬皮將頂一個諸葛亮”，往往思路更廣，寫出來的代碼精致且bug少。

這個階段，我就是不斷的熟悉敏捷各種活動的套路，一招一式，此謂守。

破

在熟悉了各種敏捷活動之后，就開始思考這些活動到底為什么會給項目、團隊帶來好處，以及在具體實施的時候，有沒有可以改善的點。

比如Sign Off應該由誰drive，之前團隊是由QA，是不是讓開發drive更合適，能讓開發有更好的責任心呢？Retrospective是一定每個迭代完成才需要，是不是團隊覺得有問題的時候，就可以來一場呢？不是每個Story都要Pair，簡單的Story是不是可以不用呢？Code Review的標準和目的到底是什么？應該不止檢查語法、邏輯錯誤，更多的是交流設計和想法。估點為什么花那么長時間，結果估的還不準確？

除過反思每一個活動，有考慮他們背后到底是為了干什么？IPM，Kick Off都是為了讓團隊正確的理解業務，Sign Off，Showcase是為了讓團隊對產出的結果進行對齊，確保做的東西是正確的，客戶想要的。Pair是為了保證質量，同時共享知識。

這些活動背后的理念，了解到敏捷并不確保快速產出，敏捷用這么多實踐來確保工作方向的正確性和質量。

離

敏捷，以核心的理念為支柱，若干原則為指導，并用敏捷活動來實現，以期用正確的方式，做正確的事。

敏捷也是為了做出更好的產出為目標的，如果做的事情，需求變動不多，需要自上而下的方式，則也不要迷信敏捷。比如：火箭驅動系統用瀑布開發更加適合。

對于具體項目，用敏捷還是瀑布？若用敏捷的話，具體用哪些敏捷活動，具體怎么用？不要所有的活動都生搬硬套，要針對項目具體情況，人員情況，具體定制。還是那句老話，具體問題具體分析。

敏捷，就是擁抱變化，快速迭代，尋求反饋，且過程中不斷持續改進。