敏捷改進應該問題驅動

敏捷改進應該問題驅動（Problem Driven）。如果組織或團隊中不存在需要改進的問題，那麼就沒有必要敏捷。

在正式啟動敏捷改進之前，應該先問一問我們為什麼要敏捷？敏捷能解決我們公司、我們團隊現有的哪些問題，給我們帶來哪些潛在的價值、額外的收益？敏捷改進成功的一個重要前提是首先對自己團隊、公司/企業/組織的現狀和存在的問題有一個清晰和清醒的認識。不管 CMMI 過程改進，還是敏捷過程改進，這第一步的現狀評估都是非常重要的。

有網友說，我們兩年之前就對敏捷很感興趣，早就躍躍欲試想敏捷了，可是到現在還是老樣子，公司領導也不大感冒，因此一點進展也沒有。應該逆向思考。如果兩年都過去了，你們公司採用傳統的做法都還運作得好好的，那為什麼要敏捷呢？這正說明你們公司可能不需要敏捷。不要為了敏捷而敏捷。不要因為外面流行敏捷，媒體和 marketing 都在宣傳敏捷，敏捷看起來很時尚，很時髦，很 cool，就盲目地嘗試敏捷，何必勞民傷財呢？還是採取保守療法好。

通常在緊迫性越大，大家一致希望改變的動力越大的情況下，敏捷改進的效果越好。

有網友說，既然有統計表明 Scrum 是目前最流行的敏捷方法，那我們就試試 Scrum 吧。

且慢，敏捷不是某一種具體的方法，敏捷不是 Scrum，也不是 XP，因為除了 Scrum 和 XP，還有 AgileUP、FDD、Crystal、太極敏捷（Taiji）等等方法。敏捷是一套價值觀和原則，至少也是一個集合的概念。究竟哪一種敏捷方法適合你，需要進行認真的調查、研究和分析。別人的敏捷不是你的敏捷，別人的成功也不是你的成功。所以，不要先入為主地認為，要敏捷，就一定要 Scrum，或者一定要 XP。

經典的 Scrum 在某種意義上是對傳統專案管理的顛覆，Scrum 過程大膽地取消了專案經理這個角色，專案管理的工作由產品負責人、ScrumMaster 和自組織的開發團隊共同來完成，這勢必要求企業對原有的管理文化、開發文化包括考核文化作出調整，估計光這一點就會把很多人嚇跑。

在嘗試 Scrum 之前，應該先作一下評估，問這樣一些問題：我們企業現在存在哪些問題，Scrum 能否解決這些問題；Scrum 是否與我們公司的管理制度和企業文化相匹配，如果不匹配，需要我們作出多大程度的改變，能否承受？如果 Scrum 不是適合我們企業的最佳敏捷方法，那麼是否可以採用其他的或者混合的敏捷方法？單個方法不行，複方的行不行？西式的做法不行，中式的行不行？...

在明確了企業存在的問題和改進目標，並大致挑選出可以實現這一改進目標的敏捷方法集之後，才是挑選何種工具的問題。即便是同一種、同一類敏捷方法，比如 Scrum、XP 或 Scrum + XP，也都有很多種來自多個廠家的敏捷管理和開發工具可供挑選。

如果經過仔細的評估和分析，發現 Scrum 和/或 XP 確實有可能是適合我們企業的最佳方法，那麼此時再大膽推進也不遲。

以上是比較合理的問題驅動敏捷改進的思考邏輯和順序。如果顛倒順序，在沒有弄明白企業什麼要敏捷、什麼是敏捷的情況下，盲目地採用廠家優先、工具優先的做法，這種敏捷實施的失敗可能性是很高的。

掌握了正確的思路和方法，敏捷可以離你很近。