Becoming Agile#

Bob Martin 一開始接觸 XP 時覺得「有什麼難的？照著幾個簡單的紀律做就好了」。但現實是，無數組織嘗試導入 Agile 卻失敗了。失敗的根本原因往往不在技術，而在於組織對 Agile 的認知偏差——把 Agile 想成了它不是的東西。

Agile Values（敏捷價值觀）#

Kent Beck 很早就提出了 Agile 的四大價值觀：Courage、Communication、Feedback、Simplicity。

Courage（勇氣）#

勇氣是指合理程度的冒險，不是魯莽
Agile 團隊不會因為追求政治安全而犧牲品質與機會
勇氣的展現：部署最小可行功能集、堅持高品質程式碼與紀律
魯莽的行為：對品質沒有信心就部署、為了趕進度而犧牲品質
「品質與紀律能加速開發」這個信念本身就需要勇氣，因為它會不斷受到急躁的人挑戰

Communication（溝通）#

重視直接、頻繁、跨角色的溝通
程式設計師、客戶、測試人員、管理者應該坐在一起、經常互動
不只是靠會議、Email 或即時通訊，更要有面對面的非正式對話
團隊的默契（gel）就是在這種高頻、混亂、非正式的互動中產生的

Feedback（回饋）#

Agile 的大多數紀律都圍繞著快速回饋而設計
Planning Game、Refactoring、TDD、CI、Small Releases、Collective Ownership 等做法，都是為了最大化回饋的頻率與數量
回饋讓團隊能在錯誤還小的時候就發現並修正，驅動專案走向好的結果

Simplicity（簡單）#

簡單 = 直接（directness），無論是在程式碼還是在團隊行為上
軟體界常說「每個問題都能靠多加一層 indirection 解決」，但 Agile 的價值觀是盡量減少 indirection
被動攻擊（Passive aggression）是一種 indirection——發現問題卻沉默、明知後果嚴重卻不說
程式碼需要一定程度的 indirection 來管理耦合，但團隊溝通上應該盡可能直接

Bob 的結論：Keep the code simple. Keep the team simpler.

The Menagerie（方法動物園）#

市面上有各式各樣的 Agile 方法（XP、Scrum 等上千種），但 Bob 的建議很簡單：

不必糾結選哪個方法——最終你都會根據自身需求微調流程，殊途同歸
最關鍵的是要採用完整的 Circle of Life，尤其是技術實踐（Technical Practices）
很多團隊只採用外圈的業務實踐，結果落入 Martin Fowler 所稱的 Flaccid Scrum 陷阱——初期生產力很高，但隨著程式碼腐化，生產力急速下降
Agile 的業務實踐是一種極度高效地製造巨大混亂的方式——如果你不同時維護程式碼的整潔，這些混亂會拖垮整個專案

不要只做半套 Agile。業務實踐若缺少技術實踐的支撐，只會更快地把程式碼搞爛。

Transformation（轉型）#

價值觀的根本衝突#

從非 Agile 轉型到 Agile，本質上是一場價值觀的轉變。Agile 強調冒險、快速回饋、高頻溝通、打破層級壁壘；但大型組織的中階管理層（middle management）卻是為了安全、一致性、指揮控制、計畫執行而存在的。

Bob 的觀察：

高層主管通常認同 Agile 的價值觀（這就是為什麼他們會啟動轉型）
基層開發者的價值觀也與 Agile 天然對齊
障礙在中間——中階管理層的工作本質就是抵抗這種改變

flowchart TD
    A["高層主管<br>認同 Agile 價值觀"] -->|啟動轉型| B["中階管理層<br>安全、控制、計畫執行"]
    B -->|抵抗改變| C["基層開發者<br>與 Agile 天然對齊"]
    style B fill:#f96,stroke:#333

三個轉型故事#

The Subterfuge（暗中破壞）：一個 2000 年的案例中，高層和開發者都支持轉型，但技術主管和架構師誤以為 Agile 會削弱他們的角色，於是秘密策劃破壞行動。最終被發現後遭到解僱，但轉型也沒能成功。

The Lion Cubs（幼獅效應）：某部門成功導入 XP 多年，成果卓越到被 Computerworld 報導，帶領轉型的 VP 因此升遷。新 VP 上任後，像雄獅取代舊領袖一樣「殺掉前任的所有成果」，直接終結 Agile，團隊紛紛離職。

Weeping（崩潰痛哭）：2003 年在一家知名券商進行的 Agile 轉型，一切看似順利。在最終評估會議上，有人突然在後排哭了起來，接著情緒支撐崩塌，人們紛紛說「太難了，撐不下去」，高層於是終止轉型。

Bob 對這些故事的結論：“Expect something weird to happen."（預期會有奇怪的事情發生。）

Faking It（偷偷做 Agile）#

有些團隊在中階管理層反對 Agile 的組織裡，採取 Booch 和 Parnas 所說的 “faking it” 策略：

暗地裡用 Agile 的方式開發，但表面上提供中階管理層要求的所有文件和流程
例如：管理層要分析文件，團隊就在前幾個 iteration 用 Agile 方式分析需求（實際上在寫程式碼），然後排幾個 documentation story 來產出文件
風險在於，如果被發現是「假裝的」，管理層可能會強行移除 Agile 紀律

哪裡容易成功？#

組織規模	說明
小型組織	沒有中階管理層，高層與開發者價值觀一致，最容易全面導入
中型組織	如果中階管理層是從基層升上來、仍保有直接與冒險的心態，有機會成功
大型組織	Bob 認為應該是 create（創建）而非 transform（轉型）——就像 IBM 當年為了開發 PC 而另設一個全新的組織單位，而不是改造既有組織
個人層級	接受 Agile 價值觀的個人若待在反 Agile 的環境中會很不適應，最終往往會遷移到認同 Agile 的公司

Coaching（教練）#

Trainer vs. Coach#

Bob 對 Agile Coaching 的看法偏保守：

Agile Trainer（訓練師）：來自外部，短期（一到兩週）教團隊 Agile 的價值觀與紀律，然後離開
Agile Coach（教練）：來自團隊內部的成員，在開發過程中守護流程
- 當團隊在壓力下偏離紀律時（停止 pairing、不 refactoring、忽略 CI 失敗），Coach 負責提醒
- 角色像是團隊的良心，提醒大家自己許下的承諾
- 這個角色通常在團隊成員間輪流擔任，成熟的團隊甚至不需要
- Coach 不是管理者、不負責預算與排程、不對外代表團隊

Scrum Master 的問題#

Scrum 把 Coach 稱為 Scrum Master，這個頭銜的發明既是好事也是壞事
認證機制吸引了大量 Project Manager，增加了 Agile 的知名度
但也導致 Coach 角色與 Project Manager 角色被混為一談
現在很多 Scrum Master 根本不是 Coach，只是換了個頭銜的 PM

Certification（認證）#

Bob 的態度非常直接：現有的 Agile 認證毫無意義。

認證機構只保證你付了錢、（可能）參加了兩天的課程，不保證你能當好 Coach
認證製造了「Certified Scrum Master 有特殊能力」的荒謬暗示
培訓課程本身可能有價值，但不應該只訓練一個人——團隊每個成員都該接受訓練

真正的認證應該是什麼？#

Bob 認為有意義的認證應該包含：

一整個學期的課程
包括 Agile 訓練與實際督導下的 Agile 專案開發
嚴格評分，學生必須證明理解 Agile 價值觀並能熟練執行 Agile 紀律

Agile in the Large（大規模敏捷）#

這是 Bob Martin 在本章中表達最強烈觀點的段落。

Bob 的核心論點#

Agile 是為 4 到 12 人的小型軟體團隊設計的，從未打算用於大規模團隊
大規模團隊的組織問題，人類五千多年前就已經解決了——金字塔、二戰、登月計畫都是大規模團隊協作的成果
真正沒被解決過的問題是：如何有效組織小型軟體團隊——而這正是 Agile 所解決的
軟體開發的獨特性（不蓋實體建築、不能數學證明、不發現物理定律）需要一套特殊的紀律

對 SAFe、LeSS 等框架的態度#

Bob 坦承自己沒有深入研究這些框架，但基於他的觀察發表意見
他認為不存在所謂的 “Agile in the Large”
正確做法：把開發者組織成小型 Agile 團隊，然後用傳統的管理與營運研究方法來管理這些團隊
軟體的獨特性不會因為團隊變大就延伸到跨團隊的協作層面

Bob 自己也承認這只是他的觀點，可能「完全錯誤」。他說也許自己只是那個叫年輕人「滾出我草坪」的老頑固。但他確實如此押注。

Agile Tools（敏捷工具）#

本節由 Tim Ottinger 和 Jeff Langr 撰寫。

工匠與工具的類比#

木匠先精通手工具（錘子、鋸子、鉋子），再學習電動工具
即使有了電動工具，高手也不會丟掉手工具——要根據場景選擇正確的工具
精通工具後，工具變成透明的（transparent），使用者可以專注在作品本身

好工具的五個特質#

幫助人達成目標
能快速學到「夠用」的程度
對使用者變得透明（不用一直想怎麼操作工具）
允許適應與再利用（adaptation and exaptation）
價格合理

Git 被舉為好工具的典範：快速、本地 commit、離線可用、分支和合併能力強，80/20 法則適用——20% 的功能就能應付 80% 以上的日常需求。

Physical Tools（物理工具）#

白板、膠帶、索引卡、便利貼等物理工具完美符合好工具的條件：

直觀、不需訓練、認知負擔幾乎為零
極度靈活，可以自由改造、加顏色、貼圖示
便宜且容易取得
Co-located 團隊可以只用這些簡單工具管理巨大且複雜的專案
限制：對遠端團隊效果差、不自動記錄歷史

ALM Tools 的問題#

ALM（Agile Lifecycle Management）工具在商業上很成功，但作為工具徹底失敗：

問題	說明
難以快速學會	通常需要專門培訓，團隊成員經常得上網搜尋才能完成簡單操作
不透明	在會議中常看到有人笨拙地操作 ALM 工具，而不是專注在討論上
難以客製化	想加一個欄位？可能要等工程師處理或提交 change request，五秒能完成的事變成五天、五週
昂貴	授權費本身就是大筆支出，加上培訓、維護、客製化成本
預設模式常與 Agile 衝突	例如假設每人有個別工作分配，不支援 cross-functional 協作
Pillory Board（公開處刑板）	有些 ALM 工具提供每人工作負載和進度的 dashboard，變成用來「羞辱程式設計師加班」的武器

Workers use and control tools; tools don’t control and use people. 應該先確立團隊的工作模式，再選擇支援該模式的工具，而不是反過來讓工具決定你的流程。

務實建議#

從物理工具開始，等流程穩定後再考慮 ALM 工具
如果只是需要管理一面卡片牆，用像 Trello 這樣的通用工具就夠了
選擇 ALM 工具時，確認它：快速上手、日常使用透明、容易客製、負擔得起、支援你的工作方式

Coaching – An Alternative View（另一種觀點）#

本節由 Damon Poole 撰寫，他與 Bob Martin 在 Agile Coaching 議題上持不同看法。

Damon 的 Agile 歷程#

Damon 在 2005 年之前其實是「不自覺地在做 Agile」——小型跨功能團隊、in-house 客戶、User Story、小型頻繁發佈
後來不自覺地滑入了 Waterfall（發佈週期膨脹到 18 個月），卻不知道為什麼開發變得痛苦
一開始他認為 Agile 是「蛇油」，但在研究如何反駁 Agile 的過程中頓悟：Agile 本質上是一種找到市場最高價值功能並快速變現的演算法

為什麼需要 Agile Coach？#

Damon 與 Bob 在這點上有明顯分歧：

Agile 的概念很簡單（Manifesto 只有 264 個字），但真正成為 Agile 很難
成為 Agile 涉及翻轉根深蒂固的信念、文化、流程與思維方式
一個人改變就夠難了，要讓整個團隊在不友善的環境中一起改變，難度倍增
持久改變的關鍵：找到人們自己意識到且願意投資的問題或機會，協助他們達成目標
Coaching 幫人們發現盲點、挑戰潛在假設，讓他們自己解決自己的問題，而非直接給處方

Professional Coaching 的導入#

2008 年 Lyssa Adkins 把 Professional Coaching 的技巧帶入 Agile Coaching 領域
ICAgile 的 ICP-ACC 認證涵蓋：Active Listening、Emotional Intelligence、提出開放式問題、保持中立等技能
ICF（國際教練聯盟）定義了 70 項能力，分 11 大類，認證過程要求數百小時的有償教練實踐

Coaching 不等於萬能#

純粹的 Coaching 技巧不夠——如果團隊從沒聽過 Kanban，光問好問題不會讓人自發發明 Kanban
Agile Coach 需要在六大領域具備專業知識：Agile 框架、Agile 轉型、Agile 產品管理、Agile 技術實踐、引導（Facilitation）、教練（Coaching）
組織最常低估的領域是技術實踐——不會寫好測試和好程式碼，技術債會不斷拖累 velocity

mindmap
  root((Agile Coach<br>六大領域))
    Agile 框架
    Agile 轉型
    Agile 產品管理
    Agile 技術實踐
    引導 Facilitation
    教練 Coaching

對大規模 Agile 的不同觀點#

Damon 的看法與 Bob 不同——他認為大規模 Agile 是一個需要被認真對待的問題：

常見錯誤：用傳統的 top-down、command-and-control 方式來推動 Agile 轉型
Damon 的核心洞見：成功導入 Agile 的問題，本質上與成功開發軟體的問題完全一樣
最有效的策略：用 Agile 的方式來導入 Agile——把受影響的人當作「客戶」，用 retrospective 和 open-space 找出他們的挑戰，建立 Agile adoption backlog，用 dot voting 排序，實作幾個 top items，然後回顧、重複
與其直接套用 SAFe 或 LeSS 等現成食譜，不如發現並實作適合你組織的客製食譜

flowchart TD
    A[找出受影響的人] --> B["Retrospective / Open-Space<br>找出挑戰"]
    B --> C[建立 Adoption Backlog]
    C --> D[Dot Voting 排序]
    D --> E[實作 Top Items]
    E --> F[回顧與調整]
    F --> B

實用做法清單#

Damon 建議逐步採用的個別實踐：

實踐	說明
Kanban 實踐	視覺化工作、限制 WIP、拉式系統
Scrum/XP 實踐	Daily Standup、Product Owner、Retrospective、Cross-functional Team、User Story、Pair Programming 等
Align Team Events	跨團隊對齊 iteration 時間，使阻礙能快速向上反映
Escalation Trees	定義清晰的阻礙升級路徑（Scrum of Scrums、Retrospective of Retrospectives）
Regular Interteam Interaction	跨團隊的 Scrum Master、PO、成員定期互動
Portfolio Kanban	在 initiative 層級設定 WIP limit，減少多工、簡化跨團隊協調
Minimum Viable Increments	尋找最短路徑產出最高價值，極致做法就是 Continuous Delivery

團隊層級的實踐如何支撐大規模#

Damon 強調「藉由做好小事來做大事」（going big by focusing on the small）：

實踐	效果
SOLID 原則	減少跨團隊依賴
小而有價值的 User Story	限制依賴範圍
小型頻繁發佈	及早發現整合與架構問題
Continuous Integration	每次 checkin 後跨產品整合
Simple Design / Emergent Design	避免集中式的龐大預先架構，搭配 Microservices 實現大規模 Agility

Conclusion（結語）#

Bob 在結語中自嘲：這一章講的「不要做什麼」比「要做什麼」還多。但他的初心不變——二十年後他依然認為「有什麼難的？照著幾個簡單的紀律做就好了。」

本章的核心訊息：Agile 轉型最大的阻力不是技術，而是價值觀的衝突。不要想著一步到位地改造整個組織，而是從小團隊開始，堅守完整的 Agile 紀律（包括技術實踐），讓成果說話。選擇工具時，簡單的往往比昂貴的更好。