111 高普考高考二級 資訊處理 軟體專案管理研究 考古題詳解

核心觀念

本題評量敏捷軟體專案管理（Agile Project Management）中需求估算技術的理論與實務應用，核心考點包含：

1. 規劃撲克（Planning Poker / Scrum Poker）的本質與淵源：源自傳統估算技術「寬客戴爾菲法」（Wideband Delphi Method），是敏捷社群（特別是 Scrum 與極限編程 XP）廣泛採納的「相對估算」（Relative Estimation）與「群體共識決策」技術。
2. 故事點（Story Points）與費氏數列（Fibonacci Sequence）：理解以非線性數列（如簡化費氏數列 $0, 1, 2, 3, 5, 8, 13, 20, 40, 100$）度量工作規模、複雜度及不確定性，而非直接估算「絕對工時」（Absolute Man-Hours）。
3. 認知偏差消除：主要在於防範「錨定效應」（Anchoring Effect）與「團體迷思」（Groupthink），並提高團隊集體當責性（Collective Ownership）。
4. 情境題型推演（遠距辦公 / Remote Work）：考驗考生將敏捷儀式（Agile Ceremonies）實體物理互動轉化為數位協作工具鏈（協作軟體、視訊會議、非同步/同步估算機制）的應變設計能力。

---

解題方法

本題為高考二級之典型申論題，採「三段式結構」鋪陳：

1. 定義與用途層次剖析：從「相對規模評估」、「消除心理偏誤」、「促進跨職能溝通」三個維度論述規劃撲克的用途。
2. 施行步驟標準化流程：依照會議生命週期，劃分為「會前準備 $\rightarrow$ 需求宣讀與答疑 $\rightarrow$ 獨立估算暗扣 $\rightarrow$ 同步亮牌 $\rightarrow$ 極端值辯論 $\rightarrow$ 收斂與記錄」六大關鍵步驟，展現嚴謹的工程與專案管理程序。
3. 疫情遠距情境應變（配套措施）：從「數位工具鏈導入」、「線上引導與防範疲勞」、「協作契約與規範」三大實務構面作答，體現理論落地於真實專案現場之專業度。

---

選項分析

（本題為申論題，無選擇題選項；評分核心在於論述是否涵蓋以下評分要點）：

• 用途面向：是否清楚點出「相對估算」取代「絕對估算」、避免「錨定效應」、促進「跨職能共識」。
• 步驟面向：是否完整交代出牌、盲評、同步亮牌、極端值討論、再投票的循環收斂機制。
• 遠距面向：是否明確提出線上估算工具、通訊溝通機制、以及非同步準備以降低視訊疲勞的具體作法。

---

解題技巧

1. 破除名詞死背，點出核心心理機制：論述用途時務必寫出「錨定效應」（Anchoring Effect）。許多專案往往因資深工程師或架構師率先發言，導致全員預估數字被牽著走；規劃撲克的「先暗扣、再同步翻牌」即為破解此偏誤的核心關鍵。
2. 撲克牌特殊符號的加分細節：在描述撲克牌面時，補充問號（$?$ 代表需求不明、無法評估）與咖啡杯（$\text{Coffee Break}$ 代表需要休息、注意力下降），展現對敏捷實務細節的掌握。
3. 遠距情境切忌泛泛而談：不要只寫「使用視訊軟體開會」，應精確指出「專用線上估算平台（如 PlanningPoker.com、Jira 整合外掛）」搭配「線上白板（Miro/Mural）」與「開鏡頭建立非語言溝通共識」，分數才會落在優等區間。

---

【答案】

一、規劃撲克方法（Planning Poker）之用途

規劃撲克是由 Mike Cohn 等敏捷先驅所提倡、改良自寬客戴爾菲法（Wideband Delphi）的一種基於共識之相對估算技術。其核心用途包含以下四點：

1. 實施「相對估算」（Relative Estimation），降低絕對工時預測誤差： 傳統軟體專案常嘗試預估「確切人天/人時」，極易因技術細節變異而失真。規劃撲克引導團隊以「故事點」（Story Point）或理想天數，針對使用者故事（User Story）的**複雜度（Complexity）、工作量（Effort）與不確定性（Uncertainty）**進行相對尺規比較，大幅提高估算效率與客觀性。
2. 避免認知偏誤，消除「錨定效應」（Anchoring Effect）與「團體迷思」： 在公開發言的會議中，資深工程師或管理階層的主觀意見常成為團隊的思考錨點，壓抑資淺人員的判斷。規劃撲克要求成員在揭牌前各自獨立思考並暗扣出牌，防止他人先入為主的影響，保障估算的獨立性與客觀性。
3. 促進跨職能團隊之溝通，釐清隱含需求與技術風險： 估算本質不是追求絕對精準，而是藉由數值差異觸發對話。當團隊出現懸殊估值時，能及早暴露出彼此對規格認知不一、遺漏非功能性需求（如安全、效能）或技術架構隱藏風險，進而促使產品負責人（Product Owner）立即釋疑。
4. 建立團隊集體承諾與當責文化（Collective Ownership）： 估算結果並非單一主管指派，而是開發團隊全員共同參與、充分辯論後產生的集體共識，有效增強團隊對衝刺（Sprint）承諾的認同感與凝聚力。

---

二、規劃撲克方法之標準施行步驟

核心觀念

本題評量軟體專案時程管理（Software Project Schedule Management）中「時程壓縮技術」（Schedule Compression Techniques）的實務限制與反思。核心觀念包括：

1. 時程壓縮的範疇界定：專案管理知識體系（PMBOK）傳統上主要列出「趕工法」（Crashing，以增加成本換取時間）與「快速跟進法」（Fast Tracking，將循序工作改為平行施作）。在軟體工程領域（如 Steve McConnell 的《Rapid Development》與 Fred Brooks 的《人月神話》），時程壓縮尚包含「範疇縮減」（Scope Reduction）、「超時加班」（Overtime）、「妥協品質／累積技術債」（Compromising Quality / Technical Debt）及「分期交付」（Phased / Incremental Delivery）等手段。
2. 軟體工程經典定律：

• 布魯克斯法則（Brooks' Law）：向已延遲的軟體專案增加人手只會使專案更加延遲。
• 收益遞減法則（Law of Diminishing Returns）：過度投入工時會因疲勞導致邊際產出遞減。
• 巴姆缺陷放大模型（Boehm's Defect Amplification Model）：前期未發掘的缺陷，其修復代價在後續生命週期階段呈指數級攀升。

3. 專案管理三重限制（Triple Constraint）：時程、成本、範疇與品質相互牽制，壓縮時程必然引發其他維度的代價或風險轉移。
4. 法規依據：本題屬軟體專案管理學理題，無特定公務法規條文，以專案管理知識體系與國際軟體工程學界權威論述為依歸。

---

解題方法

1. 破題排除檢驗：題幹嚴格限制「除了趕工法與快速跟進法外」，故不可答增加人力、增購現成模組（COTS）或將串聯任務重疊等變形，必須提出軟體開發實務上另外兩種截然不同的壓縮策略。選取學理定義最明確的「範疇縮減（Scope Reduction）」與「超時加班（Overtime）」（並可輔以「妥協品質標準」作補充說明）。
2. 對比分析設計：針對所提技術，精準建立「迷思（Myth）」與「真實狀況（Reality）」的對照架構：

• 迷思：說明管理者在專案初期過度樂觀的直覺假設。
• 真實狀況：依據軟體複雜度、架構相依性與人因工程，闡述實際執行時引發的副作用與隱藏成本。

3. 綜合歸納考量因素：從迷思與真實狀況的反差中，反推管理者決策時不可忽視的核心變數，涵蓋範疇架構、人因極限、缺陷返工、利害關係人期望及專案時機點。

---

選項分析

本題為高考二級之「申論問答題」，無客觀選項。針對答題架構與各子題得分盲點分析如下：

1. 子題一（提出兩種技術）：

• 盲點：若寫「增加資深工程師」或「將工作切割外包」，本質仍屬於投入資源的「趕工法（Crashing）」；若寫「架構設計與編碼同步進行」，本質仍屬於「快速跟進法（Fast Tracking）」，皆屬踩雷失分。
• 正確切入點：應明確提出變更專案內涵（範疇縮減）或壓榨現有工時（超時加班）。

2. 子題二（說明迷思與真實狀況）：

• 盲點：僅列出「優點與缺點」，未扣合題幹指定的「Myth（施作前所抱持之錯誤認知）」與「Reality（施作後面臨之客觀事實）」。
• 正確切入點：迷思必須著重於「線性比例預期」與「忽視反作用力」；真實狀況則強調「非線性代價」與「延遲放大」。

3. 子題三（說明專案管理者應考量因素）：

• 盲點：流於泛泛之論（如「要好好溝通」、「要控制成本」），未從上述迷思與真實狀況推導而來。
• 正確切入點：必須逐一對應前述分析，點出「範疇核心度與耦合性」、「人因疲勞與士氣」、「缺陷修復返工成本」與「專案生命週期所處階段」。

---

解題技巧

1. 善用「Myth vs. Reality」對照標題：閱卷委員在閱卷時偏好對仗分明的小標，每一項技術皆切分為「施行前的迷思」與「施行後的真實狀況」，確保題幹要求的關鍵字全數落於卷面顯眼處。
2. 引述經典軟體工程理論背書：在申論中適度引用 Brooks、McConnell 或 Boehm 等大師概念，能將回答層次從「一般通識管理」提升至「軟體專案管理研究」的專業水準。
3. 緊扣題幹引言作答：題幹提及「部分專案管理者傾向在專案一開始時，便思考與認為這些技術能有效運用」。

核心觀念

本題評量軟體專案管理中「軟體成本與工時估算（Cost and Effort Estimation）」的進階理論體系。題目要求在排除傳統七大主流方法（參數模型、演算法模型、功能點、由上而下、由下而上、專家判斷、類比法）的限制下，提出**另外兩種本質不同（Different Natures）**的估算方法。

考生必須跳脫傳統「單一確定值（Point Estimation）」與「傳統瀑布式階層拆解」的思維，從以下兩個不同典範（Paradigm）切入：

1. 機率統計與風險不確定性導向：三點估算法（Three-Point Estimation / PERT 機率估算法）。
2. 敏捷經驗主義與相對規模導向：敏捷相對估算法（Agile Relative Estimation，以撲克規劃法 Planning Poker 為代表）。

---

解題方法

方法一：三點估算法（Three-Point Estimation / PERT 機率估算法）

1. 基本性質

• 機率統計與風險驅動（Probabilistic & Risk-Driven）：不預設工作量為固定常數，而是將成本與工時視為連續隨機變數，藉由機率分佈模型量化專案的不確定性與風險暴露。

2. 核心原理

• 考量軟體開發中的高度不確定性，針對各工作項目建立三種情境估算值：
• 最樂觀成本／工時（Optimistic, $O$）：在一切條件極度順利下的最低成本。
• 最可能成本／工時（Most Likely, $M$）：在正常條件與一般資源下的實際成本。
• 最悲觀成本／工時（Pessimistic, $P$）：在發生各種重大風險與障礙下的最高成本。
• 透過機率分佈加權計算期望值（Expected Value, $E$）與標準差（Standard Deviation, $\sigma$）：
• 貝氏分佈（Beta 分佈 / 傳統 PERT 公式）：強調最可能情境之權重： $E = \frac{O + 4M + P}{6}$ $\sigma = \frac{P - O}{6}$
• 三角分佈（Triangular Distribution）：適用於歷史資料較缺乏時： $E = \frac{O + M + P}{3}$
• 利用中央極限定理（Central Limit Theorem），將各子項目之變異數（$\sigma^2$）累加，評估專案在特定信賴區間（如 68.26%、95.44%）下的預算覆蓋率，並據此提撥管理應變儲備（Contingency Reserve）。

3. 施行步驟

• 步驟一：分解估算工作單元：將專案範疇劃分為適當粒度的可評估活動。
• 步驟二：判定三種情境數據：由開發團隊依據技術難度、環境變數與歷史風險，分別估算出各項目的 $O$、$M$、$P$ 數值。
• 步驟三：計算活動期望值與變異數：依據選定的分佈模型（如 Beta 分佈），計算每個活動的期望成本 $E_i$ 與變異數 $\sigma_i^2 = \left(\frac{P_i - O_i}{6}\right)^2$。
• 步驟四：匯總專案總成本與風險度量：
• 專案總期望成本：$E_{\text{total}} = \sum_{i=1}^{n} E_i$
• 專案總標準差：$\sigma_{\text{total}} = \sqrt{\sum_{i=1}^{n} \sigma_i^2}$
• 步驟五：決定報價基準與應變儲備：依組織的風險承受度（Risk Appetite），選定信賴區間（例如 $E_{\text{total}} + 2\sigma_{\text{total}}$ 提供約 97.7% 的完工信心），計算並提列預算儲備。

---

方法二：敏捷相對估算法（Agile Relative Estimation / 撲克規劃法 Planning Poker）

1. 基本性質

• 敏捷經驗主義與相對規模導向（Agile Empirical & Relative Sizing）：放棄直接預測絕對工時或貨幣金額，改以團隊集體智慧評估工作項目之間的「相對規模比率」，再透過團隊產能（Velocity）將規模換算為實際成本。

2. 核心原理

• 相對規模優於絕對度量：人類大腦對「A 比 B 大幾倍」的直覺判斷，遠比「A 需要精確花費多少人月」更為準確。
• 韋伯-費希納定律（Weber-Fechner Law）：尺度越大，感知差異的門檻越高。因此使用經過修訂的**費氏數列（Modified Fibonacci Sequence：0, 1, 2, 3, 5, 8, 13, 20, 40, 100）**定義「故事點（Story Points）」，點數綜合反映了工作的複雜度、不確定性與風險。

核心觀念

本題旨在評量考生在「軟體專案管理研究」領域中，將現代新興資訊技術——**人工智慧（Artificial Intelligence, AI）與專案管理知識體系（如 PMI PMBOK）**整合之理論深度與實務洞察力。 核心評量要點包含：

1. AI 在專案管理生命週期之應用層次：涵蓋預測分析（Predictive Analytics）、自然語言處理（NLP）、啟發式最佳化演算法（Optimization Algorithms）等技術在範疇、時程、成本、風險與品質管理中的具體落實。
2. 專案管理人員（Project Manager, PM）之賦能與角色轉型：探討 AI 如何由「自動化日常事務」提升至「增強決策分析（Augmented Decision-making）」，促使 PM 從繁瑣的行政追蹤者（Task Administrator）轉型為具備高階溝通、同理心與策略思維的領導者（Strategic Leader）。

---

解題方法

本題採「客觀系統應用」與「主觀人員賦能」兩大維度切入，契合題目雙核心子題：

1. 第一子題（AI 在專案管理之應用）：採用「專案核心管理領域（時程／成本／風險／資源／品質）」作為橫向展開架構，論述 AI 技術（如迴歸模型、分類演算法、神經網路、基因演算法）在專案流程中如何將非結構化資料轉化為可行動之洞察。
2. 第二子題（AI 如何幫助專案管理人員）：採用「管理者工作型態轉變」為縱向切入點，從「降低事務性工作負擔」、「消除認知偏誤與優化決策」、「主動式預警與敏捷因應」以及「專注高價值領導力與利害關係人協調」等層面逐層剖析。

---

解題技巧

1. 破題對齊 PMBOK 核心術語：避免僅空泛討論 AI 技術（如深度學習、CNN 等），務必連結專案管理專有名詞（如 EVM 掙值分析、關鍵路徑法 CPM、利害關係人管理、衝刺回顧 Sprint Retrospective 等），展現跨領域整合實力。
2. 避免「AI 取代 PM」的極端論述：國考評分偏好「人機協同（Human-in-the-loop）」觀點。強調 AI 扮演「智慧副駕駛（Copilot）」角色，負責運算、模式比對與預測；PM 負責價值判斷、道德責任、衝突化解與商業談判。
3. 架構層次分明：申論排版採大標題、小標題加粗條列，關鍵字（如：預測性時程分析、主動風險管理）置於各段首句，利於閱卷委員在短時間內掌握得分亮點。

---

【答案】

(一) 人工智慧（AI）在專案管理之應用分析

隨著機器學習（Machine Learning）、自然語言處理（NLP）及大型語言模型（LLM）的成熟，AI 在專案管理之應用已由單純的流程自動化，邁向「智慧預測與自主調度」，具體應用層面如下：

1. 時程與工作量估算（Schedule & Effort Estimation）

• 歷史數據導向之預測模型：利用機器學習迴歸演算法分析組織過往專案的程式碼規模、使用者故事（User Stories）複雜度與實際工時，自動校正估算偏差，提供比傳統三點估算法（PERT）更精確的時程機率分佈。
• 動態關鍵路徑最佳化：結合約束理論與遺傳演算法，即時監控專案相依性網絡，在任務發生延誤時，動態重算要徑並提供最佳化的趕工（Crashing）或快速跟進（Fast Tracking）排程方案。

2. 成本預測與掙值管理強化（Cost Forecasting & Enhanced EVM）

• 智慧 EVM 指標預測：傳統掙值管理仰賴線性外推完工尚需估算（$ETC$）與完工估算（$EAC$）。AI 模型可納入景氣波動、物料成本、人員流動率等非線性變數，建立非線性預測模型，精準預測預算超支風險。