總聽到不少人提到敏捷，敏捷開發，敏捷開發相關工具。大家似乎很有興趣，但交談下來，能夠了解敏捷開發，清楚自己是否適合敏捷，怎麼入手開始做敏捷的人並不多。因為之前有過相關開發經歷，所以想聊聊我對敏捷的認識。
什麼是敏捷開發呢？
經常和開發人員提到敏捷開發，大家的第一反應是：就是快速交付嘛，提高開發效率。其實並不是。。。雖然成功的敏捷開發項目會有這個效果，但這並不是敏捷目的。從本質上講，敏捷開發和傳統瀑布開發是兩種不同的開發模式，敏捷並不是疊加在瀑布開發上的“加快開發的手段”。從概念上說，敏捷開發是以用戶的需求為核心，採用迭代、循序漸進的方法進行軟件開發的模式。將一個大項目分為多個產品特性，根據優先級分別實現，每個產品特性都是可見、可測試、可交付的。與瀑布開發相比，不需要等長時間的需求、分析、設計、開發、測試、交付的週期才能看到產品。而是一段時間一段時間就可以看到部分產品。而按照二八原則，前面20%的時間可以實現80%的主要功能，那麼從用戶的角度就可以在前期得到大部分的功能——這就是讓用戶感到“快速”的原因了。
概念上不太容易理解的話，我常用這個例子來解釋敏捷：修房子。傳統的建造方式肯定是：明確用戶想要什麼房子，根據用戶要求出架構圖，然後室內設計圖，然後招人建造，最後驗收。敏捷的方式就是：用戶要一個房子，想要客廳、臥室、餐廳、廚房、衛生間。那麼根據優先級，先造個臥室就可以睡覺了！所以第一個迭代就是造個臥室，相關的架構、設計、建造時間相比以前縮短到1/4. OK, 臥室好了可以交給用戶，用戶的第一大需求已滿足。然後第二優先級的是衛生間。接著第二個迭代修衛生間。第三個迭代修廚房（或者客廳，根據用戶要求），後面修餐廳…
萬一用戶要第二層，完了，前期沒考慮第二層的需求，當前房間不能支撐第二層——這就涉及到“重構”，敏捷開發的另一個常用實踐。
什麼樣的團隊適合採用敏捷開發？
理論上來說都可以，包括大型項目，多團隊協作項目，現在大規模敏捷都有不少的流程，比如SAFe，LeSS。各有利弊。但是敏捷團隊建議是6-9人的小團隊。建議需求變化較大，前期需求不太明確的開發項目使用。建議團隊有很強的自組織能力。個人覺得還是從小團隊開始“練手”吧。
做敏捷之前，需要什麼準備？
理解敏捷，選擇合適的項目來做嘗試。初步確定採用哪些敏捷實踐(best practise)，比如我曾經所在敏捷團隊採用的站會，看板，計劃會，回顧會，backlog tracking tool, 燃盡圖，持續集成（包括自動化冒煙測試）。。。更高階的團隊有自動化測試（特別是迴歸測試），流程中嵌入代碼走查（沒有走查的代碼不允許提交），使用開發管理集成工具。。。最好有專職敏捷教練。
敏捷開發需要什麼工具？
當前比較流行的代碼管理工具是Git，任務管理工具Jira，持續集成管理工具Jenkins（自動化平臺已使用），靜態代碼掃描（當前自動化代碼掃描使用fingbugs規則已經滿足需求），甚至還有基於UML的代碼生成工具。但並不是說有了工具就可以敏捷，沒有工具就不能敏捷。買個白板做看板，再結合Excel，就可以做項目管理。選擇合適的工具固然重要，更重要的是意識的轉變。
敏捷一定會提高交付效率嗎？
在初期不一定，說不定還更慢。搭建環境，適應新的流程，團隊需要磨合，但基於“回顧會”的有效性，會慢慢變好的。有效的“回顧會”，需要團隊成員積極貢獻自己的力量，把看到的問題暴露出來，使團隊成長成自組織能力強的團隊。每個人能夠把自己當作成就產品的重要一員，在開放平等的環境裡集思廣益，積極改進。如果完全聽PM的，或者完全看別人怎麼做，自己就怎麼做。這樣就很難找到適合自己團隊的方法。
閱讀更多 銀行小馬農的日常 的文章
