XP 2000 會議

四個戰爭故事

會議的第一天正式開始，由四場受邀演講揭開序幕，所有演講都談論使用適應性流程的專案和團隊，儘管其中只有一場完全使用 XP。當然，那場就是經常被提到的 Chrysler Payroll 專案，稱為 C3。Ron Jeffries 上台演講這個專案，並不僅僅完整描述它的成功，還說明了導致它取消的原因。總而言之，該專案在第一年左右表現得非常好，交付了一個系統，至今仍每月為 Chrysler 的大約 10,000 名領薪員工發薪。後來，逐漸出現了問題。Ron 將這些問題歸納為

• 薪資部門（使用系統）和資訊系統部門（為系統付費）之間的目標衝突
• 團隊與薪資部門和資訊系統部門的管理階層之間的溝通中斷

Robert Martin 接著演講，他的主題是一個教育測驗公司的專案。這個專案是由 Robert、Jim Newkirk 和其他同事在數年內完成的。需求非常模糊且容易變更，因此他們透過短暫（一週）的迭代和頻繁與客戶聯繫來處理這個問題。儘管他們沒有使用完整的 XP 做法，但他們發現關鍵元素讓這個可能棘手的狀況獲得成功，而且這些緊密的迭代甚至可以在 C++ 環境中發揮作用。這個經驗是導致他們的公司 Object Mentor 去年熱情擁抱 XP 的經驗的最佳範例。

Ralph Johnson 的範例開發是 Refactoring Browser，這個著名的 Smalltalk 工具是重構工具中可能性的象徵。它作為大學博士研究的一部分開發，再次使用一些 XP 做法來開發這個工具。緊密的迭代和設計的演化方法再次成為核心，就像在設計中積極使用重構一樣。

最後一個範例是 Dave Thomas 的，他是 Object Technology International (OTI) 的創辦人。OTI 以許多早期要求嚴苛的物件導向專案而聞名，這些專案在嵌入式系統中使用 Smalltalk 和虛擬機器技術。他強調以人為導向、自動化測試，以及緊密的迭代。與會議中的許多人相反，他強調你可以將這些技術用於固定價格專案。

這些演講的累積效應是，有許多方法可以使用精簡方法獲得成功。與其他方法論一樣，精簡方法並非萬靈丹，但它們提供了可以引導人們走向成功的原則。

XP 會統一嗎？

一個反覆出現的話題是 XP 和 Rational Unified Process 之間的關係。由於各種原因，許多人認為兩者需要更緊密地結合在一起。Dave Thomas 報導說 Ivar Jacobson 非常希望看到 RUP 採用 XP，有效地讓 XP 成為 RUP 的一個實例。Robert Martin 採取了另一種策略：如何讓 XP 看起來像 RUP，以滿足堅持要你執行 RUP 的老闆？Robert 在與 Grady Booch 和 Jim Newkirk 合作撰寫 Booch 的經典 OO 設計書籍第三版時，提出了一個相當明確的範例說明你可以如何做到這一點。他也宣布 Rational 已經委託他將材料納入官方 Rational Unified Process 文件中，以確保 XP 可以成為 RUP 的一個實例。

在這裡我們看到兩個問題：XP 和 RUP 是否可以配合使用，如果是，這樣是否可取？Robert 的方法，加上 Ivar 的願望，似乎讓配合使用只是時間問題。如果 RUP 存在，那麼 XP 肯定在選項中。可取性是另一個問題。似乎大多數 XP 使用者都歡迎這種方法，讓業界的人們更容易採用 XP。然而，令人擔憂的是，使用 RUP-XP 會稀釋 XP，導致人們錯失重要的實務。

在我看來，這差異不大。沒有什麼可以阻止 RUP 包含 XP，而部分使用 XP 的問題在使用 RUP 時與不使用時並無不同。最後，最大的問題圍繞在人身上。適應性流程本質上以人為導向，而且它們在將人視為抽象資源的環境中根本無法運作。XP 是否在 RUP 的旗幟下採用，對這個更重要的問題沒有影響。

開放的心態

閱讀網路上許多關於 XP 的文章，你經常會得到一個強烈的印象，認為有一群狂熱分子反對任何偏離唯一正確的 XP 方式。關於這個會議最好的事情之一是，狂熱主義在很大程度上被留在國內。相反地，我看到一個會議，雖然圍繞著 XP 主題，但並沒有試圖過度推廣特定的 XP 口號。

主題更在於儘管 XP 為軟體流程提供了良好的基礎，但變異既被允許也被接受。會議中的大多數人充其量只是 XP 的部分採用者，而會議主題允許許多演講僅專注於 XP 的特定方面：重構、測試、故事收集等。

我就像 Dave Thomas 一樣，對於看到這種開放性感到非常欣慰。XP 的態度有助於它引起人們的注意，但也引發了阻力。我發現它的實務非常有價值，但我不是那種將整體方法視為一組僵化規則來遵循的人。方法論應根據使用它們的人員進行選擇和調整，而不是相反。

新的方向

會議的最後一場小組討論並不令人意外：XP 如何在軟體產業中被採用的不可避免話題。而小組討論的主題是 XP 就如同任何其他試圖在商業世界中成長的新技術一樣。對許多人來說，問題在於他們如何在自己的組織中使用 XP 或 XP 的某些部分。即使與會者想要使用它，他們是否能說服老闆讓他們使用？

我認為這有點偏離重點。適應性方法的一個重要主題是它們將技術責任賦予技術人員，而技術人員應做出技術決策。問題不在於公司是否允許 XP，而在於公司是否允許技術人員做出技術決策。沒有這一點，XP 的問題就無關緊要。如果你的公司不像這樣，問題就變成了你是否能對你的公司產生影響。

如果無法改變，你必須質疑自己為何要待在那裡。我在一個小組中臨時想出一個短語：「如果你無法改變你的組織，那就改變你的組織！」這不只是 Thoughtworks 的招募廣告（儘管我們總是樂於從糟糕的公司中招募優秀人才），這也是呼籲軟體專業人士記住，最終沒有人比你自己更能為你的職業生涯負責，而現在這個市場正是讓你對自己的工作感到不滿的時候。

傑克的觀點

（由 Jack Bolles 提供）

XP2000 已成過去，它之所以與眾不同，並非因為主題，而是因為討論和與會者的素質。正如我們的同事 Foemmel 可以告訴你（關於 XMLOne），一個主題的第一次會議可能會有很多行銷和宣傳。由於主題性質相當極端，我預期會有許多後者，但令人高興的是我失望了。除了 Robert Martin 的「約櫃」演講之外，幾乎沒有任何行銷活動；>

人群中擠滿了現在主要使用 Java 的現任和前任 Smalltalker。還有一些電信人員，他們大多使用 C。與這兩組人交談後，我了解到是什麼吸引他們使用 XP。後者習慣於協作環境。當工作環境也是系統時，你會傾向於測試你的工作，與其他團隊成員協作並使用相同的映像進行溝通。電信人員的行程非常緊湊，難以找出需要隔離的錯誤，而且足跡很小，需要謹慎的編碼標準。

將這些群體聯繫在一起，以及在會議和其他對話中不斷出現的是，參與開發流程的所有人之間絕對需要良好的溝通。XP 的 12 項實務都明顯地促進了溝通。有些是在開發人員之間，有些是在開發人員和客戶之間，有些是在客戶之間。根據那些採用 XP 的人所說，真正的收穫是在所有流程都運作時，溝通促成的改善大於各部分的線性總和。

我想到的一件事是，XP 的 12 項實務可以分成兩組。第一組包含個人實務，這些實務（在很大程度上）不需要依賴他人才能執行。其中包括測試、重構、簡單設計，以及在較小程度上，結對程式設計、明智的工作週和編碼標準。第二組需要整個團隊：小版本、持續整合規劃遊戲、現場客戶、集體所有權。沒有理由讓開發人員無法親自使用個人實務。樹立好榜樣，無論是測試你的程式碼還是重構，都傾向於對人們產生影響。軼事證據報告指出，XP 的無聲滲透已成功使用。

在嘗試改變群組實務時，其效果較不顯著。特別是涉及開發團隊以外團隊的實務。這是為什麼？個人實務，主要針對開發人員，是我們所有人都應該執行的眾所周知的最佳實務。以團隊為導向的實務要求客戶和管理人員執行他們不習慣、未經證實且需要放棄控制權的事情（即使他們從未真正擁有控制權，例如專案時程）。

讓所有人參與這個流程一直是一個真正的挑戰。關於如何說服人們嘗試它，特別是管理階層和客戶，有很多手足無措的情況。Martin Fowler 多次雙關語地說，如果你的組織沒有按照你認為它應該做的事情去做，你應該「改變你的組織」。無論這表示改變組織運作方式，還是改變你工作的組織，都留給學生練習。

但這並不能掩蓋 XP 文獻和傳說中一個顯而易見的漏洞，那就是如何讓客戶和管理人員「接受改變」。希望在 XP2001 之前這會有所改變。