極限程式設計 - 附加特性

本章我們將學習極限程式設計的一些附加特性。

反饋迴圈

極限程式設計的魅力在於持續的反饋，它讓每個人都保持專注，開發工作持續朝著正確的方向前進，避免延誤。

在極限程式設計中，反饋是在不同層面上實現的，達到必要和足夠的細節。這在迭代和釋出過程中都是持續不斷地進行的。

下表列出了反饋事件和反饋持續時間。

專案管理

在極限程式設計中，專案管理並未被特別強調，管理者的角色只執行最少且最必要的管理活動。

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

• 釋出計劃

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

  • 估算為故事估算，可以以故事點表示。

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

  • 釋出被分成迭代。

• 迭代計劃

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

  • 估算為任務估算。

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

  • 任務驗收由團隊承諾和責任制來保證。

• 跟蹤

  • 專案層面根據實際執行時間以故事點衡量速度。

  • 開發人員層面根據實際執行時間以任務估算衡量生產力。

  • 缺陷跟蹤

極限程式設計 – 行業經驗

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

從XP實踐中學習到的經驗

在接下來的部分，您將瞭解這些經驗教訓。

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

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

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

• 計劃 − 如果團隊在一個迭代中完成了許多使用者故事，則縮小迭代規模。讓團隊達成共識來修改計劃。

極限程式設計的擴充套件

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

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

文件

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

應用XP的優勢

極限程式設計在以下情況下被認為是有優勢的：

• 高度不確定的環境

• 內部專案

• 合資企業

應用XP的劣勢

極限程式設計在以下情況下被認為是有劣勢的：

• 環境龐大而複雜。

• 需求已被充分理解。

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

對XP的誤解

關於極限程式設計存在一些誤解。下表對這些誤解進行了澄清。