敏捷專案管理就是「應用精實管理原則，帶領敏捷開發團隊，駕馭充滿變數的專案」。
敏捷開發法是從軟體產業衍生出來的團隊工作方式，對敏捷專案管理的重要性不言可喻。
本文先就敏捷開發法的來龍去脈，做一番介紹：
厚重的計畫文件，推不動變動的產業
專案管理協會(Project Management Institute, PMI)出版的專案管理知識體系指南(PMBOK ®Guide)在全球流通超過450萬本，專案管理的相關知識，儼然成為當代顯學，不過，很多專案披著「正式」的管理外衣，卻仍在使用1970年代航太和營建業的做事方法，管理新產品開發團隊，試圖透過詳細的事前規劃，從需求、分析、設計、實作、測試到上線，一個階成接著一個階段，打造出「完美」的產品。很不幸地，這些專案通常從啟動日開始，先用超過一半的時間寫文件，剩下不到一半的時間才用來開發。本來以創意活力維生的開發團隊，被當成生產線的機台，不斷加班趕工，而照著白紙文件規格開發出來的成果，交付到客戶手上竟然發現...原來需求搞錯了方向。此時專案不管要不要繼續執行，逾期、超支的這筆帳，通常就算在開發團隊的頭上。
其實，除了航太和營建產業以外，大多數開發專案的本質就是變更，客戶在專案初期只能提出大概的想法，要看到團隊交付實際成果，客戶才會「有感覺」，才能進一步提出比較具體的需求，至於厚重的產品規畫文件，對新產品開發這種充滿變動的產品來說，不但浪費時間，而且根本派不上用場。
開發新產品就像橄欖球爭球，情勢隨時在變化
基於這個體認，日本學者竹內 弘高(Hirotaka Takeuchi)和野中 郁次郎(Ikujiro Nonaka)，早在1980年代就曾根據就近觀察產業的心得，在《哈佛商業評論》(Harvard Business Review)上發表專文指出，全球市場求新求變，競爭激烈，新產品開發帶來的營收，是很多大廠賴以為生的命脈，為了快速又有彈性地開發出新產品，很多大廠放棄部門對部門的接力開發方式，改用類似橄欖球賽(r
豐田業績長紅，精實生產獲得各界矚目
大約在同一個時期，以豐田(Toyata)為主的日本汽車，在美國攻城掠地，通用(GM)、福特(Ford)和克萊斯勒(Chrysler)這三巨頭(The Big Three)市占率節節敗退，就連美國政府強迫日本簽下「『自願性』貿易協議」(voluntary trade agreement, VTA)，限制日本對美國市場輸出的汽車數量，也無法扭轉美國汽車業的頹勢。對此，美國麻省理工學院(Massachusetts Institute of Technology, MIT)，耗費鉅資啟動研究計畫，思索全球汽車產業的未來，並希望瞭解豐田汽車當時攻無不克的原因，時至1990年，沃麥克(James P. Womack)等幾位學者把研究心得，寫成《改變世界的機器: 精實生產個故事》(The Machine that Changed the World: The Story of Lean Production)，這本書的副標寫著「豐田在全球汽車大戰的秘密武器，正在掀起世界產業革命」，這就是豐田的生產方式被稱為精實生產(Lean Production)的由來。
傳統無法解決問題，敏捷開發嶄露頭角
90年代資訊科技(Information Technology, IT)蓬勃發展，著重大量文件的傳統專案管理思維，已經和軟體開發的現實脫節。許多有志之士認為，IT業界需要的是輕量級的開發方法(lightweight methodology)，其中，當過飛官、醫官的軟體產業傳奇人物--Jeff Sutherland，受到「新新產品開發遊戲」這篇文章的啟發，在OOPSLA'95大會上，和 Ken Schwaber一同發表了軟體開發專案應用Scrum流程的概念，並在接續的幾年內，根據實務經驗，提出舉世聞名的Scrum Framework，這就是後來最多人應用的敏捷開發方法(Agile Development)。約莫在同一個時期，在IT業界推動軟體設計模式(Software Design Pattern)和測試驅動開發(Test-driven Development, TDD)而馳名的Kent Beck，帶領團隊開發克萊斯勒的C3工資系統(Chrysler Comprehensive Compensation Payroll Project)，Kent Beck彙整實戰心得，在1999年出版《極致軟體製程》(Extreme Programming Explained: Embrace Change)，提出簡稱為XP的開發方法，在當時被視為帶領小型開發團隊，面對需求模糊、變更頻繁專案時的一盞明燈，成為另一個知名的敏捷開發方法。2000年春天，Kent Beck邀請了一群業界先進，在美國奧瑞岡州(Oregon)聚會，討論軟體業應該有的輕量的開發方法，雖然沒有獲得什麼實質成果，倒是開出了第一槍。
2001敏捷開發大會師
到了2000年9月，軟體業名人Robert C. Martin，透過Email發出英雄帖，並設立網頁籌備下一次輕量開發陣營的聚會，當時的邀請文字寫說：「我打算在2001年1到2月間，在芝加哥市舉行一場小型會議(為期2天)。會議目的是讓主張輕量方法的各方領袖齊聚一堂，除了受邀的您以外，還希望您告訴我該和誰接觸。」後來這群受邀者幾經討論，決定在猶他州的斯諾柏德(Snowbird, Utah)這個度假勝地聚會，時間就訂在2001年的2月11到13日。聚會當天，來自XP、SCRUM、DSDM、Adaptive Software Development、Crystal、Feature-Driven Development和Pragmatic Programming這7大門派，一共17名大師齊聚一堂，在彼此競爭的軟體開發業界，算是空前的盛況。
會議的主題，是改善既有軟體開發太重視表面文件的笨重流程，希望找出各家能求同存異的看法，會議的成果，就是後來鼎鼎有名的「敏捷軟體開發宣言」(Manifesto for Agile Software Development)。根據Jim Highsmith的說法，兩天的聚會輕鬆愉快，在快要接近尾聲時，Bob Martin開玩笑，要大家留下幾句含糊的聲明(mushy statement)再解散，其他成員聽了之後反而覺得，難得有這麼多派的大師在場，既然大家都覺得傳統開發做法不可取，倒不如利用這次聚會，集思廣益想出一些鼓吹人本、信任、尊重和合作的觀念，敏捷軟體開發宣言，就是這樣產生的。至於為何取名叫敏捷(Agile)呢？據說，當年各派的大師們，雖然都對重量的開發流程覺得不滿意，但也不想把自己鼓吹的做事方法被叫做輕量開發法，幾經討論之後，大家聽取Martin Fowler的意見，才選用了敏捷這個字。至於宣言裡面短短的4句話，目前已經獲得各界認同，成為開發團隊在面臨變動專案時「動則得救」的心法：
價值驅動，滿足變更需求
敏捷軟體開發宣言問世後，引發了廣大迴響。《經濟學人》(The Economist)刊出「團隊精神：敏捷說了算」(Team Spirit: Agile Counts)專文，介紹敏捷開發法，這篇文章劈頭第一句就說：「開發軟體時，災難的常見原因之一，就是交付的產品和客戶當初訂的一模一樣」(A COMMON cause of disaster in software development is that the end product is precisely what the customer originally ordered)。咦，做出客戶期初想要的產品，有什麼不對？相信多數的軟體開發同業都同意，軟體開發專案中，客戶一開始只能講出大方向，大概的講法，不管期初的需求和規格文件怎麼寫，客戶要操作到真正交付的軟體，才會「比較有感覺」，才會進一步講出新的想法，如果開發團隊堅持完全照著期初的文件來做事，或是在客戶有新需求時，推說不在合約內，或是動輒祭出「變更管理委員會」(Change Control Board, CCB)來抗拒變更，就會和客戶實際需求漸行漸遠，到了期末交出來的成果，當然不會獲得客戶認同。這種必須與時俱進的「特色」，就叫做「價值驅動」(value-driven)，只要是需求變動快(volatile)、產品上市時程急迫(urgent)的產業，都有類似的情況，其中又以新產品開發的專案最為明顯。
