本章是整本書的基礎，Robert C. Martin（Uncle Bob）從敏捷的歷史脈絡出發，解釋了 Agile 為何誕生、它的核心宣言是什麼，以及 Agile 專案管理的基本運作方式。理解這些根基，才能在後續章節中掌握各項實踐的意義。
Agile 的歷史#
「小步前進」是人類本能#
Agile 的核心概念——以小步驟前進、持續衡量進度、不斷修正方向——並非什麼革命性發明。從五萬年前人類協作完成目標開始，這就是最直覺的做事方式。早期軟體開發也是如此，例如 Mercury 太空艙的控制軟體團隊就採用半天為單位的迭代，並搭配單元測試。
Scientific Management 與 Waterfall 的崛起#
然而，軟體產業在 1970 年代走上了另一條路——Scientific Management（科學管理）。這套方法強調由上而下的指揮控制：先徹底分析問題、制定詳細計畫，然後嚴格執行。Frederick Winslow Taylor 在 1880 年代將其商業化，在製造業取得了巨大成功。
1970 年，Winston Royce 發表了一篇關於大型軟體專案管理的論文，其中包含一張著名的階梯式流程圖。諷刺的是，Royce 本人並非在提倡這個流程——那張圖只是他用來批判的稻草人。但人們只看了前兩頁的圖，就把它當成了標準做法。因為圖形看起來像水流過一系列岩石，這個方法被稱為 Waterfall（瀑布式開發）。
Figure 1.1: Winston Royce's diagram that inspired Waterfall development
Waterfall 為什麼失敗#
Waterfall 的概念聽起來很合理：先分析、再設計、最後實作。但在軟體開發中，這套方法在接下來的三十年裡反覆失敗。原因很簡單：
- 需求從不固定：客戶自己也不完全清楚想要什麼，需求持續變動
- 分析和設計沒有明確的完成標準：團隊往往「因為時間到了」就宣布完成，而非真正做好
- 問題總在最後才爆發：直到實作階段（通常是截止日前兩週），才發現專案根本來不及
Uncle Bob 生動描述了典型的 Waterfall 專案：老闆在會議中拍板六個月的時程，團隊在分析和設計階段「假裝完成」，最終在實作階段陷入 Death March（死亡行軍）——瘋狂加班、品質崩壞、交付延遲。他稱這種「下次做更多分析和設計」的反應為 Runaway Process Inflation（失控的流程膨脹）。
Agile 的覺醒（1990 年代）#
儘管 Waterfall 主導了思維，改變的種子仍然萌芽：
- 1980s 末～ 1991：Smalltalk 社群開始出現敏捷跡象；Grady Booch 的 OOD 書籍中有相關暗示；Alistair Cockburn 提出 Crystal Methods
- 1994：Design Patterns 社群受到 James Coplien 論文啟發，開始討論替代方案
- 1995：Schwaber、Sutherland 等人發表了 Scrum 論文，Waterfall 的堡壘被正式突破
- 1999：Robert C. Martin 接觸到 Kent Beck 的 Extreme Programming（XP），深受啟發並與 Beck 合作開發 XP 課程
timeline
title Agile 的歷史演進
1970 : Royce 發表 Waterfall 論文
1980s~1991 : Smalltalk 社群敏捷跡象
: Crystal Methods 提出
1994 : Design Patterns 社群討論替代方案
1995 : Scrum 論文發表
1999 : Kent Beck 發表 XP
2001 : Snowbird 會議
: Agile Manifesto 誕生Snowbird 會議與敏捷宣言的誕生#
2001 年 2 月，Robert C. Martin 與 Martin Fowler 在芝加哥的咖啡店策劃了一場會議，邀請各家輕量級流程的倡導者齊聚一堂。Alistair Cockburn 協助安排了猶他州 Snowbird 滑雪度假村作為會場。
17 位軟體專家帶著不同背景出席，代表了 XP、Scrum、Feature-Driven Development、DSDM、Crystal 等五種輕量級流程。令人驚訝的是，這群意見分歧的人竟然達成了共識。有人（可能是 Ward Cunningham 或 Martin Fowler）在白板上寫下了四組價值對比——這就是 Agile Manifesto（敏捷宣言） 的核心。
Uncle Bob 反覆強調：「Agile」這個名字並非眾人最愛的選項，只是「一堆壞選項中最不差的」。他自己偏好「Light Weight」，但其他人認為這暗示「無足輕重」。
敏捷宣言（The Agile Manifesto）#
敏捷宣言表達了四組核心價值偏好：
| 優先（左側） | 次要（右側） |
|---|---|
| 個人與互動（Individuals and interactions） | 流程與工具（Processes and tools） |
| 可運作的軟體（Working software） | 詳盡的文件（Comprehensive documentation） |
| 客戶協作（Customer collaboration） | 合約談判（Contract negotiation） |
| 回應變化（Responding to change） | 遵循計畫（Following a plan） |
宣言的措辭經過精心設計——右側的項目（流程、文件、合約、計畫）並非沒有價值，只是左側的項目在軟體開發中更為重要。這不是非黑即白的選擇，而是優先順序的宣告。
會後兩週，17 人透過反覆的郵件討論，完成了配套的 Principles（原則） 文件。這些原則的用意是確保四項價值觀不會淪為人人都能同意、卻不改變任何行為的「Mom and apple pie」口號。Ward Cunningham 建立了 agilemanifesto.org 網站並開放連署，敏捷運動由此正式展開。
Agile 概覽#
Iron Cross（鐵十字）——專案管理的物理定律#
所有專案都受制於一個不可違抗的權衡：Good（品質）、Fast（速度）、Cheap（成本）、Done（完成度）——四選三，第四個無法兼顧。
好的管理者不會要求四個面向都達到 100%，而是調整各面向的係數，追求「夠好、夠快、夠便宜、完成足夠多」。Agile 的目的就是提供數據，讓管理者做出理性的權衡決策。
Agile 本身不保證專案成功。它只是一個框架，幫助團隊產出管理所需的數據。在 Agile 框架下仍然完全可能因為糟糕的決策而導致專案失敗。
牆上的圖表——用數據取代希望#
Agile 團隊的核心武器是兩張圖表：
Velocity Chart（速度圖）：顯示團隊每次迭代完成的 Story Points。任何人只需看一眼就能判斷團隊的平均速度（例如每週約 45 點），進而預估未來的產出。
Figure 1.2: The team's velocity
Burn-down Chart（燃盡圖）：顯示距離下一個里程碑還剩多少點數。注意下降速度會比 Velocity 慢，因為開發過程中會持續發現新需求。燃盡圖的斜率可以預測里程碑的達成時間。
Figure 1.3: Burn-down chart
Hope is the project killer.（希望是專案的殺手。） Agile 的重要目標之一是「在希望殺死專案之前，先消滅希望」。Agile 不是為了更快開發，而是為了盡早知道我們的處境有多糟，好讓管理者及時做出應對。
迭代（Iteration）驅動的開發#
Agile 專案將時間切分為固定長度的 Iteration（迭代），通常為一到兩週。
Figure 1.4: The whole project
Iteration Zero 用來建立初始的 Story 清單、設置開發環境、進行初步估算和規劃。但關鍵在於：分析、設計和實作從不停止——整個專案期間，每個迭代都包含這三種活動。Agile 不是一系列的小 Waterfall。
數據驅動的計畫校正#
第一個迭代結束後，團隊得到了真實的數據：實際完成了多少 Story。這通常令人失望——幾乎不可能完成所有計畫的 Story。但這就是數據的價值。
Figure 1.5: Calculating the new end date
單一迭代的數據誤差範圍很大。經過四到五個迭代後，團隊的 Velocity 趨於穩定，對專案結束日期的預測也越來越準確。
Figure 1.6: More iterations mean a better idea of the project end date
管理 Iron Cross 的四種手段#
當數據顯示專案無法如期完成時，管理者有四種調整方式：
1. 調整時程（Schedule）：延後截止日。但日期通常基於商業理由（展會、股東會、資金到期），很少能改。
2. 增加人力（Staff）：直覺上「人多力量大」，但 Brooks’ Law 告訴我們——在延遲的專案中增加人手只會讓它更延遲。 新成員需要學習期，會暫時拖累原有團隊的生產力。
Figure 1.7: The actual effect of adding more members to the team
3. 降低品質（Quality）：停止寫測試、停止 Code Review、停止重構，瘋狂寫程式碼。這看似能加速，實際上是最糟的選擇。
The only way to go fast, is to go well.（唯一快的方法，就是做好。） 任何偷工減料都不會加速開發，只會讓速度變慢。品質不能降低，反而應該提高。
4. 調整範疇（Scope）：這是最務實的選擇。與利害關係人協商，哪些功能可以延後？在理性的組織中，數據終將勝過立場。利害關係人會被迫審視計畫，移除非必要的功能。
為了避免團隊實作了不重要的功能，Agile 要求每個迭代開始前由利害關係人決定優先順序——永遠先做最有商業價值的功能（Business Value Order）。
Circle of Life——XP 的實踐框架#
Ron Jeffries 繪製的 Circle of Life 圖展示了 Extreme Programming 的完整實踐體系。Uncle Bob 選擇以 XP 為本書核心，因為在所有 Agile 流程中，XP 定義最清楚、最完整、最不含糊。
Figure 1.8: The Circle of Life
Circle of Life 分為三個同心環：
外環：面向業務的實踐（Business-facing）#
這一層大致等同於 Scrum 的範疇：
| 實踐 | 說明 |
|---|---|
| Planning Game | 將專案拆解為 Feature、Story、Task，並進行估算、排序和排程 |
| Small Releases | 以小批量交付，縮短反饋週期 |
| Acceptance Tests | 為每個 Feature/Story 定義明確的完成標準 |
| Whole Team | 團隊包含程式設計師、測試人員、管理者等不同角色，共同朝同一目標努力 |
中環：面向團隊的實踐（Team-facing）#
這一層管理團隊的內部溝通與協作：
| 實踐 | 說明 |
|---|---|
| Sustainable Pace（可持續節奏） | 避免團隊燃燒殆盡，確保長期穩定的產出 |
| Collective Ownership（集體所有權） | 防止知識孤島，每個人都對整個程式碼庫負責 |
| Continuous Integration（持續整合） | 頻繁整合程式碼，隨時掌握系統狀態 |
| Metaphor（隱喻） | 建立團隊與業務共用的語彙和溝通語言 |
內環：面向技術的實踐（Technical）#
這一層確保最高的技術品質：
| 實踐 | 說明 |
|---|---|
| Pairing（結對程式設計） | 持續的知識分享、程式碼審查與協作 |
| Simple Design（簡單設計） | 避免過度工程，不做不需要的事 |
| Refactoring（重構） | 持續改善所有工作成果 |
| Test-Driven Development（TDD） | 技術團隊的安全繩——在維持最高品質的同時快速前進 |
mindmap
root((Circle of Life))
外環：業務實踐
Planning Game
Small Releases
Acceptance Tests
Whole Team
中環：團隊實踐
Sustainable Pace
Collective Ownership
Continuous Integration
Metaphor
內環：技術實踐
Pairing
Simple Design
Refactoring
TDD這三層實踐與敏捷宣言的四項價值觀緊密對應。例如「個人與互動」對應 Whole Team、Pairing、Sustainable Pace；「可運作的軟體」對應 TDD、Acceptance Tests、CI。但書中後續章節會揭示，這些連結遠比表面上更深刻。
結論#
Agile 是一個幫助小型軟體團隊管理小型專案的輕量框架。但這份「小」的意義深遠——因為所有大型專案，本質上都是由許多小專案組成的。
隨著軟體日益深入人類生活的每個層面，Agile 作為最能有效支撐軟體開發的方法論，其重要性只會持續增長。