內容已複查
約 36 分鐘 · 0 張概念卡 · 3 題對應考古題

系統取得策略與敏捷交付深入：從 sourcing 到 sprint

題面來自台大官方試卷；解析與逐項自評標準（rubric）為本站依已複查來源整理的非官方內容，策略申論容許有條件且有證據的替代論點。

考古題證據邊界： 考古題只證明此範圍曾出現；題面均為申論或開放題，答案非官方，課程練習採 rubric self-review，絕不進自動計分或完整模擬考。

第一次接觸也沒關係

這堂先懂這些詞

先記住白話意思，不必急著背英文。看到正文時，再把正式名稱接回來。

IT 投資組合

也會看到：IT portfolio

像分配理財資產一樣，把 IT 預算分散在維運、成長、法遵與實驗項目。

生活例子：
家庭預算同時留給修水管、節能設備和新家電試用。
別搞混：
不是把所有專案列成一張清單；重點是整體風險與效益配置。

自建／採購／委外／訂閱服務

也會看到：build、buy、outsource、SaaS

分別是自己開發、買現成軟體、請外部廠商執行，以及按期訂閱雲端軟體。

生活例子：
自己煮、買調理包、請外燴、訂月費餐盒。
別搞混：
委外只轉移執行，不會把需求與治理責任一起丟掉。

Scrum

也會看到：Scrum framework

用短週期、透明檢查與調整來處理複雜工作的敏捷框架。

生活例子：
每兩週完成可試用的小改版，再依回饋調整。
別搞混：
不是一套固定瀑布流程，也不是每天站會的別名。

深入 build/buy/outsource/SaaS 的決策框架與 Scrum 的實務執行細節，重點在申論中如何分析取得決策的權衡。

先抓住這幾件事

  • 運用多準則框架比較 build、buy、outsource 與 SaaS
  • 以功能點（FPA）與 COCOMO 估算系統開發成本
  • 解釋 Scrum events 之間的 inspection-adaptation 循環
  • 辨識敏捷導入中的常見反模式（anti-patterns）

1.系統取得不是技術決策，是策略決策

Build/buy/outsource/SaaS 決策的進階分析需要用多準則框架，而不是簡單的成本比較。Laudon 教科書的多準則框架考量至少五個面向：(1) Strategic uniqueness——這個系統是否是企業的核心差異化來源？核心能力應該自建以保護競爭優勢。(2) Control needs——對資料、流程和升級時程的控制需求有多高？SaaS 的控制權最低，build 最高。(3) Cost structure——capex（自建一次性投入）vs opex（SaaS 持續訂閱費）的財務偏好。SaaS 將 capex 轉為 opex，對現金流有好處，但長期 TCO 可能更高（5 年期 SaaS 費用可能超過一次性買斷）。(4) Time-to-market——SaaS 最快（幾天到幾週），buy 中等（幾個月），build 最慢（幾個月到幾年）。(5) Risk profile——build 風險在於開發失敗和 scope creep；buy 風險在於 fit-gap 和客製化成本；outsource 風險在於溝通問題和品質控制；SaaS 風險在於供應商依賴和資料安全。 常見的 hybrid 策略：核心自建 + 周邊 SaaS（例如自建推薦引擎 + 用 Salesforce 做 CRM + 用 Slack 做內部溝通）、核心買斷 + 部分模組客製化、自建原型 + 成熟後外包維護。選擇不是一次性的——系統在不同生命週期階段可能需要不同的取得方式。 考試進階：不要只寫「應該用 SaaS」——要列出你用了哪些準則、每個準則下的分析是什麼、結論在什麼條件下成立。

  • 多準則框架五面向：strategic uniqueness、control needs、cost structure、time-to-market、risk profile
  • SaaS 將 capex 轉 opex，短期現金流好但 5 年期 TCO 可能超過買斷
  • Hybrid 策略常見：核心自建 + 周邊 SaaS + 部分模組外包
  • 選擇不是一次性的——系統在不同生命週期階段可能需要不同取得方式
  • 答題要列出用了哪些準則、分析是什麼、結論在什麼條件下成立

2.成本估算是範圍管理工具

成本估算方法的進階理解。FPA（Function Point Analysis）的計算步驟：(1) 辨識五種功能類型：External Inputs（EI，從外部接收的資料）、External Outputs（EO，向外部發送的資料或報告）、External Inquiries（EQ，查詢功能，輸入觸發輸出但不改變資料庫）、Internal Logical Files（ILF，系統維護的資料群組）、External Interface Files（EIF，系統參考但不維護的外部資料群組）。(2) 每個功能類型依複雜度（低/中/高）加權。(3) 加總得到 Unadjusted Function Points（UFP）。(4) 乘以 Value Adjustment Factor（考慮系統特性如分散式處理、效能需求、複雜度等）得到 Adjusted Function Points。(5) 除以團隊生產力（每功能點的工時）估算總工時。 FPA 的優點是需求導向（不依賴技術選擇——同一個功能用 Java 或 Python 開發，功能點相同），但缺點是需要相對明確的需求定義才能辨識功能。在敏捷開發中，Story points 取代了功能點的角色——但兩者的用途不同。Story points 是相對估算（「這個 story 是那個 story 的 2 倍複雜」），不是絕對估算（「這個 story 需要 40 小時」），不應該轉換為時數或用來衡量團隊生產力。 Cone of uncertainty 指出估算誤差隨專案階段收窄：概念階段估算的誤差範圍是 0.25x-4x（實際可能是估算的四分之一到四倍），需求確認後收窄到 0.5x-2x，設計完成後收窄到 0.8x-1.25x。所以好的估算不是給一個精確數字，而是給一個範圍並標明所在階段。 估算偏低的常見原因：optimism bias（人類天生低估複雜度）、scope creep（需求持續增加但估算不更新）、unknown unknowns（不知道自己不知道什麼）、anchoring（被第一個估算值錨定，後續調整不足）。

  • FPA 五功能類型：EI、EO、EQ、ILF、EIF，依複雜度加權後得到功能點
  • FPA 需求導向（不依賴技術選擇）但需要明確需求——敏捷中用 story points 替代
  • Story points 是相對估算不是絕對時數——不應轉換為時數或衡量生產力
  • Cone of uncertainty：概念階段誤差 0.25x-4x，設計完成後收窄到 0.8x-1.25x
  • 估算偏低四原因：optimism bias、scope creep、unknown unknowns、anchoring

3.Scrum 的核心是 empiricism，不是儀式

Scrum 的進階理解聚焦在 empiricism（經驗主義）的運作機制。很多組織「導入 Scrum」但只採用了形式（每天開站會、兩週一次 sprint）而沒有採用核心原則（透明度、檢視、調適）。 Scrum Guide 2020 版本的重要更新：(1) 更強調「自管理」（self-managing）而非「自組織」（self-organizing）——區別在於自管理的團隊不只決定「怎麼做」，還參與決定「做什麼」和「誰來做」。(2) Sprint Goal 成為必要元素——每個 Sprint 必須有一個明確的目標，所有工作圍繞這個目標。沒有 Sprint Goal 的 Sprint 只是「在時間箱裡做一堆任務」，失去了聚焦和決策依據。(3) Product Goal 是長期目標——Product Backlog 是達成 Product Goal 的計劃，PO 需要管理 stakeholder 期望和優先順序。 常見的 Scrum 反模式（anti-patterns）：(1) Scrum-but——「我們用 Scrum，但不做 Retrospective」「我們用 Scrum，但 Sprint 長度不固定」。每個 event 都有特定目的，跳過一個就破壞了 inspection-adaptation 循環。(2) Micro-management——把 Daily Scrum 變成主管彙報會，PO 直接指派工作而不是排序 Backlog。(3) Sprint 0 永無止境——「我們還在做架構設計、環境準備、需求收集」——Sprint 0 不應該超過 1-2 個 Sprint 的時間。(4) Velocity 作為 KPI——velocity 是 planning 工具（幫助團隊預估下個 Sprint 能做多少），不是 productivity metric。把它當 KPI 會導致團隊灌水（inflating story points）。 考試角度：比較 Scrum 和 Waterfall 時，不要只列差異表——要解釋在什麼條件下各自適用（需求確定度、change frequency、feedback availability、team autonomy）。

  • Scrum 2020 強調 self-managing（決定怎麼做+做什麼）而非 self-organizing
  • Sprint Goal 是必要元素——沒有 Goal 的 Sprint 只是「時間箱裡的任務列表」
  • 四大反模式：Scrum-but（跳過 event）、micro-management、Sprint 0 無限延長、velocity 當 KPI
  • Velocity 是 planning 工具不是 productivity metric——當 KPI 會導致灌水
  • 比較 Scrum vs Waterfall 要寫適用條件，不只列差異表

4.敏捷反模式比方法論更重要

敏捷導入的組織挑戰通常比技術挑戰大。技術團隊可以在一個月內學會 Scrum 的形式，但組織文化的轉變需要一年以上。常見的組織阻力：(1) 中層管理者——敏捷強調自管理團隊和扁平化溝通，中層管理者的「資訊中繼站」角色被削弱，導致抵制。(2) 績效制度——傳統的個人績效考核（individual performance review）與敏捷強調的團隊協作和共同責任衝突。(3) 合約管理——固定範圍固定價格（fixed scope, fixed price）的外包合約與敏捷的迭代交付和需求變更不相容。(4) 法規環境——某些產業（金融、醫療、國防）的法規要求完整的事前文件和審批流程，與敏捷的「working software over comprehensive documentation」原則衝突。 大規模敏捷（Scaling Agile）框架：SAFe（Scaled Agile Framework）是最廣泛使用的，它在多團隊層面增加了 Agile Release Train（ART，由多個 Scrum 團隊組成的跨功能團隊）、Program Increment（PI，通常 10-12 週的規劃週期）和 PI Planning（所有團隊同時參與的規劃活動）。LeSS（Large-Scale Scrum）則強調「less is more」——盡量減少額外的角色和流程，讓多個團隊共用一個 Product Backlog 和一個 PO。 考試提醒：不要把敏捷等同於「沒有規劃」或「不寫文件」。敏捷是「適量規劃」（just enough planning）和「有用的文件」（living documentation），不是「不做」。如果考題問「敏捷適合所有專案嗎？」——答案是不，要說清楚在什麼條件下不適用。

  • 敏捷導入的組織阻力：中層管理者角色削弱、個人績效制度衝突、合約不相容、法規要求
  • SAFe 增加 ART 和 PI Planning 處理多團隊協調；LeSS 強調減少額外流程
  • 大規模敏捷有成本——框架本身增加協調複雜度和學習曲線
  • 敏捷不等於「不規劃不寫文件」——是「適量規劃」和「有用的文件」
  • 敏捷不適合所有專案——需求完全確定、法規要求完整文件的場景可能不適用

一起搭作答骨架

範例 1：如何回答「系統取得策略與敏捷交付」的比較題？

  1. 定義比較軸與分析單位。
  2. 各寫一條作用機制。
  3. 加入至少兩項條件或風險。
  4. 用案例與指標驗證。

所以作答主軸是：可接受的答案不只一種；關鍵是條件透明、概念正確、推論可追蹤，並能說明限制。

範例 2：題目要求提出建議時，如何避免只列 buzzwords？

  1. 先指出要改善的問題。
  2. 說明建議如何改變流程、資訊或激勵。
  3. 指定責任人與衡量方式。
  4. 補上失敗訊號與替代方案。

所以作答主軸是：建議應包含 action、mechanism、metric 與 risk，而不是只寫「導入 AI／雲端／平台」。

這裡最容易寫偏

  • 把工具名稱當成因果解釋
  • 沒有說明分析層級與前提
  • 只寫單一立場，不處理權衡
  • 把非官方參考解析當唯一標準答案
  • 引用時事卻沒有日期與來源邊界

換你快速判斷

先用自己的話說出定義、機制、條件與取捨，再展開答案。

最後用考古題自評

請先完成自己的申論，再依非官方解析和逐項自評標準檢查；不使用 A–E 假選項或虛假分數。

開始本課申論自評

參考來源