這次的課程起源於資訊廠商JRS（乙方）承接考試院的「及格證書系統重建」專案開始，JRS不僅承包專案，更主動提議舉辦一場「敏捷共識營」，誠摯邀請政府單位考試院(甲方)共同參與。
JRS深知，多數政府標案仍採傳統瀑布式開發流程，對於快速變更與漸進交付的需求常顯笨重、低效。而軟體開發講求靈活應變與快速迭代，若仍用瀑布手法執行，將容易造成進度落後與交付失準。
因此，這場課程不只是單向講授，更是一場促進甲乙雙方理解、對話與合作的實務工作坊。透過共同語言與共識的建立，為敏捷在政府標案中的實踐打開了一扇窗。
很榮幸受邀擔任這場敏捷共識營的講師。對我而言，這是一個極為難得的機會，能夠設計一場讓來自截然不同體系的甲乙雙方——政府單位與資訊廠商——共同參與的敏捷課程。
雙方平時各自處於不同的工作節奏與語言系統中，卻在這一天，坐在同一個教室裡，從相同的起點出發，一起學習敏捷、建立共通語言、開啟實質對話。這樣的交會，不僅是合作的起點，更是改變的契機。
關鍵時刻：處長的一句話改變大家的看法
課程進行到尾聲時，考試院資訊處徐處長說了一句令人印象深刻的話：
「其實政府的標案並沒有限制不能做敏捷，我一直在思考這個敏捷空間在哪裡，其實是完全沒有衝突的。」
這句話打破許多參與者的迷思，也揭開我們深入討論的契機。而我想補充的是：「最重要的彈性，不在合約，而在人與人之間的共識。」
假設這次沒有這場共識營，只有乙方在單方面推行敏捷，那麼這個專案的風險一定高。但因為甲方也理解並接納敏捷，他們才能成為真正的合作夥伴。
敏捷與政府標案的「SOW矛盾」真的無解嗎？
政府標案一開始通常會寫出所謂的工作說明書（SOW），其中包含所有功能需求，無論是否重要，照理都必須全部實現。
但在實際開發過程中，常會發現新的、更關鍵的需求浮現。這時有多條可行的路：
- 合約變更流程：透過正式程序新增或調整功能。
- 功能換功能：將不重要的項目替換為更具價值的新需求。
- 敏捷迭代過程中所造成的成本增加：於專案結案後仍有預留預算，可靈活運用
- 敏捷迭代過程中所造成的時程延宕：甲方向監辦單位說明變更原由，並不屬於違約
- 善用國發會為敏捷客製化的採購建議書：如附件1 & 2
這些其實都是敏捷與政府採購制度能共存的證明。
乙方觀點：JRS眼中的敏捷啟發
這是JRS第一次以敏捷方法推動政府專案。從 Slido 提問中可看出，他們提問內容貼近真實挑戰，例如:如何在不確定需求下展開開發、如何有效管理變更等。我也逐一回應，讓他們感受到敏捷實際上是有解的。
- 產品開發可以只把重要的功能、事情做對做好就可以結案，未來往下一階段前進，但是，專案要如何處理？
- 需求確認了也開發了，但客戶因應市場需求或他的長官要求又重新定義新的規格
- 敏捷在專案完成維護階段如果仍要求持續優化，成本如何估算？
- 公務部門必須先提供投標的RFP，為了如何因應敏捷式開發可能如何因應，PMO辦公室的角色是否也可以因應此變化調整？
- CMMI的繁複文件對於交接、後續維護有助益，使用敏捷式開發著人員互動及可運作的軟體，對於公司KM知識庫的建立是否有改變？
- 在傳統瀑布式開發團隊之系統分析SA、設計SD角色，在敏捷方法中是否仍需要
- SM在公司要由高階主管來擔任，還是讓誰來擔當均可？ 什麼特質的人比較容易成功？
- Scrum team每個人能力都要很強，這些人才應該不好找
JRS提到一個關鍵痛點：傳統專案中，需求不清楚、使用者模糊不確定，往往導致成本暴增、時程延誤。敏捷則剛好解了這些困難：
- 需求不明確？ 每次迭代產出 MVP 讓甲方驗收，邊做邊探索甲方的真正需求細節。
- 時程壓力大？ 通常來自於需求不明確，而造成的重工，需求明確了時程可提前完成。
- 使用者不滿意？ 敏捷強調迭代過程中，邀請使用者參與、回饋調整。
難題來了：使用者多聲音不一致怎麼辦？
乙方提出一個常見困境：「如果來了很多使用者，有人說OK，有人說不行怎麼辦？」
我當下回答得很簡單：「有 PO（產品負責人）代表就可以解決。」這位 PO 就是甲方代表，他的責任是統整意見、做出產品優先順序的決策。這也是敏捷能維持效率與品質的關鍵。
一場為對話而生的課程設計
整場課程的設計，我特別著重於「對話」。一開始，我分享了三種理想敏捷合約：
- 時間&材料合約 (T&M contracts )
- 不勞而獲 (Money for nothing)
- 變更免費 (Change for free)
然而政府合約屬於「固定總價」，無法完全套用上述合約模式。因此，我引導他們將原始的 SOW 轉化為使用者故事與產品待辦清單（PBL），並開始排出優先順序與增量交付計畫。
透過這樣的轉換，大家開始討論：
- 如何運用合約變更機制？
- 哪些功能可以「功能換功能」？
- 合約限制之下，還有哪些彈性空間可用？
政府標案也能 Scrum！共創需求清單的感動時刻
那天最令人動容的畫面，就是政府甲方與資訊廠商乙方肩並肩，同步書寫一份可持續排序、迭代優化的產品待辦清單，取代傳統一次定稿的需求說明書。當需求被拆解成小而可驗證的工作項目，並隨著優先順序不斷調整，大家終於看見敏捷真正強調的「價值最大化」與「風險最小化」。在共識營的氛圍裡，政府甲方不再只是需求單位，廠商也不再只是接單工匠；雙方用白板便利貼，討論「何者最有助於及早產生價值」，從而在每一次短迭代的衝刺後，都能獲得早期回饋並迅速改進。這一幕讓人驚覺：原來政府標案也能充滿創新與活力，只差一個讓彼此理解的對話場域。
對還在觀望的政府單位與資訊廠商，我想說：勇敢跳進來吧！政府其實從未禁止敏捷，國發會的 RFP 建議範本早已納入相關作法；Waterfall 最大的痛點，就是終於驗收時卻發現「成品與想像落差巨大」。我曾在 CSM 課程中詢問二十五位薦任文官，是否獲得過完全符合需求的資訊系統，結果幾乎全搖頭。與其抱怨，不如創造平台：邀請甲方參與共識營、CSM 課程，讓共同語言與信任在一開始就扎根。只要願意讓「需求、回饋、調整」成為日常，敏捷絕不是「做不到」，而是「一起做到」。
我訪談承辦人，對於政府敏捷合約的彈性確認
政府採購長期被視為「一錘定音」的瀑布式執行模式，然而考試院近期資訊系統重建案顯示，透過妥善的契約設計與溝通機制，即使在固定總價標案下，仍可保留足夠的敏捷彈性。以下我整理與承辦人商業分析師的對談重點，供有意承接政府敏捷專案之民間廠商參考。
一、預留後續擴充權限
合約明訂「第五階段」，允許機關於驗收後兩年內追加最高原發包預算的35% (各案件不同)，用於功能優化與客服強化。此舉相當於預先保留「迭代預算」，確保專案在正式上線後可因應實際使用情形持續優化。
二、「功能換功能」機制
當初始需求未臻成熟或優先順序有所調整時，可透過契約變更將原列但低優先的功能替換為更具價值的新功能；若新舊功能開發成本相當，無需增減價款即可執行。此安排使專案能在不增加預算的前提下，保持敏捷迭代的靈活度。
三、進度調整與違約判定
若因新增功能導致工期延長，由甲方先行向監辦單位說明變更緣由並取得同意。只要延期屬新增需求所致，且履約管理文件完整，通常不視為違約，也不會啟動罰款機制。此處關鍵在於透明溝通與正式程序。
四、採購級距與監管強度
追加預算後，如改變政府採購法查核級距，須接受更嚴格之核准與審查。廠商投標前應詳查各金額門檻對流程與文件的影響，評估行政成本並預留作業時間。
五、活用國發會敏捷建議書指引文件
國發會已發布「敏捷開發招標文件撰寫指引」，內含需求拆分、里程碑付款及驗收標準等範例，雖不限定合約類型，卻提供可直接引用之操作框架。建議廠商於提案時結合自身熟悉之 Time and Materials 等合約模式，提出符合政府規範且兼具彈性的方案。以下網站及範本提供參考