打造人民有感的政府數位服務：英國案例分享

這是2015年發表的最後一篇研究專題了，雖然題目是打造政府數位服務，內容是真正的大型敏捷案例，想要把組織轉型敏捷的，想找敏捷專案驗收標準的，還是想為專案訂定「有感」KPI的，在這篇文章裏面都有線索。全文刊載在國家發展委員會《政府機關資訊通報》第338期，有需要的朋友直接去下載吧。

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

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)

The Agile Product Development Illustrated

秒懂 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，白話的意思就是「再說啦」。

善用Agile+UX，英國打造人民有感的數位政府

一句話一張圖 搞懂什麼是UX

UX Designer是敏捷產品開發專案中的重要角色，大力推動敏捷開發的美國政府，目前每個公家機關平均都投入2個專職人力外加2個兼職人力，執行UX相關的工作。
從敏捷的觀點來說，不論用了多少UX的招式，如果不是從解決使用者問題出發，一切都是白搭。

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®官網下載全文。

一眼看懂MVP、MMF和Product Backlog

學會和敏捷當朋友，工作機會向你招手

徐柏峰

        如果敏捷(Agile)定位為「具備快速因應變更，幫客戶解決問題的能力」，這個能力在當前的就業市場到底有多重要呢？全球最大的職缺搜尋引擎 Indeed.com ，給您直接了當的答案。

資料來源：Indeed.com

Agile職缺10年成長20倍

        從西元2006年1月起算，在短短10年間，與Agile有關的職缺數量，一路增加了20倍；同一個時期，又名瀑布式(Waterfall Model)的系統發展生命週期(System Development Life Cycle, SDLC)，相關職缺卻停滯不前。

資料來源：Indeed.com

PMP證照供過於求

        在專案管理的領域，最廣為人知的認證，就是被台灣補習班當成提款機的Project Management Profession Certification認證(簡稱PMP)，如果把PMP的職缺數量消長，和SDLC的職缺變化放在一起觀察，可以發現非常有趣的現象：PMP和SDLC的走勢幾乎是一模一樣。這意味著什麼呢？就業市場認為，PMP主張「先作文再做事」的種種流程，這是從營建、國防和航太產業(又稱為天龍國產業)衍生來的遊戲規則，這些規則相當於SDLC，也就是Waterfall。過去10年間，雖然假顧問公司之名的補習班，用輔考大隊當提款單、用考古題當提款卡，填鴨量產了很多PMP，不過，天龍國產業的職缺畢竟不多，證照供過於求的結果，就直接反映在薪資低落的現象上了。

PMI-ACP證照竄起，反映產業趨勢

        從2011年底開始，靠PMP證照每年營收超過60億台幣的專案管理協會(Project Management Institute, PMI)，順勢推出PMI Agile Certified Practitioner(簡稱PMI-ACP)認證，用來鑑別專案從業人員是否具備「因應變更，滿足客戶需求的『敏捷』能力」。只要透過 Indeed.com的數據，觀察PMI-ACP和PMP這2個關鍵字的職缺需求變化，就會知道那些假顧問公司之名的補習班，為什麼紛紛急著拿香跟拜，開班傳授自己也沒有的「敏捷專案管理」實務了。

資料來源：Indeed.com

        如果想找國內Agile相關的職缺，不妨到Indeed.com看看。


相關文章：不會敏捷？A咖公司止步

專案產業特性小調查

徐柏峰

        因為羨慕的關係，我把國防、航太和營建等產業，尊稱為天龍國產業，這些產業專案的共同特性是需求一開始就很明確，而且時程長、預算高，團隊人數又多，適合先寫作文，再開始做事的「正統」專案管理方法，需求變更對他們來說，相當於是修改合約，因此必須透過遊戲規則嚴格把關，避免變更頻繁發生。根據PMI的資料，在台灣參與天龍國產業的專案從業人員，大概是3.3%，這些令人羨慕的朋友們，工作環境比較接近PMP描述的那個理想世界。

        步入中年的我，現在轉行應該是來不及了，不過基於實事求是的精神，身為職業敏捷教練，我決定「利用職務之便」，針對接觸到的專案從業人員，開始進行近距離的調查。

        第1話，2015年2月間，滿腔熱血的台灣敏捷專家們，發起一場專案管理實務活動，共有27位從事專案相關工作的朋友前來共襄盛舉，這27人當中，有20個人持有PMP認證，13個人有PMI-ACP認證。我們在現場白板上拉出2 條線，構成4個象限，簡單透過2個問題，讓大家根據自問自答的結果，把自己的名字寫在卡片上，然後放在對應的象限。我們的2個問題是：

• 您從事的專案，客戶開始講不清楚需求，看到需求之後還會變來變去？如果是，請往右，如果不是，請往左。
• 您從事的專案， 結案時程在18個月以內(或金額在3,000萬台幣以內)？如果是，請往上，如果不是，請往下。

        經過簡短的3分鐘，台灣史上第一次的專案產業特性「小」調查結果出爐，統計結果和PMI的數字十分接近。參與活動的27個人當中，除了官拜副總的Jim哥以外，其餘的普羅大眾們，名字都集中在右上角的象限。這代表什麼意思呢？看來，大多數朋友在執行專案時，最需要的是在短期內因應變更的能力，這個能力就叫「擅變力」(Agility)，這就是敏捷專案管理的目的。

台灣敏捷專家協會海報

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