如同所有敏捷流程，Scrum 是一種迭代（iterative）且增量（incremental）的軟體開發方法。這兩個詞雖然經常一起使用，但含義不同：

• 增量開發：逐塊建構系統——先完成一部分，再加入下一部分。Alistair Cockburn 稱之為「分階段和排程策略」
• 迭代開發：承認第一次不太可能做對，因此先開發一個初步版本，收集回饋，再開發改進版本

在純粹增量的流程中，我們完整開發一個功能再進入下一個；在純粹迭代的流程中，我們不完美地建構整個系統，再透過多次迭代來改善。Scrum 的 sprint 結合了兩者的優點，消除了單獨使用任一方法的弱點。

本章探討 sprint 的多個面向：每個 sprint 交付可運作軟體的重要性、交付有價值功能、在當前 sprint 為下一個做準備、團隊在 sprint 中協作、維持固定的時間箱，以及不在 sprint 中途改變目標。

每個 Sprint 都交付可運作的軟體（Deliver Working Software Each Sprint）#

每個 sprint 結束時，Scrum 團隊必須產出可運作的軟體——既完整又潛在可交付（potentially shippable）的軟體。這是新 Scrum 團隊必須克服的最大挑戰之一，也是 Agile Manifesto 四大價值之一的體現：「重視可運作的軟體勝過詳盡的文件。」

敏捷方法論強調可運作軟體有三個關鍵原因：

• 可運作的軟體鼓勵回饋：向使用者展示一個功能性的部分產品，比提供一份文件更能引發有品質的回饋。50 頁的產品規格太容易被擱置和忽略
• 可運作的軟體幫助團隊衡量進度：專案最大的風險之一是不知道還剩多少工作。透過強調每個 sprint 交付可運作軟體，團隊避免了讓系統長期停留在未完成狀態
• 可運作的軟體允許提前出貨：在快速變化的競爭環境中，即使功能較少也能提前出貨可能極具價值

定義「潛在可交付」#

團隊應該討論並達成共識，定義一個適合其環境的 definition of done，描述什麼構成潛在可交付的產品增量。每個被帶入 sprint 的 backlog 項目都必須符合這些標準才能被視為完成。

例如，ePlan Services 公司將 done 定義為「已編碼、已測試、已簽入、撰寫良好、已整合、且有自動化測試」。每個項目除了要滿足自身的 conditions of satisfaction 外，還必須符合這個全域性的完成定義。

潛在可交付的準則#

• Potentially shippable means tested（潛在可交付意味著已測試）：在 sprint 結束時，新功能應該無 bug，且不應引入舊功能的 bug。特殊測試（如整合測試、效能測試、可用性測試）可以在偶爾的 release sprint 中執行
• Potentially shippable does not necessarily mean cohesive（潛在可交付不一定意味著功能完整）：有時一個功能需要跨多個 sprint 才能形成最小可用的功能集。但在此之前的每個 sprint，產品仍應處於潛在可交付狀態
• Potentially shippable means integrated（潛在可交付意味著已整合）：在多團隊專案中，done 的定義應包含整合開發流。整合應盡可能在 sprint 期間持續進行

每個 Sprint 都交付有價值的東西（Deliver Something Valuable Each Sprint）#

除了交付可運作的軟體，Scrum 團隊還被要求每個 sprint 交付對使用者或客戶有價值的東西。每個 sprint 的部分工作應產生使用者可見的功能，因為 sprint 工作方式的核心好處之一就是能在每個 sprint 結束時從使用者和客戶那裡獲取回饋。

追蹤子彈（Tracer Bullet）方法#

作者以一個開發房屋搜尋網站的團隊為例。當一個功能太大無法在單一 sprint 完成時，團隊有三種選擇：

1. 只做後端搜尋，在 sprint review 展示命令列結果
2. 只做使用者介面，使用模擬資料
3. 同時做部分後端和前端，展示一個支援 10 個搜尋欄位且功能不完整的應用程式

作者推薦第三種方法——Andy Hunt 和 Dave Thomas 所說的「tracer bullet」（追蹤子彈）。它的價值在於「儘早產出一些真正能給使用者看的東西，觀察我們離目標有多近」。如果必須在前兩種方法中選擇，作者更傾向第一種（後端功能），因為它能真正展示功能可運作，只是還沒有漂亮的介面。

不可見的功能#

並非所有產品都有對終端使用者可見的功能，但每個產品的功能都對某人可見。例如，一個建構共用資料存取層的 component team 的「使用者」是其他四個 feature team 的程式設計師和測試人員。該團隊在 sprint review 中可以展示純技術功能（如資料庫的級聯刪除）。

在當前 Sprint 為下一個做準備（Prepare in This Sprint for the Next）#

撞球式 Sprint#

作者接到一位開發總監的求助電話：她的三個團隊的 sprint planning 各需要三天。問題不在於會議本身，而是撞球式 sprint（billiard ball sprints）——一個 sprint 結束後，下一個立刻開始，但團隊完全沒有準備，不得不花大量時間在 sprint planning 中學習接下來要做什麼。

避免撞球式 sprint 的最佳方式是遵循童子軍準則：做好準備。Ken Schwaber 建議分配約 10% 的團隊時間來為下一個 sprint 做準備。

只拉入能完成的工作#

團隊不應將一個明顯太大而無法完成的 user story 拉入 sprint。太模糊的 stories 也不應被拉入——如果一個 story 還不夠被理解到可以在 sprint 中完成，團隊需要先花時間了解它。

重要的是，被拉入 sprint 的 story 只需要被「充分理解」（sufficiently understood），而非「完全理解」。Product owner 和其他團隊成員仍然會在 sprint 期間協作完善 story 的細節。每個 backlog 項目在被拉入 sprint 時所需的細節程度，是讓它能在一個 sprint 內從 backlog 項目變成可運作、已測試功能的最低必要量。

使用者體驗設計的案例#

以使用者體驗（UX）設計為例：有些 user stories 幾乎不需要 UX 設計（如「查看 About 對話框」），有些則需要大量設計工作（如電子商務網站的訂單取消流程）。對於後者，UX 設計工作可能需要在前一個 sprint 就開始——先進行設計原型和使用者測試，讓團隊在下一個 sprint 開始時有足夠的設計基礎來實作。

在 Sprint 中全程協作（Work Together Throughout the Sprint）#

Steve Jobs 被問到 Apple 如何持續創新偉大產品時，他的回答揭示了 Scrum 團隊應有的深度協作精神：產品不是從一個部門傳到另一個部門，而是所有部門同時、有機地一起工作。

避免按活動分期的 Sprint#

團隊最容易掉入的陷阱之一是在 sprint 內序列式地執行工作——第一週分析、第二週設計、第三週編碼、第四週測試。這種序列方法效率低下：太多閒置等待、太多專業分工、太多交接。

好的 Scrum 團隊會盡量重疊各種活動——分析的同時開始建構、建構的同時開始測試。許多敏捷工程實踐（如自動化單元測試、測試驅動開發）有助於實現這種重疊。

避免按活動分期的 Sprint（Activity-Specific Sprints）#

如果團隊未能學會重疊工作，他們可能退而求其次採用 activity-specific sprints——一個 sprint 做分析和設計、下一個 sprint 做編碼、再下一個做測試。這種做法有三個嚴重缺點：

• 增加時程風險：規劃下一個 sprint 的工作量高度依賴上一個 sprint 的工作品質
• 從想法到可運作功能的時間更長：延長了獲取客戶和使用者回饋的時間
• 並未真正解決重疊工作的問題：當所有工作在同一個 sprint 中完成時，團隊以相同的步調前進，成員互相幫助。引入 activity-specific sprints 後，不同子團隊以不同速度推進，工作堆積在某些子團隊前面

以 Finish-to-Finish 取代 Finish-to-Start#

Activity-specific sprints 的最大問題是它們創造了 finish-to-start（完成後開始）的關係。好的 Scrum 團隊學會了重疊活動，使用 finish-to-finish（同時完成）的關係——所有工作在 sprint 結束時同時完成，否則就退回 backlog。

整合使用者體驗設計#

在傳統管理的專案中，使用者體驗設計（UED）被視為前期活動。但在 Scrum 中，我們希望 UX 設計師與其他團隊成員一起工作。在 sprint 期間，不同成員會在兩個目標之間分配時間：完成當前 sprint 的工作，以及為下一個 sprint 做準備。程式設計師大部分時間用於新增功能，而 UX 設計師可能大部分時間用於了解即將到來的功能——為複雜的 backlog 項目創建詳細設計。但關鍵是，他們也會花時間回應當前 sprint 中正在編碼和測試的設計問題。

Autodesk 的敏捷互動設計師 Desiree Sy 將這種方式稱為 design chunks——將設計拆分為 sprint 大小的塊。這需要練習，但 just-in-time 設計最終會產出更好的設計，因為它縮小了發現可用性問題和修正之間的差距。

架構與資料庫設計#

UX 設計、架構和資料庫設計本質上是同一個問題的不同面向：如何將傳統上在瀑布式流程前期完成的活動整合到迭代式開發中。

作者以架構師 Klaus 的案例說明：Klaus 在開發科學資料工作流產品時，保持對整體架構和設計的全局思考，但利用 sprint 來迭代地解決需要做出的決策。Product owner 在排列優先順序時，會考慮 Klaus 對哪些 stories 應該提前開發以建立堅實基礎的建議。每個 sprint 都交付新的可運作軟體，同時也解決了架構上的不確定性。

保持時間箱的規律性和嚴格性（Keep Timeboxes Regular and Strict）#

固定 Sprint 長度的好處#

作者在早期實踐迭代開發時犯了一個錯誤：不固定 sprint 長度，每次在 sprint planning 時決定這次要跑兩週還是六週。後來他發現固定 sprint 長度有顯著好處：

• 團隊受益於規律的節奏：固定一到四週的節奏幫助團隊建立最適合的工作韻律
• Sprint planning 變得更容易：經過通常兩到五個 sprint，團隊就能學會一個 sprint 可以規劃多少工時的工作
• Release planning 變得更容易：Scrum 團隊透過經驗數據來制定發布計畫，固定 sprint 長度讓 velocity 的衡量更為可靠
• 這是 Richard Feynman 會做的事：費曼厭倦了每天選擇甜點，決定永遠選巧克力冰淇淋。同樣地，在每個 sprint 開始時選擇長度是一種精力浪費

選擇一個在你的環境中運作良好的星期幾來開始 sprint，例如星期五——這樣可以把 sprint review、retrospective 和 planning 都排在同一天。

偶爾偏離固定長度是可以接受的，例如遇到長假期時，兩週 sprint 的團隊可以改跑一個三週的 sprint 來維持大致相同的工作天數。

永遠不要延長 Sprint#

sprint 必須嚴格按時結束。不要在計劃的結束日到達時決定多加幾天來完成工作。即使在一年期專案的第一個 sprint 延長幾天看似無傷大雅，但這傳達了一個危險的訊息：錯過截止日期是可以接受的。

嚴格執行 sprint 截止日意味著團隊偶爾需要放棄在 sprint 中計劃完成但未完成的工作。當有跡象顯示並非所有計劃的工作都能完成時，product owner 應盡早與團隊討論，決定哪些工作應該完成、哪些應該放棄。

不要改變目標（Don’t Change the Goal）#

Scrum 對變更採取雙管齊下的策略：sprint 內部不允許變更——團隊承諾一組工作並期望在 sprint 期間保持不變；但 sprint 外部，整個世界可能在變化。

為什麼要反對中途變更#

Scrum 對中途變更的強硬立場看似有害專案成功——畢竟有時候變更確實很重要。但作者建議至少初期採取強硬立場，因為：

• 如果 product owner 發現了必須立即處理的新需求，Scrum 的做法是宣布 abnormal termination（異常終止），然後立即規劃一個新的 sprint。這提高了變更的可見性和成本意識
• 更常見的情況是像 Janis 的案例：她在 sprint 第七天突然想到更好的搜尋畫面設計。團隊面臨選擇——取消當前 sprint 重新開始，或繼續完成當前工作。Scrum 幫助團隊從正確的角度思考：是「夠好的搜尋畫面加上額外七天的其他功能」比較好，還是「更好的搜尋畫面但少七天的功能」比較好？最終團隊決定先完成當前工作，九個月後才實作改進版

打破重新導向團隊的習慣#

許多組織已經養成了不斷重新導向開發團隊的習慣。團隊被打斷往往不是因為 product owner 發現了緊急的客戶需求，而是因為 product owner 或利害關係人沒有提前思考。

作者分享了一個 B2B 公司的案例：業務每次簽約都需要開發團隊花 5-10 小時新增合作夥伴。作者與業務溝通後約定，只有在 sprint 開始前已簽約的合作夥伴才會被處理。業務不但沒有反對，反而告訴作者這是一個賣點——合作夥伴的上線時間現在與 sprint 週期綁定，有明確的時程表。

之後放寬強硬立場#

作者通常建議 Scrum 團隊初期採取反對中途變更的強硬立場。這不是因為要盲目遵守 Scrum 規則，而是要幫助組織中的其他人認識到重新導向團隊是有成本的。當組織不再把每個新需求都視為值得中途變更的緊急事件時，就可以適度放寬。

客戶真正想要的往往是可預測性。大多數客戶理解非關鍵的 bug 不能立即修復。當你能告訴他們「我們每兩週發布一次系統修補，你的問題會在兩週後的那次修補中解決」時，他們通常能接受——因為他們過去從未從軟體開發組織獲得這種程度的可預測性。

獲取回饋、學習並調適（Get Feedback, Learn, and Adapt）#

每個 sprint 可以被視為一次實驗。Product owner 和團隊在 sprint 開始時會面，識別能執行的最有價值的實驗。實驗涉及以可運作軟體的形式創造一定量的新功能，這個新增量被要求達到潛在可交付的標準，以便最大化實驗的回饋。在 sprint 結束時，實驗被評估，團隊整體從中學習。

學習的內容包含兩個面向：

• 關於產品：使用者喜歡什麼？不喜歡什麼？覺得什麼令人困惑？接下來想要什麼？新增量讓他們想到了什麼之前沒想到的功能？
• 關於 Scrum 流程本身：一個 sprint 能完成多少工作？什麼阻礙了我們？什麼可以幫助我們加速？我們每個 sprint 都有達到「done」的軟體嗎？

這些學習之所以有價值，正是因為 Scrum 既是迭代的又是增量的。Product owner、團隊和 ScrumMaster 能夠回頭改進之前部分完成但可運作的實作：為資料搜尋畫面增加更多欄位、將使用者介面從「可接受」提升到「優秀」、在最重要的系統部分調校效能。計畫被更新，工作被重新排序，一切都基於對團隊能在期限內完成多少工作的更好理解。

迭代與增量開發的核心在於：產生回饋、從中學習、然後調適我們正在建造什麼以及如何建造。Sprint 為團隊提供了實現這一切的機制。