第五章 研究分析
第一節 公部門運用敏捷專案的契機與利基
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
62
第五章 研究分析
本研究主要的目的主要是從公部門的角度來探討應用敏捷開發於專案的動 機、敏捷專案過程中遇到的困難與挑戰、為敏捷開發所做出的調整、以及敏捷方 法所帶來的優點與效應。為了能讓分析較為聚焦，本文根據訪談內容編排研究分 析的章節設計，本章第一節敘述公部門運用敏捷方法的原因、探討什麼類型的專 案比較適合使用敏捷方法，並討論敏捷方法所帶來的實質效益與後續影響。第二 節則說明行政機關運用具備敏捷精神的開發方式會遭遇什麼挑戰、運用敏捷方法 時須在專案中做出什麼調整、以及最後對於公部門應用敏捷方法的反思。第三節 則提出公部門導入敏捷精神其實是一個天平調整的過程。
第一節 公部門運用敏捷專案的契機與利基
壹、 導入敏捷於專案的原因與合適情境
從訪談過程與次級資料中發現，在應用敏捷專案前公部門高層決策者對於敏 捷開發的認知是採用的一個重要原因，若其本身對敏捷專案管理的內容與特性有 深入的瞭解，且在其他公務同仁亦認為機關的屬性與敏捷的特性相符時，雖然對 於導入結果不清楚，但就會開啟運用敏捷於專案過程的契機，例如 A 機關於訪 談過程中提到：
「因為我們資訊中心的最上面的主管就是馬主任，我們馬主任本身是學 專案管理的，他對這一塊非常非常熟悉，他不見得是實際的執行單位，
但他很支持。我們確實是資訊主管很支持這樣的專案進行，甚至他鼓勵 我們每年都應該做一個敏捷式的專案管理」。（A1）
「一開始的時候就是從一些專案的管理雜誌上面所獲得這樣的一個新 知，那獲得這個新知去具體了解後，這個是跟我們軟體開發這樣的一個 屬性是很適合的，但是我們又不清楚那個到底可以帶來什麼樣的一個效 應，那就是在嘗試的一個情況下先試做了一個，單純就是這樣子」。（A1）
但縱然過去從沒聽過敏捷專案管理，只要該機關具有開放的組織文化，當外 部顧問向其介紹敏捷開發的內容與精神，在專案主管的支持下亦會開啟公部門應 用敏捷專案的機會，如同 B 機關的專案即是在已經啟動委外服務程序的時候，
剛好行政院國家資訊通信發展推動小組（NICI）–政府資訊委外服務團邀請他們
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
導入「敏捷式專案管理」，當時的專案主管認為此方法和該機關大力推行的「設 計思考」（Design Thinking）概念非常接近，即決定導入敏捷方法（NCDR，n. d.）。 C 機關則提到日前曾應用敏捷精神成功挽救接近失敗的專案。受訪者指出當時在 上線前夕才發現開發系統有部分需求仍停留在待確認階段，導致後面版本出來時 遇到了預期與實際產生落差。因此，那時主要利用敏捷精神來縮短期程，讓專案 成員利用每週會議或每天會議追進度，優先處理會影響上線時程的項目，以偏向 問題端的方式確認問題是否有被排除，排除後做測試以及驗證，讓產品功能趕快 上來、盡快處理問題優化的項目。同時間並根據問題複雜性、問題重要性、影響 工作等面向排定後續版本的進度，盡量在短時間內讓專案的品質盡快收斂起來，
確認產品符合業務單位的需求。
「他的狀況其實在上線規劃期間沒什麼敏捷性的概念，他是很標準式的 SDLC，就是瀑布式的專案管理，那到後面其實才進入敏捷式，原因很 簡單，因為長官已經壓著上線時程了，那時程已經壓好，那當然只能挑，
就是進入一些比較敏捷式的處理，就是挑哪些東西會影響上線的我們優 先處理，那我大概是每週會議或每天會議就在去追那些進度，那就看說 有沒有排除這樣的方式去管理問題，這比較偏向問題端，那有即時性的 其實初期可能每天開會，然後確認這個東西確實有排除，排除的話回去 還要做測試，測試再驗證。那就是他整個 circle 變非常短」。（C4）
「因為後來看到需求訪談時，有些東西還停留在待確認，這也是一開始 的問題，因為需求訪談的複雜性蠻高的，所以導致後面其實這些需求沒 有確認，到後面的版本出來的時候，gap 出來了，就需求沒有確認，那 做出來是工程師想像的東西，那當時就說這不能用啊，他說我講 A 你 怎麼做 B 出來，他說沒有我的 B 可以符合你的 A」。（C4）
另外，從敏捷顧問的角度來看公部門導入敏捷的因素，根據訪談結果則可以 歸納為以下幾點：一、使用者需求不易掌握，且變動性高，因此公部門可以運用 敏捷方法深入探索使用者需求。敏捷顧問提到的需求變動性高的原因則與行政院 主計處電子處理資料中心的調查結果相仿，包括「衍生性需求」、「政策法令修 改」、「管理階層要求」、以及「需求發展階段缺漏」等四點；二、運用敏捷方法 分階段開發及展示成果，讓使用者提前體驗重要成果，降低專案後期的修改；三、
跨單位整合需求單位、使用者及資訊單位，運用敏捷方法可以強化跨單位共識。
訪談過程中，受訪者 A2 及 A1 就提到：
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
64
「因為敏捷在討論需求問題的過程中我們會使用一些像 user story map 或 user story 去探索他的需求，所以這個時候我們會把 user、廠商、還 有承辦單位、還有資訊單位，把它統籌起來，去強化跨單位有共識，對 於這討論出來的需求就像上一頁這個」。（A2）
「政府單位有時候政策上會變動，那或是使用者那邊因為政令上下來，
這一季跟下一季可能方向上會變動，好但是合約都出去了，所以你現在 問他確切的需求，要他一開始在傳統的計劃性一開始就要畫押，那他一 定沒有辦法，或是他交出來，但你知道那種東西未來在年底，或是長官 要的東西一定會變動，所以那如果這樣的話，傳統的做法就是年初還是 會有一個計劃書，然後會有需求文件，那你知道後面一定不會是這個，
會有好幾次的變更，所以導致那個廠商你前面寫的那些我都要做，但做 完以後幾乎要改個三成四成，那導致廠商的成本會不斷的上升所以敏捷 最重要的一件事就是說…要去符合民眾的需求」。（A2）
「除了我們自己單位的角度是這樣想，還有就是我們廠商的角度，廠商 的角度就剛剛提啊，如果就多探索，如果他願意跟你探索那當然很好，
那就是要去做一個磨合，廠商要去做溝通的。專案議程初期就要做這樣 的溝通，不是只有我們單方面，其實涉及到三方，剛剛講一個案子的進 行大概有三方，就是我們專案政府單位就是專案管理方，第二方開發方 廠商，第三方是需求單位使用者那端，這三方全部都要有一個共同的認 知」。（A1）
而公部門在得到導入敏捷於專案過程的動機後，除了必須思考應用敏捷開發 過程需克服的挑戰及調整外，亦須考慮什麼樣的類型適合敏捷專案管理，此時我 們可以從曾使用過的機關經驗瞭解什麼類型的專案適用於公部門。透過訪談內容 發現，公部門管理者認為目前比較適合進行敏捷開發的類型為軟體開發，因其較 有彈性、比較不會受限於規格上面的限制。而敏捷教練則認為一般來說，「需求 變動性高之專案」、「跨單位整合之專案」、以及「具急迫性之重要策略專案」的 類型皆適合適合專案全程應用敏捷管理。但是敏捷教練同時指出，如果將專案分 階段，局部使用敏捷精神，則敏捷可適用於大部分的專案類型。訪談內容如下：
「也只有軟體開發案比較適合這樣，軟體設計本來就有彈性，如果你是 做這種硬體設計或許就沒有這種彈性，規格死了能用就能用，軟體是有
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
彈性的，比如說我一個查詢，簡單那個查詢 ok 啊，那 Google 還可以進 階查詢，那我就寫個查詢，到時候如果你要做到進階那最好啊，今年能 吸收的方面他就去做，那個不能做的方面那可能今年就取捨，至少基本 的先做出來，那我們只要探索出這個需求，那明年，這個也是一個好的 產出，今年探出需求的結果，沒做的明年我們想辦法把它做完，那這個 工我們沒有白費，那是軟體專案的精神很適合，硬體就不見適合了」。
（A1）
「什麼樣的狀況比較適合？需求變化性高，那如果他完全沒有變動性就 不太需要用，那再來可能也有跨單位的整合，再來可能比較急迫性的或 重要政策，那這種是如果要純敏捷，因為你問的問題是敏捷方法，所以 我回答這三個是純敏捷，但是如果你說一般的專案可不可以用，可以。
你可以採用敏捷精神，剛剛組長提到的硬體他可能比較不適用，但是他 可以局部使用敏捷精神，比如說我採敏捷精神只是把它分段而已，但事 實上每段裡面就像我剛剛跟你講的每段還是計劃性，那這樣子他也是局 部用到敏捷精神這樣也 ok 啊」。（A2）
另外，受訪者 C4 亦提到在執行智慧城市慨念驗證（PoC）的專案時，因為 使用者需求不明確、產品仍在開發階段等原因，其非常適合採取類似敏捷精神的 方法，透過訂定階段性目標的方式進行專案，此種將供應、需求與資金匯集的策 略迎刃解決過往智慧城市在資金、資源、及解決方案上所面臨的挑戰，台北市的 此一策略有可能成為全球智慧城市遊戲規則的改變者，其得到前 IDC 亞太區副 總裁 Mr.Charles 的大力讚賞。
「智慧城市一直都是 Agile，因為他不是採購案，所以他其實就是訂一
「智慧城市一直都是 Agile，因為他不是採購案，所以他其實就是訂一