軟體工程/過程/極限程式設計簡介
極限程式設計 (XP) 是一種軟體開發方法，旨在提高軟體質量和對不斷變化的客戶需求的響應能力。作為敏捷軟體開發的一種型別，[1][2][3] 它提倡在短期開發週期（時間盒）中進行頻繁的“釋出”，旨在提高生產力並引入可以採用新客戶需求的檢查點。
極限程式設計的其他元素包括：結對程式設計或進行廣泛的程式碼審查、所有程式碼的單元測試、避免在實際需要之前編寫功能、扁平化的管理結構、程式碼的簡潔性和清晰度、隨著時間的推移和對問題的更深入瞭解，期望客戶需求的變化，以及與客戶和程式設計師之間的頻繁溝通。[2][3][4] 該方法的名稱來源於將傳統軟體工程實踐的有益元素提升到“極限”水平的想法，理論上，如果一些東西好，更多就更好。它與“牛仔式編碼”無關，後者更加自由形式化和無計劃性。它不提倡“死亡行軍”式的工作時間安排，而是提倡以可持續的節奏工作。[5]
批評者指出了一些潛在的缺點，[6] 包括對不穩定需求問題的處理、對使用者衝突沒有記錄的妥協，以及缺乏總體設計規範或文件。
歷史
[edit | edit source]極限程式設計是由肯特·貝克在克萊斯勒綜合薪酬系統 (C3) 薪資專案工作期間建立的。[6] 貝克於 1996 年 3 月成為 C3 專案負責人，並開始完善專案中使用的開發方法，並編寫了一本關於該方法的書籍（1999 年 10 月，《極限程式設計解釋》出版）。[6] 克萊斯勒在 2000 年 2 月取消了 C3 專案，當時該公司被戴姆勒-賓士收購。[7]
雖然極限程式設計本身比較新，但它的許多實踐已經存在了一段時間；畢竟，這種方法將“最佳實踐”提升到極限水平。例如，“在每個微增量之前先編寫測試的測試驅動開發實踐”早在 1960 年代初期的美國國家航空航天局水星計劃就被使用（Larman 2003)。為了縮短總開發時間，一些正式的測試文件（例如驗收測試）是在軟體準備測試時（或之前不久）開發的。在 XP 中，透過編寫自動化測試（可能位於軟體模組內部）來驗證即使是最小的軟體編碼部分的操作，而不是僅僅測試較大的功能，將這一概念提升到了極致。一些其他 XP 實踐，例如重構、模組化、自底向上設計和增量設計，由利奧·布羅迪在 1984 年出版的書籍中進行了描述。[8]
起源
[edit | edit source]1990 年代的軟體開發受到兩個主要影響的塑造：在內部，面向物件程式設計取代了面向過程程式設計，成為該行業某些人青睞的程式設計正規化；在外部，網際網路的興起和 dot-com 熱潮強調了上市速度和公司增長作為競爭優勢。快速變化的需求要求縮短產品生命週期，並且往往與傳統的軟體開發方法不相容。
克萊斯勒綜合薪酬系統啟動是為了確定使用物件技術的最佳方法，以克萊斯勒的薪資系統作為研究物件，使用 Smalltalk 作為語言，GemStone 作為資料訪問層。他們請來了肯特·貝克，[6] 一位著名的 Smalltalk 從業者，來對系統進行效能調優，但他的角色隨著他注意到他們在開發過程中遇到的幾個問題而擴大。他抓住這個機會，根據他與他的長期合作者沃德·坎寧安的工作，提出並實施了一些實踐上的改變。貝克描述了這些方法的早期構想：[9]
我第一次被要求領導一個團隊時，我要求他們做一些我認為明智的事情，比如測試和審查。第二次，風險更大。我心想，“該死的魚雷，至少這會讓文章寫得更好，”[並且]要求團隊將我認為至關重要的東西的旋鈕都調到 10，並排除其他一切。
貝克邀請羅恩·傑弗里斯加入專案，以幫助開發和完善這些方法。此後，傑弗里斯一直擔任教練，將這些實踐灌輸到 C3 團隊的習慣中。
有關 XP 背後的原則和實踐的資訊透過在坎寧安的 WikiWikiWeb 上的原始維基上的討論傳播到更廣泛的世界。各種貢獻者討論並擴充套件了這些想法，並由此產生了一些衍生方法（參見敏捷軟體開發）。此外，多年來，XP 網站上的超文本系統地圖一直對 XP 概念進行了解釋，網址為“http://www.extremeprogramming.org”，大約在 1999 年。
貝克編輯了一系列關於 XP 的書籍，從他自己的《極限程式設計解釋》（1999 年，ISBN 0-201-61641-6）開始，將他的理念傳播給更廣泛、但非常樂於接受的受眾。該系列的作者對 XP 及其實踐的各個方面進行了探討。甚至還有一本書專門批判這些實踐。
XP 在 20 世紀 90 年代後期和 20 世紀初引起了轟動，並在許多與起源截然不同的環境中被採用。
最初實踐所需的高紀律性往往會消失，導致一些被認為過於嚴格的實踐在個別站點上被棄用或縮減，甚至未完成。例如，針對特定專案的每日結束整合測試實踐，可能會改為每週結束的計劃，或者簡化為相互商定的日期。這種更為寬鬆的計劃可以避免人們為了透過每日結束測試而倉促生成人工存根。更靈活的計劃允許在幾天的時間內更充分地開發一些複雜的功能。然而，定期進行一些整合測試可以在將過多工作投入到不同方向的錯誤方向之前，檢測到不同小組在非相容、切線方向上的工作。
與此同時，其他敏捷開發實踐並沒有停滯不前，XP 仍在不斷發展，從實際經驗中吸取更多教訓，以使用其他實踐。在《極限程式設計解釋》的第二版中，貝克增加了更多價值和實踐，並將主要實踐和輔助實踐區分開來。
《極限程式設計解釋》將極限程式設計描述為一種軟體開發紀律，它組織人員以更高效地生產更高質量的軟體。
在傳統的系統開發方法（如 SSADM 或瀑布模型）中，系統的需求是在開發專案開始時確定的，並且通常從那時起就固定下來。這意味著在後期更改需求的成本（軟體工程專案的常見特徵[需要引用]）將很高。與其他敏捷軟體開發方法一樣，XP 試圖透過使用多個較短的開發週期來降低變更成本，而不是使用一個較長的開發週期。在這種理論中，變更是在軟體開發專案中自然、不可避免且理想的方面，應該對其進行規劃，而不是試圖定義一組穩定的需求。
極限程式設計還在敏捷程式設計框架之上引入了一些基本價值觀、原則和實踐。
XP 描述了在軟體開發過程中執行的四項基本活動：編碼、測試、傾聽和設計。下面將分別描述這些活動。
XP 的支持者認為，系統開發過程中唯一真正重要的產出是程式碼 - 計算機可以解釋的軟體指令。沒有程式碼，就沒有可用的產品。
編碼還可以用來找出最合適的解決方案。編碼還可以幫助傳達關於程式設計問題的想法。一個程式設計師在處理一個複雜的程式設計問題，發現難以向其他程式設計師解釋解決方案時，可能會將它編碼，並使用程式碼來演示自己的意思。支援這一觀點的人認為，程式碼始終清晰簡潔，不可能被解釋為多種含義。其他程式設計師可以透過編碼自己的想法來對這段程式碼給出反饋。
除非測試一個函式，否則無法確定它是否正常工作。錯誤和設計錯誤是軟體開發中普遍存在的問題。極限程式設計的方法是，如果少量測試可以消除一些缺陷，那麼大量測試就可以消除更多缺陷。
- 單元測試確定給定功能是否按預期工作。程式設計師會編寫儘可能多的自動化測試，這些測試可能會“破壞”程式碼；如果所有測試都成功執行，那麼編碼就完成了。每段編寫的程式碼在繼續下一個功能之前都要進行測試。
- 驗收測試驗證程式設計師理解的需求是否滿足客戶的實際需求。這些測試發生在版本規劃的探索階段。
“測試馬拉松”是一個程式設計師見面進行協作測試編寫的活動，類似於軟體測試方面的頭腦風暴。
程式設計師必須傾聽客戶需要系統做什麼，需要什麼“業務邏輯”。他們必須充分理解這些需求，以便向客戶提供關於如何解決問題或無法解決問題的技術方面的反饋。客戶和程式設計師之間的溝通在規劃遊戲中得到了進一步的解決。
從簡單性的角度來看，當然可以說系統開發不需要編碼、測試和傾聽之外的東西。如果這些活動執行得當，結果應該始終是一個可以工作的系統。實際上，這行不通。在沒有設計的情況下，可以走很遠，但在某個時候，你會卡住。系統變得過於複雜，系統內的依賴關係不再清晰。可以透過建立組織系統邏輯的設計結構來避免這種情況。良好的設計可以避免系統內出現大量依賴關係；這意味著更改系統的一部分不會影響系統的其他部分。
極限程式設計最初在 1999 年認可了四個價值觀。在《極限程式設計解釋》的第二版中增加了一個新的價值觀。五個價值觀是
構建軟體系統需要將系統需求傳達給系統開發者。在正式的軟體開發方法中，此任務透過文件來完成。極限程式設計技術可以被視為在開發團隊成員之間快速構建和傳播機構知識的方法。目標是讓所有開發人員對系統的共同觀點與系統使用者持有的觀點相一致。為此，極限程式設計提倡簡單設計、共同隱喻、使用者和程式設計師之間的協作、頻繁的口頭交流和反饋。
極限程式設計鼓勵從最簡單的解決方案開始。額外的功能可以在以後新增。這種方法與更傳統的系統開發方法的區別在於，它側重於為今天而不是明天、下週或下個月的需求進行設計和編碼。這有時被概括為“你不會需要它”（YAGNI）方法。[5] XP的支持者承認，這種方法有時會帶來明天修改系統需要更多努力的弊端；他們聲稱，這可以透過以下優勢來彌補：不投資於可能在變得相關之前就會發生變化的未來需求。為不確定的未來需求進行編碼和設計意味著存在將資源浪費在可能不需要的東西上的風險。與“溝通”價值相關的是，設計和編碼的簡單性應該提高溝通質量。一個簡單的設計和非常簡單的程式碼可以很容易地被團隊中的大多數程式設計師理解。
反饋
[edit | edit source]在極限程式設計中，反饋與系統開發的不同維度有關。
- 來自系統的反饋：透過編寫單元測試，[6] 或執行定期的整合測試，程式設計師可以從實現更改後系統的狀態獲得直接反饋。
- 來自客戶的反饋：功能測試（也稱為驗收測試）由客戶和測試人員編寫。他們將獲得有關其系統當前狀態的具體反饋。此審查計劃每兩到三週進行一次，以便客戶可以輕鬆地指導開發工作。
- 來自團隊的反饋：當客戶在規劃遊戲中提出新的需求時，團隊會直接給出實現這些需求所需時間的估計。
反饋與溝通和簡單性密切相關。透過編寫證明特定程式碼段會崩潰的單元測試，可以輕鬆地傳達系統中的缺陷。來自系統的直接反饋告訴程式設計師重新編寫此部分。客戶能夠根據功能需求（稱為使用者故事）[6] 定期測試系統。引用肯特·貝克的話說：“樂觀是程式設計的職業病，反饋是治療方法。”
勇氣
[edit | edit source]一些實踐體現了勇氣。其中一項原則是始終為今天而不是明天進行設計和編碼。這是為了避免陷入設計困境，從而需要花費大量精力才能實現其他任何內容。勇氣使開發人員能夠在需要時對程式碼進行重構而感到舒適。[6] 這意味著審查現有系統並對其進行修改，以便更容易地實現未來的更改。勇氣的另一個例子是知道何時丟棄程式碼：有勇氣刪除過時的原始碼，無論建立該原始碼花費了多少精力。此外，勇氣意味著堅持：程式設計師可能在一天中一直卡在一個複雜的問題上，然後在第二天快速解決問題，只要他們堅持不懈。
尊重
[edit | edit source]尊重價值包括尊重他人以及自尊。程式設計師不應該提交會導致編譯失敗、使現有單元測試失敗或以其他方式延誤同行的工作的更改。成員透過始終追求高質量並透過重構尋求當前解決方案的最佳設計來尊重自己的工作。
採用前面提到的四個價值觀會導致獲得團隊中其他人的尊重。團隊中的任何人都不會感到不被重視或被忽視。這確保了高度的動力，並鼓勵對團隊以及對專案目標的忠誠。這種價值觀非常依賴於其他價值觀，並且非常注重團隊中的人。
規則
[edit | edit source]XP規則的第一個版本由Don Wells[10]於1999年在XP網站上釋出。在規劃、管理、設計、編碼和測試類別中給出了29條規則。明確指出規劃、管理和設計是為了反駁XP不支援這些活動的論點。
Ken Auer[11]在2003年的XP/Agile Universe上提出了XP規則的另一個版本。他認為XP是由其規則而不是其實踐（實踐更容易發生變化和含糊不清）定義的。他定義了兩個類別：“參與規則”，規定了軟體開發能夠有效進行的環境，以及“遊戲規則”，定義了在參與規則框架內的逐分鐘活動和規則。
原則
[edit | edit source]構成XP基礎的原則基於上述價值觀，旨在促進系統開發專案中的決策。這些原則旨在比價值觀更具體，並且更容易轉化為實際情況下的指導。
反饋
[edit | edit source]極限程式設計認為，如果反饋快速完成，則反饋最有幫助，並表達了行動與其反饋之間的時間對學習和進行更改至關重要。與傳統的系統開發方法不同，與客戶的接觸是在更頻繁的迭代中進行的。客戶對正在開發的系統有清晰的瞭解。他或她可以根據需要提供反饋並指導開發工作。
單元測試也有助於快速反饋原則。在編寫程式碼時，單元測試會直接提供有關係統對所做更改的反應方式的反饋。例如，如果更改影響了與進行更改的程式設計師範圍無關的系統的一部分，那麼該程式設計師將不會注意到缺陷。當系統投入生產時，這種錯誤很可能出現。
假設簡單性
[edit | edit source]這是關於將每個問題都視為其解決方案“極其簡單”。傳統的系統開發方法建議計劃未來併為可重用性進行編碼。極限程式設計拒絕這些想法。
極限程式設計的倡導者表示，一次性進行大的更改並不奏效。極限程式設計應用增量更改：例如，系統可能每三週釋出一次小型版本。當進行許多小的步驟時，客戶可以更好地控制開發過程以及正在開發的系統。
擁抱變化
[edit | edit source]擁抱變化的原則就是不反對變化，而是擁抱它們。例如，如果在一次迭代會議上發現客戶的需求發生了巨大變化，程式設計師應該擁抱這種變化，併為下一次迭代計劃新的需求。
實踐
[edit | edit source]極限程式設計被描述為有12種實踐，分為四個領域
細粒度反饋
[edit | edit source]- 結對程式設計[6]
- 規劃遊戲
- 測試驅動開發
- 整個團隊
- 持續整合
- 重構或設計改進[6]
- 小版本釋出
- 可持續的步伐
- 客戶始終可用
- 先編寫單元測試程式碼
- 一次只有一對程式設計師整合程式碼
- 將最佳化留到最後
- 不加班
- 所有程式碼必須具有單元測試
- 所有程式碼必須透過所有單元測試才能釋出。
- 發現錯誤時，在解決錯誤之前先建立測試（錯誤不是邏輯錯誤，而是你忘記編寫的測試）
- 經常執行驗收測試併發布結果
XP 中的實踐一直存在爭議。[6] 極端程式設計的支持者認為，透過讓現場客戶[6] 非正式地提出變更請求，該過程變得靈活，並節省了正式開銷的成本。XP 的批評者認為，這會導致代價高昂的返工和專案範圍蔓延，超出之前商定的或已獲得資金的範圍。
變更控制委員會表明多個使用者在專案目標和約束方面存在潛在衝突。XP 的快速方法在一定程度上依賴於程式設計師能夠假設統一的客戶觀點，以便程式設計師可以專注於編碼，而不是記錄折衷目標和約束。這也適用於涉及多個程式設計組織的情況，尤其是那些爭奪專案份額的組織。[需要引用]
極端程式設計的其他潛在爭議方面包括
- 需求以自動驗收測試的形式表達，而不是規範文件。
- 需求是增量定義的，而不是試圖提前獲取所有需求。
- 軟體開發人員通常需要成對工作。
- 沒有前期的大設計。大部分設計活動是在執行中和增量進行的，從 "最簡單可行方案" 開始，只有在失敗的測試要求時才新增複雜性。批評者將其比作"除錯系統使其出現"，並擔心這將導致比僅在需求發生變化時進行重新設計更多的重新設計工作。
- 專案中配備了客戶代表。這個角色可能成為專案的單點故障，有些人發現它會導致壓力。此外，還存在非技術代表進行微觀管理的風險，他們試圖規定技術軟體功能和架構的使用。
- 對 XP 其他所有方面的依賴："XP 就像一圈毒蛇，串聯在一起。只要其中一條蛇鬆脫，就會有一條非常憤怒、有毒的蛇朝你襲來。" [12]
從歷史上看，XP 僅適用於 12 人或更少的團隊。解決此限制的一種方法是將專案分解成更小的部分，並將團隊分解成更小的組。據稱，XP 已成功用於超過 100 名開發人員的團隊中[需要引用]。ThoughtWorks 聲稱在多達 60 人的分散式 XP 專案中取得了合理的成功[需要引用]。
2004 年，工業極端程式設計 (IXP)[13] 作為 XP 的演變而被引入。它旨在帶來在大型分散式團隊中工作的能力。它現在有 23 種實踐和靈活的價值觀。由於它是敏捷家族的新成員，沒有足夠的資料來證明其可用性，但它聲稱是 XP 缺陷的解決方案。
2003 年，Matt Stephens 和 Doug Rosenberg 出版了《重構極端程式設計：反對 XP 的論據》，該書質疑 XP 流程的價值，並提出了改進 XP 的方法。這在文章、網際網路新聞組和網站聊天區引發了長時間的辯論。這本書的核心論點是，XP 的實踐是相互依存的，但很少有實際組織願意/能夠採用所有實踐；因此整個過程都會失敗。這本書還提出了其他批評，並以負面方式將 XP 的"集體所有權"模型比作社會主義。
自從《重構極端程式設計》（2003 年）出版以來，XP 的某些方面已經發生了變化；特別是，XP 現在允許對實踐進行修改，只要滿足所需目標。XP 還使用越來越通用的術語來表示過程。有些人認為這些變化使之前的批評失效；另一些人聲稱這只是在淡化流程。
RDP 實踐是一種定製極端程式設計的技術。該實踐最初是在由 Philippe Kruchten 和 Steve Adolph 組織的研討會中作為一篇長篇研究論文提出的（參見 APSO 研討會 在 ICSE 2008 ），但它是唯一提出的和可用於定製 XP 的方法。RDP 實踐背後的寶貴理念在短時間內為其在行業的適用性提供了理由。RDP 實踐試圖透過依賴 XP 規則技術來定製 XP。
其他作者試圖將 XP 與更早的方法協調起來，以形成一種統一的方法。XP 試圖取代其中一些，例如瀑布模型；例如：專案生命週期：瀑布、快速應用開發等等。摩根大通公司嘗試將 XP 與能力成熟度模型整合 (CMMI) 和六西格瑪的計算機程式設計方法結合起來。他們發現這三個系統相互加強，從而導致更好的開發，並且沒有相互矛盾。[14]
極端程式設計最初的炒作和有爭議的原則（例如結對程式設計和持續設計）引起了特別的批評，例如來自 McBreen[15] 和 Boehm 和 Turner[16] 的批評。然而，許多敏捷實踐者認為，這些批評是對敏捷開發的誤解。[17]
特別是，Matt Stephens 和 Doug Rosenberg 的《重構極端程式設計》對極端程式設計進行了審查和批評。[18]
批評包括
- 方法論的有效性取決於參與人員，敏捷無法解決這個問題
- 通常用作透過缺乏可交付成果的定義從客戶那裡榨取金錢的手段
- 缺乏結構和必要的文件
- 僅適用於高階開發人員
- 包含不足的軟體設計
- 需要頻繁的會議，給客戶帶來巨大的開銷
- 需要太多的文化變革才能採用
- 可能導致更困難的合同談判
- 效率低下：如果程式碼一個區域的要求在多次迭代中發生變化，則可能需要多次重複執行相同的程式設計。而如果有一個計劃要遵循，則預計只需要編寫一個程式碼區域。
- 無法制定提供報價所需的實際工作量估計，因為在專案開始時，沒有人知道整個範圍/需求
- 由於缺乏詳細的需求文件，可能會增加範圍蔓延的風險
- 敏捷是功能驅動的；非功能質量屬性很難作為使用者故事來設定
- ↑ "2005年以人為本的技術研討會"，2005，PDF 網頁：Informatics-UK-report-cdrp585.
- ↑ a b "設計模式和重構"，賓夕法尼亞大學，2003，網頁：UPenn-Lectures-design-patterns.
- ↑ a b "極限程式設計"（講座論文），USFCA.edu，網頁：USFCA-edu-601-lecture.
- ↑ "敏捷軟體開發宣言"，敏捷聯盟，2001，網頁：Manifesto-for-Agile-Software-Dev
- ↑ a b "每個人都是程式設計師"，作者：克萊爾·特里斯特拉姆。技術評論，2003年11月。第 39 頁
- ↑ a b c d e f g h i j k l m "極限程式設計"，計算機世界（線上），2001年12月，網頁：Computerworld-appdev-92.
- ↑ 重構極限程式設計：反對 XP 的論點. ISBN 1590590961.
{{cite book}}: 未知引數|coauthors=被忽略 (|author=建議) (幫助) - ↑ 布羅迪，萊奧 (1984)。思考 Forth (平裝本). 普倫蒂斯-霍爾. ISBN 0-13-917568-7. 檢索於 2006-06-19.
{{cite book}}: 引用中存在空的未知引數：|origmonth=，|month=，|chapterurl=，|coauthors=，以及|origdate=(幫助) - ↑ 肯特·貝克和馬丁·福勒的訪談
- ↑ 唐·韋爾斯
- ↑ 肯·奧爾
- ↑ 反對極限程式設計的論點：一個自指安全網
- ↑ Cutter 聯盟 :: 工業 XP：在大型組織中使 XP 奏效
- ↑ 極限程式設計 (XP) 六西格瑪 CMMI.
- ↑ 麥克布林，P. (2003)。質疑極限程式設計. 波士頓，馬薩諸塞州：艾迪生-韋斯利. ISBN 0-201-84457-5.
- ↑ 博厄姆，B. (2004)。平衡敏捷性和紀律：困惑之人的指南. 波士頓，馬薩諸塞州：艾迪生-韋斯利. ISBN 0-321-18612-5.
{{cite book}}: 未知引數|coauthors=被忽略 (|author=建議) (幫助) - ↑ sdmagazine
- ↑ 重構極限程式設計，馬特·斯蒂芬斯和道格·羅森伯格，出版商：Apress L.P.
- 肯·奧爾和羅伊·米勒。應用極限程式設計：為勝利而戰，艾迪生-韋斯利。
- 肯特·貝克：極限程式設計解釋：擁抱變化，艾迪生-韋斯利。
- 肯特·貝克和馬丁·福勒：計劃極限程式設計，艾迪生-韋斯利。
- 肯特·貝克和辛西婭·安德烈斯。極限程式設計解釋：擁抱變化，第二版，艾迪生-韋斯利。
- 阿里斯特·科伯恩：敏捷軟體開發，艾迪生-韋斯利。
- 馬丁·福勒：重構：改進現有程式碼的設計，艾迪生-韋斯利。
- 哈維·赫雷拉 (2005)。案例研究：克萊斯勒綜合薪酬系統. 蓋倫實驗室，加州大學歐文分校。
- 吉姆·海史密斯。敏捷軟體開發生態系統，艾迪生-韋斯利。
- 羅恩·傑弗里斯，安妮·安德森和切特·亨德里克森 (2000)，極限程式設計安裝，艾迪生-韋斯利。
- 穆罕默德·米拉克霍爾利 (2008)。RDP 技術：定製 XP 的一種實踐，國際軟體工程大會，2008 年關於審查敏捷實踐或敏捷牛仔競技場槍戰的國際研討會論文集，德國萊比錫 2008，第 23-32 頁。
- 克雷格·拉曼和 V. 巴西利 (2003)。“迭代式和增量式開發：簡史”，計算機 (IEEE 計算機協會) 36 (6): 47-56。
- 馬特·斯蒂芬斯和道格·羅森伯格 (2003)。重構極限程式設計：反對 XP 的論點，Apress。
- 瓦爾德納，JB. (2008)。“奈米計算機和群體智慧”。在：ISTE，225-256。
- 極限程式設計
- 一個簡要介紹
- 工業極限程式設計
- XP 雜誌
- XP 實施中的問題和解決方案
- 在離岸開發中使用敏捷軟體開發流程 - ThoughtWorks 在大型分散式專案中實施 XP 的經驗