新方法論

設計與建構的分離

方法論的常見靈感來自於土木或機械工程等工程學科。此類學科在建造前非常注重規劃。這些工程師會製作一系列圖紙，精確指出需要建造什麼以及如何將這些東西組合起來。許多設計決策（例如如何處理橋樑上的負載）會在製作圖紙時做出。然後將圖紙交給不同的團隊（通常是不同的公司）來建造。假設施工過程將遵循圖紙。實際上，施工人員會遇到一些問題，但通常都很小。

由於圖紙指定了零件以及如何將它們組合在一起，因此它們作為詳細施工計畫的基礎。此類計畫可以找出需要完成的任務以及這些任務之間存在的依賴關係。這允許對施工進行合理的預測時間表和預算。它還詳細說明了從事施工工作的人員應如何執行其工作。這使得施工在智力上不太熟練，儘管他們通常在手動操作上非常熟練。

因此，我們在此看到的是兩種根本不同的活動。難以預測且需要昂貴且有創造力的人員的「設計」以及更容易預測的「施工」。一旦有了設計，我們就可以規劃施工。一旦有了施工計畫，我們就可以以更可預測的方式處理施工。在土木工程中，施工在成本和時間上都遠大於設計和規劃。

因此，軟體工程方法論的方法如下：我們想要一個可預測的時間表，可以使用技能較低的人員。為此，我們必須將設計與施工分開。因此，我們需要找出如何為軟體進行設計，以便在規劃完成後，施工可以很順利。

那麼這個計畫是什麼形式？對許多人來說，這是設計符號（例如 UML）的角色。如果我們可以使用 UML 做出所有重要的決策，我們就可以建立施工計畫，然後將這些設計作為施工活動交給編碼人員。

但關鍵問題在這裡。你能否獲得一個設計，能夠將編碼轉變為可預測的施工活動？如果是這樣，這樣做的成本是否足夠低，以使這種方法值得？

所有這些都讓人想到幾個問題。第一個問題是如何將類 UML 的設計轉變為可以交給程式設計師的狀態。類 UML 設計的問題在於，它在紙上看起來可能非常好，但實際上必須對其進行程式設計時，它卻存在嚴重的缺陷。土木工程師使用的模型基於多年的實務，這些實務已載入工程規範中。此外，關鍵問題（例如力在設計中扮演的方式）適用於數學分析。我們唯一可以對類 UML 圖形進行的檢查是同行審查。雖然這很有幫助，但它會導致設計中的錯誤，而這些錯誤通常只會在編碼和測試期間發現。即使像我這樣技術熟練的設計師，在將這種設計轉換為軟體時，也常常會感到驚訝。

另一個問題是比較成本。在建造橋樑時，設計工作的成本約佔工作量的 10%，其餘為施工。在軟體中，花在編碼的時間要少得多。McConnell 建議，對於大型專案，只有 15% 的專案是程式碼和單元測試，這幾乎與橋樑建造比率完全相反。即使將所有測試都視為施工的一部分，設計仍然佔工作量的 50%。這提出了關於軟體設計的性質與其在其他工程領域中所扮演角色之間的重要問題。

這類問題促使 Jack Reeves 建議，事實上，原始碼是一種設計文件，而施工階段實際上是使用編譯器和連結器。確實，任何可以視為施工的內容都可以而且應該自動化。

這種想法導致了一些重要的結論

• 在軟體中：施工非常便宜，幾乎是免費的
• 在軟體中，所有工作都是設計，因此需要有創造力且有才華的人
• 創造性過程不易規劃，因此可預測性很可能是一個不可能達成的目標。
• 我們應該非常小心使用傳統的工程比喻來建構軟體。這是一種不同的活動，需要不同的流程

需求的不可預測性

在每個我遇到的問題專案中，我聽過一個重複的抱怨。開發人員來找我並說：「這個專案的問題在於需求總是在變動」。我對這種情況感到驚訝的是，竟然有人會對此感到驚訝。在建置商業軟體時，需求變動是常態，問題在於我們如何處理它。

一個途徑是將需求變動視為需求工程不佳的結果。需求工程背後的想法是在開始建置軟體前，先對需求有充分的了解，取得客戶對這些需求的簽核，然後設定程序，在簽核後限制需求變動。

這其中一個問題是，光是試著了解需求選項就很困難。這更困難的原因在於，開發組織通常不會提供需求的成本資訊。你最後會發現自己處於一種情況，你可能很想要在你的車上安裝電動天窗，但業務員無法告訴你這會讓車子的價格增加 10 美元，還是 10,000 美元。在沒有成本概念的情況下，你怎麼知道你是否願意付費安裝電動天窗？

估算很困難，原因有很多。部分原因在於軟體開發是一種設計活動，因此很難規劃和估算成本。部分原因在於基本材料持續快速變動。部分原因在於，很多事情取決於參與的個人，而個人很難預測和量化。

軟體的無形本質也加劇了這個問題。在實際使用軟體功能之前，很難看出它的價值。只有在你使用某個軟體的早期版本時，你才會真正開始了解哪些功能是有價值的，哪些部分不是。

這導致了一個諷刺的觀點：人們期望需求應該是可變動的。畢竟，軟體應該是「軟的」。因此，需求不僅是可變動的，而且應該是可以變動的。要讓軟體客戶修正需求需要耗費大量的精力。如果他們自己曾經涉足軟體開發，情況會更糟，因為他們「知道」軟體很容易變更。

但即使你能夠解決所有這些問題，並真正獲得一組準確且穩定的需求，你可能仍然註定會失敗。在當今的經濟中，基本的商業力量正在過於快速地改變軟體功能的價值。現在可能是一組良好的需求，但在六個月後就不是了。即使客戶能夠修正他們的需求，商業世界也不會為他們停下腳步。而且商業世界的許多變化都是完全無法預測的：任何人如果說不是這樣，要不是在說謊，就是已經在股票市場交易中賺了十億美元。

軟體開發中的其他所有事情都取決於需求。如果你無法獲得穩定的需求，你就無法獲得可預測的計畫。

預測性是否不可能？

一般來說，不行。有些軟體開發是可以預測的。例如 NASA 的太空梭軟體團隊，就是軟體開發可以預測的絕佳範例。這需要大量的儀式、充足的時間、龐大的團隊和穩定的需求。有些專案就像太空梭。不過，我不認為大多數的商業軟體都屬於這個類別。對於這些軟體，你需要一種不同的流程。

其中一個最大的危險是假裝你可以遵循一個可預測的流程，但實際上並非如此。從事方法論的人員並不太擅長於識別邊界條件：方法論從適當轉變為不適當的地方。大多數方法論學者都希望他們的理論能被所有人使用，因此他們不了解或不公開他們的邊界條件。這導致人們在錯誤的情況下使用某種方法論，例如在不可預測的情況下使用可預測的方法論。

有強烈的誘惑會這麼做。可預測性是一個非常理想的屬性。然而，如果你相信你可以在無法預測的情況下進行預測，這將導致人們在早期制定計畫，然後無法適當地處理計畫瓦解的情況。你會看到計畫和現實逐漸脫節。很長一段時間，你可以假裝計畫仍然有效。但到了某個時刻，差距會變得太大，計畫就會瓦解。通常這種瓦解是痛苦的。

因此，如果你處於一個無法預測的情況，你就不能使用預測性方法論。這是一個沉重的打擊。這表示許多用於控制專案的模型，許多用於整個客戶關係的模型，都不再適用。可預測性的好處非常大，很難放棄它們。就像許多問題一樣，最困難的部分只是意識到問題的存在。

然而，放棄可預測性並不表示你必須回到無法控制的混亂中。相反地，你需要一個可以讓你控制不可預測性的流程。這就是適應性的全部意義。

控制不可預測的流程 - 迭代

那麼，我們如何在一個不可預測的世界中控制自己？最重要且仍然困難的部分是準確地知道我們在哪裡。我們需要一個誠實的回饋機制，它能準確地告訴我們在頻繁的間隔中情況是什麼。

這種回饋的關鍵是反覆開發。這不是一個新觀念。反覆開發已經存在一段時間，有許多名稱：增量式、演化式、分階段式、螺旋式... 許多名稱。反覆開發的關鍵是頻繁地製作最終系統的工作版本，其中包含所需功能的子集。這些工作系統的功能較少，但否則應忠實於最終系統的需求。它們應完全整合，並像最終交付一樣經過仔細測試。

這一點的重點是，沒有什麼比經過測試的整合系統更能為任何專案帶來強有力的現實感。文件可以隱藏各種缺陷。未經測試的程式碼可以隱藏許多缺陷。但是當人們實際坐在系統前並使用它時，缺陷就會真正顯現：無論是在錯誤方面，還是在需求誤解方面。

在可預測的流程中，反覆開發是有意義的。但在適應性流程中，反覆開發是必要的，因為適應性流程需要能夠處理所需功能的變更。這會導致一種規劃風格，其中長期計畫非常流動，而唯一穩定的計畫是為單一反覆開發而制定的短期計畫。反覆開發在每次反覆開發中為你提供穩固的基礎，你可以以此為基礎制定後續計畫。

這方面的關鍵問題是反覆開發應持續多久。不同的人有不同的答案。XP 建議一到兩週的反覆開發。SCRUM 建議一個月的長度。Crystal 可能會進一步延伸。然而，趨勢是讓每次反覆開發盡可能短。這會提供更頻繁的回饋，因此你可以更常知道自己的進度。

適應性客戶

這種適應性流程需要與客戶建立不同類型的關係，特別是在開發是由獨立公司執行時。當你聘請獨立公司進行軟體開發時，大多數客戶會偏好固定價格合約。告訴開發人員他們想要什麼，要求報價，接受報價，然後開發組織就有責任建置軟體。

固定價格合約需要穩定的需求，因此需要可預測的流程。適應性流程和不穩定的需求表示你無法使用通常的固定價格概念。嘗試將固定價格模型套用在適應性流程中，最終會導致非常痛苦的爆炸。這種爆炸的可怕之處在於，客戶受到的傷害與軟體開發公司一樣多。畢竟，如果客戶的業務不需要，他們就不會想要軟體。如果他們得不到軟體，他們的業務就會受損。因此，即使他們沒有支付任何費用給開發公司，他們仍然會損失。事實上，他們損失的金額會超過他們為軟體支付的金額（如果該軟體的業務價值較低，他們為什麼要付費購買軟體？）

因此，在無法使用可預測流程的條件下簽訂傳統的固定價格合約，對雙方來說都是危險的。這表示客戶必須以不同的方式工作。

這並不表示你無法預先為軟體設定預算。這表示你無法設定時間、價格和範圍。常見的敏捷方法是設定時間和價格，並允許範圍以受控的方式變更。

在適應性流程中，客戶對軟體開發流程有更細緻的控制。在每次反覆開發中，他們都可以檢查進度並更改軟體開發的方向。這會導致與軟體開發人員建立更緊密的關係，成為真正的業務夥伴關係。這種程度的參與並不適合每個客戶組織，也不適合每個軟體開發人員；但這對於讓適應性流程正常運作至關重要。

所有這些都為客戶帶來許多優點。首先，他們獲得更具回應性的軟體開發。一個可用，儘管最小的系統，可以在早期投入生產。然後，客戶可以根據業務變更，以及從實際使用系統中學習到的知識，來變更其功能。

與此同樣重要的是對專案真實狀態的更高可見度。預測流程的問題在於專案品質是透過符合計畫來衡量的。這使得人們在現實與計畫出現分歧時難以發出訊號。常見的結果是專案後期進度大幅落後。在敏捷專案中，每次反覆運算都會持續重新制定計畫。如果潛伏著壞消息，它往往會提早出現，而此時仍有時間採取措施應對。事實上，這種風險控制是反覆開發的一項主要優點。

敏捷方法透過縮短反覆運算長度，以及以不同的方式看待這些變異，進一步採取此步驟。瑪麗·波彭迪克以她的短語「需求的後期變更是一種競爭優勢」最精闢地總結了觀點上的這種差異。我認為大多數人都注意到，業務人員在開始時很難真正了解他們對軟體的需求。我們經常看到人們在過程中了解哪些元素有價值，哪些沒有。通常，在客戶有機會使用軟體之前，最有價值的功能根本不那麼明顯。敏捷方法尋求利用這一點，鼓勵業務人員在系統建置時了解他們的需求，並以能夠快速納入變更的方式建置系統。

所有這些都對構成成功專案具有重要意義。預測專案通常透過它符合計畫的程度來衡量。一個準時且符合成本的專案被認為是成功的。這種衡量標準對敏捷環境來說毫無意義。對於敏捷主義者來說，問題在於業務價值 - 客戶是否獲得對他們而言比投入成本更有價值的軟體。一個好的預測專案將按照計畫進行，一個好的敏捷專案將建置出與原始計畫預見的不同且更好的東西。

可相容的程式單位

傳統方法的目標之一是開發一個流程，其中所涉及的人員是可以替換的組成部分。有了這樣的流程，你可以將人員視為可使用各種類型的人員資源。你有一個分析師、一些編碼人員、一些測試人員、一個經理。個人並不那麼重要，只有角色才重要。這樣一來，如果你計畫一個專案，就不管你得到哪個分析師和哪個測試人員，只要你知道你擁有多少人，這樣你才知道資源數量如何影響你的計畫。

但這引發了一個關鍵問題：參與軟體開發的人員是否是可以替換的零件？敏捷方法的一個關鍵特點是它們拒絕這個假設。

也許最明確拒絕將人員視為資源的是 Alistair Cockburn。在他的論文 將人員描述為非線性、一階軟體開發元件 中，他提出可預測的流程需要以可預測方式運作的元件。然而，人員並非可預測的元件。此外，他對軟體專案的研究使他得出結論，人員是軟體開發中最重要因素。

在 [他的文章] 標題中，我將人員稱為「元件」。這就是人員在流程/方法設計文獻中被對待的方式。這種方法的錯誤在於「人員」具有高度變異性和非線性，具有獨特的成功和失敗模式。這些因素是一階因素，而非可忽略的因素。流程和方法設計者未能考量這些因素，導致我們經常看到的各種非計畫專案軌跡。

-- [cockburn-non-linear]

人們不禁懷疑軟體開發的本質是否對我們不利。當我們對電腦進行程式設計時，我們控制的是一種本質上可預測的裝置。由於我們從事這項工作是因為我們擅長此道，因此當面對人類時，我們最容易搞砸。

儘管 Cockburn 在其以人為中心的軟體開發觀點中表達得最為明確，但以人為先的概念是許多軟體思想家的共同主題。問題在於，方法論往往反對將人員視為專案成功的首要因素的概念。

這會產生強烈的正向回饋效果。如果你期望所有開發人員都是即插即用的程式設計單元，你就不會嘗試將他們視為個人。這會降低士氣（和生產力）。優秀的人員會尋找更好的地方，而你最終會得到你想要的：即插即用的程式設計單元。

決定以人為優先是一項重大的決定，需要很大的決心才能貫徹始終。將人視為資源的概念深植於商業思維中，其根源可以追溯到 弗雷德里克·泰勒 的科學管理方法的影響。在經營工廠時，這種泰勒主義方法可能是有道理的。但是，對於我認為軟體開發是高度創造性和專業性的工作來說，這並不成立。（事實上，現代製造業也在遠離泰勒主義模式。）

程式設計師是負責任的專業人士

泰勒主義概念的一個關鍵部分是，從事這項工作的人並非最能找出如何最好地完成這項工作的人。在工廠裡，這可能是由於幾個原因。部分原因是，許多工廠工人並非最聰明或最有創造力的人，部分原因是管理層與工人之間存在緊張關係，因為當工人賺得較少時，管理層可以賺得更多。

最近的歷史越來越向我們展示，對於軟體開發來說，這種說法是多麼不真實。越來越聰明和有能力的人被軟體開發所吸引，既被它的浮華所吸引，也被潛在的豐厚回報所吸引。（這兩者都讓我放棄了電子工程。）儘管 00 年代初經濟不景氣，但軟體開發中仍然有大量的才華和創造力。

（這裡很可能存在代際效應。一些軼事證據讓我懷疑在過去十五年左右的時間裡，是否有更多更聰明的人涉足軟體工程。如果是這樣，這將是電腦行業為何如此崇拜年輕人的一個原因，就像大多數崇拜一樣，其中需要有一絲真理。）

當您想聘用和留住優秀員工時，您必須承認他們是有能力的專業人士。因此，他們是決定如何進行技術工作的最佳人選。泰勒主義關於一個獨立的規劃部門決定如何做事的概念只有在規劃者比實際執行者更了解如何完成工作時才有效。如果您有聰明、有上進心的員工在做這項工作，那麼這一點就不成立。

管理以人為本的流程

人員導向在敏捷流程中以各種不同的方式表現出來。它會產生不同的影響，並非所有影響都一致。

其中一個關鍵要素是接受流程，而非強加流程。軟體流程通常是由管理階層強加的。因此，它們經常會遭到抵制，特別是當管理階層已經長時間離開實際開發工作時。接受流程需要承諾，因此需要團隊所有成員積極參與。

這最終導致一個有趣的結果，那就是只有開發人員自己才能選擇遵循適應性流程。這對於 XP 來說尤其如此，因為執行 XP 需要大量的紀律。Crystal 自認是一種紀律較少的做法，適合更廣泛的受眾。

另一點是，開發人員必須能夠做出所有技術決策。XP 在其規劃過程中直指這個核心，它指出只有開發人員才能估計完成某項工作需要多少時間。

這種技術領導力對於許多擔任管理職位的人來說是一個重大的轉變。這種做法需要分攤責任，開發人員和管理階層在專案領導方面享有平等的地位。請注意，我說的是平等。管理階層仍然扮演著角色，但承認開發人員的專業知識。

造成這種情況的一個重要原因是我們產業中技術變化的速度。幾年後，技術知識就會過時。技術技能的這種半衰期在任何其他產業中都是無與倫比的。即使是技術人員也必須承認，進入管理階層意味著他們的技術技能將會迅速衰退。前開發人員需要承認，他們的技術技能將會迅速消失，他們需要信任並依賴現任開發人員。

測量的困難性

如果你有一個流程，其中說明工作應如何完成的人員與實際執行工作的人員不同，則領導者需要一些方法來衡量執行者的效率。在科學管理中，強烈推動開發客觀的方法來衡量人員的產出。

由於難以對軟體套用測量，這對軟體來說特別相關。儘管我們盡了最大的努力，我們還是無法測量軟體中最簡單的事情，例如生產力。沒有這些事情的良好測量，任何類型的外部控制都注定要失敗。

在沒有良好測量的情況下引入測量管理會導致其自身的問題。Robert Austin 對此進行了精彩的討論。他指出，在衡量績效時，你必須將所有重要的因素納入衡量。任何遺漏的部分都會導致執行者改變他們的做法以產生最佳測量結果，即使這顯然會降低他們所做工作的真實效能。這種測量功能障礙是基於測量的管理的致命傷。

Austin 的結論是，你必須在基於測量的管理和委派管理（執行者決定如何執行工作）之間做出選擇。基於測量的管理最適合重複的簡單工作，知識需求低且產出易於測量 - 與軟體開發完全相反。

所有這些的重點在於，傳統方法在假設基於測量的管理是最有效率的管理方式下運作。敏捷社群認識到軟體開發的特點是，基於測量的管理會導致非常高的測量功能障礙。實際上，使用委派式管理風格更有效率，這是一種以敏捷主義觀點為核心的方法。

企業領導的角色

但是技術人員無法自己完成整個流程。他們需要業務需求的指導。這導致了適應性流程的另一個重要面向：他們需要與業務專業知識有非常密切的聯繫。

這超出了大多數專案對業務角色的參與。敏捷團隊無法在偶爾的溝通下生存。他們需要持續取得業務專業知識。此外，這種取得並非在管理層級處理，而是每個開發人員都具備的。由於開發人員是其專業領域中有能力的專業人士，因此他們需要能夠與其他專業領域的其他專業人士平等合作。

當然，其中很大一部分原因在於適應性開發的本質。由於適應性開發的整個前提是事物會快速變化，因此你需要持續聯繫才能通知所有人有關變更。

對開發人員來說，沒有什麼比看到自己的辛勤工作付諸東流更令人沮喪的了。因此，重要的是要確保有高品質的業務專業知識，既可供開發人員使用，又具有足夠的品質，讓開發人員可以信賴他們。

敏捷宣言

「敏捷」一詞在 2001 年初被劫持用於此活動，當時一群曾經深度參與這項工作的人聚在一起交換想法，並提出了敏捷軟體開發宣言。

在此工作坊之前，許多不同的團體一直在開發關於軟體開發的類似想法。這項工作大多（但絕非全部）來自物件導向軟體社群，該社群長期倡導迭代開發方法。這篇文章最初寫於 2000 年，試圖將這些不同的主題串聯起來。當時這些方法沒有共同的名稱，但「輕量級」的綽號已經在它們周圍出現。許多參與其中的人不認為這是一個好詞，因為它無法準確傳達這些方法的本質。

2000 年在俄勒岡州由肯特·貝克主辦的工作坊中，曾經討論過這些方法中更廣泛的問題。儘管這個工作坊專注於極端程式設計（當時最受關注的社群），但有幾位非極端程式設計師參加了。其中一個討論是極端程式設計是成為廣泛或具體的運動會更好。肯特比較喜歡一個更專注的凝聚社群。

如果我沒記錯的話，這個工作坊是由吉姆·海史密斯和鮑伯·馬丁主要組織的。他們聯繫了他們認為在具有這些類似想法的社群中很活躍的人，並在 Snowbird 工作坊中召集了十七人。最初的想法只是聚在一起，建立對彼此方法的更深入了解。羅伯特·馬丁熱衷於獲得一些聲明，一份可以讓產業團結在這些技術背後的宣言。我們還決定要選擇一個名稱作為各種方法的總稱。

在工作坊的過程中，我們決定使用「敏捷」作為總稱，並提出了宣言的一部分價值觀。原則部分在工作坊中開始，但大部分是在之後的 wiki 上開發的。

這項努力顯然引起了關注，我想我們都對宣言獲得的關注和讚賞程度感到非常驚訝。儘管宣言並非嚴謹的敏捷定義，但它確實提供了有助於集中想法的重點聲明。在我們完成宣言後不久，吉姆·海史密斯和我為《SD 雜誌》寫了一篇文章，對宣言提供了一些評論。

同年稍後，十七位撰寫宣言書的人員中的大多數，與其他許多人一起，在 2001 年的 OOPSLA 中再次聚首。有人建議宣言書的作者應該開始一些持續的敏捷運動，但作者們同意他們只是碰巧參加那個工作坊並製作那份宣言書的人。那個小組無法宣稱領導整個敏捷社群。我們協助船隻下水，應該讓任何想駕駛它的人駕駛。因此，十七位宣言書作者作為一個組織機構就此結束。

後續的下一步是成立 敏捷聯盟，許多這些作者積極參與其中。這個小組是一個非營利組織，旨在推廣和研究敏捷方法。在其他事務中，它贊助美國的年度會議。

XP（極限程式設計）

在 1990 年代後期敏捷方法開始流行時，極限程式設計獲得了最大的關注。在許多方面，它仍然如此。

XP 的根源在於 Smalltalk 社群，特別是 Kent Beck 和 Ward Cunningham 在 1980 年代後期的密切合作。他們兩人在 90 年代初期的許多專案中改進了他們的實務，擴展了他們對軟體開發方法的想法，這種方法既具有適應性，又以人為導向。

Kent 在諮詢任務中繼續發展他的想法，特別是 Chrysler C3 專案，該專案後來被稱為極限程式設計的創建專案。他大約在 1997 年開始使用「極限程式設計」這個術語。（C3 也標誌著我最初接觸極限程式設計，以及我與 Kent 友誼的開始。）

在 1990 年代後期，極限程式設計的消息傳開，最初是透過新聞群組的說明和 Ward Cunningham 的 wiki，Kent 和 Ron Jeffries（C3 的同事）花了很多時間在那裡說明和辯論各種想法。最後，在 90 年代末和 00 年代初出版了許多書籍，詳細說明了這種方法的各個方面。這些書籍大多以 Kent Beck 的 白皮書 為基礎。Kent 在 2004 年製作了白皮書的 第二版，對這種方法進行了重大的重新闡述。

XP 從五個價值觀開始（溝通、回饋、簡潔、勇氣和尊重）。然後將這些價值觀闡述成十四個原則，再進一步闡述成二十四個實務。這個想法是，實務是團隊每天可以做的事情，而價值觀是支撐這個方法的基本知識和理解。沒有實務的價值觀很難應用，而且應用方式有很多種，很難知道從何開始。沒有價值觀的實務是沒有目的的例行活動。價值觀和實務都很重要，但兩者之間有很大的差距 - 原則有助於彌合這個差距。XP 的許多實務都是古老、經過嘗試和測試的技術，但經常被許多人遺忘，包括大多數計畫流程。除了復活這些技術之外，XP 還將它們編織成一個協同的整體，其中每個技術都得到其他技術的加強，並由價值觀賦予目的。

對我來說，最引人注目且一開始就吸引我的地方之一，就是它非常強調測試。雖然所有流程都提到測試，但大多數都只給予很低的重視。然而，XP 將測試置於開發的基礎上，每個程式設計師在撰寫生產程式碼時都會撰寫測試。測試整合到持續整合和建置流程中，為未來的開發提供一個高度穩定的平台。XP 在這裡的方法，通常在標題 測試驅動開發 (TDD) 的描述下，即使在沒有採用 XP 其他大部分內容的地方也產生了影響。

關於極端程式設計有很多出版品。然而，一個混淆的領域是白皮書的第一版和第二版之間的轉變。我在上面說過，第二版是極端程式設計的「重新闡述」，因為方法仍然相同，但描述方式不同。第一版（有四個價值觀、十二個實務和一些重要但大多數被忽略的原則）對軟體產業產生了巨大的影響，而且大多數對極端程式設計的描述都是根據第一版的描述撰寫的。在閱讀有關 XP 的材料時請記住這一點，特別是如果是在 2005 年之前準備的。事實上，大多數常見的 XP 網路描述都是基於第一版。

要深入了解，自然要從 白皮書第二版 開始。這本書簡短扼要（160 頁）地說明了 XP 的背景和實務。肯特·貝克在世紀之交編輯了一系列有關極端編程的多彩書籍，如果一定要選一本推薦，我會選擇 紫色那本，但請記住，它和大多數資料一樣，都是根據第一版編寫的。

網路上有很多關於 XP 的資料，但大多數都是根據第一版編寫的。我所知道的少數有考量第二版的說明之一，是 Michele Marchesi 所撰寫的 The New XP（PDF）一文，Michele Marchesi 是在薩丁尼亞舉辦原始 XP 會議的主辦人。如果要討論 XP，可以到 yahoo 郵件列表。

我早期參與 XP 社群，並與社群成員建立友誼，因此對 XP 非常熟悉、喜愛且有偏好。我認為它的影響力來自於將敏捷開發原則與實際執行這些原則的一套紮實技術相結合。許多早期關於敏捷的著作忽略了後者，引發了敏捷理念是否真的可行的疑問。XP 提供了實現敏捷希望的工具。

Scrum

Scrum 也在 80 年代和 90 年代發展起來，主要是在物件導向開發圈中，作為一種高度迭代的開發方法。它最著名的開發者是 Ken Schwaber、Jeff Sutherland 和 Mike Beedle。

Scrum 專注於軟體開發的管理面向，將開發分為 30 天的迭代（稱為「衝刺」），並透過每日 Scrum 會議進行更嚴密的監控和控制。它較不重視工程實務，許多人會將其專案管理方法與極端編程的工程實務結合。（XP 的管理實務其實沒有太大的不同。）

Ken Schwaber 是 Scrum 最積極的倡導者之一，他的 網站 是尋找更多資訊的好起點，而他的 書 可能是最好的入門參考。

Crystal

Alistair Cockburn 長期以來一直是敏捷社群的主要發言人之一。他開發了 Crystal 軟體開發方法家族，作為針對不同規模團隊量身打造的一組方法。Crystal 被視為一個家族，因為 Alistair 認為隨著團隊規模和錯誤嚴重性的變化，需要不同的方法。

儘管有這些變化，所有水晶方法都具備共同的特徵。所有水晶方法都有三個優先事項：安全性（在專案成果中）、效率、可居住性（開發人員可以與水晶共存）。它們也具備共同的特性，其中最重要的三個是：頻繁交付、反省改進和密切溝通。

可居住性優先事項是水晶思維方式的重要部分。Alistair 的任務（在我看來）是尋找最少的流程，並在人類不可避免的低紀律基本假設下仍能成功。因此，Alistair 認為水晶需要的紀律比極端程式設計少，以較低的效率換取更高的可居住性和降低失敗的機率。

儘管有水晶的綱要，但並未對其所有表現形式進行全面的描述。描述最完善的是 水晶精華，其中有現代書籍說明。還有一個 wiki 提供進一步的資料和水晶的討論。

情境驅動測試

從一開始，就是軟體開發人員推動敏捷社群。然而，許多其他人也參與軟體開發，並受到這股新運動的影響。一個顯而易見的群體是測試人員，他們經常生活在瀑布思維所包含的世界中。常見的準則指出測試的角色是確保軟體符合預先寫好的規格，因此測試人員在敏捷世界中的角色遠非明確。

事實證明，測試社群中的幾個人已經質疑主流測試思維一段時間了。這導致了一個稱為情境驅動測試的群體。最好的說明是這本書 軟體測試中的經驗教訓。這個社群在網路上也非常活躍，看看 Brian Marick（敏捷宣言的作者之一）、Brett Pettichord、James Bach 和 Cem Kaner 所主持的網站。

精實開發

我記得幾年前在軟體開發會議上發表有關敏捷方法的演講，並與一位熱切的女性討論敏捷理念與精實製造運動之間的相似之處。Mary Poppendieck（和丈夫 Tom）繼續成為敏捷社群的積極支持者，特別關注精實生產與軟體開發之間的重疊和靈感。

精實製造運動是由豐田的大野耐一所開創，通常稱為豐田生產系統。精實生產是許多早期敏捷主義者的靈感來源 - Poppendiecks 最著名於描述這些想法如何互動。一般來說，我對這些類比推理非常謹慎，事實上，設計和施工之間的工程分離一開始就讓我們陷入這種困境。然而，類比可以產生好點子，我認為精實理念為敏捷運動引入了許多有用的想法和工具。

Poppendiecks 的 書籍 和 網站 是獲取更多資訊的明顯起點。

（Rational）統一流程

另一個從物件導向社群中出現的知名流程是 Rational Unified Process（有時簡稱為 Unified Process）。最初的想法是，就像 UML 統一建模語言一樣，UP 可以統一軟體流程。由於 RUP 出現的時間與敏捷方法差不多，因此關於這兩者是否相容有很多討論。

RUP 是非常龐大的實務集合，實際上是流程架構，而不是流程。它並未提供單一軟體開發流程，而是試圖提供團隊可供個別專案選擇的共通實務集合。因此，團隊使用 RUP 的第一步應該是定義其個別流程，或如 RUP 所稱的開發案例。

RUP 的主要共通面向是它以用例為導向（開發透過使用者可見功能驅動）、反覆運算，以及以架構為中心（優先建立一個能持續整個專案的架構）。

我對 RUP 的經驗是，它的問題在於其無限的可變性。我曾看過 RUP 使用說明，範圍從具有「分析反覆運算」的僵化瀑布式流程到完美的敏捷流程。我發現，人們希望將 RUP 行銷為單一流程，導致人們幾乎可以做任何事並稱之為 RUP，結果讓 RUP 變成一個沒有意義的詞彙。

儘管如此，RUP 社群中仍有一些非常傑出的人物與敏捷思考非常契合。我對我與 Phillippe Kruchten 的所有會面印象深刻，而他的 書籍 是 RUP 的最佳起點。Craig Larman 也在關於 OO 設計的熱門 入門書籍 中，開發了以敏捷風格使用 RUP 的說明。