PMI-ACP Boot Camp

我看見大象在跳舞，政府也敏捷了！

徐柏峰

        如果你認為政府機關就像大象一樣，推不動求快求變的敏捷方法，哪你就錯了！美國和英國政府，在經歷許多失敗教訓之後，決定在資訊科技(Information Technology, IT)類專案，向業界學習最佳實務，用敏捷方法推行政府專案。

政府是大咖的發包業主

        政府的IT專案中，發包委外(Acquisition)是很常見的作法。根據美國白宮「行政管理和預算局」(Office of Management and Budget, OBM)的統計，美國政府光在2011年間，就花了76億美元IT相關專案上。這些政府外包專案，向來是套用瀑布式開發方式，預算龐大，執行工期也常，不過失敗的案例卻是時有所聞。

美國政府資訊專案，經常不能善終

        以美國政府專案來說，「紐約市政府自動化薪資系統」(The New York City Automated Payroll System, NYCAP )，在1999年啟動時預計投入6千6百萬美元，後來一直拖到2011年才結案，光是追加的預算，就超過3億6千萬美元，相當於原先規畫的5.5倍；紐約市政府另一項名為CityTime的薪資系統，原本打算投入5年6千3百萬美元，但實際上耗費了10年7億7千萬美元才收場；[1] 美國國稅局(Internal Revenue Service, IRS)在1994至2005年間，投入1億8千5百萬美元開發電子舞弊偵測系統，後來IRS因故決定棄用系統，反而在1年內造成高達8億美元的損失。[2]

英國政府資訊專案，失敗案例時有所聞

        再以英國政府為例，1992年10月26日，「倫敦救援服務電腦輔助派遣系統」(The London Ambulance Service Computed Aided Dispatch System, LASCAD)上線，原本預計針對每天平均2000~2500通的報案電話，提供自動派遣救護車的服務，不料，因為系統功能發生異常，某些民眾甚至在報案11個小時後才等到救護車，間接造成30人死亡，當時LAS的首長John Wilby因此引咎辭職，LASCAD系統因此遭到棄用。[3] 另外，英國政府原定投入187億美元，打造「全國衛生服務系統」 (National Health Service, NHS)，建立中央化的醫療資料庫，NHS系統開發到第9年，也因為成效不彰，在2011年宣布終止，已經投入的44億美元付諸流水。[4]

美國政府機關的敏捷案例越來越多，國會立法要求國防部也要跟進

大型政府專案失敗案例層出不窮，美國和英國政府不約而同地向業界學習，決定採用敏捷方法。在美國政府方面，白宮行政管理和預算局(Office of Management and Budget, OBM)，建議美國政府機關在推動資訊專案計畫時，應該使用敏捷方法，把資訊系統分割成模組化的小單位，循序漸進地交付。過去幾年以來，包括美國國家航空暨太空總署(National Aeronautics and Space Administration, NASA)、商務部(Department of Commerce)、退伍軍人事務部(Department of Veterans Affairs, VA)和國稅局(Internal Revenue Service, IRS)在內，都陸續傳出使用敏捷方法執行資訊專案計畫的案例。[5] 最具戲劇性的是，美國國會在《2010年國防授權法案》(The National Defense Authorization for Fisical Year 2010)，立法要求一向擁護瀑布式開發的美國國防部(Department of Defense, DoD)，未來辦理資訊委外( Acquisition of Information Technology)時，必須遵守4大原則，細看這4大原則，可以看到敏捷軟體開發宣言的影子：

• Early and continual involvement of the user

• Multiple, rapidly executed increments or releases of capability

• Early, successive prototyping to support an evolutionary approach

• A modular, open-systems approach

英國政府要求機關

        在英國方面，英國政府從2011年3月開始，要求機關要用敏捷方法辦理資通訊(Information and Communications Technology, ICT)專案，英國政府認為，軟體開發專案中，技術發展很快，需求輕重緩急變更非常頻繁，以往在初期鎖定需求的做法，把變更當例外的做法，有先天的重大缺陷。英國國家審計局(National Audit Office, NAO)建議，在資通訊類採購案，應該採用敏捷方法降低專案失敗的風險。英國內閣辦公室(Cabinet Office)早就在2011年間設定目標，要求政府機關在在2013年4月以前，把一半的ICT專案改成使用敏捷方法，並且希望在2014年以前，能把ICT計畫的平均交付時間縮短20%。[6]

---

[1] The Standish Group, ibid, p 4.有關NYCAP和CityTime案的報導，請參考http://www.nytimes.com/2011/11/01/nyregion/bloomberg-administration-admits-mishandling-citytime-and-nycaps-programs.html?_r=1&

[2] Robert D. Schneider, Tony Higgins and Keith Barrett, Requirements Definition & Management for Dummies(Mississauga: John Wiley & Sons Canada, Ltd, 2013), p.p. 24-25.

[3] 有關LASCAD系統失敗的分析，請參考ErichMusick網站，網址為http://erichmusick.com/writings/technology/1992-london-ambulance-cad-failure.html

[4] 有關NHS系統失敗案例的報導，請參考Neil Versel, U.K. Scrapping National Health IT Network. See http://www.informationweek.com/regulations/uk-scrapping-national-health-it-network/d/d-id/1099364?

[5] GAO, Software Development: Effective Practices and Federal Challenges in Applying Agile Methods, July 2013, pp. 29-30.

[6] NAO, Governance for Agile Delivery, P 7.

Build It with The Whole Team

Percy Pofeng Hsu

In my company, the diagrams below illustrate how "Business People" collaborate with Developers in every single Sprint.

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

徐柏峰

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

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

        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%，應該比較具備成功的條件吧！

用減法管需求才是王道

徐柏峰

軟體功能客戶使用率統計

資料來源：Chaos Manifesto 2013, p2.

很多學過專案管理的人，都看過Standish Group的報告，Standish Group在Chaos Manifesto 2013中指出，2004到2012年之間，軟體開發專案在結案時，平均只交付了64%~74%的功能。針對這種沒有「通通都要拿去做雞精」的專案，Chaos Manifesto的解讀非常有意思，報告中指出，團隊開發出來的軟體當中，只有2成功能是用戶經常用到，5成的功能是幾乎沒有或從來沒有用到，3成功能是偶爾或不常用到。不論功能後來有沒有用，團隊都要花時間做需求、分析、設計、開發這些動作，而每個動作都要花錢。不管是誰家的專案，如果問客戶，永遠會得到「通通都要，而且很急」的需求，問團隊，每次都得到時間和成本不夠的答案，與其自怨自艾，真的有意義的作法是，用減法管需求，先集中火力，開發對客戶最有價值的功能，這就是80/20法則的應用。

我再說一次！你嘛卡拜託，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/

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

政府機關敏捷案例：美國專利商標局PE2E專案

徐柏峰

美國專利商標局(The United States Patent and Trademark Office, USPTO)，負責全美專利和商標申請和核准手續，是隸屬於商務部(Department of Commerce)的重要機關。USPTO首長由美國總統任命，全銜為商務部次長暨專利商標局局長(Under Secretary of Commerce for Intellectual Property and Director of the United States Patent and Trademark Office)。[1] 在美國聯邦政府中，USPTO是排名第1的幸福機關(Best Places to Work in the Federal Government)，USPTO每年靠著規費，「營收」(Earned Revenue)表現非常可觀，而且一年比一年好，而收入當中超過9成，來自專利審查(Patent Examination)。[2]

USPTO歷年營收

金額單位：百萬美元

資料來源：USPTO, FY2013 Performance and Accountability Report, pp. 77.

1. 專案背景

        USPTO的專利審查程序，分為審查前(Pre-Examination)、審查(Examination)和審查後(Post-Examination)等3個階段，每階段內都有重要的流程：

 USPTO專利審查階段

資料來源：USPTO, Patent End-to-End Planning and Oversight Need to Be Strengthened to Reduce Development Risk, p. 1.

1.1 早期使用大量紙本

        從19世紀到20世紀初期的專利審查流程，使用大量的紙本文件。專利申請案從申請案分類(Classification of Claims)、先前技術搜尋(Prior Art Search)、審查(Examination)、初步審查意見(Drafting of Office Actions)、回應申請審查意見(Responding to Applicants‘ Replies to the Office Actions)，一直到核發證明(Issuance of a Paper Patent)，每個步驟使用的都是實體的紙本檔案，審查的動作慢，而且要花很多空間來存放紙張。[3]

1.2 80年代開始數位化

        隨著申請案越來越多，紙本審查的效能漸漸跟不上時代腳步。1981年間，美國的專利申請數為114,710件，而同年度的專利領證量為71,010件，由於審查流程必須大量調閱卷宗，翻閱紙張，審查官工作忙不過來，積案(Backlog)越來越多。^[4] 為了改善專利審查發證的效率，USPTO在1982年12月，向美國國會提出「無紙化辦公室」(Paperless Office)計畫，從那時候起，USPTO在將近30年內，陸續投入了超過10億美元，建立起將近50個相關的資訊系統，並把紙本的申請文件，陸續數位化成圖片檔案，讓相關同仁把原本要翻文件的動作，改成調閱圖片檔，來提升專利審查的工作效能。[5]

1.3 近年專利業務暴增

        最近幾年來，紙本文件確實數位化了，透過數位圖檔審查申請案的工作流程，卻和以前的紙本審查一樣，遇到效能瓶頸。時至2010年，USPTO建立的「專案檔案包裹」(Patent File Wrapper)系統，堪稱全球最大的專利資料庫，每年向USPTO申請專利的件數，超過50萬筆。不過，USPTO局裡6千多名審查官，在處理專利申請案件時，最多要從16個相關資訊系統，搜尋相關資料，然後再用手工剪貼文件，才能執行業務，而且有些資訊系統的效能不佳，找一筆專利申請資料要等上好幾分鐘，讓審查官想快也快不起來，而USPTO的積案數量，也逐步攀升到72萬件。

        根據USPTO自己的統計，從2006年到2010年間，雖然電子化申請的比率，從原本的14%，拉高到將近9成，但專利申請人平均要等上25.7個月，才能拿到首次通知(First Office Action)，而平均待審時間甚至將近3年。[6] 不僅如此，歷經30年陸續建立的相關系統，已經變成「歷史共業」，不論是系統維護、檔案備份，還是人員訓練，都是頭痛的問題。

USPTO 2010年專利審查概況

資料來源：USPTO, FY2010 Performance and Accountability Report

2. 導入過程

2.1 Patent File Wrapper遭到列管

        USPTO的窘境，受到白宮當局的關切。2010年，負責幫美國總統編制和審核預算OMB，把Patent File Wrapper系統列為聯邦高風險專案，要求USPTO限期提出解決措施，才能再拿到預算繼續進行系統開發。對此，USPTO幾經研商，終於在2010年第4季提出因應方案，打算建構一個新的資訊平台，取代既有的Patent File Wrapper，並把既有資訊系統主要功能都整合進來，讓審查專利在單一資訊系統裡面串起來，成為一貫化的流程。

2.2 提出PE2E平台解決效能瓶頸

        USPTO提出的新構想，叫做「專利端到端」(Patent-End-to-End, PE2E)平台。根據USPTO觀察，要改善既有資訊系統的效能，就要把原本透過圖片檔呈現的申請文件，改成使用「可擴充標記語言」(eXtensible Markup Language, XML)格式來記錄，建立起以文字為基礎的作業流程(Text-based Processing)，才能提升互動性(Interactive)，並進一步提升審查效率。為了達到這個目標，USPTO當局決定，導入敏捷開發方法中的Scrum來建立PE2E，幫USPTO改善審查專利的流程。

2.3 引入敏捷概念取代瀑布式規劃

        根據USPTO前局長David Kappos的回顧，USPTO資訊長John B. Owen從2010年5月起，就在局裡推動敏捷開發的想法，不但在內部針對資訊同仁和使用單位同仁，辦理敏捷的教育訓練，而且也招募了一些具備敏捷素養的計畫經理(Program Managers)。David Kappos表示，傳統上，USPTO 走的是瀑布式開發法，把系統切割成一個階段接著一個階段，專案交付時程都很長，同仁要等上好幾個月，甚至好幾年，才能收到「不見得符合需要的」新功能。相反地，敏捷不但強調快速交付，還要使用者從頭就參與，可以確保專案成功地做出使用者想要(Want)和需要(Need)的工具。[7]

2.4 PE2E的2階段開發策略

        針對PE2E系統，USPTO當局規劃投入1億3千萬美元，進行系統開發，並編列每年1千5百萬美元的維護費用，讓專案成果在2013年上線。由於系統架構非常龐大，相關技術十分複雜，USPTO決定向業界「借力」，把PE2E平台分為2階段開發：第1階段先發包一個雛型開發專案，同時委託3家廠商，各自針對UPSTO未來需要的資訊系統，先建立起核心基礎設施的原型(prototype)，讓參與PE2E的相關同仁「有感覺」。到了第2階段，再評選出1家系統整合商(System Integrator, SI)，根據第1階段的成果，透過敏捷方法，由優勝廠商「統包」，一個開發週期接著一個開發週期，「先求有，再求好」，逐步打造出PE2E需要的各個功能。

2.5 USPTO自己做系統整合

        2011年3月， PE2E第1階段的3家廠商進行成果發表，USPTO評估後發現，沒有一家廠商做出的雛形，符合USPTO的預期。USPTO毅然決定，在第2階段「自己動手做」，擔當整個PE2E平台的「統包」，主導架構設計和的系統整合。

        根據規劃，PE2E必須在2011年底前，釋出(Release)第1次的開發成果。為了達到這個時程目標，USPTO決定縮減範圍，打消原先要先開發核心架構(Core Architecture)的念頭，轉而先做專利審核流程中最明確的需求，讓審查官能先看到被分派到的申請案清單，以便根據審閱每個案件的主張，在申請案上加上註解。第1次釋出的範圍名稱，叫做「中央複審單元」(Central Reexamination Unit, CRU)，USPTO規劃投入80名真正的使用者，試行新的工作流程，如果系統功能成熟，再把功能開放給局裡6千多名審查官的使用。

        2011年4月，PE2E開始規畫使用介面，到了6月中，開始進行架構設計和開發，為了加速開發速度， USPTO 把第1次釋出的需求獨立整理成一個專案，發包給一家廠商開發，不過，後續的釋出要做些什麼，要怎麼發包，USPTO都沒有提出具體的作法。[8]

3. 執行成效

3.1 PE2E開發初期遭到批評

        PE2E專案內部怎麼使用敏捷開發，相關資料並不多見，不過，批評PE2E「不夠敏捷」的聲音，已經先傳開來。2011年9月，PE2E的第1次釋出進行到一半，美國商務部督察長辦公室(Office of Inspector General, OIG)，就對PE2E專案發出稽核報告指出，PE2E專案雖然導入敏捷方法，不過實際做法卻不符合敏捷的要求。針對OIG的評論，在USPTO主導推動敏捷的資訊長John B. Owen虛心受教，表明會逐一改善。[9]

OIG對PE2E的稽核結果

資料來源：USPTO, Patent End-to-End Planning and Oversight Need to Be Strengthened to Reduce Development Risk, pp. 4-7.

        截至2015年初為止，PE2E平台仍在開發中，導入敏捷的專案成效，目前還難有定論。不過，針對USPTO政策、目標、成效和規費等營運事務，負責向USPTO局長提出建言的「專利公眾諮詢委員會」(Patent Public Advisory Committee, PPAC)，從2010年起，不但每年都在年度報告上提到敏捷，也非常肯定USPTO引入敏捷的作法。[10] USPTO前局長David Kappos在官方的網誌上表示，敏捷和USPTO以往的瀑布式方法比起來，有3個根本上的差異：首先，敏捷擁抱變更，把變更視為常態。在敏捷團隊中，不但預期變更發生，而且還刻意規畫變更，並且根據商務的需要，及時改變計畫來因應；其次，敏捷透過1~3個月的衝刺期，把風險降到最低。在落實敏捷的環境中，團隊氣氛鼓勵盡早失敗，執行上發生的問題或是產品品質的缺失，會在衝刺期內就顯現，不用等到後面。最後，透過敏捷可以讓團隊一步一腳印地把高品質的成品做出來，並且根據使用者實際的需要來改善功能。David Kappos站在局長的高度呼籲，推動敏捷就要改變文化。專案團隊成員當中，一定要包括使用者這個角色，負責在開發期間，實際操作並測試系統功能。使用者提供的回饋意見，要能快速地整合到未來的開發週期當中，如此一來，在幾個月內就能看到改善的成果。[11]3.2 USPTO由上而下推動敏捷文化

3.3 PE2E1.0版預計2015年上線

        USPTO的2014-2018戰略計畫中，把持續開發PE2E列為重要的資訊科技目標。根據USPTO對美國國會提出的《2015年預算說明書》(Fiscal Year 2015 President’s Budget: The USPTO Congressional Budget Justification)，PE2E系統發展的進程如下：

PE2E系統主要進展和未來展望

資料來源：USPTO, Fiscal Year 2015 President’s Budget: The USPTO Congressional Budget Justification.

---

[1] 經濟部智慧財產局，《美國專利須知》，民國93年5月，第5頁。

[2] USPTO, FY2013 Performance and Accountability Report, p. ii.

[3] USPTO, PATENT PUBLIC ADVISORY COMMITTEE ANNUAL REPORT 2011, p 20.

[4] Hon. Gerald J. Mossinghoff and Stephen G. Kunin, “New Post Grant Administrative Trials Before the USPTO’s Patent Trial and Appeal Board.”

[5] USPTO, Patent End-to-End Planning and Oversight Need to Be Strengthened to Reduce Development Risk, p. 1.

[6] USPTO, FY2010 Performance and Accountability Report, p 12; 2013年度，USPTO的電子化申請比率已經突破98%，請見USPTO, FY2013 Performance and Accountability Report, p i.

[7]  David Kappos, “USPTO Gets Agile.” http://www.uspto.gov/blog/director/entry/uspto_gets_agile

[8] USPTO, Patent End-to-End Planning and Oversight Need to Be Strengthened to Reduce Development Risk, p. 2.

[9] USPTO, ibid, pp. 10-13.

[10] 《1999年美國發明人保護法案》，詳見USPTO官網http://www.uspto.gov/patents/law/aipa/

[11] David Kappos, “USPTO Gets Agile.” http://www.uspto.gov/blog/director/entry/uspto_gets_agile

Daily Stand-up 的起源

徐柏峰

圖片由美商 Digital River提供，為Daily Stand-up會議實況，Digital River為全球知名電子商務平台商，開發團隊使用敏捷方法，獲台北市政府選為2014年幸福企業

敏捷開發法的眾多門派中，最容易入門的一派，應該非Scrum莫屬了。根據Jeff Sutherland和Ken Schwaber的建議，Scrum Team中的全體開發人員(Development Team)，每天應該花最多15分鐘，在相同時間、相同地點(at the same time and place)，針對為了達成本期目標(Sprint Goal)「前一天完成的工作、今天預計的工作以及過程中遭遇的困難」這3個問題，輪流自問自答，讓整個團隊掌握專案最新進度，由於這是Scrum Team每日例會，因此叫做Daily Scrum，又因為會議過程儘量是站著開會，因此又稱為Daily Stand-up Meeting。時至今日，不管是不是Scrum Team，很多號稱導入敏捷開發的團隊，都有Daily Stand-up的實務，不過真的知道站立會議來由的人，卻不多見。

        全世界第一個Scrum Team

話說1993年，Jeff Sutherland在知名軟體公司Easel Corporation任職，「官拜」物件科技部副總(VP of Object Technology)，念醫科出身的Jeff Sutherland覺得，軟體業界盛行「先寫作文再寫程式」的瀑布式開發方式，非常沒有效率，因此他決定自己帶隊試行新的工作方法，全世界第一個Scrum Team就這樣成軍了。Jeff Sutherland認為，帶領宅男宅女工程師組成開發團隊，就像帶兵打仗一樣，如果團隊士氣高昂，戰鬥力自然就會顯現出來。於是，喜歡看橄欖球(Rugby)比賽的Jeff Sutherland靈機一動，安排在公司播放黑衫軍(All Blacks)的哈卡舞(Haka)影片，要求團隊成員要「學著點」。[1] 

本圖為紐西蘭國家隊2006年與法國隊對戰前的畫面，後來紐西蘭以23:11勝出；圖片來源wikipedia

看Haka戰舞激勵Scrum Team士氣

黑衫軍是紐西蘭國家橄欖球隊，在國際體壇上戰功彪炳，曾在4年1次的世界盃橄欖球賽，寫下2屆冠軍、1屆亞軍和2屆季軍的輝煌紀錄。每次出賽前，黑衫軍會先在場上一字排開，表演毛利族(Mori)傳統的哈卡戰舞來激勵團隊士氣。哈卡舞的動作、聲音和表情都很震撼，看過的人勢必血脈噴張，留下深刻印象。懂得「帶人要帶心」道理的Jeff Sutherland，在施展放影片奇招之後，接著上演感性的「開示」，果然把工程師情緒炒得火熱，原本「走鐘」的開發團隊，決定要放手一搏。

        Borland團隊每天溝通，發揮高產能

當時，立志要改變的Easel Corporation團隊聽說，總部位於美國加州的寶藍(Borland Software Corporation)公司，在Quattro Pro for Windows專案上，8名工程師只花了31個月，就寫出超過1百萬行的程式碼，這平均每周每人1千行的效能，無疑是地表上戰鬥力最強的團隊。[2] Easel Corporation團隊進一步觀察後發現，寶藍的「秘密醬汁」(secret sauce)非常簡單：就是天天召集團隊，討論手上的工作。原來，寶藍的團隊成員都在一個地方，成員之間透過每天固定會面，用自我管理的方式，解決眼下遭遇的問題，會議中，如果有同事遇到技術瓶頸，其他人就用三個臭皮匠勝過一個諸葛亮的心態，合力找到問題的解答。

     
        Easel Corporation團隊自訂每日會議規則

        研究過寶藍的開會方式之後，Jeff Sutherland和他的Easel Corporation團隊覺得方向是對了，不過問題是，寶藍團隊每天會議超過1個小時，每次有人提出技術細節，其他人就全部綁在同一場會議上，耽誤很多時間。對此，Jeff Sutherland一行人幾經思索，決定導入團隊每天交換意見的實務，不過為了讓會議更有效率，Easel Corporation團隊訂了3條家規：

1. 會議要每天舉行，全員都要出席，如果有人缺席，溝通就沒有到位。會議時間安排在幾點並不重要，重要的是定期的聚會，讓團隊有了「心跳」。.
2. 會議時間不能超過15分鐘，會議只講工作重點，如果有需要深入的議題，相關人等就約在會後詳談。
3. 這是大家都要積極參與的會議，過程中儘量站著溝通，一面拉近講者和聽者的距離，另一方面可以確保會議時間不會拖太久。

Daily Stand-up溝通效果十分明顯

就這樣，全世界第一個使用Scrum的團隊，開始每天花15分鐘站著開會，Daily Stand-up的實務，就這樣誕生了。至於Easel Corporation團隊在導入Daily Stand-up之後，效果怎麼樣呢？根據Jeff Sutherland的說法，當年專案開始找大家站個開會之後，原本規劃4周完成的工作量，竟然1個禮拜就全部搞定，連團隊成員自己都不敢相信，受到這個成功試行經驗的激勵，從此以後，Jeff Sutherland確認自己選對的方向(That’s when I knew I might be on to something)，接著在另外4家公司試行Scrum開發方法，累積了豐富的實務經驗，才和一同創始Scrum的好友Ken Schwaber，參與2001年的敏捷大會，偕同另外15位業界先進，簽署了舉世聞名的「敏捷軟體開發宣言」(Agile Software Development Manifesto)。[3]

---

[1] All Blacks隊一般翻譯為「全黑隊」，筆者認為，以「黑衫軍」稱呼較有氣勢。

[2] James O. Coplien, Borland Software Craftsmanship: A New Look at Process, Quality and Productivity, 原文請見https://sites.google.com/a/gertrudandcope.com/info/Publications/Patterns/Process/QPW

[3] Jeff Sutherland, The Origin of The Daily Stand-up, see https://www.linkedin.com/pulse/20140926150354-136414-the-origin-of-the-daily-stand-up