Agile Framework

敏捷流言終結者

敏捷團隊不寫文件嗎? 敏捷專案可以隨時改需求嗎?
敏捷方法雖然很盛行，但外界誤解還是很多。
史上第一個 Scrum Master: John Scumniotales 參與製作了流言終結者，10個問題，10個答案，幫您快速破除迷思。

https://www.yumpu.com/en/document/view/28103508/john-scumniotales-paul-dupuy-jeff-mckenna-serena-tim-walker-al-

靠北不是敏捷開發，不寫文件也不是

Image Source: http://giphy.com/gifs/western-cowboy-henry-fonda-xulayf0YLcCwo

有一個問題，每次在推廣敏捷方法的場合幾乎都有人提出。被問了這們多年，我想乾脆在這裡說個清楚。

問題是：你們不做規劃，不寫文件，怎麼確保產品的品質？

我的回答是這樣...

靠北不是敏捷開發
客倌您誤會了，既不做規劃，也不寫文件的那群人，用的是散兵游勇的「靠北編程法」(Cowboy Programming)，而不是團隊合作的敏捷開發法(Agile Development)。通常，施展靠北法進行開發的團隊，要不是懶惰，就是沒有能力分析問題，要不就是自我感覺異常良好的『自認型天才工程師』，不論是哪一種，最近幾年隨著敏捷方法越來越流行，這群靠北大師經常在開會時隨便講一講畫一畫，就開始動工，號稱自己用的是『敏捷開發』，所以不進行設計，直到自己對客戶承諾「包在我身上」的專案後來真的「『包』在我身上」，他們就拿敏捷當藉口說：「台灣團隊不適合跑敏捷」，「客戶不懂，所以不適合使用敏捷開發」。也因為這樣，才會有人寫出「為什麼我不推薦敏捷開發《嫁給RD的UI Designer》」的文章，真的是對敏捷誤會大了！

客倌您聽好了，開心的敏捷環境是這樣運作的：

We Are All Developers的團隊文化
每3-9個人編成1個開發團隊，如果人數超過9人，就加開1隊，依此類推。
每隊的成員當中，不論個別專長是需求、分析、設計、實作、測試、作文、作畫、道歉(這個很重要)還是其他，對外一律稱為Developers，大家的專長加一加，要能夠因應產品開發過程中，各個環節的技術要求。

Three Amigos，決定產品品質

Image Source: http://giphy.com/gifs/sY1yvrxROgCM8

產品品質好不好，要看團隊裡的「3個好朋友」能否發出1+1+1>3的聲音，其中：

    第1個朋友的聲音，叫做Customer Voice
如果Customer Voice發揮作用，不論是透過文件，還是面對面溝通，團隊成員就都能說得出「客戶目前面臨的問題」(稱為「需要」(Needs))，以及「目前來說，適合用什麼方法來解決問題」(稱為「需求」(Requirements))。

    第2個朋友的聲音，叫做Worker Voice
如果Worker Voice發揮作用，有關工期估算，以及需求的執行方式，就會「由下而上」交給實際開發的人負責，而不會交由「官大學問大的河馬」決定。(HIPPO=Highest Paid Person's Opinion)

    第3個朋友的聲音，叫做Quality Voice
如果Quality Voice發揮作用，具備測試專長的同事，從專案啟動的第1天，就會是團隊編制內的專屬(Dedicated)成員，而不是開發階段結束後才接手的「外人」。在每個需求進入開發前，扮演QA角色的人，會事先開出相關測試案例，讓其他人有所依據，而在開發告一段落後，尤其是在Release前夕，如果大家都跑光，只留QA下來加班，就不能算是真正的We Are All Developers文化。

Document Late，撰寫又快又好又便宜的文件

Image Source: http://agilemodeling.com/essays/documentLate.htm

在文件方面，很多人對敏捷軟體開發宣言(Manifesto for Agile Software Development)斷章取義，以為"Working software over comprehensive documentation" 就代表敏捷團隊不寫文件。對此，我只能說：錯，錯，錯。敏捷團隊不但會寫文件，而且寫的是很精確的文件。以我自己曾經帶領或擔任Coach的團隊為例，我們認為文件的最大用處不是用來規劃(Planning)未來，而是用來記錄結果，因此在Product Planning、Release Planning、Iteration Planning和Daily Standup這些規劃的場合，我們把相關人員聚在一起，用面對面溝通的方式，利用大面積的白板、便條貼、照片和螢幕擷取畫面，紀錄和需求相關的所有細節。在Iteration期間，Three Amigos之間只要有任何疑慮，不論是需求不清、作法不明，還是遇到卡關(Block)，相關人等一律直接「踹共」，一邊塗鴉，一邊就當場把問題講開，而不必多花時間刻作文、發Mail或請聖旨。
由於每個Iteration的實際產出，不但要經過QA的驗證，還會直接給使用者測試，因此歷經幾個Iterations累積出來的開發成果，在Release前早就「準備好了」。我們知道高品質的產品，一定要搭配相關的文件，因此在實務上，我們有些團隊是在Release前預留Hardening Iteration，讓團隊成員寫文件，也有些團隊，是在確定Release「安全下莊」之後，讓成員在比較不緊張的情緒下，才開Iteration來補齊前一個Release的文件。
拿結果來寫文件，就像是把箭射出去才描靶，和以往「先寫作文再做事」的主流開發方法比起來，我們不論是需求、分析、設計、布署，還是使用者文件，都可以寫得又快、又好、又便宜，這個最佳實務，就叫做Document Late。

相關文章：敏捷開發(Agile Development)

秒懂 MoSCoW排序法，專案聚焦不再瞎忙

敏捷方法陣營中，DSDM Consortium提出的MoSCoW排序法，在「願望很多、時程很趕」的專案世界裡，是很實用的需求管理招式。

MoSCoW的作法就是在進行Iteration Planning(當期規劃)時，把需求分為4大類，其中：
1. Must Have(M): 對Iteration Goal來說，沒有交付就不能達標的事。
2. Should Have(S): 對Iteration Goal雖然重要，但目前仍有替代方案，就算沒有交付，也不影響達標的事。
3. Could Have(C): 與Iteration Goal沒有直接關係，如果交付可以加分，但就算忽略也不會影響達標的事。
4. Won't Have It Right Now(W): 和Iteration Goal完全沒有關係的事。

根據DSDM的建議，M、S、C類的需求，在規劃時應該各自配置60%、20%和20%的工時，在開發週期內，M類需求如果沒有做完，團隊就不做S類需求，S類需求沒做完，就不做C類需求，至於W類的需求，顧名思義就是要團隊敬而遠之，避免花時間在上面的事。

因此，如果用MoSCoW法管理需求，整個開發週期執行下來，就算預計的工時和實際工時有落差，也能確保「最重要的事獲得最早而且最多的資源」，這就是敏捷團隊「要事先行」(First Things First)的原理！

The Product Backlog Iceberg Revised

敏捷需求大師Mike Cohn，曾經用冰山(Iceberg)比喻專案的Product Backlog，很貼切地表達了專案的所有需求和需求之間，也有大小輕重緩急的概念。

從敏捷開發的實務來說：
1. 排進目前Iteration執行的需求，不但要控制在一期做得完的大小，而且要分解出相關的Tasks。
2. 預計下個Iteration執行的需求，需要經過Grooming(或稱Refinement)，確保大小適中，而且備妥Acceptance Criteria，達到Ready的狀態。所謂的Ready Story，就是團隊在進行Iteration Planning時，不用花10鐘就能把相關的Task分解出來的Story。
3. 團隊和Product Owner同意排進Release Backlog的需求，就是Committed的狀態，這些需求當中，有的比較粗略，還需要進一步分解優化。
4. 至於當前Release以外的需求，說得好聽叫做Defer Commitment，白話的意思就是「再說啦」。

Scrum全球應用調查報告，搶先看

號稱有40萬會員的Scrum Alliance®，日前公布了The 2015 State of Scrum Report，針對敏捷方法在全球業界的應用概況，提供了一些有趣的統計資訊。

第一、Scrum雖然是最多人用到的敏捷開發法，不過，超過半數的受訪者表示，自己公司的團隊是混搭各門各派的實務(例如在Scrum團隊中使用Kanban顯示進度，或是應用XP的Pair Programming、Test Driven Development)；聲稱自己團隊完全只用Scrum的，只有42%。

第二、使用Scrum可以改善開發團隊的工作和生活的品質，不過有趣的是，超過7成的人表示，在公司使用Scrum的團隊，和其他非Scrum的團隊之間，竟然存在著緊張的氣氛。

第三、把開發人力組成一個一個的小團隊，是主流的作法，團隊平均人數是7個人。

第四、採用短開發週期是普遍的現象，最多團隊選擇以2週為1個Sprint的長度。

第五、使用Scrum執行專案的成功率比較高，如果使用Scrum的專案是由PMO主導管理，成功率超過9成。

另外，超過95%的受訪者表示，體驗過Scrum的開發方式之後，未來還再進一步深入應用，如果這個調查屬實，Scrum應該是「黏著度」前無古人的團隊工作方式了。

本文所有資訊及圖片，取自The 2015 State of Scrum Report，該報告受訪對象超過4,400人，橫跨108個國家14個產業，如需進一步資訊，請自Scrum Alliance®官網下載全文。

敏捷團隊跑得快，上面坐個老太太

徐柏峰

使用敏捷方法可以提升團隊開發速度，這是千真萬確的事，不過，如果團隊接的是政府標案，就算提早開發出成品，也不見得可以提早驗收請款。

使用敏捷方法，可以縮短問世時間，提升開發效能

        VersionOne的年度敏捷調查報告指出，公司考慮導入敏捷方法的頭號理由，就是希望縮短「面市時間」(Time to Market, TTM)，也就是產品從概念產生到上市銷售之間的時間。對承接政府標案的廠商來說，TTM可以比喻成拿到標案到開發票請款之間的時間。想當然，TTM越短，對廠商越有價值。QSM Accociates曾經出具報告指出，使用敏捷方法的團隊，TTM可以提升50%、產能(Productivies)可以提升25%。[1] VersionOne對實際使用敏捷方法的團隊進行調查，結果發現，高達87%的團隊成員認為，開發的速度確實比以往還要快。[2] 撇開這些有商業色彩的報告不說，身為Scrum共同創始人的Jeff Sutherland在國際學術研討會上發文指出，Yahoo導入敏捷方法後，平均開發速度(Velocity)比以往的瀑布式方法增加了35%。由於使用敏捷方法提升後速度提升的案例實在太多，因此Jeff Sutherland訂出超高標準說，導入敏捷方法後效能要達到瀑布式方法的400%，才稱得上是真正的高產能(Hyperproductive State)。[3]

公部門的辦事心態，不見得適合敏捷

      敏捷團隊跑得快，這是親身經歷的事。筆者在2009年剛接觸敏捷方法的時候，在政府委外開發軟體的專案上，應用Iteration Planning、Iteration Review、Face to Face Communication和Working Software這些技巧，把原本7個月要結案的專案，提前在5個半月內就全部「打完收工」，而且從測試報告、使用手冊到結案報告也全都做完。筆者原本以為提早做完就可以請求驗收付款，結果就在請求驗收文送出之前，機關承辦人來電訓誡說，絕對不可以讓上面覺得進度超前，以後也絕對不要做這種「找麻煩的事」。承辦人的理由是，當初專案講好7個月做出來，如果提前就能完工，就表示專案「不應該花那麼多錢」，因此承辦人怕被指責說在圖利廠商。後來，專案從第5個半月起， 繼續演了5次的每周進度報告，會議上除了聊天打屁，就是刻意在會議紀錄上寫說哪份文件的格式不對，需要退回重改，一直到法定時間，專案才進入驗收請款程序。到了第2年，筆者接了其他政府機關的專案，同樣的戲碼依舊上演。原來，提早把事情做完，並不是每個組織都歡迎的事！冏

---

[1] Ned Kremic, Why is Agile Time to Market(TTM) delivery 50% faster? See http://www.deltamatrix.com/agile-time-to-market

[2] VersionOne, 8^th Annual State of Agile Servey, p. 9.

[3] S. Downey and J. Sutherland, Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft, IEEE HICSS 46th Hawaii International Conference on System Sciences, Maui, Hawaii, 2013

小確幸是專案勝出的秘密

徐柏峰

        從1985年開始，知名資訊顧問公司-The Standish Group，定期用批流年的方式，公布「全球」資訊類專案的成敗比率(Resolution)。不論是資訊還是專案管理背景的人，對The Standish Group的報告，應該都不陌生。

Project Resolution(2004~2012)

Source: Chaos Manifesto 2013

敏捷專案成功率是瀑布式專案的3倍

        The Standish Group在Chaos Manifesto 2011報告中說，敏捷是全球軟體開發專案的救星(The universal remedy for software development project failure)，專案使用敏捷方法，成功率會是傳統瀑布式方法的3倍。

Chaos Resolution by Style

Source: Chaos Manifesto 2011

小專案勝出機會比較大

        事隔兩年，Chaos Manifesto 2013稍稍「修正」了官方說法，改口說：專案成敗的重點，是「大處著眼、小處著手」(Think Big, Act Small)的能力，因為根據The Standish Group實證的結果，人事支出(Labor Content)在1百萬美元以下的專案，執行成功率是1千萬美元以上專案的7.6倍，失敗率是則是低於8分之1。報告中指出，以軟體開發這個領域來說，所有的大專案都能切成多個小專案，不過，切割不是把專案分階段交付這麼簡單，真正有用的切割，是把原本一大包的專案，根據商務價值來分成模組，分割成可以個別帶來小確幸的專案。

Project Resolution by Size

Source: Chaos Manifesto 2013

        在台灣和大陸，規模1百萬美元以下的專案超過70%，應該比較具備成功的條件吧！

我再說一次！你嘛卡拜託，ALM哪是敏捷？

徐柏峰

        日前針對廠商自行宣告「使用ALM工具= 敏捷2.0」的亂象，寫了一篇小抱怨。最近有前輩回應我說：「真的很懷疑你到底對人家的工具懂多少,就下此結論,雖然我也是敏捷的支持者,但實在很不能認同你」，對於前輩的指導，我真的很感謝，我以多年推動敏捷專案管理的的經驗，把我發文始末報告清楚一點。

敏捷方法來自開發實務
        如果我們跳過1970年代以年的軟工歷史不說，目前席捲全球的這一波敏捷風潮，起源1990年代。當時，數位化浪潮興起，美國的一群軟體先進，覺得當時大家理所當然「先寫作文再做事」的開發方式，在帶領團隊開發時就是「卡卡的」。當時的Kent Beck、Jeff Sutherland、Ken Schwaber、Martin Fowler、Jim Highsmith...等人，有的是天才型工程師，有的是公司VP級的主管，還有些已經是業界知名的顧問，這些來自實務界的大師們，在90年代各自用實際帶隊的經驗，歸納出務實的作法，各自創立了門派。

敏捷宣言和原則，是因應變更的心法
        這些共同反對「重量級」(Heavy Weight)開發方法的門派代表們，在2001年的敏捷大會上，是既合作又競爭的關係。合作的是，這些實務界的大師都同意，多數人參與的軟體開發專案，客戶變更非常頻繁，不能硬套從國防、營建和航太產業衍生出來的做事方法；競爭的是，這些大師都希望自己創立的門派，可以一統天下，成為軟體開發的新典範。後來的4句敏捷軟體開發宣言，以及12句敏捷原則，就是在這種競合的背景下誕生的「最大公因數」，因為這樣，敏捷宣言講的都是面對專案時，團隊成員(包括客戶在內)應該具備的心態，敏捷原則裡，則是刻意避開了任何一派的專有名詞，例如：與會各派都同意需求窗口很重要，應該要和團隊成員密切共事，不過在Scrum這派，需求提供者叫做Product Owner，在XP，則稱為Onsite Customer，為了不偏袒任一方，敏捷原則就說"Business people and developers must work
together daily throughout the project"。連用字遣詞都這麼注意了，敏捷宣言和原則裡面不推崇任何工具，是可想而知的事，敏捷宣言的第一句話說"Individuals and Interactions OVER Process and Tools"，就是這樣來的。

大廠不能管你怎麼想，卻能控制你拿什麼來想
        在軟體產業打滾了十幾年，發現業界有個奇特的現象：大廠或大組織為了營利，持續創新技術或話題，營造出「若不跟著上車，以後就完蛋」的氣氛，從幾年前的UML、SOA、CMMI、Cloud、Mobile、Big Data一直到穿戴式裝置，一直都是這樣。大咖透過工商服務型研討會和不斷"+1"的學者專家，持續施展洗腦神功，每一波行銷攻勢的終極目標就是政府，方式就是業把界堆積出來的資訊詞彙塞給政務官，「擘劃」出大型的「政策方針」，實作就是讓廠商「申請補助」，或在政府利潤豐厚的政府標案上，放進這些浮誇的詞彙。這當中最可憐的，就是當初懷抱理想投入產業的軟體工程師，一入行就發現，怎麼開發軟體和時尚業一樣，要不斷地學新花樣，可是人家時尚業可以搞復古，宅男宅女工程師卻不能拿阿爸留下的Fortran給客戶說這是時尚。

敏捷成為主流，軟體工具廠商把握商機
        每次技術改朝換代，開發相關工具就要跟著「升級」，創造更多的利潤。根據Ken Schwaber的說法，軟體生命週期管理(Application Life-cycle Manager )工具每年有50~70億美元的收益。大約從2011年開始，敏捷成功案例越來越多，Chaos Manifesto講出「使用敏捷流程的團隊，專案成功率是瀑布式流程團隊3倍」，就連一向擁抱「正式」專案管理流程的專案管理協會(Project Manage Institute, PMI)，也不惜推出容易對PMP打臉的PMI-ACP認證，來搶奪敏捷商機。看在軟體工具廠商的眼裡，敏捷當然是不能錯過的趨勢，因此，這幾年來，軟體工具廠商先是推出「支援敏捷方法」的開發工具，後來有的廠商，就把敏捷陣營裡面部分派別的實務包一包，再加上自己的獨規，做成從公司治理、開發、釋出到維護整個過程中，全部「照顧到」的大型工具。

ALM廠商大超過，敏捷大師頗有微詞
        工具功能越做越多是事實，但適不適合每個團隊使用，以及好不好用，是見仁見智的問題，不過，ALM廠商為了行銷噱頭，竟然在2013年的一場工商服務「研討會」上，在沒有邀請任何一為敏捷各派大師的情況下，自己「黃袍加身」，聲稱使用該廠商的工具，就是擁抱敏捷2.0。這廠商的說法，傳到Scrum共同創始人Ken Schwaber的耳裡，覺得非常不「蘇胡」，因此寫了一篇文章來指正，Ken Schwaber指出，2001年敏捷軟體宣言推廣的那些觀念(不是工具喔)，現在都還沒有實現，測試驅動開發(Test Driven Development, TDD)、接受測試驅動開發(Acceptance Test Driven Development, ATDD)或行為驅動開發(Behavior Driven Development)，實作的人都還很少，ALM廠商把仍是少數人用的實務當成敏捷2.0的口號在喊，就像「把馬車放到馬前面」(Putting the Cart Before the Horse)，是本末倒置的行為。

後記
        當初創始敏捷的這些大師，只用便條貼和白板搞定充滿變動的專案，感動了包括我在內的很多人。如果要問敏捷需要使用什麼工具，我覺得，唯一需要的是想要改變的心態，而不是任何廠商的工具產品。

不會敏捷？A咖公司止步

徐柏峰

Scrum創始人之一的Jeff Sutherland，日前透過LinkedIn的公開資料，針對一些全球性「A咖公司」(Leading Companies)的現職員工，統計有多少人在履歷表提到自己有敏捷經歷。全世界導入敏捷方法的公司，當然遠遠超過這些，不過從Jeff Sutherland提供的統計數字，我們可以發現，原來從2001年以來的這波敏捷風潮，已經明顯擴散到IT產業以外的產業了。如果您也想進A咖公司，快學敏捷吧！

Source: http://www.scruminc.com/company-agile/

相關文章：學會和敏捷交朋友，工作機會向你招手

Scrum的起源--The New New Product Development Game

徐柏峰

新產品開發的遊戲規則正在改變，很多公司已經發現，要在當今的競爭市場上出線，除了提供高品質、低成本和差異性這些「基本要求」，還要具備速度以及彈性…像橄欖球賽一般的途徑—以整隊為單位透過來回傳接，試著在場上攻城掠地—更適合當今的競爭性需求

這段文字摘自1986年1月份的《哈佛商業評論》(Harvard Business Review)的一篇專文，題目叫做「新新產品開發遊戲」(The New New Product Development Game)，這是當年全球製造業大廠運作的心得，也是後來軟體業敏捷開發Scrum方法的起源。

當時任教於日本一橋大學(Hitotsubashi University)的竹内弘高(Hirotaka Takeuchi)和野中郁次郎(Ikujiro Nonaka)兩位教授，走訪當時美日兩國製造業大廠後，發現在當時的環境下，製造業大廠每年收益中，越來越多的比重來自新開發的產品，為了在市場競爭中勝出，這些公司把傳統的瀑布式開發流程先放一邊，改用又快有彈性的方法發展新產品專案，竹内弘高和野中郁次郎借用英式橄欖球(Rugby)的術語，把這個現象比喻為「用正集團推進」(Moving the Scrum Down-field)，這是Scrum這個字第1次用來描述專案管理或產品開發。看過英式橄欖球的朋友應該知道，Scrum是比賽暫停或有一方輕微犯規後的爭球方式，雙方各派出8名球員，互搭肩膀組成4‧3‧1的3排人牆，等裁判下達指令後，雙方人牆頭肩相頂，由其中一方的球員找機會把球投入對峙人牆中，幫隊友爭取持球前進的機會。透過Scrum爭球時，場上情勢瞬息萬變，雙方隊員要隨時因應變更，才能掌握到優勢。或許也因為這樣，Jeff Sutherland和Ken Schwaber當年才會把體悟出來的軟體開發新方法，命名為Scrum Framework。

有趣的是，當年竹内弘高和野中郁次郎所說的「新新產品開發遊戲」，在製造業沒有激盪出什麼光與熱，兩位學者歸納出的6點新遊戲規則，後來在軟體業敏捷開發法興起之後，反而成為專案的共同特點了。

特點1，既有不穩定性(Built-in instability)

因為是開發全新的產品，管理高層也沒有經驗，因此只會指示大方向、大目標，就啟動開發專案。

特點2，自我管理的專案團隊(Self-organizing project teams)

因為是開發新產品，既有資訊非常少，公司派出跨部門菁英團隊，像他們像新創公司一樣運作，開發過程中公司打開荷包閉上嘴巴，讓團隊自我管理，自我超越。

特點3：開發階段重疊(Overlapping development phases)

新產品發展的各個階段，不再像過去一樣，要等上一個階段結束，才到下一個階段，從概念發想到生產之間，跨部門的團隊成員編在同一隊，把原本要一關過完才到下一關的開發流程，改成重疊的流程。流程中的每個階段，不同部門的成員投入專案的時間稍有不同。例如，研發的人幾乎從頭到尾都在專案內，但生產部門的人比較後期才會加入。

特點4，多重學習(Multilearning)

強調知識就是力量，不論是在個人、群體還是整個公司的層次，都鼓勵不斷吸收新知，累積本業和跨業的知識。

特點5，睿智控管(Subtle Control)

建立團體責任感，強調自我控制(self-control)，方法是同儕控制，以及透過團體關心力量。

特點6，組織化移轉學習成果(Organizational transfer of learning)

新產品開發交付後，把專案團隊成員獲得的新知識技能，轉移給公司其他同仁。例如，用滲透(osmosis)的方法，指派前一案的重要成員，接著參與後續的新案，或是把前案開發期間採用的實務，轉變成公司的標準做法。

相關文章：MetaScrum，跨部門溝通踹共

(作者為敏捷教練、全球首批敏捷專案管理師PMI-ACP®、台灣、中國兩地首位專案風險管理師PMI-RMP®)

敏捷開發(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敏捷開發大會師

到了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)的情況，發表了年度敏捷現況調查報告 (8^th 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