2014年3月18日 星期二

敏捷開發(Agile Development)

徐柏峰



        敏捷專案管理就是「應用精實管理原則,帶領敏捷開發團隊,駕馭充滿變數的專案」。敏捷開發法是從軟體產業衍生出來的團隊工作方式,對敏捷專案管理的重要性不言可喻。本文先就敏捷開發法的來龍去脈,做一番介紹:

        厚重的計畫文件,推不動變動的產業
專案管理協會(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敏捷開發大會師
到了20009月,軟體業名人Robert C. Martin,透過Email發出英雄帖,並設立網頁籌備下一次輕量開發陣營的聚會,當時的邀請文字寫說:「我打算在200112月間,在芝加哥市舉行一場小型會議(為期2)。會議目的是讓主張輕量方法的各方領袖齊聚一堂,除了受邀的您以外,還希望您告訴我該和誰接觸。」後來這群受邀者幾經討論,決定在猶他州的斯諾柏德(Snowbird, Utah)這個度假勝地聚會,時間就訂在2001年的21113日。聚會當天,來自XPSCRUMDSDMAdaptive Software DevelopmentCrystalFeature-Driven DevelopmentPragmatic Programming7大門派,一共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大好處是:管理變更優先順序、增加產能、提升專案能見度、改善團隊士氣,以及提升軟體品質。不過,報告中也提到,如果要在整個公司推廣敏捷,最大的成功要素是要獲得高層的支持,其次是要經過訓練的課程,再其次才是團隊使用共同的工具。由此看來,要在團隊推動敏捷開發,一定要有由上而下的支持,才能真的動起來。

相關文章:靠北不是敏捷開發,不寫文件也不是

(本文作者為台灣敏捷專家協會理事長)




[1] Takeuchi, Hirotaka, and Ikujiro Nonaka. "The New New Product Development Game." Harvard Business Review (January–February 1986)
[2] Matthias Holweg, The Genealogy of Lean Production, Journal of Operations Management 25 (2007) 420–437