第一章闡述了敏捷開發的精神與價值觀，但並未告訴我們具體該怎麼做。本章補足了這個缺口，介紹 Extreme Programming（XP） 的十四項核心實踐，這些實踐相互結合，構成一套完整且具體的敏捷開發流程。

mindmap
  root((XP 實踐))
    團隊
      完整團隊
      結對程式設計
      集體所有權
      開放式工作空間
      可持續的步調
    規劃
      使用者故事
      短週期
      規劃遊戲
    開發
      測試驅動開發
      重構
      簡單設計
      持續整合
    品質
      驗收測試
    願景
      隱喻

完整團隊（Whole Team）#

在 XP 中，客戶是團隊的一員，而非外部角色。所謂「客戶」是指定義並排列功能優先順序的人或群體，可能是：

  • 業務分析師、QA 專家、行銷人員
  • 被使用者社群委任的代表
  • 真正的付費客戶

重點： 理想情況下，客戶應與開發者在同一空間工作。距離愈遠，客戶愈難成為真正的團隊成員。若客戶無法常駐，應找一位能代替客戶做決策的人。

使用者故事（User Stories）#

  • User Story 是對需求的簡短記憶提示，而非完整的需求規格
  • 客戶在索引卡上寫下幾個關鍵字，開發者同時在卡片上寫下估算值
  • 不需要在早期捕捉所有細節——細節會隨著系統成形而逐漸浮現
  • User Story 是客戶用來排程的規劃工具，基於優先順序與估算成本

技巧： 過早鎖定需求細節往往導致浪費。User Story 的精神是「剛好足夠」——知道有哪些類型的細節，但不需要知道具體內容。

短週期（Short Cycles）#

XP 專案每兩週交付一次可運作的軟體，每次迭代都產出能滿足部分利害關係人需求的成果。

迭代計畫（Iteration Plan）#

  • 迭代通常為 1-2 週，代表一次小型交付
  • 客戶選擇要在該迭代實作的 User Stories，不得超過開發者的預算（velocity）
  • 迭代開始後，客戶不可變更該迭代的故事內容與優先順序
  • 迭代結束時計算完成的 Story Points，作為下一次迭代的速度基準

發布計畫（Release Plan）#

  • 發布通常涵蓋約六個迭代（約三個月），代表一次重大交付
  • 客戶根據開發者提供的預算，選擇想要實作的 User Stories
  • 發布內容可隨時調整——取消故事、新增故事、調整優先順序，但不應更動正在進行的迭代

驗收測試（Acceptance Tests）#

  • User Story 的細節透過驗收測試來定義
  • 驗收測試在故事實作之前或同時撰寫，以腳本語言編寫，可自動重複執行
  • 通過的驗收測試永遠不允許再失敗——系統始終從一個可運作的狀態遷移到下一個

結對程式設計（Pair Programming）#

  • 兩人共用一台工作站：一人駕駛（打字），一人導航（觀察、找錯、思考改進）
  • 角色頻繁切換，鍵盤在一小時內可能來回交換多次
  • 配對組合至少每天更換一次，確保每位成員在一個迭代中與每個人都合作過
  • 研究顯示：結對程式設計不會降低效率，但能顯著降低缺陷率

測試驅動開發（Test-Driven Development, TDD）#

  • 先寫失敗的單元測試，再寫讓測試通過的產品程式碼
  • 測試與程式碼的迭代週期極短，約以分鐘為單位
  • 隨時間累積一套完整的測試集，大幅促進重構的安全性
  • 為了讓程式碼可測試，自然會驅動更好的解耦設計

集體所有權（Collective Ownership）#

  • 任何配對都有權修改任何模組——沒有人是某個模組的唯一負責人
  • 雖然專長仍然存在，但每個人都會跨領域工作，促進知識在團隊中擴散

持續整合（Continuous Integration）#

  • 開發者每天多次簽入程式碼並整合到主線
  • 規則簡單：先簽入者為贏家，後簽入者負責合併
  • 每次簽入後建構整個系統，執行所有測試（包括驗收測試）
  • 如果破壞了任何既有功能，必須立即修復

可持續的步調（Sustainable Pace）#

  • 軟體專案是馬拉松，不是短跑衝刺——團隊必須保持穩定、適度的節奏
  • XP 規則：團隊不可加班，唯一例外是發布前最後一週且目標觸手可及時

注意： 跑得太快會導致倦怠、抄捷徑和失敗。團隊不應透支明天的精力來多做今天的事。

開放式工作空間（Open Workspace）#

  • 團隊在開放空間中一起工作，每張桌子有兩三台工作站
  • 牆上張貼狀態圖表、任務看板、UML 圖等
  • 密西根大學研究指出，「作戰室」環境的生產力可能提升一倍

規劃遊戲（The Planning Game）#

規劃遊戲的核心是責任分工：

  • 業務方決定功能的重要性
  • 開發方決定功能的實作成本
  • 每次發布和迭代開始時，開發者給客戶一個預算，客戶選擇不超過預算的故事

簡單設計（Simple Design）#

XP 團隊讓設計盡可能簡單且具表達力，只關注當前迭代的故事，不預先擔憂未來。三條設計箴言：

  1. 考慮可能有效的最簡方案（Consider the simplest thing that could possibly work）
  2. 你不會需要它（You aren’t going to need it, YAGNI）——抵抗提前加入基礎設施的誘惑
  3. 一次且僅一次（Once and only once）——發現重複就消除它，這會自然驅動出良好的抽象

重構（Refactoring）#

  • 重構是對程式碼結構進行一系列微小的改善性變換，不改變外部行為
  • 每次微小變換後立即執行測試，確保沒有破壞任何東西
  • 重構是持續進行的，不是留到專案結束才做——每半小時到一小時就重構一次

隱喻（Metaphor）#

  • 隱喻是將整個系統串聯在一起的全局願景，為系統元素提供一套命名體系
  • 它不僅是名稱系統，更是引導開發者選擇適當命名、函式位置和類別結構的直覺指南

本章小結#

Extreme Programming 是一組簡單而具體的實踐，它們相互結合，形成一套完整的敏捷開發流程。許多團隊可以直接採用 XP，也有許多團隊會根據自身情況做適度調整。

Backward Agile Practices Planning Forward