加拿大擴展 XP/敏捷方法工作坊

提出的問題

在準備會議時，與會者被要求提交他們對如何擴展 XP 和敏捷方法以適用於大型團隊的看法。根據詢問對象的不同，大型的定義可能從 20 到 200 多位開發人員不等。

向與會者提出的具體問題包括

• 敏捷方法的可擴展性如何？
• 早期採用者的經驗是什麼？
• 我們可以進行哪些實驗來擴展這些方法的使用？

由於參與過多個 XP 專案，我們非常渴望聽聽其他人如何看待 XP 的擴展，並分享我們自己在大團隊中使用 XP 的經驗。

Ken Schwaber

第一位主題演講者是 Ken Schwaber。Ken 和 Jeff Sutherland 是 Scrum 敏捷方法的作者和創始人。Ken 首先描述了他使用 Scrum 處理大型專案的經驗，以及他在專案生命週期的早期階段成功使用過的幾種技術。

Ken 在一個專案中說明，團隊非常擔心在開發的早期階段證明系統的整體架構。早期的專案迭代（在 Scrum 術語中稱為衝刺）包含專注於證明系統架構的故事，並穿插了幾個實際的商業案例。經過多次迭代，在此期間架構不斷被優化和測試，團隊對架構是否足以滿足業務需求有了很好的了解。

然後，透過讓原始架構團隊的創始人啟動新的團隊來實現擴展。由於已解決了大部分架構問題，新的團隊可以專注於在當時穩定的架構上實作業務邏輯。

Ken 還強調了擁有不管理團隊的 Scrum 主管的重要性，相反地，由團隊自行管理非常重要。Ken 發現，當團隊自我組織並可以自行決定如何最好地完成他們被賦予的工作時，團隊的效率會高得多。這對習慣於命令和控制式領導風格的經理來說是一項挑戰，而且最初非常違反直覺。

Ken 提出的有趣觀點是，局外人最初如何看待敏捷方法。對於所有獲得一定成功的新事物，人們自然會問這對他們有何幫助。這是他們一直在尋找的「萬靈丹」嗎？Ken 好奇 XP 和敏捷是否會遭遇與 CMM（能力成熟度模型）類似的命運。

CMM 背後有許多優秀人才，他們明確指出公司可以採取哪些措施來提高軟體專案成功的機率，並展示軟體流程成熟度。然而，CMM 從未被廣泛採用並成功實施到作者最初預期的程度。據報導，2/3 的 CMM 專案實施失敗。此外，許多業界人士對 CMM 持有負面看法，因為公司能達到的認證等級通常取決於他們聘請誰來執行認證。

敏捷方法是否會遭遇類似的命運？當然，早期採用者已獲得成功，但這些團隊通常由技能高超、積極進取、熱衷於撰寫軟體的人員組成。可以說，由這類人員組成的團隊無論採用何種方法論，都能獲得成功。

我們認為，這與敏捷關係不大，而更多的是人員對專案具有首要影響這一無法避免的事實。當你觀察建立這類團隊的相反情況（技能較差、缺乏動力、對撰寫軟體不熱衷的人員）時，這一點就會顯而易見。對於這些團隊，無論採用何種方法論，都無法讓他們獲得成功。

雖然 Ken 同意優秀的開發人員有助於順利進行流程，但根據他的經驗，被歸類為普通甚至較差的人員，在敏捷提供的支持性、創新性和團隊導向環境中，通常也能提升至卓越。他見過以前分散的普通專業人士小組完成真正偉大的事情，而他以前認為只有頂尖人才才能做到。

來自現場的報告

會議的中間部分留給其他從業人員和研究人員分享他們對大型專案的想法和經驗。

Philippe Kruchten（Rational）描述了使用 RUP 的大型團隊（200 人以上）如何成功交付過去的大型專案。在專案的早期階段，由資深從業人員組成的團隊用於完成初始的高階架構並設定開發實務。

隨著專案進入建置階段，會新增更多團隊（由細化團隊的創始人組成）。在適當分解後，每個團隊可以相當自主地工作（在迭代週期中）。在一個團隊需要另一個團隊建置的元件時，可以協調兩個團隊之間的同步點和里程碑。以這種方式處理大型專案，讓團隊產生一種錯覺，認為他們已經解耦到足以獲得小型敏捷團隊的優勢。

ClearStream Consulting 的 Gerard Meszaros 分享了他與大型團隊在大型電信公司打造數位交換器的經驗。他們頻繁發布，並在專案的生命週期中進行重大架構變更。然而，在他們能夠這麼做之前，系統已經達到臨界質量。

Gerard 也提出一個關於 XP 和敏捷實務的當前產業文獻的有趣觀點。在他看來，當今大多數的文獻都是針對已經知道如何開發軟體的人。如果 XP 要擴展到早期採用者之外，將需要一套截然不同的文獻。重複使用類比：「今天我們有給會做菜的人的食譜。我們今天沒有的是給不會做菜的人的食譜。」

一家大型加拿大能源公司分享了他們公司內部採用敏捷的經驗。他們結合使用 Scrum 和 XP，在管理專案方面取得了巨大成功。在管理階層的支持下，他們現在有一個團隊致力於向公司內的其他小組展示如何使用敏捷來增加他們的成功機會。關於 XP 和 Scrum 的進一步評論是它讓團隊能夠根據每個團隊的需求調整和修改實務的能力。他們更喜歡這種方法，而不是過去使用的萬用專案管理形式。

作者（Jonathan Rasmusson 和 Jim McDonald）也有機會分享我們自己對 XP 和大型團隊的經驗。由於我們主要使用 XP，因此我們檢視了核心實務，並將它們分為兩組——我們認為可以擴展的實務，以及無法擴展的實務。

我們相信與編寫程式碼的機制相關的 XP 實務可以擴展。我們認為沒有什麼會阻止大型開發人員團隊撰寫測試、重構和配對程式設計。多年來，人們一直在大型和小型專案中成功地實踐這些技術（在 XP 或敏捷之前）。這些只是良好的實務。

然而，以溝通為中心的那些實務將難以擴展。例如，對於 20 人以上的團隊來說，每日站立會議會變得尷尬。迭代規劃會議，所有開發人員和分析師聚集在一起規劃即將到來的迭代，由於協調如此多的人員所造成的組織和溝通開銷，將難以管理。我們在擴展 XP 時看到的最大挑戰，與我們在每個大型專案中面臨的挑戰相同——如何有效地溝通和協調大量人員。

我們也開始質疑這個問題本身。為什麼人們想要擴展 XP？在小型團隊中取得成功後，我們認為想要擴展似乎非常不合邏輯。相反，我們寧願首先尋找替代方案，了解如何將大型專案縮小到我們知道 XP 可以順利運作的規模。

Martin Fowler

會議的最後一天以 Martin Fowler 的主題演講「為什麼擴展敏捷是你最不想做的事」開始。他的主題演講標題改變了會議的基調。在那之前，會議的大部分時間都致力於嘗試回答如何擴展 XP 的問題。然而，Martin 的主題演講卻反其道而行，並詢問聽眾這是否真的是我們想要做的事情。

他的演講分為兩部分。第一部分是關於一個 Thoughtworks 專案的經驗報告，該專案涉及一個大型團隊在複雜的租賃應用程式上使用 XP 類型的流程。第二部分進一步闡述了標題，說明為什麼我們應該在嘗試擴展 XP 之前尋找替代方案。

馬丁一開始提醒我們，為什麼建構複雜的商業應用程式具有挑戰性。商業邏輯是一個矛盾修飾法。商業的大部分面向（尤其是租賃）沒有任何邏輯性。擷取商業規則、隱藏假設、特殊情況，並將這些抽象成一個穩固、經過實戰考驗的領域模型，是軟體設計中最具挑戰性的部分之一。

在大型專案中，需求收集也非常困難。馬丁提供了一個有趣的比較，將撰寫需求文件與寫書進行比較。寫一本書需要投入大量時間和精力。即使經過同儕審查和專業編輯的回饋，作者仍然無法總是成功地將其預期訊息傳達給受眾。他的觀點是，如果作者在寫書時都這麼辛苦，試想在資源遠遠不足的情況下，要擷取一個複雜商業應用程式的需求會是什麼樣子。

在專案中非常有效的一種做法是將人員輪調到應用程式的不同部分。這最初讓專案分析師感到沮喪，因為開發人員才剛開始了解問題領域，就必須轉移到系統的另一個部分。然而，隨著專案進展，將人員調動到應用程式其他部分的好處開始顯現。最後，大多數開發人員都對應用程式了解得夠多，可以勝任許多角色。對於少數人員在應用程式特定部分執行工作的依賴性降低了。開發人員本身在技術和商業領域都變得更強。對應用程式有更全面的了解，讓他們洞悉如何最佳實作新功能，同時維護整體系統架構。

馬丁主題演講的後半部分重點在於，為什麼我們應該尋找擴充敏捷的替代方案。有些專案確實需要大型團隊。所需完成的工作量通常太大，無法讓小型團隊在合理的時間內處理。電信產業的專案和大型軍事應用程式就是這種情況的範例。對於這些團隊來說，如何擴充敏捷是一個非常實際的問題。

然而，Martin 的經驗是，許多團隊不必要地龐大。這些團隊應該在嘗試擴展敏捷之前尋找替代方案（例如縮小團隊規模）。Martin 請觀眾舉手，如果他們曾經參與過一個專案，在移除團隊中最弱的一半成員後，仍然可以維持大約相同的生產力水準。大部分的觀眾都舉手了。這似乎反映出，許多觀眾有類似的經驗，並參與過團隊規模遠遠超過必要的專案。因此，Martin 建議團隊先尋找縮小不必要地龐大專案的方法，而不是先尋找擴展 XP 和敏捷的方法。

證據在哪裡？

與會者似乎難以回答的問題之一是，哪些實驗可以提供經驗證據，證明 XP/敏捷可以用於大型專案。學術/研究社群已經承擔起提出實驗和經驗證據的艱鉅任務，證明敏捷方法可以擴展到大型團隊。

雖然我們感同身受研究人員想要證明敏捷有效的渴望，但我們認為證明這一點有幾個挑戰。Jonathan 認為挑戰在於嘗試客觀地衡量軟體品質和生產力。在沒有明確、可量化的品質和生產力衡量標準的情況下，如何針對軟體工程實務進行實驗？Jim 認為，真正了解敏捷的途徑是透過社會學研究，以及研究量化和描述人類互動方式的難度。由於溝通在敏捷專案中扮演著如此關鍵的角色，他認為這些領域的研究將更深入地了解敏捷有效的原因。

摘要

研討會本身非常成功，所有與會者都享受分享他們的想法和見解的機會，討論如何最好地解決研究社群提出的挑戰性問題。XP 和其他敏捷流程似乎開始引起學術界的關注，並開始受到重視。無論早期採用者提供任何建議，很明顯的是，與任何新工具一樣，XP 在未來幾年將會被應用和誤用。