新頭銜、新角色和新職責並不是 Scrum 團隊需要做的唯一改變。要真正成功，團隊必須超越 Scrum 的基本流程（Sprint、Daily Scrum、Review、Retrospective），在實際產出工作的方式上做出根本性改變。許多團隊在採用 Scrum 基本框架後已能看到顯著改善（甚至生產力倍增），但要更進一步，關鍵在於改變技術實踐。

Scrum 本身不規定具體的工程實踐——這與其核心哲學一致：信任團隊解決問題。但大多數團隊會發現，採用新的技術實踐能讓達成目標變得容易許多。

本章探討五種源自 Extreme Programming（XP）、被許多高績效 Scrum 團隊採用的常見實踐，並討論設計如何在 Scrum 專案中既是有意的又是漸進浮現的。

Strive for Technical Excellence（追求技術卓越）#

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

傳統開發的微循環是：寫程式 → 修編譯錯誤 → 在 debugger 中逐步執行，每幾小時重複一次。TDD 的微循環則是：寫一個失敗的自動化測試 → 寫剛好通過測試的程式碼 → 重構，每幾分鐘重複一次。

TDD 的核心價值：

• 確保沒有未測試的程式碼進入系統——所有程式碼都是為了回應一個失敗的測試而寫的
• 「寫完功能後馬上補測試」的承諾在實務中很少兌現——下一個功能的壓力太大，測試往往被永遠推遲
• TDD 不僅是測試實踐，也是設計實踐：測試的選擇和排序引導開發過程，使設計至少部分從系統需求中浮現
• 難以測試的設計通常暗示程式碼結構不良

TDD 與前期架構思考並不衝突。在複雜或大型系統中，你可能確實需要一些前期的架構思考，但 TDD 可以作為微觀層面的實踐與前期架構工作有效結合。

常見反對意見：

• 「先寫測試一定比較慢，我沒時間浪費」——研究顯示 TDD 約多花 15% 的時間，但也有研究（Microsoft）顯示 bug 數量減少 24%-38%。初期多花的時間會在減少 bug 修復和維護時間中回收。

Refactoring（重構）#

Fred Brooks 在《The Mythical Man Month》中描述了軟體系統隨修改逐漸腐化的現象。幸運的是，自 1975 年以來，業界已學會如何在不引入衰退的情況下修改系統。

重構是指改變程式碼的結構但不改變其行為。例如，將兩個方法中的三行相同程式碼抽取為一個新方法（extract method），提升可讀性和可維護性。

• 重構對 TDD 的成功至關重要，也能防止 code rot（程式碼腐化）
• Robert C. Martin 的 Boy Scout Rule：「讓你離開時的營地比你到達時更乾淨」——每次 check-in 的程式碼都比 check-out 時稍微乾淨一些
• 重構是選擇在便宜的時候做一點維護，而非等到問題累積成必須全面重寫

常見反對意見：

• 「如果他們第一次就寫對，就不需要重構了」——這就像說「如果 Toyota 造的車夠好，就不需要換機油」。所有應用程式都需要維護，重構是選擇在成本低的時候進行。

Collective Ownership（集體所有權）#

集體所有權意味著所有開發者對開發過程的所有產出物（尤其是程式碼和自動化測試）共同擁有所有權。團隊要避免「那是 Ted 的程式碼，我們不能動」的陷阱。

集體所有權的責任：

• 確保沒有開發者過度專精到只能貢獻於一個領域
• 確保沒有程式碼區域複雜到只有一個人能理解和修改

好處：

• 鼓勵開發者學習系統的新部分，同時學習新的做事方式
• 好的想法能更快地在應用程式各部分傳播——程式設計師在不同部分間流動，像花粉一樣攜帶好的想法
• 集體所有權下的團隊通常寫出更乾淨的程式碼（因為沒人想在同事面前丟臉）

常見反對意見：

• 「那是我的程式碼，我不想修別人的 bug」——別人也在修你的 bug。集體所有權下，程式碼更乾淨、bug 更少。
• 「每個人擁有一個部分開發更快」——如果是短期拋棄式專案確實如此。但若是長期維護的大型系統，學習、交叉訓練和集體所有權的其他好處明顯更有利。

Continuous Integration（持續整合）#

從 1990 年代的每日建置（nightly build）開始，持續整合更進一步：每位程式設計師預期每天 check in 數次，每次都觸發完整的自動化建置與測試。

• 通常透過工具（如 Cruise Control）監控版本控制系統，在偵測到 check-in 時自動建置、測試並通知
• 強烈不建議手動方式：即便意圖良好，開發者總會忍不住偶爾跳過（「我只改了兩行」、「快六點了，我不想等 15 分鐘跑測試」）
• 對多數開發者而言，首次體驗自動化持續整合是令人大開眼界的：不僅消除了專案末期的整合風險，整個團隊還能得到近乎即時的產品狀態回饋

針對大型系統的策略： 當測試套件需要數小時才能跑完時，可將測試拆分為：

• 煙霧測試（Smoke test）：每次 check-in 後執行，包含當前 Sprint 的所有測試腳本加上過去里程碑的子集
• 完整測試：每小時執行一次，包含所有里程碑的全部測試腳本

Pair Programming（結對程式設計）#

Pair programming 是兩位開發者共同在一台電腦上寫程式的實踐。它源於「如果偶爾的程式碼審查是好的，那持續的審查更好」這一理念。

好處：

• 雖然大多數研究顯示 pairing 會稍微增加總人時（person-hours），但縮短專案總工期
• 研究一致顯示 pairing 能提升品質
• 促進知識傳遞，是讓新開發者快速上手的理想方式
• 適合處理不熟悉的領域或解決已知困難問題

不需要 100% 結對： 大多數團隊發現，即使不是全天候結對，仍能獲得絕大部分好處。建議以 part-time 方式採用，優先用於應用程式中風險最高的部分。

常見反對意見：

• 「花兩個人的薪水做一個人的工作太浪費」——短期成本增加，但通常會通過更短的時程和更高品質帶來回報。不要依賴業界研究來說服自己，直接在最困難的模組上試試看。
• 「我們趕時間，不能讓兩個人做同一件事」——恰恰相反，趕時間正是最需要 pairing 的時候。有證據顯示 pairing 能有效對抗 Brooks’ Law（「為已經延遲的專案增加人力只會讓它更延遲」）。
• 「處理難題時我需要安靜獨處思考」——與搭檔溝通後暫時分開思考即可，恢復 pairing 時分享各自的見解。

Design: Intentional yet Emergent（設計：有意圖但漸進浮現）#

Scrum 專案沒有前期分析或設計階段——所有工作都在 Sprint 的重複循環中進行。但這不代表設計不是有意圖的。有意圖的設計過程是透過刻意、有意識的決策來引導的。Scrum 的差別在於：有意圖的設計是漸進式完成的。

成為敏捷的組織需要在預期（anticipation）與適應（adaptation）之間找到適當的平衡。做前期分析和設計時，我們試圖預期使用者的需求；跳過分析直接編碼時，我們試圖適應使用者的需求。所有專案都會落在兩個極端之間的某個位置。

Getting Used to Life Without a Big Design（適應沒有大型設計的生活）#

隨著 Scrum 團隊熟練技術實踐，他們自然會從預期使用者需求轉向適應。這帶來的新現實包括：

• 規劃變得更難：沒有前期設計時，估算和承諾變得更困難。但好處是需要估算的工作通常更簡單
• 工作分配更難：有大型前期設計時，很容易看出哪些功能可以平行開發、哪些需要順序開發
• 沒有設計成品會不安：即使我們一直都知道沒有前期設計能 100% 完美，我們還是從中獲得了安慰感
• 返工不可避免：沒有大型前期設計，團隊必然會需要撤銷部分設計。幸運的是，重構和 TDD 期間建立的自動化測試能讓大多數返工規模維持較小

傳統 vs. Scrum 的成本權衡#

傳統開發中，前期分析和設計的大量投資降低了後期變更的數量，但每次變更的成本很高（因為它違反了「變更不太可能發生」的假設）。Scrum 則是有更多但更小的變更——每次返工的代價較小，因為團隊持續保持程式碼良好重構、設計盡可能簡潔、並有自動化測試套件提前偵測回歸問題。

當團隊使用良好的技術實踐（TDD、大量自動化單元測試、重構、pair programming），可能發現頻繁適應使用者需求並返工，比預期需求並偶爾返工更划算。

Guiding the Design（引導設計）#

當有人攻擊 Scrum 專案「缺乏設計」時，通常從一個錯誤的前提出發：技術團隊成員對功能開發順序沒有影響力。事實上，Scrum 團隊能做的最好的事情之一就是影響 Product Backlog 項目的順序。

• Product Owner 基於「商業價值」排定優先順序，但好的 Product Owner 會聽取技術團隊的建議
• 團隊應鼓勵 Product Owner 選擇能最大化學習和消除技術不確定性或風險的 backlog 項目
• 設計是浮現的（因為沒有前期設計階段），同時也是有意圖的（因為 backlog 項目被刻意選擇以在不同時間推動設計向不同方向發展）

在下一次 Sprint planning 之前，識別專案中前五大技術不確定性及其相關風險，看看是否有 Product Backlog 項目可以稍微提前排序，以產生消除這些不確定性所需的學習。

Improving Technical Practices Is Not Optional（改善技術實踐不是可選的）#

本章描述的技術實踐是高績效團隊的標配：

• Continuous Integration 只是 nightly build 的自然延伸，是敏捷團隊的最低門檻
• Refactoring 的技能和 Collective Ownership 的心態可以在任何團隊中逐步建立
• Pair Programming 和 TDD 等實踐直接帶來更高品質的程式碼

這些實踐綜合使用的結果是高品質、低缺陷的產品。Chapter 1 中提到的品質和缺陷率改善數據，正是團隊刻意提升技術能力、採用更好實踐的結果。

良好的技術實踐讓 Scrum 團隊能將預期與適應的平衡進一步推向適應端。減少甚至消除前期分析和設計活動，同時節省時間和金錢。Dave Thomas（Object Technology International 創辦人）總結道：「敏捷程式設計是為變化而設計……其目標是設計能接受、甚至預期變化的程式。」