第二章 文獻探討
第三節 敏捷精神應用於公部門
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
強調藉由充分利用組織內外部能力提早發現外部環境變化以即時採取適當行動 處理問題，其具有以下四個特徵：「由下而上的分權式決策制定」、「流動內外部 組織能力」、「擴大參與」、及「持續調整以回應不確定性」（Wang, Medaglia & Zheng, 2018）。其中在適應治理的討論上，Wang（2018）等人聲稱敏捷治理為適應治理 的其中一種類型。Mergel（2016）則為敏捷治理提供了一個全面性的定義，將敏 捷創新管理作為一個整體概念引入政府，其不僅包含軟體開發或專案管理，亦涵 括與過往不同的採購程序、人力資源政策、支持創新數位服務的組織與管理方 法、以及高層的推動與倡領導。Soe 及 Drechsler（2018）認為雖然可以認定數位 政府是最廣泛的概念，而敏捷治理是最狹隘的（如圖 6），但其實它們彼此之間 的關係不是固定而是動態的，可以從不同觀點多次重繪。
圖 6：數位政府、適應治理、及敏捷治理關係 資料來源：Soe & Drechsler (2018).
第三節 敏捷精神應用於公部門
壹、 重要國家與國際組織應用敏捷精神之現況
一、英國
自 2010 年 Martha Lane Fox 向英國政府寫了一封名為「Directgov 2010 and Beyond: Revolution Not Evolution」的公開信以來，開啟了近年來英國數位轉型的 濫觴，而數位首選15（Digital by default）也成為了其重要策略。2011 年，英國政
15 稱為「數位首選」，是期待民眾使用政府機關提供的服務時能夠優先選擇使用該線上服務，而
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
32
府於內閣辦公室（Cabinet Office）之下成立「政府數位服務團隊」（Government Digital Service, GDS），期盼透過集結數位、科技及資訊的人才與政府部門協力進 行數位轉型，其以「使用者為中心」（User-centric Design）及「敏捷」（Agility）
作為核心，秉持「開放」理念與其他部門合作提供更好的公共服務、構建 GOV.UK 等平台、致力政府開放資料的品質與應用、協助其他部門做出更明智的決策、以 及幫助公部門提供員工值得學習的技術16。GDS 致力落實敏捷方法，其最著名的 開發案例為只花了 10 周就交出「英國政府入口平台」GOV.UK 的 Alpha 版本。
GOV.UK 不但取代了原本分散的 1,700 個政府網站，成為英國政府的統一入口網 站，還榮獲 2013 年英國年度設計獎（Designs of the Year 2013）17。根據 2017 年 英國「數位策略」（Digital Strategy）白皮書，GDS 未來將主導以下 3 項改革計畫，
協助政府各部門達成優先政策目標：首先，英國政府將會加快數位轉型的速度、
擴大數位轉型的規模。其次，英國政府將把「政府」（Government）視為是「平 台」（Platform）的概念。第三，英國政府將採行可多次使用的構成元件（Reusable Components），讓數位服務的組合過程更加快速、便宜與易用。而截至 2018 年為 止，目前 GDS 的編制超過 800 人。
GDS 內部運作方式為針對每個政府數位服務，指派專責產品經理（Product Manager）和交付經理（Delivery Manager），搭配技術架構師、開發人員、使用 經驗設計師、數據分析師、營運人員和內容設計人員，組成跨職能的開發團隊
（Multi-disciplinary Teams），使用敏捷方法（Agile Methodologies）進行開發（徐 柏峰、吳仁傑、林祖馨，2015）。而為了促成政府數位服務的優化，必須把各機 關的本位心態翻轉成「民眾需要優於機關需要」(Put users' needs before the needs of government)，GDS 主要用以下面兩項作法達到此策略性目標：
（一）訂定《政府服務設計手冊》：
如同前段文獻回顧所述，各國開發系統的流程傳統上都是採用瀑布模式，必 須先在內部經過冗長的需求蒐集及招標程序，才能委外進行開發，必須等到所有 規範的開發程序全部走完，使用者才會開始體驗系統功能。此種開發過程僅要求 詳盡的文件描述需求（Requirements），但設計方向是否正確、設計是否直觀、有 沒有解決使用者需求等問題往往要等到「做完事情」才會知道答案（徐柏峰、吳
唯有通過驗證標準的服務才稱得上有品質、才有資格放在 GOV.UK 的網站上。
16 資料來源：GDS. About the Government Digital Service. Retrieved Nov. 26, 2018, from https://gds.blog.gov.uk/about/。
17 資料來源：iThome（2013）。打敗時尚圈和建築界 英國官網如何奪設計首獎，2018 年 11 月 26 日，取自：https://www.ithome.com.tw/article/90392。
‧
敗案例，例如：英國耗費鉅資建立的「全國衛生服務系統」 （National Health Service, NHS）因為不符使用需求，在 2011 年宣告終止，被外界稱為史上最大的 IT 投資 失敗案例18。GDS 提出政府服務設計手冊的原因在於，其認為政府對數位服務的看法正 在轉變，我們正在從過去各自分立的服務（Isolated Transactions）轉向整合、連 結、端對端的服務（End-to-end services）。為了朝這樣的方式運作，政府需要一 種新的服務標準以支持和鼓勵數位服務的變革，而各團隊亦需要新的指導手冊能 夠幫助他們達到標準、創建並提供優質服務。故 GDS 於 2013 年提出《政府服務 設計手冊》（Government Service Design Manual），目標在於「幫助各團隊為使用 者提供盡可能最好的服務」、以及「為剛接觸政府的人分享最佳實踐方法」19。 該手冊要求英國其他政府機關在打造政府數位服務時，改以 Discovery、 Alpha、
Beta、以及 Live 等四階段（如圖 7），取代以往規劃、需求、 分析、設計、實作、 service teams to use their discretion: we trust them, and it’s part of their job」21。以下 簡短介紹 Discovery、Alpha、Beta、及 Live 四個階段如何將使用者需求納入迭代 循環開發過程，開發團隊如何以 1-2 週的開發週期（Sprint）、透過迭代（Iterative）
的方式，根據回饋意見增修功能、逐步交付出階段性成果22：
18 資料來源：N. Tune (n.d.). Agile in the UK Government: An Infiltrator’s Secrets. Retrieved Nov. 26, 2018, from
https://www.agilealliance.org/resources/experience-reports/agile-in-the-uk-government-an-infiltrators-s ecrets/。
19 資料來源：GDS (2018). How we write guidance for the Service Manual. Retrieved Nov. 26, 2018, from https://gds.blog.gov.uk/2018/05/17/how-we-write-guidance-for-the-service-manual/。
20 資料來源：GDS (2013). From the centre and here to help. Retrieved Nov. 26, 2018, from https://gds.blog.gov.uk/2013/04/16/here-to-help/。
21 資料來源：GDS (2018). How we write guidance for the Service Manual. Retrieved Nov. 26, 2018, from https://gds.blog.gov.uk/2018/05/17/how-we-write-guidance-for-the-service-manual/。
22 資料來源：N. Tune (2016). Agile in the UK Government - An Insider Reveals All. Retrieved Nov.
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
34
圖 7：英國政府數位服務的開發階段 資料來源：GDS. Service Manual. Retrieved Nov. 26, 2018, from https://www.gov.uk/service-manual/start。
1. 探索（Discovery）階段
使用者的需求有哪些？目前提供哪些服務給這些需求？這些服務的表 現如何？其中有哪些潛在的技術或政策相關限制？面對這些問題，探索階段 有助於在大方向上瞭解使用者需求、瞭解現有服務的樣貌、以及初期原型需 要探索的方向。因此專案在本階段先透過 4-8 週的時間藉由嚴謹地分析政策 面、法律面與商業面的需求、透過工作坊與訪談找出使用者需要透過政府服 務解決的問題、訂出衡量績效的指標、以及探索技術或政策上的限制等面向 來研究使用者、描繪出服務所處脈絡的整幅圖畫。此階段尤其應注意的是需 要考慮兩種不同的使用者需求：「數位使用者」及「需輔助的數位使用者」，
我們必須瞭解使用者中有多少人需要協助才能使用數位資源。
2. 內部測試（Alpha）階段
由於設計服務時，通常無法事先預測所有的情況，且每個專案面對的挑 戰都大不相同，故在緊接著的 6-8 週內，會利用 alpha 階段開始探索這些挑 戰的可能解決方案、會對一小群使用者或利害關係人進行測試、引進更多的 開發者與設計師進入團隊協助建立及測試原型與解決方案，以獲得關於該原 型設計的初期回饋意見、試圖滿足使用者需求、建立解決方案的原型。而值 得注意的是，在此階段可以透過與利害關係人溝通或給特定使用者測試達成 下列目的：1.對該服務有更多的瞭解；2.測試設計取向；3.測試科技的運用；
26, 2018, from https://www.infoq.com/articles/agile-UK-government。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
4.開始建立團隊；5.在程式與整合的層次上，建立關於該服務的共同看法；
6.瞭解 Beta 所需完成的內容，或該向誰提供外部測試。
3. 外部測試（Beta）階段
當專案根據使用者需求測試解決方案、清楚瞭解開發與營運的服務、以 及需要投入的資源後，即可進入外部測試階段，此時將對可完全可運作的服 務原型進行公開測試，並準備營運此服務。故此階段的目標是建立一個讓使 用者公開測試完整的原型，在滿足使用者需求的條件下，瞭解如何在實際上 線環境下進行開發與調整服務規模，並持續改進此原型直到準備好正式上線
（取代或與現有的服務整合）。此階段將會解決一些技術和流程相關難題，
並開始滿足服務標準所列的技術面向。此時應該迅速發佈更新和改進到開發 環境中，並衡量這些改變對關鍵績效指標的衝擊。通常外部測試版的實際時 程會依專案範疇大小不同，但有適當人數的團隊不該花超過一個月的時間建 立外部測試版。而在釋出外部測試版之後，你將花一些時間反覆迭代測試此 服務直到預備完成上線。
4. 上線（Live）階段
當建立的服務能夠滿足使用者需求、公開測試時能滿足安全與績效標 準、得到公開測試結果的解決方案、以及聯絡負責數位首選服務準則團隊確 保以滿足服務要求後，即可進入「上線」階段。而上線後並非流程的終點，
該服務應該根據用戶回饋、分析指標和進一步的研究不斷改善。
（二）規範《數位首選服務標準》
GDS 針對使用率較高的交易型服務（Transactional Service），制定出「數位 首選服務標準」（Digital by Default Service Standard）要求英國中央政府部門、機 關或非部門公共機構（Non-departmental Public Body）自 2014 年 4 月以後上線或 重新設計的數位服務皆必須符合相關規範，其目的在於為政府服務建立一種數位 發展標準，使數位服務能夠維持一貫的高品質，並具有容易被改進、安全、可靠 和能夠滿足用戶需求的優點。其中為了避免《數位首選服務標準》不夠明確，造 成驗證是否符合的困擾，GDS 分別針對服務是否能夠達到 Alpha、Beta 和 Live 階段的標準，提供了詳盡的服務評鑑規範（徐柏峰 et al.，2015）。數位首選服務 標準如表 6 所示：
‧
且有決策責任的資深服務承辦人（Service Manager）領軍。4 使用敏捷、滾動、以人為本（User-centric）的方法，建構使用《政府數 位服務手冊》所規範的服務。 虛擬帳號（Dummy Accounts）和具代表性的使用者樣本，進行端對端
4 使用敏捷、滾動、以人為本（User-centric）的方法，建構使用《政府數 位服務手冊》所規範的服務。 虛擬帳號（Dummy Accounts）和具代表性的使用者樣本，進行端對端