極限編程 (XP) 可以取得成果，但它適合您嗎？
摘要
如果「極限編程」這個詞讓您聯想到 X 遊戲和動作運動，那麼您的想法並沒有錯。 事實上，極限編程 (XP) 是一種相當極端的編程方式。 與其他敏捷軟體開發方法類似，XP 使用可調適、測試驅動的開發方法進行軟體工程。 但與其他方法不同的是，極限編程有嚴格的規則和指導價值觀，用以規範工作的完成方式。
什麼是極限編程 (XP)？
極限編程是一種敏捷專案管理方法，旨在透過短暫的開發週期和更少的文件記錄來實現速度和簡單性。 流程結構由五個指導價值觀、五個規則和 12 個 XP 實踐 (我們將在本文中進一步細分) 所決定。
與其他敏捷方法一樣，XP 是一種軟體開發方法，可分解為工作衝刺。 敏捷架構遵循一個迭代流程，即在每次衝刺後完成並審查架構，對其進行改進以實現最高效率，並根據不斷變化的需求進行調整。 與其他敏捷方法類似，XP 的設計使開發人員能夠即時回應客戶故事、進行調整和變更。 但 XP 的紀律性更強，使用頻繁的程式碼審查和單元測試來快速進行變更。 它也高度創新且協作性強，在所有開發階段都優先考慮團隊合作。
免費試用 Asana極限編程與 Scrum
Scrum是另一種常見的敏捷方法，由Scrum 主持人管理。 與 XP 類似，Scrum 會從使用者故事中進行衝刺，以開發新產品或軟體功能。 然而，XP 比 Scrum 更嚴格，其嚴格的規則和準則鼓勵開發人員與客戶之間持續保持聯繫。 此外，您可以將 Scrum 用於任何需要迭代和客戶輸入的流程，而 XP 程式設計則僅適用於此。
誰創造了極限編程？
XP 的起源可以追溯到 1990 年代末，當時 Kent Beck 創建了它，用於管理克萊斯勒的薪資軟體系統 (稱為 C3 專案) 的開發。 XP 的目標是 (且仍然是) 移除開發專案中對變更程式碼的阻力。 在更傳統的軟體開發方法中，您通常會在編寫後就不再修改程式碼 (除非是進行除錯)。 使用 XP 時，您會非常仔細地審視程式碼，以至於開發人員可能會決定在單次疊代後完全重寫程式碼。
何時應使用極限編程？
由於極限編程著重於軟體開發，因此通常僅由工程團隊使用。 即使在軟體團隊中，它也只適用於某些情況。 若要從極限編程中獲得最大價值，最好在以下情況下使用：
管理較小的團隊。 由於其高度協作的性質，XP 最適合用於 10 人以下的小型團隊。
與客戶保持持續聯繫。 XP 在整個開發過程中納入客戶需求，甚至依賴客戶進行測試和核准。
擁有能夠適應變化的團隊 (且不會產生負面情緒)。 就其本質而言，極限編程通常會要求您的整個團隊放棄他們的辛勤工作。 此外，還有允許其他團隊成員隨時進行變更的規則，如果您的團隊成員可能會將其視為針對個人，則無法奏效。
精通編碼的技術層面。 XP 並不適合初學者。 您需要能夠快速工作並進行變更。
XP 的生命週期
XP 生命週期鼓勵持續整合，團隊成員幾乎持續進行整合，頻率可達每小時或每天一次。 但完整的生命週期分解如下：
從使用者故事中提取未完成的工作
您優先處理最重要的項目
開始疊代規劃
納入誠實規劃
與所有專案關係人保持持續溝通，並賦予團隊權能
發佈工作
接收回饋
返回迭代規劃階段，並依據需要重複。
極限編程的 5 個價值觀
極限編程是價值驅動的。 XP 讓您的團隊以更簡單的方式工作 (專注於簡單性和協作，而不是複雜的設計)，而非使用外部激勵因素，這一切都基於這五個價值觀。
1. 簡單
在開始任何極限編程工作之前，請先問問自己：最簡單的事情是什麼？ 「可行」這個部分是一個關鍵的區分因素，最簡單的事情並不總是實用或有效的。 在 XP 中，您的重點是先完成最重要的工作。 這意味著您正在尋找一個您知道自己可以完成的簡單專案。
2. 溝通
XP 仰賴快速的反應和有效的溝通。 為了工作，團隊需要彼此開放和坦誠。 當問題出現時，您應該勇敢發聲。 這樣做的原因是其他團隊成員通常已經有解決方案。 如果他們沒有，您會發現團隊的速度比您單獨行動更快。
閱讀：如何改善團隊溝通：6 個策略和提示3. 回饋
與其他敏捷方法一樣，XP 將使用者故事和回饋直接納入流程中。 XP 的重點是快速、簡單地產出工作，然後分享以獲得幾乎即時的回饋。 因此，開發人員在整個過程中幾乎與客戶保持持續聯繫。 在 XP 中，您會經常發佈版本，以便提早且經常獲得深入解析。 收到回饋時，您會調整流程以將其納入其中 (而非專案)。 例如，如果回饋減少了不必要的延遲時間，您可以調整流程，讓一對開發人員改善延遲時間，而不是調整整個專案。
閱讀：不喜歡提供回饋嗎？這 20 個提示是為您準備的4. 勇氣
XP 需要一定的勇氣。 您應該隨時提供有關進度的最新資訊，這可能會讓您變得相當脆弱。 如果您在 XP 中錯過了期限，您的團隊領導者可能不會想討論原因。 相反地，您會告訴他們您錯過了期限，承擔責任，並重新開始工作。
如果您是團隊主管，您在 XP 流程開始時的職責是設定成功的期望並定義「完成」。 由於團隊專注於成功，因此通常很少有針對失敗的規劃。 不過，這可能會令人害怕，因為事情不見得總是按照計劃進行。 但如果在 XP 流程中情況發生變化，您的團隊應該能夠適應並隨之改變。
5. 尊重
考慮到 XP 非常重視溝通和誠實，尊重當然也很重要。 為了讓團隊有效溝通和協作，他們需要能夠提出不同的意見。 但有很多方法可以友善地做到這一點。 尊重是一個良好的基礎，即使在完全誠實的情況下，也能帶來善意和信任。 對於極限編程而言，期望是：
客戶和開發團隊之間的相互尊重。
團隊成員之間的相互尊重。
認可團隊中的每個人都為專案帶來了有價值的貢獻。
極限編程方法的 5 條規則
極限編程的價值觀更具哲學性。 另一方面，規則則是如何完成工作的實際應用。 您需要兩者才能運作一個有效的 XP 團隊。
1. 規劃
在 XP 的規劃階段，您需要確定專案是否可行，以及是否最適合 XP。 為此，您將查看：
使用者故事，以便瞭解它們是否符合簡單性的價值，並確認客戶是否可參與流程。 如果使用者故事較為複雜，或是由匿名客戶製作，則可能不適用於 XP。
專案的 Business 版價值和優先順序，以確保這與「先完成最重要的工作」一致。
您所處的開發階段。 XP 最適合早期階段的開發，對於後期的迭代則不太適用。
確認專案適用於 XP 後，請建立發佈排程，但請記得您應該儘早、經常發佈以獲得回饋。 若要做到這一點：
將專案分解為迭代，並為每個迭代建立計劃。
設定切實可行的期限和可持續的步調。
即時分享更新內容，讓您的團隊保持誠實和透明。
分享即時更新，幫助團隊更快地識別、調整和進行變更。
2. 管理
極限編程的關鍵要素之一是實體空間。 XP 純粹主義者建議使用開放式工作空間，讓所有團隊成員在一個開放式房間中工作。 由於 XP 具有高度的協作性，因此您將受益於一個可以實際聚集在一起的空間。 但在當今這個時代，這並不總是那麼實際。 如果您在遠距團隊中工作，不妨考慮使用一個鼓勵非同步工作的平台來進行遠距協作。 這樣，即使所有成員不在同一個地點，也能繼續共同處理專案。
與其他敏捷方法一樣，使用每日站立會議進行核對並鼓勵持續、開放的溝通。 您需要使用每週週期和季度週期。 在季度週期中，您和您的團隊將審查指導工作的故事。 您還將研究您的 XP 流程，尋找差距或進行變更的機會。 接著，您將以每週週期進行工作，每個週期都會從客戶會議開始。 客戶選擇他們希望程式設計師在該週處理的使用者故事。
身為經理或團隊主管，您的重點將是維持工作進度、衡量速度、調動團隊成員以解決出現的錯誤或問題，或變更 XP 流程以適應您目前的專案和疊代。 請記住，XP 的目標是保持彈性並採取行動，因此您的工作將高度關注團隊目前的工作，並對任何變化做出反應。
3. 設計
當您剛開始使用極限編程時，請從最簡單的設計開始，因為後續的迭代會使其更加複雜。 在此階段不要新增早期功能，以便盡可能保持其最基本的功能。
XP 方法團隊通常會使用類別責任協作 (CRC) 卡來顯示設計中每個物件的互動方式。 透過填寫卡片中的每個欄位，您將獲得所有功能在相關和互動時的可視化互動。 CRC 卡片包括：
類別 (類似物件的集合)
職責 (與類別相關)
協作者 (與此類別互動的類別)
CRC 有助於刺激流程並發現潛在問題。 無論您如何設計，都需要使用一個能夠減少潛在瓶頸的系統。 為此，請務必主動尋找風險。 一旦出現潛在威脅，請指派一到兩名團隊成員在威脅發生時找到解決方案。
閱讀：專案風險管理流程 6 個清晰步驟4. 程式編碼
極限編程的一個更獨特的方面是，您將在整個編碼過程中與客戶保持持續聯繫。 這種合作關係使您能夠在每次迭代中進行測試並納入回饋，而無需等到衝刺結束。 但在 XP 中，編碼規則相當嚴格。 其中一些規則包括：
所有程式碼都必須符合編碼標準。
使用單元測試來確定需求，並開發專案的所有層面。
成對編程——兩名開發人員在同一台電腦上同時工作。 這並不會增加任何時間，而是使用雙倍的專注力來產生最高品質的質結果。
使用持續整合來新增新的程式碼，並立即進行測試。
在任何特定時間內，只有一對人可以更新程式碼，以減少錯誤。
集體程式碼所有權——團隊的任何成員都可以隨時變更您的程式碼。
5. 測試
您應該在整個極限編程過程中進行測試。 所有程式碼在發佈之前都必須通過單元測試。 如果您在這些測試期間發現錯誤，您將建立新的額外測試來修復它們。 稍後，您將把您一直在處理的同一個使用者故事設定為驗收測試。 在此測試期間，客戶會審查結果，以瞭解您將使用者故事轉化為產品的效果如何。
12 個極限編程實踐是什麼？
為了進一步完善流程，XP 還在整個流程中使用了一套 12 個實踐。 這些實踐以敏捷宣言為基礎，但經過調整以滿足 XP 的需求：
規劃遊戲： XP 規劃用於指導工作。 規劃的結果應該是您希望實現的目標、實現的時間，以及接下來要做的事情。
客戶測試：完成新功能時，客戶將開發驗收測試，以確定其與原始使用者故事的接近程度。
小版本： XP 使用小型、例行的版本，以便在整個流程中獲得深入解析。 通常，發佈會直接提供給客戶，但也可以在內部進行。
簡單設計： XP 系統旨在簡化，您只會產生必要的內容，而不會產生其他內容。
配對編程：所有編程都由一對並肩而坐的開發人員完成。 在極限編程中，沒有獨自工作的情況。
測試驅動開發 (TDD) ： XP 對回饋的依賴需要大量測試。 透過短週期，程式設計師會發佈自動化測試，然後立即做出回應。
重構：您將在此處關注程式碼庫的更細微的詳細資料，移除重複項，並確保程式碼具有一致性。 這樣做可以產出出色、簡單的設計。
集體所有權：任何編碼對都可以隨時更改程式碼，無論他們是否開發了該程式碼。 XP 以團隊的形式產出程式碼，每個人的工作都要達到更高的集體標準。
持續整合： XP 團隊不會等待已完成的迭代，而是持續整合。 通常，XP 團隊每天會進行多次整合。
可持續的步調：極限編程的工作強度要求您設定可持續的步調。 團隊應決定他們每天和每週可以以這種方式產出多少工作，並以此設定工作期限。
隱喻：隱喻是一種比喻。 這是由團隊決定的，並使用語言來描述團隊應該如何運作。 例如，我們是螞蟻，集體工作以建造螞蟻巢。
編碼標準： XP 團隊遵循一個標準。 就像作家需要掌握品牌的語調，讓內容聽起來像是同一個人一直在寫作一樣，XP 開發人員也會以相同、統一的方式編寫程式碼，讓它讀起來就像是同一個開發人員寫的。
強度高，但有效
此時，您可能已經明白極限編程是非常極端的。 這個過程既嚴謹又高度結構化，但結果可能是值得的。 XP 的獨特開發流程結合了客戶回饋和密集的協作式編程，從而產生高品質的軟體。
使用工作管理工具，簡化您的 XP 規劃和管理，就像您的工作一樣，即時更新和調整。
免費試用 Asana
