極限程式設計 - 活動與工件

---

---

本章我們將瞭解極限程式設計的活動和工件。

XP – 活動

在極限程式設計中，四個基本活動是：

• 編碼

• 測試

• 傾聽

• 設計

編碼

在結對程式設計中，編碼被認為是開發的核心。你編寫程式碼，因為如果你不編寫程式碼，那麼一天結束時你什麼也沒做。

測試

在結對程式設計中，需要進行測試以確保程式碼的正確性。如果你不測試，你就不知道何時完成編碼。

傾聽

在結對程式設計中，你需要傾聽以瞭解需要編寫什麼程式碼或測試什麼。如果你不傾聽，你就不知道要編寫什麼程式碼或測試什麼。

設計

在結對程式設計中，你進行設計以便你可以無限期地繼續編碼、測試和傾聽，因為好的設計允許系統擴充套件，並且只在一個地方進行更改。

這些活動在以下階段執行：

• 釋出計劃

• 迭代計劃

• 實現

釋出計劃

在釋出計劃中，客戶和開發人員共同制定下一個釋出的計劃，商定該釋出的使用者故事和下一個釋出日期。

釋出計劃包含三個階段：

• 探索階段

• 承諾階段

• 指導階段

釋出計劃 – 探索階段

在探索階段：

• 客戶提供系統高價值需求的簡短列表。

• 開發人員收集需求並估算每個需求的工作影響。

需求被記錄在使用者故事卡片上。為了編寫故事，客戶將在與開發人員的會議中提出問題。開發人員將嘗試定義這個問題並獲得需求。基於此次討論，客戶將編寫一個故事，指出他們希望系統的一部分做什麼。重要的是，開發人員對這個故事沒有任何影響。

主動傾聽在這個階段非常重要，因為

• 開發人員需要理解“客戶要求什麼”和“哪些需求具有高價值”。

• 客戶需要與開發人員一起了解哪些場景有助於這些價值的編寫。

雖然客戶在使用者故事卡片上編寫需求，但你需要傾聽以

• 獲得清晰度

• 避免歧義

• 如果理解方面存在可能的差距，請表達你的想法

這隻有透過口頭溝通才能實現。

釋出計劃 – 承諾階段

在承諾階段，客戶和開發人員將承諾要包含的功能以及下一個釋出的日期。

此階段涉及確定成本、效益和進度影響。在這個階段：

• 客戶按業務價值對使用者故事進行排序。

• 開發人員按風險對故事進行排序。

• 開發人員確定實現故事所需的努力和持續時間（估算）。

• 將選擇在下一次釋出中完成的使用者故事。

• 根據使用者故事和估算，確定釋出日期。

主動傾聽在這個階段非常重要，因為：

• 開發人員需要了解他們需要為當前釋出編寫什麼功能以及交付此功能所需的努力和持續時間（估算）。

• 客戶和開發人員需要了解下一次釋出日期承諾的可行性。

釋出計劃 – 指導階段

在指導階段，客戶和開發人員“引導”：

• 對各個使用者故事和不同使用者故事的相對優先順序進行更改。

• 調整計劃。

• 如果估算被證明是錯誤的。

• 以適應變化。

主動傾聽在這個階段非常重要，

• 以瞭解：

  • 需要新增的新需求。

  • 現有需求需要進行哪些更改。

  • 如果刪除任何現有需求，對現有系統的影響。

• 確定調整計劃所需的估算，考慮

  • 迄今為止完成的工作。

  • 需要新增的新需求。

  • 必須更改或刪除的現有需求。

迭代計劃

在迭代計劃中，開發人員參與計劃迭代的活動和任務。客戶不參與其中。

迭代計劃包含三個階段：

• 探索階段。

• 承諾階段。

• 指導階段。

迭代計劃 – 探索階段

在探索階段：

• 需求將被轉換成不同的任務。

• 任務記錄在任務卡上。

• 開發人員估算實現每個任務所需的時間。

• 如果開發人員無法估算任務（因為任務太小或太大），他們需要組合或拆分任務。

迭代計劃 - 承諾階段

在承諾階段：

• 任務分配給開發人員。

• 開發人員接受他們負責的任務。

• 開發人員估算完成任務所需的時間，因為開發人員現在負責該任務，並且他們應該給出最終的估算。

• 在團隊中的所有開發人員都被分配了任務後，進行負載平衡。

• 比較任務的估計時間和負載係數。

• 負載係數表示假設每週 40 小時工作制的情況下，每個開發人員在一個迭代中理想的實際開發時間量。

• 然後在開發人員之間平衡任務。如果一個開發人員的任務過多，其他開發人員必須接管他或她的一些任務，反之亦然。

迭代計劃 – 指導階段

在指導階段：

• 開發人員獲得他或她已承諾的任務之一的任務卡。

• 開發人員將與另一位開發人員一起遵循結對程式設計實踐來實現此任務。

實現

任務的實現已完成。實現包括設計、編寫單元測試、編碼、單元測試、重構、持續整合到程式碼庫、整合測試和基於任務卡和使用者故事卡的驗收測試。

極限程式設計工件

極限程式設計並非反對文件，而是鼓勵只做真正需要做的最少的事情。文件在需要進行分散式共享、歷史記錄需求、總結等情況下使用。

基本的極限程式設計工件包括：

• 使用者故事卡片

• 驗收測試

• 估算

• 釋出計劃

• 迭代計劃

• 任務卡

• 設計

• 單元測試用例

• 客戶和開發人員溝通記錄

使用者故事卡片

使用者故事卡片具有以下特點：

• 一張使用者故事卡片：

  • 包含從客戶角度對系統行為的簡短描述。

  • 必須由客戶編寫，而不是由開發人員編寫。

  • 使用客戶的術語，不使用技術術語。

  • 只應提供足夠的細節，以便估算實現故事需要多長時間。

• 系統中每個主要功能一張。

• 用於為釋出計劃建立時間估算。

• 推動驗收測試的建立。

驗收測試

驗收測試必須是一個或多個測試，以驗證故事是否已正確實現。

估算 – 釋出計劃

將用於釋出計劃的故事的努力和持續時間估算：

• 在探索階段確定目標釋出日期。

• 在指導階段調整計劃。

釋出計劃

釋出計劃包含：

• 為釋出選擇的使用者故事。

• 努力和持續時間估算。

• 已承諾的目標釋出日期。

任務卡

一張任務卡：

• 包含實現使用者故事所需的必要任務。

• 每個使用者故事一張任務卡。

• 構成任務估算和任務分配的基礎。

估算 – 迭代計劃

基於使用者故事的任務的努力和持續時間估算將在迭代計劃中用於承諾階段的任務分配和負載平衡。

迭代計劃

迭代計劃包含：

• 為迭代選擇的使用者資訊故事

• 任務分配

• 任務估算

設計

設計包含一個簡單的設計，足以實現使用者故事。

單元測試用例

這包含驅動編碼和單元測試的單元測試用例。

客戶和開發人員溝通記錄

客戶和開發人員討論故事以詳細說明細節。如果可能，則採用口頭方式，如果需要，則進行記錄。