XP 主題的變奏

為何購買方法論？

為了協助回答這些問題，我想我們必須後退一步，並問自己：方法論的目的是什麼？為什麼有人會想要使用方法論？我認為答案是，方法論的客戶是關注如何適當地開發軟體的人，並期望透過遵循方法論，他們會踏上一條經過驗證的路徑，以提高他們的成功機率。

有人可能也會說，透過遵循方法論，他們可以透過說「我盡我所能了 - 我遵循了一個受人尊敬的方法論」來保護自己免於失敗的後果。儘管後者原因常被批評，但在許多領域中，你預期會遵循某個流程來執行任務，如果你不遵循，你很可能會對後續的問題負更多責任。

在任何情況下，人們都希望有一些步驟可以遵循，以增加他們成功的機會。這是合理的。畢竟，我們已經開發軟體數十年了。我們肯定應該能夠從他人的經驗中學習。

方法論的可變性

殘酷地說，大多數方法論都是方法論者根據他曾經做過的事情所做的陳述。如果他很幸運的話 - 我懷疑大多數方法論都是基於他們希望自己能夠做的事情。充其量，你可能會有一些人結合想法：但實際上是否有人真正做過這些事情，則是另一回事。

軟體也變化多端。首先，軟體中的關鍵變數之一是人。不同的方法會對不同的人產生不同的作用。公司文化也有很大的影響。還有軟體的風格。我不相信為電話系統設計的流程適用於資訊系統，適用於遊戲。

公平地說，很大一部分的方法論者確實認識到這一點。他們知道他們無法提供人們應該遵循的一系列簡單步驟，並獲得完美的結果。總有一些調整、一些客製化需要進行。但我們如何引導客製化？方法論的客戶如何知道什麼是合理的客製化，什麼會破壞方法論？

這是一個特別的問題，適用於那些遵循敏捷方法論的人。這些方法論的一個關鍵特徵是它們是我所說的自我適應：也就是說，你預期會在使用它們的過程中隨著時間推移而改變方法論。在這種狀態下，可接受變化的界限更加流動。不僅一個專案使用的方法論之間存在差異，而且一個專案在一段時間內也會存在差異。

這是方法論者的困境。你如何描述方法論中的變化，這樣你才能安心地認為，真正嘗試遵循你的建議的人會得到你預期的好處，同時允許他們調整你的建議以更好地符合他們的特定情況？

可變性和方法論

當我們探討方法論的靈活性問題時，值得記住的是，市面上有各種風格的方法論。每種方法論都會為變異問題帶來不同的問題。因此，以下是需要思考的一組方法論分類。請記住，我這裡使用的術語是我為本文創造的，它們之間的界線非常模糊。

首先是具體流程。具體流程會提供一套固定的做法，供你遵循。具體流程幾乎不允許變異。具體流程的優點在於，它非常清楚地說明你應該如何遵循流程。具體流程的明顯限制在於，你無法改變它。好吧，其實你可以。人們經常採用具體流程，並根據當地情況進行修改。問題在於，方法論沒有提供如何這樣做的指導。此外，一旦你開始變異，你就會嚴格地超出流程，儘管你很可能已經接近到流程的愛好者會說你仍在流程之內，特別是你成功的話。

由於具體流程是如此固定，因此許多流程都附有明確的變異指南。我稱這種流程為可調整流程。可調整流程通常會在流程說明中包含一個重要部分，說明哪些變異是可以接受的，以及在何時適當地使用這些變異。因此，它們比具體流程更有優勢，因為它們確實提供了有關變異的建議。然而，它並不完美，因為通常很難理解如何正確地執行此操作。在決定要採取什麼行動之前，你必須了解基本流程和所有變異。

在這個時候，值得思考流程的大小。要了解流程中的大小是什麼意思並不容易，但一種方法是思考你閱讀了多少資料才能掌握流程。常見的模式是擁有大型的可調整流程。其想法是告訴你你應該做的一切，然後告訴你你可以省略什麼。然而，要做到這一點，你需要了解大型流程，然後才能找出小型流程。如果你需要一個較小的流程，這可能會比你想要做的工作多很多。

有許多流程是可以這樣調整的，目前最有名的可能是統一理性流程。它比大多數流程更具可調整性，以至於它被稱為流程架構。解釋這種說法的方式是，任何使用 RUP 的人都會使用 RUP 的特定流程實例，並且不需要使用或了解 RUP 的全部靈活性。因此，同時使用具體流程和 RUP（可調整流程）是很有可能的。在我看來，如果你這樣做，而且沒有真正研究 RUP，那麼你使用的就是具體流程。但是，RUP 可以在具體流程缺乏的變異方面提供建議，並幫助你與使用 RUP 其他具體實例的人溝通。

有些流程根本不會給你非常具體的步驟，而是專注於教授軟體開發的哲學，這也是流程的基礎。這種哲學流程本質上是靈活的，因為你可以執行符合哲學的專案。由於它們不會深入探討步驟和變異，因此它們可以做到這一點，而不會像可調整流程或流程架構那樣龐大。然而，由於它們缺乏具體的步驟，因此通常更難遵循，它們不會清楚地告訴你星期一需要做什麼。吉姆·海史密斯的ASD是一個哲學流程的絕佳範例。

儘管人們通常不會稱它們為流程，但相關知識群組就是最佳實務範例的集合。最佳實務範例集合的一個好例子就是 McConnel 在其優秀著作 快速開發 中的最佳實務範例集合。此類集合是一組相對獨立的優良做法，您幾乎可以按任何順序套用。與哲學流程不同，它們是具體的項目，但由您決定要將哪些最佳實務套用至您的專案。

最佳實務的優點在於您不必了解複雜的步驟網才能善加利用它們。相反地，您可以選擇您認為最有價值的做法。由於我一向不信任方法論，所以我喜歡這種方法。但 XP 讓我明白的一件事是，做法並非獨立的項目。XP 的力量並非來自個別做法，而是來自 Kent 選擇的做法之間的互動。如果您將 XP 做法視為個別做法，您就會錯過 XP 的重點。由此我了解到，做法之間的互動與做法本身一樣重要，而具體或可調整的流程擅長捕捉這種互動。

因此，所有這些方法在某種程度上都是不完美的。具體流程在理論上完全不可變，在實務上無法指導您進行變更。可調整流程在理論上運作良好，但要調整它們，您必須了解大量的資料。哲學流程為您提供良好的基礎，但並未真正提供關於該怎麼做的具體建議。最佳實務範例集合告訴您個別做法，但並未說明做法之間的互動。

什麼是 XP？

要了解變異性和 XP，我們必須先了解 XP 屬於哪個類別。對許多人來說，很明顯 XP 是具體流程。它有十二項必須遵循的做法，如果您在任何 XP 討論群組花費大量時間，您很快就會發現 XP 的倡導者投入大量心力讓人們執行所有十二項做法。因此，許多人因堅持己見而獲得相當的狂熱信徒名聲。

但是，XP 的許多吸引力來自於被 XP 的基本哲學所吸引的人，而不是具體的實務。XP 重視適應性、以人為本、輕量級和浮現行為，是一個令人信服的組合。有許多人想要使用 XP，但卻超出了具體流程的範疇。

XP 的其中一項我特別喜歡的不尋常之處，就是它為自己設定了非常明確的界線。它假設一個由大約十幾位開發人員組成的共同定位團隊。這些界線相當明確，但 XP 的許多方面對超出這些界線的專案很有吸引力。如果您有一個由三十位開發人員組成的專案，或一個有許多人遠距工作的專案，會發生什麼事？適應性和以人為本的原則仍然有效。為什麼不盡可能地接近 XP？

因此，您會看到爭論，在那些偏好 XP 的狹隘觀點和那些偏好較廣泛觀點的人之間的爭論。爭論會因為 XP 獲得許多品牌知名度而更加激烈。人們熱衷於表示他們使用 XP，因為他們知道這樣表示可以傳達許多關於其工作中所依循的價值觀和原則，即使您有一個大型或分散的團隊，這些價值觀也很重要。

XP 沒有指導委員會對什麼是或不是 XP 做出正式宣布。它更像是一個只有非正式安排的社群，而社群對於這個問題仍然有些猶豫不決。Kent 已表示他偏好 XP 成為一個具體的流程 - 一個「立下的標竿」。由於他是 XP 社群公認的領導者，因此他的偏好具有很大的份量。因此，主流觀點是 XP 指的是具體的流程。

XP 和自適應性

因此，我們將 XP 視為定義明確的流程，立下的標竿。我們如何將這與自適應性的需求相符？

答案的線索來自於 Kent Beck 在有人向他提出關於建立 XP 成熟度層級的問題時所做的聲明。大多數人對這個問題的反應是驚恐，因為 XP 可能會有任何類似 CMM 的成熟度層級的概念。Kent 就像他經常做的那樣，以一種深思熟慮的嚴肅態度回答，這常常讓人感到驚訝。他說 XP 有三個成熟度層級

• 層級 1 是你完全按照書本上的做法執行所有實務
• 層級 2 是你已經針對你的當地條件調整 XP
• 層級 3 是你不在乎你是否在執行 XP

在這裡我們看到自適應性進來了——你必須調整 XP 才能繼續執行 XP。就像我所說的：如果你在第 6 次迭代中仍然像在第 1 次迭代中那樣執行 XP，那麼你就沒有在執行 XP。

但請注意這裡的成熟度步驟。這些層級假設在調整之前，人們會按照書本上的做法執行 XP。這裡的重點是，如果不執行 XP，就很难看出 XP 如何運作。構成 XP 的實務組合以一種非常難以理解的方式運作，除非你一起執行它們，這樣你才能看到它們如何互動和協同運作。閱讀和推測其效果是實際參與的拙劣替代品。我當然可以證明，我認為 XP 將如何運作與我在 C3 上工作時所看到的之間存在很大差異。

這就是為什麼這麼多 XP 倡導者在推測如何改進 XP 之前如此強調按照書本上的做法執行 XP。通常，這會因為某些原因而被視為思想封閉的狂熱。但很多時候是因為 XP 倡導者記得他們自己早期的懷疑和他們做事情不同的傾向。只有在他們執行 XP 時，他們才意識到它以讓他們驚訝的方式運作。一旦你親自感到驚訝，你就會傾向於認為其他人也會感到驚訝，因此不願意聽取沒有經歷過這種體驗的人的意見。

改變具體的 XP

這暗示了一種不同的思考方式，關於如何使一個流程成為可變的，一種以具體流程為基礎的思考方式。不要從弄清楚如何使用複雜但可調整的流程開始，即使它明顯不適合你的需求，也要從一個具體的流程開始。使用這個次優但具體的流程。這樣做會讓你學到關於這個流程的重要知識，否則你會錯過。一旦你這樣做了，然後開始變化。使用來自其他流程的提示來幫助你做到這一點。

所以這就是變化在 XP 中運作的核心。你只有在真正理解它的運作方式時，才能真正理解如何調整一個方法論。對於一個複雜的重量級方法論，這需要大量的努力。一個敏捷方法論，只有少數實務和對週期中增量開發和學習的強烈傾向，使得這變得容易得多。從根本上來說，通過添加位元來改變一個小東西比通過拿走位元來改變一個大東西更容易。

但是，要了解 XP 的運作方式，特別困難的地方在於，不實際操作就真的很難理解 XP 的運作方式。因此，在實際操作 XP 足以了解其運作方式之前，你必須非常小心地調整 XP。

最好的解決方案是按照書本上的方式開始一個專案，讓它經過幾個反覆運算後穩定下來，然後再調整它。然而，在多數情況下，人們無法這麼做。相反地，他們需要逐步套用實務，以便在有能力時解決各種問題。我認為後者的做法雖然比較容易，但風險也比較高，因為你可能會錯過實務之間的交互作用。因此，我認為採用後者的做法，由曾經見過 XP 發揮作用的人在旁協助，並從知識的立場指導你，就顯得更為重要。

因此，使用 XP 時，你仍然會得到一套實務和經驗，作為起點。但這仍然只是個起點。你需要根據你的情況調整 XP，但在了解 XP 的運作方式的情況下這麼做很重要。在我看來，這表示你應該盡可能按照書本上的方式嘗試 XP 一段時間，即使你認為某些修改可能會讓它更有效率。將那個階段視為一個學習階段。經過幾個反覆運算後，開始調整。如果你後來的調整與你最初想到的第一組調整相同，我會感到驚訝。

XP 和界線

那麼，XP 及其界線之外的未來是什麼？在 Thoughtworks，我們一直將 XP 用作一個專案的基礎，該專案約有 60 人參與，其中一半是開發人員。這顯然太龐大，無法稱為 XP。然而，我們稱之為 XP，因為 XP 一直是我們所做工作的指導哲學。其中存在著我無法否認的矛盾。或許我們不要稱之為 XP 會更好。當然，我們必須大幅變更實務才能讓它發揮作用，而且由於規模龐大，我們從未處於整個團隊都體驗過「按照書本」的 XP 流程的情況。

儘管如此，我還是希望 XP 繼續成為其明確界線背後的地標。我們所做的事情可能是受 XP 影響，但這是一個不同的流程。我們可能不會為它命名，畢竟，它現在已經高度適應特定的專案，而且將繼續以這種方式適應，因此我們幾乎不再關心它是否仍然是 XP。我認為其他流程將會而且應該以這種方式出現，我們將看到受 XP 影響的流程蓬勃發展。也許思考 XP 的最佳方式是，它是一顆種子，而不是一棵樹。

因此，當我們選擇「購買」XP（畢竟沒有購買成本），我們得到的是種子。我們可以開始並利用 XP 社群的經驗，透過一個小而具體的流程，因此比需要客製化的東西更容易理解。在幾次反覆運算中，我們遵循該建議。但我們很快就要在它上面建構，適應我們的環境。因此，我們仍然在建構經驗，但我們無法考慮將 XP 用作「掩護你的屁股」的防禦。我不認為 XP 和其他敏捷方法適合這樣做。而且我不認為這是一個問題。敏捷方法只有在您擁有一個真正有能力的團隊，最終將控制其流程時才能發揮作用。種子是任何樹木的重要組成部分，但正如任何園丁會告訴你的，僅僅將種子丟在地上並不能保證成功。