極限程式設計 - 快速指南

---

---

極限程式設計 - 簡介

本章概述了極限程式設計。

什麼是敏捷？

“敏捷”一詞意味著 -

• 能夠快速輕鬆地移動你的身體。

• 能夠快速清晰地思考。

在商業中，“敏捷”用於描述規劃和開展工作的方式，其中理解根據需要進行更改是工作的重要組成部分。商業“敏捷性”意味著公司始終能夠考慮到市場變化。

參考：劍橋線上詞典。

在軟體開發中，“敏捷”一詞被用來表示“能夠應對變化 - 來自需求、技術和人員的變化”。

敏捷宣言

一個軟體開發團隊於 2001 年釋出了敏捷宣言，強調了開發團隊的重要性、適應不斷變化的需求和客戶參與。

敏捷宣言指出 -

我們正在透過實踐和幫助他人實踐來發現更好的軟體開發方法。透過這項工作，我們開始重視 -

• 個體和互動高於流程和工具。

• 可工作的軟體高於詳盡的文件。

• 客戶合作高於合同談判。

• 響應變化高於遵循計劃。

也就是說，雖然右側的專案也具有一定的價值，但我們更重視左側的專案。

敏捷的特點

以下是敏捷的特點 -

• 敏捷軟體開發中的敏捷側重於整個團隊的文化，擁有賦權且自組織的多學科、跨職能團隊。

• 它培養了共同的責任和問責制。

• 促進有效溝通和持續協作。

• 全團隊方法避免了延遲和等待時間。

• 頻繁且持續的交付確保了快速反饋，這反過來又使團隊能夠與需求保持一致。

• 協作有助於及時將不同的視角結合到實施、缺陷修復和適應變化中。

• 進度是持續的、可持續的和可預測的，強調透明度。

軟體工程趨勢

在軟體工程中觀察到以下趨勢 -

• 在開發開始之前收集需求。但是，如果稍後需要更改需求，則通常會注意到以下情況 -

  • 在開發後期抵制更改。

  • 需要一個嚴格的變更流程，該流程涉及變更控制委員會，甚至可能將變更推遲到以後的版本。

  • 交付具有過時需求的產品，無法滿足客戶的期望。

  • 無法在預算範圍內適應不可避免的領域變化和技術變化。

• 儘早發現並消除開發生命週期中的缺陷，以降低缺陷修復成本。

  • 測試僅在編碼完成後才開始，並且測試被認為是測試人員的責任，儘管測試人員不參與開發。

  • 衡量和跟蹤流程本身。這變得昂貴，因為 -

  • 在任務級別和資源級別進行監控和跟蹤。

  • 定義指導開發的度量標準，並在開發中衡量每個活動。

  • 管理干預。

• 在開發之前詳細說明、分析和驗證模型。

  • 模型應該用作框架。但是，專注於模型而不是開發至關重要，否則將無法產生預期的結果。

• 編碼是開發的核心，但沒有得到足夠的重視。原因是 -

  • 負責生產的開發人員通常與客戶沒有持續溝通。

  • 編碼被視為設計的翻譯，程式碼中的有效實現很少回饋到設計中。

• 測試被認為是交付前檢查缺陷的門戶。

  • 開發早期階段的進度延誤透過忽略測試要求來彌補，以確保按時交付。

  • 這導致交付後修復缺陷的成本超支。

  • 測試人員對產品質量負責，儘管他們在整個開發過程中沒有參與。

• 限制資源（主要是團隊）以適應預算會導致 -

  • 資源過度分配

  • 團隊倦怠。

  • 團隊能力的有效利用損失。

  • 人員流失。

極限程式設計 - 處理常見缺點的一種方法

軟體工程涉及 -

• 創造力

• 透過反覆試驗學習和改進

• 迭代

極限程式設計建立在這些活動和編碼的基礎上。它是詳細的（而非唯一的）設計活動，透過有效的實現、測試和持續重構來實現多個緊密的反饋迴圈。

極限程式設計基於以下價值觀 -

• 溝通

• 簡單性

• 反饋

• 勇氣

• 尊重

什麼是極限程式設計？

XP 是一種輕量級、高效、低風險、靈活、可預測、科學且有趣的方式來開發軟體。

極限編程 (XP) 的構思和開發是為了解決小型團隊在面對模糊和不斷變化的需求時軟體開發的特定需求。

極限程式設計是敏捷軟體開發方法之一。它提供價值觀和原則來指導團隊行為。團隊預計會進行自我組織。極限程式設計提供具體的核心實踐，其中 -

• 每個實踐都簡單且自成一體。

• 實踐的組合產生了更復雜和湧現的行為。

擁抱變化

極限程式設計的一個關鍵假設是，更改程式的成本可以在一段時間內保持大致恆定。

這可以透過以下方式實現 -

• 強調來自客戶的持續反饋

• 短期迭代

• 設計和重新設計

• 頻繁編碼和測試

• 儘早消除缺陷，從而降低成本

• 讓客戶始終參與開發

• 向客戶交付可工作的產品

極限程式設計概覽

極限程式設計涉及 -

• 在程式設計之前編寫單元測試，並始終保持所有測試執行。單元測試是自動化的，可以儘早消除缺陷，從而降低成本。

• 從簡單的設計開始，足以編寫手頭的功能，並在需要時重新設計。

• 結對程式設計（稱為結對程式設計），兩個程式設計師在一臺螢幕上，輪流使用鍵盤。當其中一人在鍵盤上時，另一人會不斷審查並提供輸入。

• 每天整合和測試整個系統多次。

• 快速將最小的工作系統投入生產，並在需要時進行升級。

• 讓客戶始終參與並獲得持續的反饋。

迭代有助於隨著軟體隨著不斷變化的需求而發展而適應變化。

為什麼稱之為“極限”？

極限程式設計將有效的原則和實踐推向極致。

• 程式碼審查非常有效，因為程式碼始終會被審查。

• 測試非常有效，因為存在持續的迴歸和測試。

• 設計非常有效，因為每個人都需要每天進行重構。

• 整合測試很重要，因為每天整合和測試多次。

• 短期迭代非常有效，因為釋出計劃和迭代計劃的計劃遊戲。

極限程式設計的歷史

Kent Beck、Ward Cunningham 和 Ron Jeffries 於 1999 年制定了極限程式設計。其他貢獻者包括 Robert Martin 和 Martin Fowler。

在 80 年代中期，Kent Beck 和 Ward Cunningham 在 Tektronix 啟動了結對程式設計。在 80 年代和 90 年代，Smalltalk 文化產生了重構、持續整合、持續測試和密切的客戶參與。這種文化後來被推廣到其他環境中。

在 90 年代初，核心價值觀在模式社群、山坡小組中發展起來。1995 年，Kent 在 Smalltalk 最佳實踐中總結了這些內容，1996 年，Ward 在劇集中總結了這些內容。

1996 年，Kent 在 Hewitt 添加了單元測試和隱喻。1996 年，Kent 承擔了克萊斯勒 C3 專案，Ron Jeffries 被新增為教練。這些實踐在 C3 上得到改進，並在 Wiki 上釋出。

Scrum 實踐被納入並改編為計劃遊戲。1999 年，Kent 出版了他的著作《極限程式設計解釋》。同年，Fowler 出版了他的著作《重構》。

極限程式設計自那時以來一直在發展，並且這種發展一直持續到今天。

行業成功

遵循極限程式設計實踐的專案的成功歸因於 -

• 快速開發。

• 立即響應客戶不斷變化的需求。

• 專注於低缺陷率。

• 系統持續向客戶提供一致的價值。

• 高客戶滿意度。

• 降低成本。

• 團隊凝聚力和員工滿意度。

極限程式設計的優勢

極限程式設計解決了軟體開發專案中經常遇到的以下問題 -

• 計劃延誤 - 可實現的開發週期確保按時交付。

• 專案取消 - 專注於持續的客戶參與確保與客戶的透明度以及立即解決任何問題。

• 更改產生的成本 - 廣泛且持續的測試確保更改不會破壞現有功能。始終執行的工作系統始終確保有足夠的時間來適應更改，以便不會影響當前操作。

• 生產和交付後缺陷：重點在於 - 單元測試以儘早檢測和修復缺陷。

• 誤解業務和/或領域 - 使客戶成為團隊的一部分，確保持續溝通和澄清。

• 業務變更 - 變更被認為是不可避免的，並且可以在任何時候進行調整。

• 員工流動率 - 密集的團隊協作確保熱情和善意。多學科的凝聚力培養了團隊精神。

極限程式設計 - 價值觀和原則

XP 旨在透過引入基本價值觀、原則和實踐來降低變更成本。透過應用 XP，系統開發專案應該在變更方面更加靈活。

極限程式設計價值觀

極限程式設計 (XP) 基於五個價值觀 -

• 溝通

• 簡單性

• 反饋

• 勇氣

• 尊重

溝通

溝通在專案的成功中起著重要作用。專案問題通常是由於缺乏溝通造成的。許多情況都可能導致溝通中斷。一些常見問題包括 -

• 開發人員可能不會將設計中的關鍵更改告知其他人。

• 開發人員可能沒有向客戶提出正確的問題，因此錯過了關鍵的領域決策。

• 經理可能沒有向開發人員提出正確的問題，導致專案進度被錯誤地報告。

• 開發人員可能忽略了客戶傳達的一些重要資訊。

極限程式設計強調團隊成員、經理和客戶之間持續不斷的溝通。極限程式設計實踐，例如單元測試、結對程式設計、簡單設計、通用隱喻、集體程式碼所有權和客戶反饋，都關注溝通的價值。

XP 採用教練的角色，其工作是觀察人們是否沒有進行溝通，並在必要時重新引導他們。面對面溝通是首選，可以透過結對程式設計來實現，並且客戶代表始終在場。

簡單性

極限程式設計認為“今天做一件簡單的事情，明天花一點額外代價來修改它”，比“今天做一件可能永遠不會被使用到的複雜的事情”更好。

• 做需要做的事情和被要求做的事情，但不要做更多。

  • “做最簡單的能起作用的事情”——DTSTTCPW 原則。

  • 以最簡單的方式實現新的功能。也稱為 KISS 原則，“保持簡單，傻瓜！”。

  • 當教練看到極限程式設計開發人員做一些不必要複雜的事情時，可能會說 DTSTTCPW。

  • 重構系統，使其成為具有當前功能集的最簡單的程式碼。這將最大化迄今為止所做投資所產生的價值。

• 朝著目標邁出小而簡單的步伐，並在發生故障時進行緩解。

• 創造一些你感到自豪的東西，並以合理的成本長期維護它。

• 永遠不要實現你現在不需要的功能，即“你不會需要它”（YAGNI）原則。

溝通和簡單性相互支援。

你溝通得越多，就能越清楚地看到需要做什麼，並且對真正不需要做什麼的事情更有信心。

你的系統越簡單，你就需要溝通的內容越少，需要的開發人員也越少。這將帶來更好的溝通。

反饋

每次迭代的承諾都會透過交付可工作的軟體來認真對待。軟體儘早交付給客戶，並獲取反饋，以便在需要時進行必要的更改。關於系統當前狀態的具體反饋是無價的。反饋的價值在於一個持續執行的系統，該系統以可靠的方式提供關於自身的資訊。

在極限程式設計中，在不同時間尺度上的所有級別都確保了反饋 -

• 客戶告訴開發人員他們感興趣的功能，以便開發人員可以只專注於這些功能。

• 單元測試告訴開發人員系統的狀態。

• 系統和程式碼向經理、利益相關者和客戶提供關於開發狀態的反饋。

• 頻繁釋出使客戶能夠執行驗收測試並提供反饋，並使開發人員能夠根據該反饋開展工作。

• 當客戶編寫新的功能/使用者故事時，開發人員會估算交付更改所需的時間，以便與客戶和經理設定期望。

因此，在極限程式設計中，反饋 -

• 充當變革的催化劑

• 指示進度

• 讓開發人員確信他們走在正確的道路上

勇氣

極限程式設計以以下方式為開發人員提供勇氣 -

• 專注於所需內容

• 溝通並接受反饋

• 如實告知進度和估算

• 重構程式碼

• 適應發生的任何變化

• 丟棄程式碼（原型）

這是可能的，因為沒有人單獨工作，並且教練持續指導團隊。

尊重

尊重是一個深層的價值觀，它存在於其他四個價值觀的表面之下。在極限程式設計中，

• 每個人都尊重彼此作為寶貴的團隊成員。

• 每個人都貢獻價值，例如熱情。

• 開發人員尊重客戶的專業知識，反之亦然。

• 管理層尊重開發人員接受責任並對其自身工作擁有權威的權利。

結合溝通、簡單性和具體反饋，勇氣變得極其寶貴。

• 溝通支援勇氣，因為它為更多高風險、高回報的實驗打開了可能性。

• 簡單性支援勇氣，因為對於簡單的系統，你可以承擔更大的勇氣。你不太可能在不知情的情況下破壞它。

• 勇氣支援簡單性，因為一旦你看到簡化系統的可能性，你就會嘗試它。

• 具體反饋支援勇氣，因為如果你能看到測試最終變綠，你會覺得嘗試對程式碼進行激進的修改更加安全。如果任何測試沒有變綠，你就知道可以丟棄該程式碼。

極限程式設計原則

價值觀很重要，但它們很模糊，從某種意義上說，可能無法確定某件事是否有價值。例如，從某人的角度來看很簡單的事情，從其他人的角度來看可能很複雜。

因此，在極限程式設計中，基本原則源於價值觀，以便可以根據這些原則檢查開發實踐。每個原則都體現了價值觀，並且更具體，例如快速反饋 - 你要麼擁有它，要麼沒有。

極限程式設計的基本原則為 -

• 快速反饋

• 假設簡單性

• 增量變化

• 擁抱變化

• 高質量工作

快速反饋

快速反饋是為了獲取反饋，理解它，並儘快將學習成果反饋到系統中。

• 開發人員設計、實現和測試系統，並在幾秒鐘或幾分鐘內使用該反饋，而不是幾天、幾周或幾個月。

• 客戶審查系統以檢查它如何才能做出最佳貢獻，並在幾天或幾周內提供反饋，而不是幾個月或幾年。

假設簡單性

假設簡單性就是將每個問題都視為可以用簡單的方式解決。

傳統上，你會被告知要為未來計劃，為重用而設計。這種方法的結果可能變成“客戶今天需要的沒有得到滿足，最終交付的內容可能已經過時且難以更改。”

“假設簡單性”意味著“做好今天工作的準備，並相信你能夠在未來需要的地方新增複雜性。”在極限程式設計中，你會被告知要做好工作（測試、重構和溝通），專注於今天重要的事情。

• 有了良好的單元測試，你可以輕鬆地重構程式碼以進行其他測試。

• 遵循 YAGNI（你不會需要它）。

• 遵循 DRY（不要重複自己）原則。例如，

  • 不要有多個相同（或非常相似）程式碼的副本。

  • 不要有多個冗餘的資訊副本。

  • 不要浪費時間和資源在可能不需要的事情上。

增量變化

在任何情況下，一次性進行的重大更改都無法奏效。任何問題都可以透過一系列最小的更改來解決，這些更改會帶來變化。

在極限程式設計中，增量變化以多種方式應用。

• 設計每次都稍作更改。

• 計劃每次都稍作更改。

• 團隊每次都稍作更改。

即使是極限程式設計的採用也必須分步驟進行。

擁抱變化

最佳策略是在實際解決最緊迫問題的同時保留最多的選項。

高質量工作

每個人都喜歡做好工作。他們試圖產生他們感到自豪的質量。團隊

• 工作良好

• 享受工作

• 在生產有價值的產品時感覺良好

極限程式設計 - 實踐

極限程式設計中有四項基本活動。他們是 -

• 編碼

• 測試

• 傾聽

• 設計

根據極限程式設計原則對這四項基本活動進行結構化。為了實現這一點，定義了極限程式設計實踐。

這 12 種極限程式設計實踐實現了極限程式設計的目標，並且在其中一種實踐薄弱的情況下，其他實踐的優勢將彌補不足。

《極限程式設計解釋》的作者肯特·貝克將 12 種極限程式設計實踐定義如下 -

• 計劃遊戲

• 短迭代

• 隱喻

• 簡單設計

• 測試

• 重構

• 結對程式設計

• 集體程式碼所有權

• 持續整合

• 40 小時工作制

• 現場客戶

• 編碼規範

極限程式設計的四個領域

極限程式設計實踐可以分為四個領域 -

• 快速、精細的反饋 -

  • 測試

  • 現場客戶

  • 結對程式設計

• 持續流程 -

  • 持續整合

  • 重構

  • 短迭代

• 共享理解 -

  • 計劃遊戲

  • 簡單設計

  • 隱喻

  • 集體程式碼所有權

  • 編碼規範

• 開發人員福利 -

  • 40 小時工作制

在本章中，您將詳細瞭解極限程式設計實踐以及每種實踐的優勢。

極限程式設計實踐一覽

下圖顯示了極限程式設計是如何圍繞極限程式設計實踐展開的 -

計劃遊戲

極限程式設計中的主要計劃流程稱為計劃遊戲。遊戲是在每次迭代（通常每週一次）進行的會議。計劃遊戲的目的是透過結合業務優先順序和技術估算，快速確定下一次釋出的範圍。隨著現實超越計劃，更新計劃。

業務和開發需要同步做出決策。業務決策和開發的技術決策必須相互一致。

業務人員需要決定 -

• 範圍 - 為使系統在生產中具有價值，必須解決多少問題？業務人員能夠理解什麼是不夠的，什麼太多了。

• 優先順序 - 如果給您一個選擇，您想要哪個？業務人員能夠確定這一點，而不是開發人員，但需要客戶的輸入。

• 釋出構成 - 在業務從軟體中獲得比沒有軟體更好的收益之前，需要做多少或多做多少？開發人員對這個問題的直覺可能完全錯誤。

• 釋出日期 - 在哪些重要的日期軟體（或部分軟體）的存在會產生重大影響？

技術人員需要決定 -

• 估算 - 實現一項功能需要多長時間？

• 後果 - 只有在瞭解技術後果的情況下，才應做出戰略性業務決策。開發需要解釋後果。

• 流程 - 工作和團隊將如何組織？團隊需要適應其運營的文化。軟體必須寫得好，而不是保留封閉文化的非理性。

• 詳細排程 - 在釋出範圍內，哪些故事應該首先完成？開發人員需要自由地首先安排最冒險的開發部分，以降低專案的整體風險。在該約束下，他們仍然傾向於將業務優先順序提前到開發中，從而降低了由於時間限制而不得不放棄重要故事的可能性，這些故事可能在釋出開發結束時被放棄。

因此，計劃是客戶、業務人員和開發人員之間協作的結果。

計劃遊戲 - 優勢

計劃遊戲具有以下優勢 -

• 減少浪費在無用功能上的時間

• 提高客戶對功能成本的認識

• 減少計劃中的猜測

短迭代

你應該快速將一個簡單的系統投入生產，然後以非常短的週期釋出新版本。每次釋出都應該儘可能小，以便於它能夠−

• 在短週期內實現

• 包含最有價值和最直接的業務需求

• 成為一個可工作的系統

短週期的持續時間可能會因需要構建的軟體而異。但是，需要確保選擇儘可能短的持續時間。

短週期釋出 - 優勢

短週期釋出的優勢在於−

• 頻繁的反饋

• 跟蹤

• 降低整體專案延期的可能性

隱喻

根據劍橋線上詞典 - 隱喻是一種表達方式，通常見於文學作品中，它透過指代被認為具有與該人物或物體相似特徵的事物來描述一個人或物體。例如，“思想是海洋”和“城市是叢林”都是隱喻。

你應該用一個簡單的共享故事來指導整個開發過程，這個故事講述了整個系統是如何工作的。你可以將隱喻視為要構建的系統的架構，以便所有參與開發的人員都能輕鬆理解。

隱喻由特定領域的元素組成，並展示了它們之間的相互聯絡。使用的語言是領域語言。為了識別技術實體，需要一致地使用隱喻中的詞語。

隨著開發的進行和隱喻的成熟，整個團隊將從檢查隱喻中獲得新的靈感。

良好架構的目標是為每個人提供一個連貫的故事來開展工作，這是一個既可以被業務人員，也可以被技術人員輕鬆共享的故事。因此，在極限程式設計中，透過要求一個隱喻，我們更有可能獲得一個易於溝通和闡述的架構。

隱喻 - 優勢

隱喻的優勢在於−

• 鼓勵為系統使用一套通用的術語

• 減少流行語和行話

• 一種快速簡便的解釋系統的方法

簡單設計

在任何給定時刻，系統都應該儘可能簡單地設計。一旦發現額外的複雜性，就將其移除。

在任何給定時間，軟體的正確設計是−

• 執行所有測試

• 沒有重複的邏輯，例如並行的類層次結構

• 陳述對開發人員至關重要的所有意圖

• 具有儘可能少的類和方法

為了獲得簡單的設計，請消除任何可以消除的設計元素，但不要違反前三個規則。這與“今天實現，明天設計”的建議相反。如果你認為未來是不確定的，並且你可以快速增強設計，那麼不要基於猜測新增任何功能。

簡單設計 - 優勢

簡單設計的優勢在於−

• 不會浪費時間新增多餘的功能

• 更容易理解正在發生的事情

• 重構和集體所有權成為可能

• 幫助程式設計師保持正軌

測試

開發人員持續編寫單元測試，開發需要透過這些測試才能繼續進行。客戶編寫測試以驗證功能是否已實現。測試是自動化的，因此它們成為系統的一部分，並且可以持續執行以確保系統的正常工作。結果是能夠接受更改的系統。

測試 - 優勢

測試的優勢在於−

• 單元測試促進了測試的完整性

• 測試先行為開發人員提供了一個目標

• 自動化提供了一套迴歸測試

重構

在實現功能時，開發人員總是會問是否有辦法更改現有程式碼以簡化功能的新增。在新增功能後，開發人員會問他們現在是否可以看到如何使程式碼更簡單，同時仍然執行所有測試。他們重構系統而不改變其行為以消除重複、改進溝通、簡化或增加靈活性。這稱為重構。

重構 - 優勢

重構的優勢在於−

• 促使開發人員主動改進整個產品

• 提高開發人員對系統的瞭解

結對程式設計

在結對程式設計中，整個程式碼由兩名開發人員在一臺機器上編寫，使用一個鍵盤和一個滑鼠。

每對中都有兩個角色−

• 第一個開發人員（擁有鍵盤和滑鼠的人）思考如何在這裡正確實現此方法。

• 另一個開發人員則從更策略的角度思考

  • 這種整體方法是否有效？

  • 可能還有哪些其他測試用例尚未透過？

  • 是否有辦法簡化整個系統，以便當前問題消失？

結對是動態的。這意味著兩個角色 A 和 B 可以交換位置，或者他們可以與其他團隊成員配對。更常見的是，團隊中的任何人都可以作為搭檔。例如，如果你負責一個你不熟悉的領域的任務，你可能會要求最近有經驗的人與你配對。

結對程式設計 - 優勢

結對程式設計的優勢在於−

• 三個臭皮匠，勝過一個諸葛亮

• 專注

• 兩個人更有可能回答以下問題−

  • 這種整體方法是否有效？

  • 可能還有哪些測試用例尚未透過？

  • 有沒有辦法簡化它？

集體程式碼所有權

在極限程式設計中，整個團隊對整個系統負責。儘管每個人都對每個部分都有一些瞭解，但並非每個人都對每個部分都同樣瞭解。

如果一對開發人員正在工作，並且他們發現有機會改進程式碼，他們就會繼續改進它。

集體所有權 - 優勢

集體所有權的優勢在於−

• 有助於減輕離職團隊成員造成的損失。

• 促使開發人員對整個系統負責，而不是對系統的一部分負責。

持續整合

程式碼每天整合和測試多次，每次一組更改。一個簡單的方法是有一臺專門用於整合的機器。一對準備整合的程式碼−

• 在機器空閒時開始工作。

• 載入當前版本。

• 載入他們的更改（檢查並解決任何衝突）。

• 執行測試，直到它們透過（100% 正確）。

一次整合一組更改有助於瞭解誰應該修復失敗的測試。答案是當前的開發人員對，因為上一對開發人員將測試留在了 100%。他們可能不得不放棄他們所做的事情並重新開始，因為他們可能沒有足夠的知識來編寫該功能。

持續整合 - 優勢

持續整合的優勢在於−

• 縮短了原本漫長的持續時間。

• 由於釋出前所需的時間最少，因此能夠實現短週期釋出的實踐。

40 小時工作制

極限程式設計強調每個團隊成員每週的工作時間有限，基於他們的可持續性，最多每週 45 小時。如果某人工作時間超過此時間，則被視為加班。加班最多允許一週。此實踐是為了確保每個團隊成員都保持精力充沛、富有創造力、謹慎和自信。

40 小時工作制 - 優勢

40 小時工作制的優勢在於−

• 大多數開發人員在工作超過 40 小時後效率會下降。

• 重視開發人員的福祉。

• 迫使管理層找到真正的解決方案。

現場客戶

在團隊中包含一個真實的、活生生的使用者，全天候可用，以回答問題、解決爭議並設定小規模的優先順序。此使用者可能不必僅將 40 小時用於此角色，並且也可以專注於其他工作。

現場客戶 - 優勢

擁有現場客戶的優勢在於−

• 可以對真實的開發問題給出快速且有見地的答案。

• 確保開發出的內容是需要的。

• 功能的優先順序排列正確。

編碼規範

開發人員根據強調以下內容的規則編寫所有程式碼：

• 透過程式碼進行溝通。

• 儘可能少的工作量。

• 與“一次且僅一次”規則一致（沒有重複程式碼）。

• 整個團隊自願採用。

在極限程式設計中，這些規則是必要的，因為所有開發人員−

• 可以從系統的一部分切換到系統的另一部分。

• 每天交換幾次搭檔。

• 不斷重構彼此的程式碼。

如果不遵循這些規則，開發人員將傾向於擁有不同的編碼實踐集，程式碼隨著時間的推移變得不一致，並且無法確定團隊中的誰編寫了哪些程式碼。

編碼標準 - 優勢

編碼標準的優勢在於−

• 減少開發人員花費在重新格式化其他人程式碼上的時間。

• 減少對內部註釋的需求。

• 要求程式碼清晰、明確。

極限程式設計 - 支援性實踐

如果單獨實施極限程式設計實踐，可能會很薄弱，因此可能會失敗。在極限程式設計中，所有實踐都需要作為一個整體來考慮，以便它們相互支援。一個實踐的弱點會被其他實踐的優勢所彌補。

在本章中，我們將重點關注如果單獨實施每個實踐可能存在的弱點。我們將瞭解極限程式設計如何支援此實踐，以便在與其他實踐結合使用時克服弱點。

計劃遊戲 - 來自其他 XP 實踐的支援

在本節中，我們將瞭解計劃遊戲的弱點以及其他 XP 實踐如何支援它。

計劃遊戲 - 缺點

計劃遊戲的缺點是，你不可能只用一個粗略的計劃就開始開發，並且你不能不斷更新計劃，因為這會花費太長時間並讓客戶感到不安。

計劃遊戲與其他XP實踐

其他XP實踐以以下方式支援計劃遊戲：

• 在計劃遊戲中，客戶也參與到基於開發人員提供的估算更新計劃的過程中。

• 你進行短迭代釋出，以便計劃中的任何錯誤最多隻會造成幾周或幾個月的影響。

• 你的客戶與團隊一起工作，因此他們可以快速發現潛在的變化和改進機會（現場客戶）。

• 持續測試幫助開發人員和客戶決定立即需要什麼。

因此，你可以用一個簡單的計劃開始開發，並在開發過程中不斷完善它。

短迭代釋出 - 其他XP實踐的支援

短迭代釋出 - 缺點

你不可能在幾個月後就投入生產。你當然不可能以每天到每兩個月為週期釋出新版本。這是因為你需要時間來吸收新的需求，並將更改整合到當前程式碼中。

短迭代釋出與其他XP實踐。

其他XP實踐以以下方式支援短迭代釋出：

• 計劃遊戲幫助你處理最有價值的故事，因此即使是一個小型系統也將具有業務價值。

• 持續整合使打包釋出的成本最小化。

• 測試將缺陷率降低到足以使釋出前不需要冗長的測試周期的程度。

• 你可以做一個簡單的設計，足以滿足本次釋出的需求，而不是永遠適用。

因此，你可以在開發開始後不久就進行短迭代釋出。

隱喻 - 其他XP實踐的支援

你不可能只用一個隱喻就開始開發。它可能沒有足夠的細節，而且你可能是錯的。

隱喻與其他XP實踐

其他XP實踐以以下方式支援隱喻：

• 透過結對程式設計，你將從已實現的程式碼和測試中獲得關於隱喻是否正常工作的快速具體反饋。

• 你的現場客戶可以輕鬆地使用隱喻來談論系統。

• 持續重構允許你改進你對隱喻在實現中含義的理解。

• 簡單設計幫助你與隱喻建立對映關係。

因此，你可以只用一個隱喻開始開發。

簡單設計 - 其他XP實踐的支援

簡單設計 - 缺點

你不可能只為今天的程式碼設計足夠的設計，並且你的設計可能無法繼續發展系統。

簡單設計與其他XP實踐。

其他XP實踐以以下方式支援簡單設計：

• 重構允許你進行更改。

• 透過一個整體的隱喻，你可以確定未來的設計更改將趨向於遵循一個收斂路徑。

• 結對程式設計幫助你確信你正在進行一個有效的工作的簡單設計。

• 40小時工作制幫助你專注於正確的設計。

• 持續單元測試和客戶測試確保你的簡單設計在正軌上。

因此，你可以為今天做出儘可能好的設計，而無需進行推測。

測試 - 其他XP實踐的支援

測試 - 缺點

你可能會認為：

• 你不可能編寫所有這些測試。

• 編寫測試可能需要花費太多時間。

• 開發人員不會編寫測試。

測試與其他XP實踐

其他XP實踐以以下方式支援測試：

• 簡單設計使編寫測試變得容易。

• 重構允許你決定哪些測試是必要的。

• 透過結對程式設計，即使你想不出另一個測試，你的搭檔也能想到。你可以讓你的搭檔接管鍵盤執行測試，當你看到所有測試都執行成功時，你會感到自信。

• 集體程式碼所有權確保擁有所需技能的開發人員正在處理任何複雜的編碼和測試部分。

• 持續整合並立即執行開發人員對進行的每一組更改的測試，確保：

  • 如果100%的測試透過，則新程式碼有效，或者

  • 如果任何測試失敗，則說明是該對的程式碼導致系統失敗，以便可以立即撤消更改，並且該對可以重新開始編碼，並清楚地瞭解他們正在實現的功能。

• 短迭代釋出確保為客戶提供一個可執行的系統以進行測試並提供反饋。

• 線上客戶將有時間執行所有測試並立即對正在執行的系統提供反饋。

• 計劃遊戲確保在測試後從客戶那裡獲取反饋，以便計劃下一次釋出。

因此，開發人員和客戶將編寫測試。此外，測試是自動化的，以確保極限程式設計其餘部分的工作。

重構 - 其他XP實踐的支援

重構 - 缺點

你不可能一直重構系統的設計。它會：

• 花費太長時間。

• 難以控制，並且

• 很可能破壞系統。

重構與其他XP實踐

其他XP實踐以以下方式支援重構：

• 透過集體程式碼所有權，你可以在任何需要的地方進行更改。

• 透過編碼規範，你無需在重構前重新格式化。

• 透過結對程式設計，你可以有勇氣應對艱鉅的重構任務。

• 透過簡單設計，重構更容易。

• 透過隱喻，你可以輕鬆地進行溝通。

• 透過測試，你不太可能在不知情的情況下破壞某些東西。

• 透過持續整合，如果你不小心破壞了某些東西，或者你的重構與其他人的工作衝突，你將在幾個小時內知道。

• 透過40小時工作制，你休息得很好，因此你更有勇氣，也更不容易犯錯。

因此，每當你看到機會時，你都可以重構：

• 使系統更簡單

• 減少重複

• 更清晰地進行溝通

結對程式設計 - 其他XP實踐的支援

結對程式設計 - 弱點

你不可能所有程式碼都結對編寫。這會太慢了。如果兩個人相處不好，情況會變得很困難。

結對程式設計與其他XP實踐。

其他XP實踐以以下方式支援結對程式設計：

• 編碼規範減少了衝突。

• 透過40小時工作制，每個人都精力充沛且專注，進一步降低了不必要討論的可能性。

• 結對編寫測試，讓他們有機會在解決實現部分之前統一他們的理解。

• 隱喻幫助結對確定關於命名和基本設計的決策。

• 簡單設計使結對能夠達成共識。

• 重構幫助結對討論並在使系統更簡單的過程中做出聯合決策。

• 持續整合讓結對有機會糾正任何錯誤，因此當另一方進行一些實驗時，搭檔不會反對。

• 集體程式碼所有權使團隊能夠混合搭配，並允許他們保持融洽的關係。

因此，你可以所有程式碼都結對編寫。另一方面，如果團隊單獨工作，他們更有可能犯錯誤、過度設計並忽略其他實踐。

集體程式碼所有權 - 其他XP實踐的支援

集體程式碼所有權 - 缺點

你不可能讓每個人在系統的任何地方更改任何內容。因為有可能在不知情的情況下破壞系統，並且整合成本將急劇上升。

集體程式碼所有權與其他XP實踐

其他XP實踐以以下方式支援集體程式碼所有權：

• 持續整合減少了衝突的可能性。

• 測試減少了意外破壞事物的可能性。

• 透過結對程式設計，你不太可能破壞程式碼，並且開發人員可以更快地學習他們可以有效更改的內容。

• 透過編碼規範，你將不會在程式碼上發生衝突。

• 透過重構，你保持系統簡單，以便每個人都能理解它。

因此，當他們看到改進的機會時，可以讓人在系統的任何地方更改程式碼。另一方面，如果沒有集體程式碼所有權，設計的演變速度會急劇下降。

持續整合 - 其他XP實踐的支援

持續整合 - 缺點

你不可能在僅工作幾個小時後就進行整合，因為整合需要很長時間，並且存在太多衝突以及意外破壞某些東西的可能性。

持續整合與其他XP實踐

其他XP實踐以以下方式支援持續整合：

• 測試可以快速幫助你瞭解你沒有破壞任何東西。

• 透過結對程式設計，需要整合的更改流減少了一半。

• 透過重構，程式碼被分解成更小的部分，從而減少了衝突的可能性。

• 透過編碼規範，程式碼將保持一致。

• 短迭代釋出確保對系統提供即時反饋。

• 集體程式碼所有權確保無論誰更改程式碼並進行整合，都將對系統有一個完整的瞭解。

因此，你可以在幾個小時後進行整合。另一方面，如果你不快速整合，那麼衝突的可能性就會增加，並且整合的成本也會急劇上升。

40小時工作制 - 其他XP實踐的支援

40小時工作制 - 缺點

你不可能每週工作40個小時。你無法在40個小時內創造足夠的業務價值。

40小時工作制與其他XP實踐

其他XP實踐以以下方式支援40小時工作制：

• 計劃遊戲為你提供更多有價值的工作要做。

• 計劃遊戲和測試的結合確保你只需要處理你認為需要處理的事情。

• 簡單設計和重構允許你保持專注並按時完成。

• 結對程式設計幫助你處理你能處理的事情，並將其他工作與你的搭檔共享。

• 這些實踐作為一個整體幫助你以最高速度開發，因此你無法更快地開發。

因此，您可以在每週 40 小時內創造足夠的業務價值。另一方面，如果團隊沒有保持精力充沛，那麼他們將無法執行其餘的實踐。

現場客戶 – 來自其他 XP 實踐的支援

現場客戶 – 缺點

您不可能讓一個真正的客戶全職加入團隊，而不產生任何價值。他們在其他地方可以為企業創造更大的價值。

現場客戶與其他 XP 實踐

其他 XP 實踐以以下方式支援現場客戶。

他們可以為專案創造價值 -

• 在計劃遊戲（Planning Game）中，為開發人員做出優先順序和範圍決策。

• 使用隱喻（Metaphor），為開發人員提供領域清晰度。

• 在測試中，透過編寫驗收測試並在每次短髮布後執行驗收測試。

因此，他們可以透過為專案做出貢獻，為組織創造更多價值。

編碼標準 – 來自其他 XP 實踐的支援

編碼標準 – 缺點

您不可能要求團隊按照共同的標準進行編碼，因為開發人員通常是個人主義者。

編碼標準與其他 XP 實踐

其他 XP 實踐以以下方式支援編碼標準 -

• 結對程式設計使他們能夠輕鬆地適應必要的編碼標準。

• 持續整合強制他們遵循標準，以便程式碼保持一致。

• 集體程式碼所有權鼓勵他們與標準保持一致，以便在需要時進行更改。

極限程式設計 - 演進實踐

極限程式設計自誕生以來一直在不斷發展，並且發現極限程式設計實踐在其他敏捷方法中也同樣有效。

下表顯示了極限程式設計實踐是如何演變的。

現場客戶 – 完整團隊

極限程式設計依賴於一個專案社群，強調以團隊為中心的方法。所有對極限程式設計專案做出貢獻的人，包括客戶，都是一個團隊。

客戶提供需求，設定優先順序並指導專案。這使客戶能夠了解開發的實際細節，並相應地設定優先順序和期望。這從“按客戶要求開發”轉變為“按客戶理解並與開發合作”。

專案目標是共同的責任，開發是在整個團隊中進行的持續對話。這是一場發明和溝通的合作遊戲。人們發現面對面的溝通是開發過程中最高效、最有效的方法，並且消除了等待時間和延遲。

計劃遊戲 – 釋出和迭代計劃

增量專案計劃被證明是有效的，因為它促進了準確的計劃。隨著開發的進展，基於實際效能，會學習到更多更好的資訊。首先制定一個粗略的計劃，然後逐步細化它。

釋出計劃設定長期目標，並掌握整體的大局觀。客戶提出所需的功能，開發人員進行估算，並共同商定和承諾釋出日期。由於釋出計劃在每次釋出後都會進行修訂，因此隨著專案的進展，它會變得更加精確。

迭代計劃設定短期時間框，包括迭代，通常從 1 周到 1 個月不等。迭代計劃的主要目標是在每次迭代結束時獲得一個可工作的軟體。開發人員選擇迭代的功能/故事，將其分解成任務，估計任務並承諾完成分配的任務。透過平衡團隊中的負載因素，並考慮 40 小時工作制，確保可持續的節奏。

驗收測試

客戶為一個功能編寫一個或多個自動驗收測試，以確保系統正確地實現了所需的功能。驗收測試與故事一起編寫，並在實施之前提供。

團隊自動化這些測試，以驗證功能是否正確實現。一旦測試執行，團隊確保它此後繼續正確執行，在迴歸時，透過執行到那時為止實施的所有驗收測試。

驗收測試提供了功能需求的明確規範。此外，透過驗收測試的百分比衡量了釋出完成情況，沒有最後一刻的意外。

系統始終改進，永不倒退。

單元測試

開發人員編寫單元測試，並具有足夠的覆蓋率，包含程式碼模組和方法的意圖和用法。單元測試是自動化的，具有明確的透過/失敗結果。大多數語言都有一個 xUnit 框架（例如，nUnit、jUnit）。

所有單元測試都非常頻繁地執行，並且在所有單元測試透過之前，程式碼不能被簽入。單元測試結果還有助於重構。

測試驅動開發

測試驅動開發被認為是最具創新性的極限程式設計實踐。

在測試驅動開發中，開發人員在編寫程式碼之前編寫單元測試。目的是使單元測試失敗。由於程式碼尚未實現，因此單元測試失敗。開發人員編寫足夠多的程式碼以使單元測試透過，然後，開發人員進行重構以確保程式碼簡單幹淨（沒有重複和複雜性）。

開發人員迭代直到編碼完成並且驗收測試透過。

所有單元測試都收集在一起，每次結對整合並將程式碼釋出到儲存庫時，結對都需要確保每個測試都正確執行。如果任何測試失敗，則結對知道是他們的程式碼需要更正，因為之前的整合在沒有任何缺陷的情況下通過了。

測試驅動開發傾向於導致 100% 的單元測試覆蓋率，並確保程式碼簡單且最少。

重構 – 設計改進

重構允許設計逐步發展，使其保持簡單，在您注意到時消除重複和複雜性。它透過重構改進現有程式碼的設計，而不改變其功能。

重構應由從新實現中學習來驅動。建議在編寫新程式碼後立即進行重構。重構將程式碼推向更高級別的設計模式，並得到測試的支援。

40 小時工作制 – 可持續節奏

以可以無限期持續的速度工作。可持續節奏確保人力對專案成功的貢獻，考慮到以下事實 -

• 疲勞和壓力會降低生產力和產品質量。它可能導致員工流失。

• 開發不會隨著衝刺而停止，它應該以長期目標為目標

• 除非團隊就期望達成一致，否則不會有承諾和責任感。

• 確切的小時數並不像執行能力那樣重要。

• 應避免微觀管理，同時確保在需要時可用。

極限程式設計 - 過程週期

極限程式設計是一種敏捷過程。

極限程式設計是一種敏捷過程，因為它 -

• 強調大量的溝通和反饋 -

  • 團隊內部（結對程式設計、集體程式碼所有權、簡單設計）

  • 與客戶（現場客戶和驗收測試）

  • 對於釋出計劃（客戶和開發人員參與估算）

• 極限程式設計聘用了一位教練，其工作是注意人們何時沒有進行溝通並重新引入溝通。

• 擁抱變化 -

  • 頻繁迭代（短髮布）

  • 輕鬆設計和重新設計（簡單設計）

  • 持續編碼和測試（結對程式設計）

  • 讓客戶持續參與（線上客戶）

• 以短迭代向客戶交付可工作的產品（短髮布）。

• 儘早消除缺陷，從而降低成本（結對程式設計）

  • 程式碼審查

  • 單元測試

  • 每次更改集的整合和測試

極限程式設計過程週期

極限程式設計是迭代和增量的，並由時間盒週期驅動。因此，極限程式設計過程的節奏至關重要。

極限程式設計具有以下活動級別 -

• 產品生命週期

• 釋出

• 迭代

• 任務

• 開發

• 反饋

每個活動級別都提供下一級別所需的最小輸入。它們是 -

• 產品生命週期活動為釋出週期提供輸入。

• 釋出計劃會議為迭代週期提供輸入。

• 迭代計劃會議為任務週期提供輸入。

• 任務開發為開發階段提供輸入。

• 開發產生產品。

反饋是貫穿整個專案和所有上述活動級別的持續活動。

產品生命週期

這也被稱為探索階段。它涉及功能集的定義和計劃。客戶確定高價值需求，並將需求作為使用者故事提供。

故事是此級別活動的首要交付成果。

釋出

這也被稱為承諾階段。在此活動中 -

• 整個團隊聚集在一起，以便 -

  • 審查進度。

  • 可以新增新的需求和/或更改或刪除現有的需求。

  • 客戶提出故事。

  • 討論故事。

• 開發人員確定技術方法和風險。他們提供第一級估計和選項。

• 客戶對故事進行優先順序排序並選擇目標釋出時間框。

• 客戶和開發人員承諾要包含的功能以及下一次釋出的日期。

• 開發人員 -

  • 將故事安排到可能的迭代中。

  • 包含來自先前釋出的驗收測試的缺陷修復。

  • 開始迭代。

釋出計劃是此級別活動的首要交付成果。

迭代

這也被稱為指導階段。整個團隊聚集在一起，以便審查進度並調整計劃。客戶提出迭代的故事，並更詳細地討論這些故事。

迭代計劃是此活動的首要交付成果。

開發人員 -

• 確定詳細的技術方法。

• 為每個故事建立任務列表。

• 開始開發。

• 部署系統到

可部署系統是此活動的最終交付成果。

任務

開發人員註冊任務並開始開發階段以實施故事。他們確保迭代的任務已完成。開發人員還確保迭代的故事已完成驗收測試。

開發

開發人員組成結對，這可以是一個持續的和動態的活動。

每對 -

• 驗證他們對故事的理解。

• 確定詳細的實施方法，確保簡單設計。

• 開始測試驅動開發，即編寫單元測試，實現程式碼以透過單元測試，重構以使程式碼簡單。

• 在適當的間隔將他們的程式碼整合到系統程式碼庫中。

• 經常審查進度。

反饋

結對在內部以及向團隊外部進行持續溝通。線上客戶也持續參與溝通。某些團隊採用每日站立會議，以便快速討論整體團隊狀態以及必要的重新同步和微觀計劃。

迭代和釋出審查提供整體狀態和流程調整和改進的要點。

• 開發階段可能會導致對任務的重新思考。

• 任務開發可能會導致對故事的重新思考。

• 故事重新估算可能導致迭代更改或恢復。

• 迭代結果可能會導致釋出計劃發生變化。

極限程式設計流程週期如下圖所示。

極限程式設計 - 成對程式設計

成對程式設計是一種程式設計風格，其中兩位程式設計師並排坐在一臺電腦前，共享一個螢幕、鍵盤和滑鼠，持續協作完成相同的設計、演算法、程式碼或測試。

一位程式設計師，稱為**駕駛員**，控制鍵盤/滑鼠並主動實現程式碼或編寫測試。另一位程式設計師，稱為**領航員**，持續觀察駕駛員的工作以識別缺陷，並從戰略上思考工作的方向。

如有必要，兩位程式設計師可以一起頭腦風暴任何具有挑戰性的問題。兩位程式設計師定期輪換角色，並平等合作開發軟體。

結對程式設計 - 優勢

成對程式設計的顯著優勢包括：

• 許多錯誤在輸入時就被檢測到，而不是在質量保證測試或現場檢測到。

• 最終缺陷數量在統計上較低。

• 設計更好，程式碼長度更短。

• 團隊解決問題更快。

• 人們對系統和軟體開發的瞭解顯著增加。

• 專案最終會有多人理解系統的每個部分。

• 人們學會一起工作並更頻繁地交流，從而改善資訊流和團隊動態。

• 人們更享受他們的工作。

成對程式設計實驗

成對程式設計實踐的使用已被證明可以提高軟體產品的生產力和質量。

成對程式設計研究表明：

• 成對程式設計的人工時不超過單人程式設計。

• 成對程式設計產生的缺陷更少。

• 成對程式設計產生的程式碼行數更少。

• 成對程式設計的人更享受他們的工作。

猶他大學對成對程式設計進行了實驗。結果表明：

• 成對程式設計的團隊在程式上花費的時間比個人多 15%。

• 成對程式設計編寫的程式碼始終透過的測試用例多於個人編寫的程式碼。

• 成對程式設計始終使用更少的程式碼行實現了個人實現的相同功能。

• 在能夠快速獲得切實結果的環境中學習程式設計很有趣，並且可以讓人更快地學習。

適應成對程式設計

大多數程式設計師習慣於獨自工作，並且常常抵制向成對程式設計的轉變。但是，透過實踐，他們最終可以實現這種轉變。

根據 Laurie A. Williams 和 Robert R. Kessler 在他們的書《我在幼兒園學到的關於成對程式設計的所有知識》中，很好地解釋瞭如何培養我們在幼兒園學到的技能，以建立團隊凝聚力，尤其是在成對程式設計中。

作為一名成對程式設計師的轉變和持續成功通常涉及練習日常禮儀。

以下部分摘自此出版物，可幫助您成為高效的成對程式設計師。

幼兒園課程

在幼兒園，我們學習了以下內容：

• 分享一切

• 公平競爭

• 不要打人

• 把東西放回原處

• 清理自己的垃圾

• 不要拿不屬於你的東西

• 當你傷害別人時說對不起

• 飯前洗手

• 沖水

• 暖烘烘的曲奇和冰牛奶對你有益

• 過平衡的生活——每天學習一些，思考一些，畫畫，唱歌，跳舞，玩耍和工作。

• 每天下午小睡一下

• 當你走出去的時候，注意交通，手牽手，團結在一起

• 感知奇蹟

接下來，我們從上述教誨的角度來看成對程式設計的原則。

分享一切

在成對程式設計中，

• 兩位程式設計師坐在一起，共同製作一個工件（設計、演算法、程式碼等）。

• 一個人在打字或書寫，另一個人在持續審查工作。兩者

  • 都是流程中平等的參與者

  • 對工件的各個方面負責

  • 擁有所有權

公平競爭

在成對程式設計中，

• 一個人駕駛，即控制鍵盤或記錄設計思路，另一個人持續審查工作。

• 他們定期輪換這些角色，即使其中一個人比另一個人經驗豐富得多，以確保平等參與。

• 當駕駛員思考實現時，另一個人持續審查程式碼，思考可能的更簡單的設計，當前開發如何融入當前的整體系統。

不要打你的搭檔

在成對程式設計中，

• 確保你的搭檔保持專注和任務導向。

• 你也要保持專注和任務導向。

• 確保你的搭檔遵循規定的編碼標準，從而維護對團隊其他成員的承諾。

在成對程式設計調查中，發現實現了巨大的生產力提升和質量改進。這是因為：

• 每個人都讓他們的搭檔保持專注和任務導向，沒有懈怠的可能性。

• 每個工件在生成時都會持續審查，確保質量。

把東西放回原處

在成對程式設計中，

• 你需要相信自己的技能和你搭檔的技能。這方面的任何負面想法都應該扔進垃圾桶。

• 你必須確保你表達你所知道的，並在需要時願意向你的搭檔學習。你可以透過觀察他或立即獲取他的反饋來向你的搭檔學習。

• 你需要有信心：

  • 無論何時有落後的可能性，你都可以立即從你的搭檔那裡接手。

  • 作為一對，你們可以解決自己無法解決的問題。

  • 你們可以幫助提高彼此的技能。

清理你的垃圾

在成對程式設計中，使用“肩並肩觀察”技術，

• 你會發現，知道你的搭檔發現了多少明顯但未被注意的缺陷是一件令人驚奇的事情。

• 你可以消除這些缺陷，而不會在正式的檢查會議中產生可能產生的自然敵意。

• 描述缺陷預防和缺陷消除效率。

不要把事情看得太嚴重

擁有一個搭檔來持續客觀地審查設計和程式碼是成對程式設計的一個非常有益的方面。在成對程式設計中，你需要確保你在工作中沒有過度的自我或過少的自我。

這是必要的，因為

• 過度的自我可以表現為兩種方式：

  • 擁有“我的方式或高速公路”的態度可能會阻止程式設計師考慮他人的想法。

  • 具有防禦性可能會導致程式設計師不接受建設性批評或將這種批評視為不信任。

這兩種自我表現方式都會損害合作關係。

• 另一方面，一個總是同意搭檔意見以避免產生緊張氣氛的人也會最大限度地減少協作工作的益處。為了進行有利的想法交流，在需要時應該有一些健康的意見分歧/辯論。

因此，需要在表現出太多自我和太少自我之間取得微妙的平衡。有效的成對程式設計師在最初的調整期內培養這種平衡，根據個人、工作性質和他們過去在成對程式設計方面的經驗，調整期可能需要幾個小時或幾天。

當你搬動傢俱時，如果不小心傷害了別人，要道歉

程式設計師必須能夠並排坐在一起程式設計，同時檢視電腦螢幕並共享鍵盤和滑鼠。極限程式設計師有一個“滑動鍵盤/不要移動椅子”的規則。

為了確保有效溝通，無論是在協作對內部還是與其他協作對之間，程式設計師都需要能夠看到彼此，互相提問並在諸如整合問題等方面做出決策，而無需付出太多努力。程式設計師還可以從聽到其他對話中受益，因為他們可以對這些對話做出至關重要的貢獻。

在你開始之前放棄懷疑

為了成對程式設計的成功，有必要讓兩位搭檔都理解程式設計中協作的價值、益處和體驗的樂趣。這方面任何懷疑都必須在開始時就停止。

經驗表明，擁有一位非常積極和/或經驗豐富的成對程式設計師可以帶領這對搭檔成為一個團結協作的團隊，最終取得勝利。

• 這樣一個團隊的產出大於相同人員以非團結形式工作時的產出。

• 人們從工作中獲得的樂趣大於你根據工作本身的性質所期望的樂趣。

• 一旦團隊開始凝聚，成功的可能性就會大幅上升。

沖水

成對程式設計師可以獨立地完成某些工作。但是，當他們重新加入時，他們必須在合併之前審查獨立的工作，或者沖洗並重寫獨立的工作，並持續審查工作，從而識別額外的缺陷。

在沒有搭檔審查的情況下，永遠不要合併任何獨立的工作。這是因為研究表明，與成對產生的工作相比，獨立工作存在缺陷。

暖烘烘的曲奇和冰牛奶對你有益

成對程式設計師讓彼此持續保持專注和任務導向。這可能非常激烈且精神上令人筋疲力盡。因此，定期休息以保持體力，以便進行另一輪富有成效的成對程式設計。

在休息期間，最好斷開與任務的連線，並在重新開始時以新鮮感來處理它。建議的活動包括檢視電子郵件、打電話、瀏覽網頁或進行零食休息。

過平衡的生活

定期與他人溝通是過平衡生活的關鍵。與你的搭檔和其他程式設計師進行非正式的討論，可以交流有效的想法和高效地傳遞資訊。

每天下午休息一下，不要一直一起工作

沒有必要每天下午都分開工作，但可以接受單獨工作 10-50% 的時間。這是因為：

• 許多程式設計師更喜歡單獨進行實驗性原型設計、艱難的、需要高度集中注意力的難題和邏輯思考。

• 簡單、定義明確和例行的編碼由單獨的程式設計師完成效率更高，然後與搭檔一起審查。

注意交通，手牽手，團結在一起

在成對程式設計中，

• 兩者之間不應該存在競爭。兩者必須一起工作，彷彿工件是由一個人的思想產生的。

• 搭檔需要信任彼此的判斷和對團隊的忠誠。

• 搭檔永遠不應該為任何問題或缺陷責怪另一個搭檔。

意識到兩個大腦的力量

當兩個人一起工作時，每個人都有自己的一套知識和技能，包括：

• 他們能夠有效溝通的共同知識和技能集。

• 允許他們為完成任務做出貢獻的獨特技能。

總之，一對搭檔將：

• 想出比兩人單獨工作時多出兩倍以上的解決方案。

• 更快地縮小到最佳解決方案。

• 更快地實現它，並且質量更高。

因此，成對程式設計是一種強大的技術，因為有兩個大腦始終專注於同一個問題。它迫使一個人完全集中精力解決手頭的問題。

極限程式設計 - 角色

在極限程式設計中，重點是整個團隊的協作，團隊成員在同一個地點並保持持續溝通。

然而，極限程式設計專案的運作需要一些特定的角色，而承擔這些角色的人員則承擔相應的責任，並對其對這些角色的貢獻負責。建議為這些角色分配合適的人員，而不是試圖改變人員以適應這些角色。

極限程式設計中的角色

在極限程式設計中發現有效的角色有：

• 開發人員（一些團隊也稱為程式設計師）
• 客戶
• 經理（也稱為跟蹤者）
• 教練

開發人員

開發人員的角色是極限程式設計中最重要的角色之一。要在極限程式設計中成為一名開發人員，您需要熟悉以下內容：

• 開發人員權利

  • 您有權瞭解需要什麼，並有明確的優先順序宣告。

  • 您有權始終交付高質量的工作。

  • 您有權向同行、上司和客戶尋求並獲得幫助。

  • 您有權進行並更新自己的估算。

  • 您有權承擔自己的責任，而不是被分配責任。

• 您將對此負責的主要責任：

  • 估算使用者故事

  • 從使用者故事中定義任務

  • 估算任務

  • 編寫單元測試

  • 編寫程式碼以透過編寫的單元測試

  • 執行單元測試

  • 重構

  • 持續整合

• 開發人員技能

  • 結對程式設計

  • 溝通 - 必要且細節充分

  • 始終使用隱喻來使用正確的名稱

  • 僅編寫所需程式碼。

  • 保持簡單

• 集體程式碼所有權

  • 如果有人更改了您編寫的程式碼，無論系統中的哪個部分，您都必須信任這些更改並學習。如果更改方向錯誤，您有責任改進情況，但要小心，不要責怪任何人。

  • 準備好承認你的恐懼。記住，您是團隊的一員，勇氣是極限程式設計成功的必要條件。

• 在團隊中以開發人員的身份佩戴不同的帽子，例如：

  • 程式設計師。

  • 架構師和設計師。

  • 介面架構師/UI設計師。

  • 資料庫設計人員和DBA。

  • 運維和網路設計人員。

• 有時開發人員之一必須戴上測試人員的帽子。

  • 幫助客戶選擇和編寫功能測試。

  • 定期執行功能測試。

  • 報告測試結果。

  • 確保測試工具正常執行。

客戶

在極限程式設計中，客戶角色與開發人員角色一樣至關重要，因為客戶應該知道要程式設計什麼，而開發人員應該知道如何程式設計。

這引發了客戶角色某些技能的必要性：

• 以必要和充分的細節編寫所需的故事。

• 培養對專案成功的態度。

• 在無法控制專案的情況下影響專案。

• 不時做出關於所需功能範圍的決策。

• 願意隨著產品發展而改變決策。

• 編寫功能測試。

在極限程式設計中，要求客戶與團隊保持持續溝通，並以單一的聲音與團隊交流。這是因為：

• 客戶可能是多個利益相關者。

• 客戶可能是一個社群。

• 客戶並不總是負責人（代理人）。

• 客戶可以是一個團隊，其成員包括：

  • 產品經理

  • 市場營銷、銷售

  • 業務分析師

  • 終端使用者、他們的經理

  • 業務/系統運維

客戶的主要責任：

• 編寫使用者故事

• 編寫功能測試

• 設定故事的優先順序

• 解釋故事

• 決定關於故事的問題

客戶對這些責任負責。

經理

在極限程式設計中，經理的主要職責：

• 定義計劃遊戲的規則。

• 使團隊和客戶熟悉計劃遊戲的規則。

• 監控計劃遊戲，修復任何偏差，並在需要時修改規則。

• 安排和主持釋出計劃和迭代計劃會議。

• 在團隊進行估算時參與其中，以提供關於現實如何符合他們先前估算的反饋，無論是在團隊層面還是個人層面，這最終有助於他們在下次提出更好的估算。

• 確保團隊在他們透過迭代推進的過程中朝著下一個版本努力，並保持承諾的進度和承諾的功能。

• 跟蹤功能測試缺陷。

• 跟蹤每個團隊成員的實際花費時間。

• 培養獲取所有所需資訊而不干擾團隊工作的能力。經理對這些責任負責。

教練

極限程式設計是團隊中每個人的責任。但是，如果團隊是極限程式設計的新手，那麼教練的角色至關重要。

教練的職責：

• 深入瞭解將極限程式設計應用於專案。

• 確定在出現任何問題時有幫助的極限程式設計實踐。

• 即使在其他人恐慌時也要保持冷靜。

• 默默觀察團隊，只有在預見到重大問題時才幹預，並讓團隊也看到問題。

• 確保團隊能夠自力更生。

• 隨時準備提供幫助。

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

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

XP – 活動

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

• 編碼

• 測試

• 傾聽

• 設計

編碼

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

測試

在結對程式設計中，需要進行測試以確保編碼已完成。如果你不測試，你就不知道什麼時候完成了編碼。

傾聽

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

設計

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

這些活動在以下期間執行：

• 釋出計劃

• 迭代計劃

• 實施

釋出計劃

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

釋出計劃有三個階段：

• 探索階段

• 承諾階段

• 指導階段

釋出計劃 - 探索階段

在探索階段：

• 客戶提供系統的高價值需求的短名單。

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

需求記錄在使用者故事卡片上。為了編寫故事，客戶將在與開發人員的會議中提出一個問題。開發人員將嘗試定義此問題並獲取需求。根據此討論，客戶將編寫一個故事，指出他們希望系統的一部分執行的操作。重要的是開發人員對這個故事沒有影響。

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

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

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

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

• 獲得清晰度

• 避免歧義

• 如果理解方面存在可能的差距，請表達自己

這隻有透過口頭交流才能實現。

釋出計劃 - 承諾階段

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

此階段涉及確定成本、收益和進度影響。在此階段，

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

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

• 開發人員確定實施故事所需的工作量和持續時間（估算）。

• 將選擇將在下一個版本中完成的使用者故事。

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

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

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

• 客戶和開發人員需要了解對下一個版本日期的承諾的可行性。

釋出計劃 - 指導階段

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

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

• 調整計劃。

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

• 以適應更改。

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

• 以瞭解：

  • 要新增的新需求。

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

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

• 得出調整計劃所需的估算，考慮

  • 迄今為止完成的工作。

  • 要新增的新需求。

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

迭代計劃

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

迭代計劃有三個階段：

• 探索階段。

• 承諾階段。

• 指導階段。

迭代計劃 - 探索階段

在探索階段，

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

• 任務記錄在任務卡上。

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

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

迭代計劃 - 承諾階段

在承諾階段，

• 任務分配給開發人員。

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

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

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

• 本文件對任務的估計時間和負載因子進行了比較。

• 負載因子代表在一個迭代中，假設每週工作40小時，每個開發人員理想的實際開發時間。

• 然後，任務在開發人員之間進行平衡。如果某個開發人員的任務量過大，其他開發人員必須接手他/她的一些任務，反之亦然。

迭代計劃 – 方向階段

在方向階段，

• 開發人員會獲得其中一項他/她已承諾的任務的任務卡。

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

實施

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

極限程式設計製品

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

基本的極限程式設計製品包括：

• 使用者故事卡

• 驗收測試

• 估算

• 釋出計劃

• 迭代計劃

• 任務卡

• 設計

• 單元測試用例

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

使用者故事卡

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

• 使用者故事卡：

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

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

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

  • 僅應提供足夠的細節，以便估算實現故事所需的時間。

• 系統中的每個主要功能對應一張卡。

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

• 驅動驗收測試的建立。

驗收測試

驗收測試必須是一項或多項測試，用於驗證故事是否已正確實施。

估算 – 釋出計劃

將用於釋出計劃的故事的工作量和持續時間估算：

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

• 在方向階段計劃調整。

釋出計劃

釋出計劃包含：

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

• 工作量和持續時間估算。

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

任務卡

任務卡：

• 包含實施使用者故事所需的任務。

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

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

估算 – 迭代計劃

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

迭代計劃

迭代計劃包含：

• 為本次迭代選擇的使用者故事

• 任務分配

• 任務估算

設計

設計包含一個簡單的設計，足以滿足使用者故事的實施需求。

單元測試用例

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

客戶和開發人員溝通記錄

客戶和開發人員討論故事以詳細說明細節。儘可能口頭溝通，必要時進行記錄。

極限程式設計 - 規則

考慮你參與的任何運動。你需要遵守該運動或遊戲的規則。同樣，在極限程式設計中，由於整個專案是由團隊成員之間以及與業務方（代表客戶）的協作驅動的，因此需要在專案開始時就制定出某些規則。這些規則應與極限程式設計實踐保持一致。

這些規則為團隊中的每個人提供了一個共同的參考，以便提醒每個人在事情順利進行時以及事情進展不順利時需要做什麼以及如何做。

我們在極限程式設計中提到的遊戲是計劃遊戲。

計劃遊戲的規則

在極限程式設計中，計劃遊戲從第一次釋出計劃會議開始，到最終釋出結束。

您必須在第一次釋出計劃會議之前根據極限程式設計實踐定義計劃遊戲的規則，並將規則告知業務方和團隊。您必須管理專案，確保遵守規則。

但是，在軟體開發中，不可能有一套簡單的規則適用於每個專案。它們可能需要根據業務和團隊進行調整，但不能影響極限程式設計實踐。因此，可以最初制定一套具有必要目標的規則，並且只有在需要時才能在開發過程中修改它們。

遊戲的目標是最大化團隊生產的軟體的價值。從軟體的價值中，您必須扣除其開發成本以及開發過程中產生的風險。

團隊的策略是儘可能少地投入，以儘可能快地將最有價值的功能投入生產，並結合設計和編碼策略來降低風險。

根據第一個可執行系統的技術和業務經驗教訓，業務方清楚地瞭解了現在最有價值的功能是什麼，團隊會快速將其投入生產。

此過程將持續進行迭代和釋出，直到整個開發完成。

計劃遊戲的基本規則可以分為以下幾個方面：

• 計劃

• 管理

• 設計

• 編碼

• 測試

計劃

計劃在釋出計劃和迭代計劃期間進行。兩者的規則相同。

在釋出計劃中，

• 業務方和團隊是參與者。

• 使用故事卡。

• 使用者故事由客戶在故事卡上編寫。

• 使用者故事由客戶在故事卡上編寫。

• 業務方決定要實施的功能的優先順序。

• 團隊根據故事卡提供估算。

• 計劃進行短期的（頻繁的小型）釋出

• 釋出計劃需要雙方達成一致。

• 下一個釋出將被劃分為多個迭代。

每次迭代開始時都會進行迭代計劃。

在迭代計劃中，

• 團隊成員是參與者。

• 使用任務卡。

• 為迭代中選擇的每個故事生成任務卡。

• 團隊成員必須根據任務卡估算任務。

• 每個團隊成員都被分配了任務卡。

• 然後，每個團隊成員必須根據其分配情況重新估算，以：

  • 接受工作。

  • 承擔完成工作的責任。

  • 獲得關於實際花費時間的反饋。

  • 改進估算。

  • 尊重這些估算。

因此，誰可以進行和更改估算的規則是明確的。

• 最終分配是在假設每週工作40小時和負載因子的基礎上完成的。

管理

• 團隊獲得一個專門的開放式工作區。

• 每個工作站的佈置應使兩位開發人員能夠並排坐在一起，並輕鬆滑動鍵盤和滑鼠。

• 設定並管理可持續的節奏（每週工作40小時，並且加班時間不超過一週）。

• 執行計劃遊戲的規則。

• 修復任何違反極限程式設計實踐的行為。

• 確保團隊之間的溝通。

• 避免以下溝通：

  • 無幫助的

  • 不合時宜的

  • 過於詳細的

• 鼓勵人們四處走動。

• 定期測量實際時間並傳達給團隊，以便每個團隊成員都能瞭解其績效與預測的對比。這確保了團隊成員在估算方面有所改進。

• 根據需要為團隊提供食物。

設計

設計的規則包括：

• 為系統選擇一個隱喻，並在開發過程中不斷發展它。

• 保持設計的簡單性。

• 不要過早新增功能。

• 現在只構建滿足當前需求所需的架構，並相信以後可以新增更多。

• 儘可能地進行重構。

編碼

編碼的規則包括：

• 業務方（代表客戶）應始終可用。

• 開發人員應根據強調程式碼溝通的規則編寫所有程式碼。

• 應確保結對程式設計。

• 應遵循編碼規範。

• 所有程式碼都必須有單元測試。

• 在為系統的每一部分編寫程式碼之前，先編寫單元測試，這樣建立程式碼就會更容易、更快。建立單元測試和建立一些程式碼使其透過所需的時間與直接編寫程式碼所需的時間大致相同。這簡化了迴歸測試。

• 在編碼時，你應該只戴以下四頂帽子之一：

  • 新增新功能，但僅更改實現。

  • 新增新功能，但僅更改介面。

  • 重構程式碼，但僅更改實現。

  • 重構程式碼，但僅更改介面。

• 為整個團隊提供一個專門的整合工作站。

• 一次只有一對開發人員整合程式碼，並確保所有測試都透過。

• 應經常進行整合。

• 應使用集體所有權。

測試

測試的規則包括：

• 所有程式碼在釋出之前都必須透過所有單元測試。

• 發現缺陷時編寫測試。

• 應經常執行驗收測試。

極限程式設計 - 其他功能

在本章中，我們將學習極限程式設計的一些其他功能。

反饋迴圈

極限程式設計的魅力在於持續的反饋，它讓每個人都保持專注，開發工作持續朝著正確的方向發展，不會出現任何延遲。

在極限程式設計中，反饋是在不同的級別上完成的，並達到必要和足夠的細節。這在迭代和釋出中也持續不斷地進行。

下表說明了反饋事件和反饋持續時間。

專案管理

在極限程式設計中，專案管理沒有得到強調，並且管理者的角色執行最少且最基本的管理活動。

然而，這些活動包含了專案管理的要求。

• 釋出計劃

  • 範圍由使用者故事卡片中的使用者故事定義。

  • 估算為故事估算，可以以故事點為單位。

  • 交付里程碑由釋出計劃捕獲。

  • 釋出被劃分為迭代。

• 迭代計劃

  • 故事在任務卡片中分解成任務。

  • 估算為任務估算。

  • 任務分配透過平衡團隊中的負載因子來完成。

  • 任務驗收由團隊承諾和責任制來完成。

• 跟蹤

  • 速度以專案級別的實際實施時間的故事點表示。

  • 生產力以開發人員級別的實際實施時間的任務估算表示。

  • 缺陷跟蹤

極限程式設計 - 行業經驗

從業界執行的極限程式設計專案中，有一些對團隊有用的經驗教訓。

XP實踐的經驗教訓

在以下章節中，您將瞭解這些經驗教訓。

• 簡單設計 - 簡單設計高效、易於構建和維護。

• 隱喻 - 使用隱喻的主要目的是在整個開發過程中使用特定於領域的名稱，這使得客戶也可以積極參與開發。

• 集體所有權 - 每個人都為自己的優秀程式碼感到自豪。透過協作，每個人都為每個人的程式碼感到自豪。

• 計劃 - 如果團隊在一個迭代中完成了許多使用者故事，則使迭代更小。讓團隊達成共識以更改計劃。

擴充套件極限程式設計

最初，極限程式設計被認為在較小的團隊中有效，團隊規模最多為 12-16 名開發人員。

後來，人們觀察到可以將極限程式設計擴充套件到 40-50 人的團隊。但是，建議透過構建遞迴團隊來進行擴充套件。首先構建一個小型團隊，然後逐步擴大團隊規模，使用第一個團隊來為遞迴團隊提供種子。

文件

極限程式設計不反對任何文件。它鼓勵記錄所需的內容，何時需要以及僅記錄所需和足夠的細節。這可能因專案而異，由專案決定文件的範圍。但是，極限程式設計實踐不允許跳過文件。

應用XP的優勢

極限程式設計在以下情況下被發現是有利的 -

• 高度不確定的環境

• 內部專案

• 合資企業

應用XP的劣勢

極限程式設計在以下情況下被發現是不利的 -

• 環境龐大而複雜。

• 需求得到了很好的理解。

• 客戶距離較遠或無法聯絡。

XP的誤解

關於極限程式設計有一些誤解。下表給出了存在的誤解的澄清。

Scrum + 極限程式設計

極限程式設計是最早出現的敏捷方法之一，並且在不斷發展。肯特·貝克（Kent Beck），極限程式設計的創始人，在開發它時，其前提是使用最佳程式設計實踐並將它們發揮到極致。

極限程式設計在當前情況下專注於目前業界流行的最佳實踐，並將它們發揮到極致。最普遍的例子是測試驅動開發、全團隊方法、可持續節奏等。

XP – 靈活性作為技術

極限程式設計如此受歡迎的原因之一是其靈活的特性。此外，極限程式設計更多的是關於技術而不是流程，因此與以流程為中心的方案很好地融合。因此，您可以輕鬆地將極限程式設計的功能與其他想法結合起來，無論何時

• 一些極限程式設計實踐在流程中是互補的。

• 極限程式設計本身不適合實施。

但是，請記住，您選擇的任何極限程式設計實踐都應將其核心內容貫徹到底。否則，您不能聲稱您正在使用極限程式設計。

事實上，對於您採用的任何流程，這一點都是正確的。允許混合搭配，但前提是您正在使用互補的功能，並且您沒有損害所用功能的價值。

目前最流行的極限程式設計混合方案是Scrum + 極限程式設計混合方案。我們將從最基本且仍然流行的軟體開發方法論 - 瀑布模型開始。

瀑布模型

在瀑布模型中，開發按階段進行，在完成前一階段之前，任何階段都不能開始。

瀑布模型在許多組織中仍在使用，儘管有些人將其視為傳統方法論。如果需求在開發開始之前完全已知，則它是一種成熟且有效的方法論。該過程簡單明瞭，不需要任何培訓或指導。

您需要記住的是，沒有哪種方法論適用於所有情況，每種方法論都有其自身的優缺點。因此，您必須瞭解哪種方法論適合您的環境、您的客戶利益。

讓我們看一下瀑布方法論的缺點 -

• 由於所有需求都必須在開發開始之前知道，因此當需求不完整或含糊不清時，它不適用。

• 由於該方法論是單向的，因此無法將任何階段的反饋帶回到任何較早的階段，儘管關於最終產品的清晰度有所提高。

• 測試僅在開發完成後進行，由未參與早期階段（如需求收集或開發）的開發人員團隊進行。這種“最後測試”方法通常會導致缺陷包含、高缺陷率、交付給客戶的高未發現缺陷。

• 在開發結束之前，不會提供可工作的產品，因此沒有人會知道是否正在構建正確的東西，即使它正在正確地開發。

• 缺陷修復和需求更改難以被吸收，因為有很大的可能破壞設計，並且產生的成本也很高。

如果您在開發中預測到此類情況，則敏捷方法論最適合。

敏捷方法論

敏捷方法論提倡 -

• 頻繁釋出可工作的產品增量，使反饋能夠在正確的時間流入。

• 以團隊為中心的方法，使每個人都對最終產品負責。

• 靈活的計劃，專注於為客戶交付價值，滿足客戶期望，投資回報。

• 隨時準備接受更改，以便交付的最終產品不會過時。

出現了多種敏捷方法論，其中Scrum變得越來越流行，並且被廣泛使用。

Scrum如何發揮作用？

在Scrum中，專案被分解成釋出和時間盒式的短衝刺。對於每個衝刺，您將只承擔客戶優先順序最高並且您可以在一個衝刺中交付的必要和足夠的功能。在每個衝刺結束時，您將擁有一個可以釋出的可工作的產品。

需求稱為積壓專案，迭代稱為衝刺。將採用持續測試和測試優先方法。開發人員和測試人員也參與使用者故事的編寫，這些使用者故事就是積壓專案。這使團隊中的每個人都能提前瞭解產品的行為，也有助於在衝刺開始時就確定驗收標準。

正如我們之前所說，Scrum在其定義中，在某些情況下是有效的，但與任何其他開發方法論一樣，它也存在自身的缺點。

• 時間盒式的衝刺不允許在釋出計劃中有任何靈活性，這會阻礙開發和測試。

• Scrum本身不提供開發方向。

因此，Scrum通常與其他更側重於開發策略的敏捷方法論結合使用。

Scrum + 極限程式設計混合

Scrum被頻繁地使用，並結合了互補的極限程式設計實踐，極限程式設計側重於工程方面，如持續溝通、頻繁的反饋迴圈、重構、集體所有權、持續整合、測試驅動開發等，而Scrum側重於衝刺的固定範圍、燃盡圖等。

• 由於Scrum是一種定義明確的方法論，因此從專案的第一天起就更容易適應。

• 由於極限程式設計更側重於溝通和團隊凝聚力，因此團隊更專注於開發。

因此，Scrum + 極限程式設計混合被發現是有效的。

Scrum + XP混合專案的工具

SpiraTeam和Rapise等工具適用於Scrum + 極限程式設計混合專案。SpiraTeam在一個整合的檢視中提供關鍵專案質量和進度指標的報告儀表板，該檢視專為Scrum和極限程式設計專案量身定製。

一些指標包括 -

• 需求測試覆蓋率
• 任務進度
• 專案速度
• 主要風險和問題

Rapise工具是一個測試自動化解決方案，可以完全整合到您的開發流程中，並可以適應您不斷變化的需求。您可以使用它來測試桌面、Web和移動應用程式。開發人員、測試人員和業務使用者可以使用此工具生成驗收測試。

極限程式設計 - 工具

在本章中，我們將學習一些在極限程式設計中使用的工具。

極限計劃

極限計劃是一種基於瀏覽器的敏捷專案管理解決方案，專為支援包括Scrum和極限程式設計在內的敏捷方法而設計。

極限計劃專注於規劃和跟蹤對客戶具有實際業務價值的功能（或使用者故事）的進度。

極限計劃的關鍵功能包括 -

• 支援整個團隊，包括專案經理、開發人員、質量保證、技術支援和利益相關者。

• 透過拖放輕鬆地估算和計劃軟體釋出。

• 在一個地方管理功能、缺陷、測試用例和開發任務。

• 具有整合的問題跟蹤功能，可以從頭到尾管理客戶請求。

• 提供最新的更改，並透過電子郵件通知和專案活動報告。

更多資訊 - www.extremeplanner.com

專案計劃與跟蹤系統

PPTS是一個基於Web的環境，支援選擇根據敏捷方法論Scrum和/或極限程式設計開發軟體的團隊。

PPTS功能包括 -

• 專案、迭代和資源屬性的管理

• 可優先順序排序的產品待辦事項

• 工作分解結構（衝刺待辦事項）

• 指標（速度和估算/實際工作量）

• 燃盡圖和進度圖表

• 日曆

• 資源分配

• 基於整體角色（管理員或使用者）或專案中的角色（專案負責人、開發人員或客戶）對資訊進行細粒度訪問控制

• 選單和語言自定義（提供英語和荷蘭語）

• 與PR/CR工具整合

更多資訊 - http://ses-ppts.sourceforge.net/

Targetprocess

Targetprocess 是一款視覺化專案管理軟體，使您能夠直觀地管理複雜的工作並專注於重要事項。

Targetprocess 為您的整個組織提供所需的可見性和透明度。從看板和Scrum到幾乎任何運營流程，Targetprocess都能靈活地適應您的管理方法和組織結構。

Targetprocess 提供 -

• 用於計劃和進度跟蹤的看板。看板檢視提供了許多選項，可以無縫處理大量卡片。

• 可與任何人共享的看板，以在外部廣播資訊。它們非常靈活。

• 可以使用拖放操作移動多個卡片。

• 用於專案層次結構的列表，並輕鬆管理待辦事項。

• 完全自定義、內聯編輯和精美設計。

• 圖形報表。

• 時間線。

• 自定義檢視。

• 儀表盤。

更多資訊 - www.targetprocess.com

Plone Extreme Management Tool

Plone Extreme Management 工具提供專案管理功能，支援極限程式設計方法。

Plone Extreme Management 工具提供 -

• 內容型別 -

  • 專案 - 專案經理可以新增多個專案。對於每個專案，客戶和員工都可以新增迭代和使用者故事。

  • 迭代 - 專案將按迭代進行計劃。迭代是一段1到3周的時間，在此期間將實施多個使用者故事。

  • 需求 - 包含客戶希望在這個專案中實現的使用者故事。它被用作捆綁客戶願望並初步指示專案規模的一種方式。

  • 使用者故事 - 客戶可以透過描述這些功能來定義新的功能。

  • 任務 - 員工可以透過定義任務來估算使用者故事。

  • 工時記錄 - 在處理任務時，員工可以跟蹤時間並在一天結束時輕鬆記錄這些時間。

• 工作流程。

• 時間跟蹤器。

• 釋出計劃。

• 迭代總結。

Java 開發人員的 XP 工具

下表列出了 Java 開發人員用於相關活動的工具列表。

.Net 開發人員的 XP 工具

與 Java 一致，.Net 有 NAnt、NUnit、CruiseControl.NET。Visual Studio 擁有許多重構工具。

在您的組織中採用 XP

如果您計劃在您的組織中採用極限程式設計，首先選擇一個適合極限程式設計的專案和團隊。獲得一位經驗豐富的教練。讓團隊習慣極限程式設計實踐、估算和團隊溝通。

使用專案所需的最小極限程式設計規則啟動專案。允許這些規則演變以實現更好的實施。考慮極限程式設計實踐之間的協同效應。為團隊提供足夠的時間來克服學習曲線。管理團隊文化和變化。

建議首先採用內部專案。一旦您成功實施該專案，您將擁有團隊和管理層支援您將其擴充套件到其他合適的專案。