敏捷專案管理指引

前言

敏捷專案管理的定義與重要性

敏捷專案管理（Agile Project Management）是一種以人為本、迭代式、增量式的專案管理方法論。它強調：

適應變化：擁抱需求變更，而非抗拒變化
快速交付：透過短週期迭代，頻繁交付可用的軟體或產品
客戶協作：與客戶密切合作，持續獲得回饋
團隊自主：授權團隊自我組織和決策

為什麼敏捷專案管理很重要？

市場快速變化：現今金融科技環境瞬息萬變，傳統瀑布式開發無法及時回應
客戶期望提升：客戶期待更快的上市時間和更高的產品品質
技術複雜度增加：現代系統整合度高，需要靈活的開發方式
法規環境變動：金融業法規頻繁更新，需要敏捷的回應機制

與傳統瀑布式開發的差異

比較項目	瀑布式開發	敏捷開發
開發流程	線性、順序性	迭代式、增量式
需求變更	後期變更成本高昂	擁抱變更，持續調整
客戶參與	專案初期和結尾	整個開發過程
交付頻率	專案結束時一次交付	每2-4週交付一次
風險管控	後期才發現問題	早期發現，快速調整
文件重點	詳盡的文件	可用的軟體
團隊結構	階層化管理	自我組織團隊

實務案例

某銀行數位轉型專案原採瀑布式開發，18個月後才發現市場需求已改變。改採敏捷開發後，每3週展示一次成果，第6個月就推出MVP（最小可行產品），成功搶占市場先機。

敏捷專案管理核心原則

Agile Manifesto 四大價值

敏捷宣言（Agile Manifesto）於2001年發布，奠定了敏捷開發的核心價值觀：

1. 個體與互動重於流程與工具

重點：人是專案成功的關鍵，良好的溝通比完美的工具更重要
實務應用：
- 每日站會面對面溝通
- 建立開放的工作環境
- 鼓勵團隊成員直接對話

2. 可用的軟體重於詳盡的文件

重點：以交付可用的產品為目標，而非完美的文件
實務應用：
- 專注於核心功能的實現
- 文件簡潔明瞭，以必要為準
- 透過實際產品驗證需求

3. 客戶協作重於合約談判

重點：與客戶建立夥伴關係，共同創造價值
實務應用：
- 客戶參與每次Sprint回顧
- 定期收集客戶回饋
- 調整產品方向以符合客戶真實需求

4. 回應變化重於遵循計劃

重點：靈活回應市場和需求變化
實務應用：
- 定期評估和調整專案優先級
- 建立彈性的開發架構
- 預留緩衝時間應對變更

敏捷十二項原則

最高優先級：透過早期和持續交付有價值的軟體來滿足客戶
歡迎需求變更：即使在開發後期也歡迎需求變更
頻繁交付：頻繁地交付可用的軟體，從幾週到幾個月
協同工作：業務人員和開發者必須在整個專案中每天協同工作
激發個體：圍繞被激發的個體構建專案，給他們所需的環境和支持
面對面溝通：在開發團隊中最有效的溝通方式是面對面的交談
可用軟體：可用的軟體是衡量進度的主要標準
可持續發展：敏捷流程提倡可持續的開發速度
技術卓越：持續關注技術卓越和良好設計會增強敏捷性
簡潔：簡潔——最大化未完成工作量的技藝——至關重要
自組織團隊：最好的架構、需求和設計來自自組織團隊
定期調整：團隊定期反思如何能變得更有效，然後調整行為

在金融/銀行專案中的適用性說明

適用場景

數位化轉型專案：線上銀行、行動APP開發
法規遵循系統：需要快速回應法規變更
客戶體驗改善：根據客戶回饋持續優化
創新產品開發：新金融商品或服務的探索

注意事項

法規要求：某些文件和審查流程不可省略
安全考量：資安測試和稽核需要充分時間
風險管控：金融業對風險敏感，需要適當的控制點
合規性：確保敏捷實踐符合內控制度

實務案例

某區域銀行開發客戶關係管理系統，採用Scrum方法：

Sprint長度：2週
團隊組成：產品負責人（業務）、Scrum Master（IT）、開發團隊6人
成果：原預計12個月的專案，8個月完成並上線，客戶滿意度提升30%

常用敏捷方法

Scrum 框架

Scrum是最廣泛使用的敏捷方法之一，特別適合複雜產品的開發。

Scrum 三大角色

產品負責人（Product Owner, PO）
- 職責：
  - 定義產品願景和策略
  - 管理產品待辦清單（Product Backlog）
  - 設定功能優先級
  - 接受或拒絕Sprint成果
- 技能要求：
  - 深度了解業務需求
  - 良好的溝通協調能力
  - 決策能力和商業敏銳度
Scrum Master
- 職責：
  - 促進Scrum流程的執行
  - 移除團隊障礙
  - 保護團隊免受外部干擾
  - 指導團隊持續改善
- 技能要求：
  - 敏捷教練技能
  - 衝突解決能力
  - 團隊建設經驗
開發團隊（Development Team）
- 特性：
  - 自我組織和跨功能
  - 規模通常為3-9人
  - 共同承擔Sprint目標
- 職責：
  - 估算工作量
  - 選擇Sprint內容
  - 交付潛在可發布的產品增量

Scrum 五大事件

Sprint
- 時間盒：1-4週（建議2週）
- 目的：創建可交付的產品增量
- 關鍵點：時間固定，範圍可調整
Sprint Planning（Sprint規劃會議）
- 時間：Sprint長度每週2小時（2週Sprint = 4小時）
- 參與者：全體Scrum團隊
- 產出：Sprint目標和Sprint Backlog
- 議程：
  - 檢視Product Backlog
  - 討論Sprint目標
  - 選擇Sprint Backlog項目
  - 制定實現計劃
Daily Scrum（每日站會）
- 時間：每天15分鐘
- 參與者：開發團隊為主
- 三個問題：
  - 昨天做了什麼？
  - 今天計劃做什麼？
  - 遇到什麼障礙？
Sprint Review（Sprint檢視會議）
- 時間：Sprint長度每週1小時
- 參與者：Scrum團隊 + 利害關係人
- 目的：展示Sprint成果，收集回饋
- 產出：更新的Product Backlog
Sprint Retrospective（Sprint回顧會議）
- 時間：Sprint長度每週45分鐘
- 參與者：Scrum團隊
- 目的：檢討流程，持續改善
- 格式：Stop-Start-Continue或其他回顧技巧

Scrum 三大產出物

Product Backlog（產品待辦清單）
- 定義：按優先級排序的功能清單
- 特性：動態調整、永不完成
- 內容：用戶故事、技術任務、缺陷修復
Sprint Backlog（Sprint待辦清單）
- 定義：Sprint期間要完成的工作
- 所有權：開發團隊
- 更新：Daily Scrum時更新進度
產品增量（Increment）
- 定義：Sprint結束時潛在可發布的產品
- 標準：符合完成定義（Definition of Done）
- 累積性：包含所有之前Sprint的成果

Kanban 方法

Kanban是一種視覺化的工作流程管理方法，強調持續流動和改善。

核心原則

視覺化工作流程
- 使用看板顯示所有工作項目
- 清楚標示工作狀態
限制在制品（WIP, Work in Progress）
- 設定每個階段的工作項目上限
- 避免多工處理，專注於完成
管理流動
- 監控工作項目的流動速度
- 識別和解決瓶頸

Kanban看板設計

基本的Kanban看板通常包含以下欄位：

待辦	進行中	測試中	完成
WIP限制：無	WIP限制：3	WIP限制：2	WIP限制：無
需求分析	開發功能A	測試功能B	功能C
功能設計	開發功能D		功能E
Bug修復	開發功能F

在制品限制（WIP Limits）

目的：避免同時處理太多工作
設定原則：
- 開始時設定較寬鬆的限制
- 觀察流動狀況後逐步調整
- 當達到WIP限制時，團隊應協助完成現有工作

關鍵指標

前置時間（Lead Time）：從提出需求到完成交付的時間
週期時間（Cycle Time）：從開始工作到完成的時間
吞吐量（Throughput）：單位時間內完成的工作項目數

混合模式（ScrumBan）

ScrumBan結合了Scrum和Kanban的優點，適用於維護型專案或需求變化頻繁的專案。

結合方式

從Scrum借用：
- Sprint的時間盒概念
- 角色定義（PO、SM、Team）
- 定期回顧會議
從Kanban借用：
- 視覺化看板
- WIP限制
- 持續流動

適用場景

維護和支援專案：需求不定期產生
研發專案：需求探索性強
過渡期間：從瀑布式轉向敏捷的中間階段

實務案例

某銀行IT維運團隊採用ScrumBan管理日常工作：

Sprint長度：1週
看板設計：緊急 | 待辦 | 分析中 | 開發中 | 測試中 | 完成
WIP限制：分析中(2) | 開發中(4) | 測試中(2)
效果：平均處理時間從5天縮短至3天，客戶滿意度提升25%

敏捷專案管理流程

需求收集與優先級排序

需求收集方法

用戶故事（User Stories）

格式：作為[角色]，我想要[功能]，以便[價值]

範例：

作為銀行客戶，我想要透過手機APP查詢帳戶餘額，
以便隨時掌握財務狀況而不用到分行排隊。

用戶故事地圖（User Story Mapping）
- 目的：視覺化整個用戶旅程
- 步驟：
  1. 識別用戶活動
  2. 分解為具體任務
  3. 排列優先順序
  4. 規劃發布版本
需求工作坊（Requirements Workshop）
- 參與者：產品負責人、業務專家、開發團隊
- 活動：腦力激盪、親和性分析、優先級投票

優先級排序技巧

MoSCoW方法
- Must have：必須具備
- Should have：應該具備
- Could have：可以具備
- Won’t have：不會具備
Kano模型
- 基本型需求：不滿足會導致客戶不滿
- 期望型需求：滿足程度與客戶滿意度成正比
- 興奮型需求：超出客戶期望的功能

價值vs複雜度矩陣

高價值低複雜度 → 快速執行
高價值高複雜度 → 重點專案
低價值低複雜度 → 填補空隙
低價值高複雜度 → 避免執行

Sprint 規劃流程

Sprint Planning詳細流程

會議前準備（Product Owner）

確保Product Backlog已整理並排序
準備Sprint目標草案
收集利害關係人回饋

會議進行（4小時示例 - 2週Sprint）

第一部分：What（2小時）
- 回顧上個Sprint成果
- 討論Sprint目標
- 選擇Sprint Backlog項目
- 確認團隊產能（Velocity）
第二部分：How（2小時）
- 分解用戶故事為具體任務
- 估算任務工作量（小時）
- 識別依賴關係和風險
- 確認Sprint承諾

Sprint目標範例

Sprint 12目標：
完成客戶身分驗證功能，包括：
- 實名制驗證API整合
- 人臉辨識功能
- 驗證結果通知機制
使客戶能夠在線上完成身分驗證流程。

每日站會最佳實踐

會議結構

時間：固定時間（例如每天上午9:00）
地點：固定地點或線上會議室
參與者：開發團隊為主，PO和SM可參與但不主導

三個問題的深入解析

昨天完成了什麼？
- 重點在「完成」，不是「做了」
- 對照Sprint目標的進展
今天計劃做什麼？
- 具體的工作項目
- 與團隊其他成員的協作
遇到什麼障礙？
- 技術難題
- 外部依賴
- 資源不足

常見問題與解決方案

問題	解決方案
會議時間過長	嚴格控制15分鐘，詳細討論會後進行
成員報告給Scrum Master	提醒這是團隊間的溝通，不是狀態匯報
討論技術細節	記錄問題，會後與相關人員討論
部分成員不參與	檢討團隊動機和承諾

Sprint Review實務指南

會議準備

Demo環境：確保展示環境穩定
邀請名單：相關利害關係人
展示腳本：準備展示流程和重點

會議進行

Sprint概述（10分鐘）
- Sprint目標回顧
- 完成vs未完成項目
功能展示（30-40分鐘）
- 實際操作展示
- 重點強調商業價值
收集回饋（15-20分鐘）
- 利害關係人提供意見
- 記錄新的需求或變更
下個Sprint預覽（5分鐘）
- 簡述下個Sprint方向

Sprint Retrospective回顧技巧

回顧會議格式

Stop-Start-Continue
- Stop：團隊應該停止做什麼？
- Start：團隊應該開始做什麼？
- Continue：團隊應該繼續做什麼？
Mad-Sad-Glad
- Mad：讓人生氣的事情
- Sad：讓人沮喪的事情
- Glad：讓人高興的事情
五個為什麼（5 Whys）
- 針對特定問題深入探討根本原因

改善行動計劃

SMART目標：具體、可測量、可達成、相關、有時限
負責人：明確指派改善行動的負責人
追蹤機制：下次回顧時檢視改善成效

待辦清單管理

Product Backlog管理

DEEP原則

Detailed appropriately：適當詳細程度
Emergent：持續演進
Estimated：已估算工作量
Prioritized：已排定優先級

Backlog精煉（Refinement）

頻率：每週1-2次，每次1-2小時
參與者：PO + 部分開發團隊成員
活動：
- 拆分大的用戶故事
- 更新估算
- 澄清需求細節
- 重新排序優先級

Sprint Backlog管理

任務板範例

┌─────────┬─────────┬─────────┬─────────┐
│ 待辦    │ 進行中  │ 完成    │ 驗收    │
├─────────┼─────────┼─────────┼─────────┤
│ 任務A   │ 任務B   │ 任務C   │ 任務D   │
│ 任務E   │ 任務F   │ 任務G   │         │
│         │         │         │         │
└─────────┴─────────┴─────────┴─────────┘

工作拆解與估時

用戶故事拆解原則

INVEST標準

Independent：獨立的
Negotiable：可協商的
Valuable：有價值的
Estimable：可估算的
Small：小的
Testable：可測試的

Story Points估算

估算相對大小

使用費氏數列：1, 2, 3, 5, 8, 13, 21…
基準故事：選擇一個中等複雜度的故事作為基準
相對比較：其他故事相對於基準故事的複雜度

Planning Poker流程

介紹故事：PO說明用戶故事
澄清問題：團隊提問，PO解答
個別估算：每人選擇一張卡片
同時亮牌：所有人同時顯示估算
討論差異：討論估算差異較大的原因
重新估算：達成共識

估算參考因素

技術複雜度：需要學習新技術？
工作量：需要多少開發時間？
風險程度：有多少未知因素？
依賴關係：需要等待其他團隊？

速度（Velocity）計算與預測

Velocity定義

團隊在一個Sprint中完成的Story Points總和。

計算方式

Velocity = Σ 已完成用戶故事的Story Points

速度預測

過去3個Sprint平均：適用於穩定團隊
趨勢分析：考慮團隊成長或變化
季節性調整：考慮假期或特殊情況

實務範例

某團隊速度記錄：

Sprint 8: 23 點
Sprint 9: 27 點
Sprint 10: 25 點
平均速度: 25 點
下個Sprint預估產能: 25 ± 3 點

敏捷工具與實務應用

Jira 使用要點

專案設定

敏捷專案建立

選擇Scrum或Kanban模板
設定Sprint長度（建議2週）
配置問題類型：Story、Task、Bug、Epic
建立自訂欄位（如Story Points、業務價值）

工作流程設定

待辦 → 進行中 → Code Review → 測試中 → 驗收 → 完成

Backlog管理

Epic管理

用於大型功能或業務目標
包含多個相關的User Story
追蹤長期進度

Story管理

使用Story Points估算
設定接受標準（Acceptance Criteria）
連結至相關Epic

Sprint管理

使用Sprint Planning功能
透過燃盡圖追蹤進度
定期更新剩餘工作

報表與儀表板

關鍵報表

燃盡圖（Burndown Chart）：追蹤Sprint進度
速度圖（Velocity Chart）：團隊產能趨勢
累積流量圖（Cumulative Flow Diagram）：工作流程分析
Epic燃盡圖：長期目標追蹤

Trello 簡易敏捷實踐

看板設計

基本敏捷看板

產品待辦 | Sprint待辦 | 進行中 | Code Review | 測試 | 完成

進階看板（ScrumBan）

待分析 | 準備就緒 | 開發中 | 測試中 | 部署中 | 完成 | 回顧

卡片管理

卡片內容

標題：簡潔描述功能
描述：用戶故事格式
檢核清單：任務分解
截止日期：Sprint結束日
標籤：優先級、類型

Power-Ups推薦

Voting：優先級投票
Burndown：燃盡圖
Time Tracking：時間追蹤

Azure DevOps 整合實踐

專案結構

Area Path設定

專案根目錄
├── 前端團隊
├── 後端團隊
├── 測試團隊
└── DevOps團隊

Iteration Path設定

發布計劃
├── Sprint 1 (2024/01/01 - 2024/01/14)
├── Sprint 2 (2024/01/15 - 2024/01/28)
└── Sprint 3 (2024/01/29 - 2024/02/11)

Work Item設定

階層結構

Epic (業務目標)
└── Feature (大功能)
    └── User Story (用戶故事)
        └── Task (開發任務)

與Git整合

分支策略

main (主分支)
├── develop (開發分支)
├── feature/US001-login (功能分支)
└── hotfix/BUG001-security (修復分支)

Pull Request流程

建立功能分支
提交Pull Request
代碼審查
自動化測試
合併至develop

團隊協作技巧與溝通模式

高效團隊特徵

心理安全感（Psychological Safety）

鼓勵提出問題和意見
容忍失敗，從錯誤中學習
開放透明的溝通環境

共同目標

清楚的Sprint目標
一致的完成定義
共享的成功標準

互補技能

跨功能團隊組成
知識分享機制
配對程式設計

溝通最佳實踐

會議效率提升

明確議程：會前發送議程和準備材料
時間控制：嚴格遵守時間盒
行動項目：會議結束前確認行動項目和負責人
會議記錄：記錄決議和行動項目

遠距協作

工具選擇：統一使用的協作工具
時區考量：跨時區團隊的會議安排
非同步溝通：重要資訊的文件化

衝突解決

早期識別：觀察團隊動態，及早發現問題
開放對話：創造安全的討論環境
聚焦問題：針對問題本身，避免人身攻擊
尋求共識：找到雙贏的解決方案

與利害關係人互動的策略

利害關係人分析

利害關係人地圖

高影響力 + 高興趣 → 密切管理（高階主管）
高影響力 + 低興趣 → 讓其滿意（法遵部門）
低影響力 + 高興趣 → 隨時告知（終端用戶）
低影響力 + 低興趣 → 監控即可（其他部門）

溝通計劃

溝通頻率矩陣

利害關係人	溝通方式	頻率	內容
專案贊助人	面對面會議	每月	專案狀態、重大決策
產品負責人	Daily + Sprint會議	每日/每Sprint	需求澄清、優先級
終端用戶	Demo + 回饋會議	每Sprint	功能展示、使用回饋
技術架構師	技術會議	每週	技術決策、架構討論

期望管理

RACI矩陣

Responsible：負責執行
Accountable：承擔責任
Consulted：需要諮詢
Informed：需要告知

變更管理

變更請求：正式的變更請求流程
影響評估：評估變更對時程、成本、範圍的影響
決策會議：利害關係人共同決策
溝通變更：及時傳達變更決定

產品展示技巧

準備階段

環境檢查：確保展示環境穩定
腳本準備：規劃展示流程和重點
備案計劃：準備展示失敗的應對方案

展示技巧

商業價值導向：強調對業務的價值
用戶視角：從用戶的角度展示功能
互動參與：邀請利害關係人親自操作
收集回饋：積極記錄和回應意見

實務案例：銀行數位專案

某銀行手機APP改版專案的利害關係人管理：

專案背景

專案期間：6個月
團隊規模：15人
主要利害關係人：分行經理、客戶代表、IT部門、法遵部門

溝通策略

高階主管：每月董事會報告
分行經理：每兩週功能展示
客戶代表：每Sprint用戶測試
法遵部門：每次發布前合規檢查

成果

按時交付，功能滿意度95%
客戶使用率較舊版提升40%
獲得年度最佳數位創新獎

敏捷專案管理在銀行系統的特別注意事項

法規與稽核配合

法規遵循要求

重要法規

個人資料保護法：客戶資料處理和保護
資通安全管理法：系統安全要求
洗錢防制法：客戶身分確認和交易監控
金融控股公司法：集團內部控制

敏捷實踐中的法規考量

文件要求
- 保留必要的設計文件
- 記錄重要決策過程
- 建立變更追蹤機制
審查流程
- 整合法遵審查至Sprint Review
- 設立法規檢核點（Compliance Gate）
- 建立法遵人員與開發團隊的溝通機制

稽核準備

稽核文件清單

專案章程和範圍說明
需求變更記錄
測試計劃和執行結果
風險評估和控制措施
程式碼審查記錄

敏捷稽核策略

傳統稽核 → 敏捷稽核
━━━━━━━━━━━━━━━━━━━━━
專案結束時稽核 → 持續稽核
完整文件審查 → 抽樣審查
瀑布式流程 → 迭代式檢查
一次性稽核 → 風險導向稽核

實務建議

法遵團隊整合

法遵代表參與Sprint Planning
設立法遵用戶故事
建立法遵知識庫

風險管理

每個Sprint進行風險評估
建立風險處理追蹤表
定期更新風險登錄簿

敏感資料安全與保密要求

資料分類與保護

資料分級

機密等級    |  處理要求        |  存取控制
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
極機密      |  加密存儲        |  需要授權
機密        |  安全傳輸        |  角色控制  
內部使用    |  存取記錄        |  部門控制
公開        |  一般處理        |  無限制

開發環境安全

環境分離

開發環境：假資料或遮蔽資料
測試環境：部分真實資料（遮蔽敏感欄位）
生產環境：完整真實資料

資料遮蔽技術

靜態遮蔽：開發/測試環境使用假資料
動態遮蔽：即時遮蔽敏感資訊
代碼化：將敏感資料轉換為代碼

安全開發實踐

Secure SDLC整合

需求階段：安全需求分析
設計階段：威脅建模
開發階段：安全編碼
測試階段：安全測試
部署階段：安全配置

DevSecOps實踐

開發 → 安全檢查 → 測試 → 安全掃描 → 部署

跨部門溝通與外包管理

跨部門協作挑戰

常見部門

IT部門：技術實現
業務部門：需求提供
法遵部門：合規審查
風險管理：風險評估
資安部門：安全審查

外包管理策略

外包團隊整合

統一工具：使用相同的專案管理工具
共同儀式：參與Scrum儀式
文化融合：建立共同的工作文化
知識轉移：確保知識不流失

品質控制

代碼審查：所有外包代碼必須審查
架構一致性：遵循統一的架構標準
測試要求：達到預定的測試覆蓋率

溝通機制設計

多層次溝通

戰略層 → 高階主管月會
戰術層 → 部門主管週會  
執行層 → 團隊每日站會

跨部門Sprint Review

邀請所有相關部門代表
展示業務價值而非技術細節
收集各部門回饋和需求

銀行系統特有挑戶

高可用性要求

系統可用性目標

99.9%：一般業務系統（年停機時間 < 8.76小時）
99.95%：重要業務系統（年停機時間 < 4.38小時）
99.99%：核心業務系統（年停機時間 < 52.56分鐘）

敏捷實踐調整

藍綠部署：降低部署風險
漸進式發布：功能開關控制
回滾計劃：快速回復機制

效能要求

效能指標

回應時間：< 3秒
並發用戶：> 10,000
交易處理量：> 1,000 TPS

效能測試整合

每個Sprint進行效能測試
建立效能基準線
持續監控效能指標

資料一致性

ACID特性保證

原子性：交易要麼全部成功，要麼全部失敗
一致性：資料庫始終保持一致狀態
隔離性：並發交易不互相影響
持久性：已提交的交易永久保存

分散式系統考量

最終一致性：允許短暫的不一致
補償機制：失敗時的回復策略
冪等設計：重複執行不會產生副作用

常見問題與解決策略（FAQ）

團隊抗拒敏捷

常見抗拒原因

管理層面

擔心失去控制權
不相信團隊自主能力
習慣詳細的計劃和報告

開發層面

害怕頻繁的會議
擔心需求變更過多
不熟悉敏捷實踐

文化層面

傳統的階層文化
避免風險的心態
個人績效導向

解決策略

漸進式轉型

從小團隊開始：選擇開放度高的團隊試點
混合模式：保留部分傳統做法
成功案例分享：展示敏捷的成功效果
培訓和指導：提供充分的培訓支持

管理層說服

商業價值展示：用數據證明敏捷的效益
風險降低：強調敏捷如何降低專案風險
競爭優勢：說明敏捷對市場競爭的重要性

文化改變

心理安全環境：建立容錯的文化
團隊建設活動：增強團隊凝聚力
個人發展計劃：提供成長機會

實務案例

某銀行IT部門敏捷轉型經驗：

挑戰

200人的IT團隊
20年的瀑布式開發經驗
強烈的文件導向文化

策略

選擇5個人的創新團隊作為試點
保留原有的里程碑報告
每月分享試點團隊的成功經驗

成果

6個月後，50%的團隊主動要求轉換
專案交付時間平均縮短30%
客戶滿意度從60%提升到85%

需求變動過於頻繁

問題分析

變動原因

市場環境快速變化
客戶需求不明確
競爭對手推出新功能
法規政策變更

影響評估

團隊士氣下降
開發效率降低
技術債務增加
專案時程延遲

應對策略

需求管理機制

變更控制流程
- 評估變更影響
- 計算變更成本
- 利害關係人決策
優先級管理
- MoSCoW方法排序
- 商業價值評估
- 技術複雜度考量
Sprint保護機制
- Sprint期間不接受新需求
- 緊急需求走特殊流程
- 下個Sprint才考慮變更

產品負責人培訓

需求分析技巧：如何挖掘真實需求
優先級設定：如何平衡各方需求
溝通技巧：如何說服利害關係人

技術應對

架構設計

模組化設計：降低變更影響範圍
介面標準化：減少系統間耦合
配置參數化：透過配置調整行為

開發實踐

測試驅動開發：確保變更不破壞現有功能
持續重構：保持代碼品質
功能開關：控制功能的啟用和停用

開發與業務優先級衝突

衝突情況

典型衝突

業務要求新功能 vs 技術要求重構
短期交付壓力 vs 長期技術穩定
功能完整性 vs 技術債務清理
用戶體驗 vs 系統效能

解決方法

建立共同語言

技術債務可視化
- 用業務語言解釋技術風險
- 量化技術債務的成本
- 展示長期影響
價值導向對話
- 技術決策的業務價值
- 風險和機會的平衡
- 長短期效益分析

協商機制

定期技術債務Sprint：每4-5個Sprint安排一個技術Sprint
20%技術時間：每個Sprint 20%時間用於技術改善
技術故事：將技術需求包裝成用戶故事

決策框架

技術決策矩陣

影響 \ 急迫性  |  高急迫  |  低急迫
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
高影響        |  立即處理 |  計劃處理  
低影響        |  快速處理 |  暫緩處理

投資組合平衡

70%：業務功能開發
20%：技術債務清理
10%：創新實驗

成功案例

某金融科技公司的經驗：

問題

業務團隊要求快速上線新產品
技術團隊擔心系統穩定性
雙方經常發生爭執

解決方案

建立技術風險儀表板
每月技術債務報告會議
技術負責人參與產品規劃

結果

技術故障率從5%降至1%
新功能開發速度提升20%
團隊合作滿意度顯著改善

敏捷規模化挑戰

大型專案挑戰

協調複雜度

多個團隊間的依賴
統一的架構標準
一致的交付節奏

常見問題

團隊間溝通不足
重複開發
整合困難

規模化框架

SAFe (Scaled Agile Framework)

團隊層級：Scrum團隊
程序層級：敏捷發布火車
組合層級：價值流

LeSS (Large-Scale Scrum)

保持Scrum的簡潔性
多團隊共享Product Backlog
統一的Sprint週期

實施建議

組織結構調整

功能導向團隊：按業務功能組織
跨功能技能：減少團隊間依賴
共享服務：避免重複開發

技術架構

微服務架構：減少團隊間技術依賴
API優先：標準化團隊間介面
持續整合：頻繁整合各團隊成果

結論與建議

如何在不同規模專案中靈活應用敏捷

小型專案（5人以下團隊）

建議實踐

簡化儀式：縮短會議時間，合併部分會議
輕量工具：使用Trello或簡單的看板
角色兼任：PO和SM可由同一人擔任
非正式溝通：面對面交談替代正式會議

範例配置

團隊規模：3-5人
Sprint長度：1週
Daily Scrum：10分鐘
Sprint Planning：1小時
Sprint Review：30分鐘
Sprint Retrospective：30分鐘

中型專案（5-20人團隊）

建議實踐

標準Scrum：完整實施Scrum框架
跨功能團隊：包含開發、測試、UI/UX
工具整合：使用Jira等專業工具
定期培訓：持續提升團隊敏捷技能

組織架構

產品負責人 (1人)
Scrum Master (1人)  
開發團隊 (6-8人)
  ├── 前端開發 (2-3人)
  ├── 後端開發 (2-3人)
  ├── 測試人員 (1-2人)
  └── UI/UX設計 (1人)

大型專案（20人以上團隊）

建議實踐

規模化框架：採用SAFe或LeSS
多層級協調：建立不同層級的同步機制
架構治理：統一技術標準和架構決策
持續整合：自動化測試和部署

組織模式

發布火車 (80-125人)
├── 系統團隊
├── 敏捷團隊1 (8-12人)
├── 敏捷團隊2 (8-12人)
├── 敏捷團隊3 (8-12人)
└── 共享服務團隊

專案類型適配

新產品開發

重視MVP和用戶回饋
頻繁的市場驗證
彈性的需求調整

既有系統維護

採用Kanban或ScrumBan
重視技術債務管理
穩定的發布節奏

合規驅動專案

保留必要的文件
整合稽核檢查點
風險導向的開發

新進PM的學習資源清單

必讀書籍

敏捷基礎

《敏捷軟體開發：原則、實務與模式》 - Robert C. Martin
- 敏捷開發的基本概念和實踐
- 適合初學者理解敏捷思維
《Scrum：用一半的時間做兩倍的事》 - Jeff Sutherland
- Scrum框架的詳細說明
- 豐富的實務案例
《使用者故事對照》 - Jeff Patton
- 用戶故事的寫作技巧
- 需求管理的最佳實踐

進階學習 4. 《精實開發與看板方法》 - Mary Poppendieck

精實思維在軟體開發中的應用
Kanban方法的深入探討

《敏捷教練》 - Lyssa Adkins
- 如何成為優秀的Scrum Master
- 團隊指導和組織變革
《規模化敏捷》 - Dean Leffingwell
- SAFe框架的完整指南
- 大型組織的敏捷轉型

線上資源

官方網站

Scrum.org：https://www.scrum.org/
- Scrum指南和認證資訊
Agile Alliance：https://www.agilealliance.org/
- 敏捷社群和最佳實踐
Scaled Agile：https://scaledagile.com/
- SAFe框架和培訓資源

學習平台

Coursera：敏捷專案管理專項課程
edX：MIT的敏捷開發課程
Pluralsight：技術導向的敏捷課程
LinkedIn Learning：商業導向的敏捷課程

中文資源

敏捷台灣：https://agile.tw/
- 台灣敏捷社群
敏捷中國：http://www.agilechinese.com/
- 中國敏捷實踐分享

認證建議

初級認證

Certified ScrumMaster (CSM)
- 入門級Scrum認證
- 2天培訓 + 線上考試
Professional Scrum Master I (PSM I)
- Scrum.org的認證
- 可自學參加考試

進階認證 3. Certified Scrum Product Owner (CSPO)

產品負責人認證
適合業務背景的PM

SAFe Agilist (SA)
- 規模化敏捷認證
- 適合大型組織

實踐社群

台灣敏捷社群

敏捷台灣聚會：每月定期聚會
Scrum Gathering Taipei：年度大會
各大學敏捷讀書會：學術交流

線上社群

LinkedIn敏捷群組：國際交流
Facebook敏捷社團：經驗分享
Slack工作空間：即時討論

持續學習建議

實踐導向

從小做起：在目前工作中嘗試敏捷實踐
觀察學習：參與其他敏捷團隊的會議
回饋改善：定期反思和調整實踐方式

知識更新

訂閱部落格：追蹤敏捷專家的最新觀點
參加會議：年度敏捷大會和研討會
網路課程：持續學習新的敏捷實踐

經驗分享

撰寫部落格：記錄實踐經驗和心得
社群分享：在敏捷聚會中分享經驗
內部培訓：在組織內推廣敏捷實踐

成功實施敏捷的關鍵要素

組織文化

信任文化：相信團隊有能力自我管理
學習文化：鼓勵實驗和從失敗中學習
透明文化：開放分享資訊和問題

領導支持

高階支持：管理層的明確支持和投入
資源投入：提供必要的培訓和工具
耐心等待：給予團隊足夠的轉型時間

團隊能力

跨功能技能：減少對外部依賴
自我組織：團隊有能力自主決策
持續改善：主動尋求改善機會

客戶參與

積極參與：客戶願意投入時間參與專案
及時回饋：快速提供功能回饋
彈性需求：接受需求的演進和調整

參考資料

官方文件

Agile Manifesto：http://agilemanifesto.org/
- 敏捷宣言原文
Scrum Guide：https://scrumguides.org/
- Scrum官方指南
Kanban Guide：https://kanbanguides.org/
- Kanban方法指南

學術研究

“The Impact of Agile Practices on Software Quality” - IEEE Software
“Agile Software Development in the Large” - ACM Computing Surveys
“Success Factors for Agile Software Development Projects” - Journal of Software Engineering

產業報告

State of Agile Report - VersionOne/CollabNet
- 年度敏捷實踐調查報告
Project Management Institute Pulse Report
- 專案管理趨勢報告
Deloitte Tech Trends
- 技術趨勢和敏捷實踐

工具文件

Jira Agile Tutorial：https://www.atlassian.com/agile/tutorials
Azure DevOps Agile Process：https://docs.microsoft.com/en-us/azure/devops/
Trello Agile Workflow：https://trello.com/teams/agile

培訓機構

Scrum Alliance：https://www.scrumalliance.org/
Scrum.org：https://www.scrum.org/
Scaled Agile Framework：https://scaledagile.com/
敏捷台灣：https://agile.tw/

本指引文件版本：v1.0
最後更新日期：2025年8月13日
文件維護：專案管理辦公室

如有任何疑問或建議，請聯繫專案管理辦公室或參與敏捷社群討論。

敏捷專案管理指引#

目錄#

前言#

敏捷專案管理的定義與重要性#

為什麼敏捷專案管理很重要？#

與傳統瀑布式開發的差異#

實務案例#

敏捷專案管理核心原則#

Agile Manifesto 四大價值#

1. 個體與互動 重於 流程與工具#

2. 可用的軟體 重於 詳盡的文件#

3. 客戶協作 重於 合約談判#

4. 回應變化 重於 遵循計劃#

敏捷十二項原則#

在金融/銀行專案中的適用性說明#

適用場景#

注意事項#

實務案例#

常用敏捷方法#

Scrum 框架#

Scrum 三大角色#

Scrum 五大事件#

Scrum 三大產出物#

Kanban 方法#

核心原則#

Kanban看板設計#

在制品限制（WIP Limits）#

關鍵指標#

混合模式（ScrumBan）#

結合方式#

適用場景#

實務案例#

敏捷專案管理流程#

需求收集與優先級排序#

需求收集方法#

優先級排序技巧#

Sprint 規劃流程#

Sprint Planning詳細流程#

Sprint目標範例#

每日站會最佳實踐#

會議結構#

三個問題的深入解析#

常見問題與解決方案#

Sprint Review實務指南#

會議準備#

會議進行#

Sprint Retrospective回顧技巧#

回顧會議格式#

改善行動計劃#

待辦清單管理#

Product Backlog管理#

Sprint Backlog管理#

工作拆解與估時#

用戶故事拆解原則#

Story Points估算#

Planning Poker流程#

估算參考因素#

速度（Velocity）計算與預測#

Velocity定義#

計算方式#

速度預測#

實務範例#

敏捷工具與實務應用#

Jira 使用要點#

專案設定#

Backlog管理#

報表與儀表板#

Trello 簡易敏捷實踐#

看板設計#

卡片管理#

Azure DevOps 整合實踐#

專案結構#

Work Item設定#

與Git整合#

團隊協作技巧與溝通模式#

高效團隊特徵#

溝通最佳實踐#

與利害關係人互動的策略#

利害關係人分析#

溝通計劃#

敏捷專案管理指引

目錄

前言

敏捷專案管理的定義與重要性

為什麼敏捷專案管理很重要？

與傳統瀑布式開發的差異

實務案例

敏捷專案管理核心原則

Agile Manifesto 四大價值

1. 個體與互動重於流程與工具

2. 可用的軟體重於詳盡的文件

3. 客戶協作重於合約談判

4. 回應變化重於遵循計劃

敏捷十二項原則

在金融/銀行專案中的適用性說明

適用場景

注意事項

實務案例

常用敏捷方法

Scrum 框架

Scrum 三大角色

Scrum 五大事件

Scrum 三大產出物

Kanban 方法

核心原則

Kanban看板設計

在制品限制（WIP Limits）

關鍵指標

混合模式（ScrumBan）

結合方式

適用場景

實務案例

敏捷專案管理流程

需求收集與優先級排序

需求收集方法

優先級排序技巧

Sprint 規劃流程

Sprint Planning詳細流程

Sprint目標範例

每日站會最佳實踐

會議結構

三個問題的深入解析

常見問題與解決方案

Sprint Review實務指南

會議準備

會議進行

Sprint Retrospective回顧技巧

回顧會議格式

改善行動計劃

待辦清單管理

Product Backlog管理

Sprint Backlog管理

工作拆解與估時

用戶故事拆解原則

Story Points估算

Planning Poker流程

估算參考因素

速度（Velocity）計算與預測

Velocity定義

計算方式

速度預測

實務範例

敏捷工具與實務應用

Jira 使用要點

專案設定

Backlog管理

報表與儀表板

Trello 簡易敏捷實踐

看板設計

卡片管理

Azure DevOps 整合實踐

專案結構

Work Item設定

與Git整合

團隊協作技巧與溝通模式

高效團隊特徵

溝通最佳實踐

與利害關係人互動的策略

利害關係人分析

溝通計劃