敏捷專案管理就是「應用精實管理原則，帶領敏捷開發團隊，駕馭充滿變數的專案」。敏捷開發法是從軟體產業衍生出來的團隊工作方式，對敏捷專案管理的重要性不言可喻。本文先就敏捷開發法的來龍去脈，做一番介紹：
厚重的計畫文件，推不動變動的產業
專案管理協會(Project
Management Institute, PMI)出版的專案管理知識體系指南(PMBOK ®Guide)在全球流通超過450萬本，專案管理的相關知識，儼然成為當代顯學，不過，很多專案披著「正式」的管理外衣，卻仍在使用1970年代航太和營建業的做事方法，管理新產品開發團隊，試圖透過詳細的事前規劃，從需求、分析、設計、實作、測試到上線，一個階成接著一個階段，打造出「完美」的產品。很不幸地，這些專案通常從啟動日開始，先用超過一半的時間寫文件，剩下不到一半的時間才用來開發。本來以創意活力維生的開發團隊，被當成生產線的機台，不斷加班趕工，而照著白紙文件規格開發出來的成果，交付到客戶手上竟然發現...原來需求搞錯了方向。此時專案不管要不要繼續執行，逾期、超支的這筆帳，通常就算在開發團隊的頭上。
其實，除了航太和營建產業以外，大多數開發專案的本質就是變更，客戶在專案初期只能提出大概的想法，要看到團隊交付實際成果，客戶才會「有感覺」，才能進一步提出比較具體的需求，至於厚重的產品規畫文件，對新產品開發這種充滿變動的產品來說，不但浪費時間，而且根本派不上用場。
開發新產品就像橄欖球爭球，情勢隨時在變化
基於這個體認，日本學者竹內 弘高(Hirotaka
Takeuchi)和野中 郁次郎(Ikujiro Nonaka)，早在1980年代就曾根據就近觀察產業的心得，在《哈佛商業評論》(Harvard Business Review)上發表專文指出，全球市場求新求變，競爭激烈，新產品開發帶來的營收，是很多大廠賴以為生的命脈，為了快速又有彈性地開發出新產品，很多大廠放棄部門對部門的接力開發方式，改用類似橄欖球賽(rugby)的組隊方法，從各部門挑選出代表性的成員，組成跨職能(cross-functional)團隊，專責在短時間內，開發出公司的明星產品。當年，竹內
弘高和野中
郁次郎把這種團隊開發方式，比喻為橄欖球賽裡面的正集團(Scrum)鬥牛，並以「新新產品開發遊戲」(The New New Product
Development Game)來描述這個管理專案的方法。[1]
豐田業績長紅，精實生產獲得各界矚目
大約在同一個時期，以豐田(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)的由來。[2]
傳統無法解決問題，敏捷開發嶄露頭角
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)的產業，都有類似的情況，其中又以新產品開發的專案最為明顯。
敏捷開發席捲全球，企業和政府全買單
從2001年起，敏捷軟體開發宣言的心法，很快就獲得全球主流軟體公司青睞，成為帶領開發團隊的事實標準(de facto standard )，而敏捷開發法用來規劃產品、開會、分工和共享資訊的做法，已經成為舉世公認的最佳實務(Best Practices)。影響所及，國外就連政府機關也開始轉向，英國和美國政府不約而同地從2011年開始，把敏捷方法視為推動資通訊專案的當然作法。其中，英國政府在內閣辦公室(Cabinet Office)下，成立了「政府數位服務團」(Government Digital Service, GDS)，組成超過500人的團隊，協助政府以民眾需要為出發點，進行改造；至於美國政府，則是在總務署(General Services Administration, GSA)成立一個超過100人的團隊，幫政府資訊專案進行敏捷轉型。
日前，知名敏捷開發工具供應商VERSIONONE，針對全球軟體產業導入敏捷開發(Agile Development)的情況，發表了年度敏捷現況調查報告 (8th Annual State of Agile Survey)，當中針對已經導入敏捷開發的團隊進行調查，詢問敏捷開發對實際專案有什麼幫助，報告中顯示的前5大好處是：管理變更優先順序、增加產能、提升專案能見度、改善團隊士氣，以及提升軟體品質。不過，報告中也提到，如果要在整個公司推廣敏捷，最大的成功要素是要獲得高層的支持，其次是要經過訓練的課程，再其次才是團隊使用共同的工具。由此看來，要在團隊推動敏捷開發，一定要有由上而下的支持，才能真的動起來。
相關文章：靠北不是敏捷開發，不寫文件也不是、
日前，知名敏捷開發工具供應商VERSIONONE，針對全球軟體產業導入敏捷開發(Agile Development)的情況，發表了年度敏捷現況調查報告 (8th Annual State of Agile Survey)，當中針對已經導入敏捷開發的團隊進行調查，詢問敏捷開發對實際專案有什麼幫助，報告中顯示的前5大好處是：管理變更優先順序、增加產能、提升專案能見度、改善團隊士氣，以及提升軟體品質。不過，報告中也提到，如果要在整個公司推廣敏捷，最大的成功要素是要獲得高層的支持，其次是要經過訓練的課程，再其次才是團隊使用共同的工具。由此看來，要在團隊推動敏捷開發，一定要有由上而下的支持，才能真的動起來。
相關文章：靠北不是敏捷開發，不寫文件也不是、
(本文作者為台灣敏捷專家協會理事長)
沒有留言:
張貼留言