[Agile] 敏捷過程及實踐時，除了Scrum你還會融合哪些實踐、方法、框架？
心裡有敏捷，做起來就會敏捷
Agile 是一個廣泛的概念，根據這個概念，有非常多的方法論都可以跟敏捷沾得上邊。從上面這張圖可以看到在敏捷這把大傘下，各個方法論可以根據規則多寡一字排開，越下面的就越彈性、規則越少；越上面的規則越多。
換個面向來看，也可以將方法論分成比較輕量的框架以及比較複雜的框架（適用於複數團隊的敏捷方法）。
也由於敏捷是一個概念的特性，在實務運用上來說的組合當然也就相當多元。不會說敏捷一定要走 Scrum，不是 Scrum 就不是敏捷這樣狹隘的定義。
為了讓團隊更敏捷，以下將介紹過去曾經用過的方法，依序從個人 Level 介紹到企業 Level。
TDD/FDD/ATDD/BDD or XXDD
https://en.wikipedia.org/wiki/Test-driven_development
雖然我很少用 TDD 開發 XDD，但對於開發者個人來說，好的測試習慣絕對是讓個人更上一層樓的關鍵。有好的測試不但能在幫助開發者想清楚使用情境，也可以在幫助開發者更順暢的重構，也才有辦法嘗試各種的程式改善方式，可以說是個人開發者踏入敏捷的第一步。
極限編程 XP
極限編程以敏捷宣言基礎，加速了開發取得回饋的循環。其中一個比較廣為人知的概念就是 Pair Programming。在 Pair 的時候，工程師可以彼此即時的交流、討論、相互學習，不管是用來帶新人還是解決困難問題都滿有幫助，也可以省去後續 Code Review 互等的時間。
Kaban
看板是一個很輕量化將工作事項透明化的方法，運用的情境也很廣泛，最重要的觀念是 WIP 限制，可以推動大家把事情「完成」，減少「半成品」的狀態。而且對於團隊來說也是很容易接受不太會受反對的方法。
Scrum
Scrum 適合小團隊使用，有明確的角色分工以及固定的活動，透過這些活動來促進團隊合作以及進步。
LESS
當公司或產品規模越來越大，Scrum 就不見得適用，LESS 將一個大的產品團隊分為幾個獨立的小 Scrum 團隊來管理協作。像現在的公司同時進行數個專案，就滿適合使用 LESS 的方式來管理個別專案團隊的工作。
LEAN
在組織層級面或向上溝通時，很難套用什麼 Scrum 或 LESS 的方法。這時候還是需要回歸敏捷的初心，這時候 LEAN 的精神和概念就非常好用。像是
- 提高品質
- 加快流程速度，避免浪費
- 降低成本
- 改善資本投入，使股東價值實現最大化
- 提高顧客滿意度
這些都是公司管理階層注重的價值。也提醒我們除了在帶團隊外，也要隨時看看組織流程中有沒有可以優化改善的地方。
以上這就是這幾年來，要讓企業/團隊/個人敏捷起來，使用過的敏捷框架或概念。敏捷絕對不是一天兩天的事情，可能也沒有一個終點，每個概念還是需要花很多的時間跟心力才有辦法實踐和落地，在使用上也絕對沒有怎樣比較的方式，還是需要看狀況搭配使用。
