產品待辦列表及Sprint待辦列表
這20多個月時間裡，主要做一件事，就是實現從瀑布開發轉型為敏捷反覆運算開發。過程涉及需求管理、工程方法導入、過程自訂、團隊建設、過程改進等等。

轉型的效果以及團隊的真實感受是企業最看重的，重心也一直放在這。但現實總是殘酷的，即使企業有意導入敏捷，輔導計畫也完全公開透明，可依然要面對來自崇高的「集體主義者」，如：怎麼快速複製敏捷流程？怎麼快速培養多位敏捷教練？怎麼證明敏捷一定有效？單點專案的成功與組織的能力固化如何匹配上？什麼時候才能看到組織轉型的效果，可以給我個準確的時間點嗎？採用敏捷後，品質或效率可以提高多少倍？有沒有量化的經驗資料可以參考，諸如此類……等，特別是這些問題有些來自於你的直屬領導時，那種感覺是不好的，倒不全是因為信任或自尊心之類的緣故，而是因為品質體系的線性邏輯思維令人沮喪。

一、敏捷到底是什麼？
這一問題看似簡單，實則複雜。要一兩句話解釋清楚一個複雜方法論是非常困難的，特別現在有很多的「電梯一分鐘」等行銷手段，顯得企業高層越來越沒有耐性去聽這種複雜的理論。在資訊時代，不管是聽隔壁鄰居說，還是透過網路搜尋，客戶多多少少都有自己對敏捷的一點理解，甚至是解讀。要達成共識，需要從結果回推定義，因此我給敏捷下了一個定義：「敏捷開發，就是以價值驅動的方式來激發團隊，讓團隊在可預見的固定短週期內，持續、穩定的交付可工作的產品（軟體或硬體），並根據使用者的回饋及時改進調整。」

基於這個定義，再來理解大家現在耳熟能詳的幾個實踐，例如：反覆運算、持續集成、完整團隊、回顧會議、故事牆、自動化測試……等等，都是為了達到這一結果而「發明」或採納的具體實踐方式。「跑敏捷就一定要採納並實踐這些嗎？」當然不是，如果團隊已經具備以上定義所展現出來的產品能力特質，哪怕有些實踐名稱團隊壓根沒聽過，也可以說自己是敏捷的。那是否採納了已知的所有實踐，就一定能達到這個敏捷結果？顯然也不成立。

二、怎麼判斷現有的團隊條件，適不適合跑敏捷？
既然敏捷實踐與敏捷結果的關係是個非必要的條件，那證明兩者之間的邏輯落差因素是什麼？意識、能力、制度、組織結構、文化、還是其他不可見約束？

這個就是讓理性的管理者所顧慮的，也不敢貿然激進式引入敏捷的一個很重要原因。敏捷推行三步走戰略（專案級＞版本級＞產品級），已經讓業務主管們行成了一種邏輯認知，認真按照這個三步走戰略逐漸採納其匹配的IPD-CMM階段性實踐，是個比較保險穩妥的做法，並可最終帶來敏捷希望的「短平快好」結果。

所以，「現有團隊適不適合跑敏捷」這個問題的答案，外人是無法替你回答的。取決於你對敏捷理解到什麼程度。從結果定義理解，那最好不過的，以敏捷結果目標驅動，自然能悟道，欠缺的條件自然不再是主要矛盾。從務虛的意識形態理解（消除浪費、以人為本、持續改進）也行，只要認為團隊所作所為是符合這三點核心理念的，甚至是割裂的只遵守某一點（更重要的是團隊面臨衝突選擇的決策依據是否吻合），也可以認為自己是適合敏捷的，或說敏捷是沒有門檻的。而從務實的，可分解的實踐及理解敏捷，當然也可以，好則用，不好則廢，也沒什麼痛苦或困惑之感。

結語：該怎麼導入敏捷？
上述問題一、二都考慮清楚了？真的考慮清楚了？那這個問題其實也就明朗了，甚至可以說，你的團隊的敏捷結果其實一早就明朗了。假設 ，所有團隊的敏捷轉型能達到的最好成果，取決於專案最高權益人的認知與投入。這個假設，在我不斷地專案合作過程中得到驗證。合作之初，團隊未來能走多遠，專案結果好壞的判斷，能有個八九不離十。