新方法論（原始版本）

設計與建構的分離

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

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

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

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

那麼，這個計畫採取什麼形式？對許多人來說，這正是設計符號的角色，例如 UML。如果我們能使用 UML 做出所有重要的決定，我們就能建立一個施工計畫，然後將這些設計交給程式設計師作為施工活動。

但這裡存在著關鍵問題。你能得到一個有能力將編碼轉換為施工活動的設計嗎？如果是，施工在成本和時間上是否足夠大，以使這種方法值得？

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

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

這些問題導致傑克·李維斯提出，事實上，原始碼是一個設計文件，而施工階段實際上是編譯器和連結器的使用。的確，任何你可以視為施工的東西都可以而且應該自動化。

這種思考方式會導致一些重要的結論

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

需求的不可預測性

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

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

這樣做的一個問題是，光是試著了解需求的選項就很困難。這甚至更困難，因為開發組織通常不會提供需求的成本資訊。你最後會陷入一種情況，你可能很想要在你的車上安裝天窗，但業務員無法告訴你這會讓車輛成本增加 10 美元還是 10,000 美元。在對成本沒有太多概念的情況下，你怎麼能算出你是否願意為那個天窗付費？

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

軟體的無形本質也會造成影響。在實際使用軟體功能之前，很難看出它的價值為何。只有在使用某個軟體的早期版本時，你才會真正開始了解哪些功能是有價值的，哪些部分沒有價值。

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

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

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

預測性是否不可能？

一般來說，沒有。有些軟體開發是可以預測的。例如 NASA 的太空梭軟體團隊就是軟體開發可以預測的最佳範例。它需要許多儀式、充裕的時間、龐大的團隊和穩定的需求。有些專案就像太空梭一樣。不過，我不認為許多商業軟體符合這個類別。對於這類軟體，您需要不同類型的流程。

最大的風險之一就是假裝您可以在無法預測時遵循可預測的流程。從事方法論的人員不太擅長找出邊界條件：方法論從適用轉變為不適用的地方。大多數方法論學者都希望所有人都可以使用他們的方法論，因此他們不了解或不公開其邊界條件。這會導致人們在錯誤的情況下使用方法論，例如在無法預測的情況下使用可預測的方法論。

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

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

不過，放棄可預測性並不表示您必須回到無法控制的混亂狀態。相反地，您需要一個流程，讓您能夠控制無法預測的事物。這就是適應性的全部意義。

控制不可預測的流程

因此，我們如何在無法預測的世界中控制自己？最重要且仍然困難的部分是準確地知道我們身在何處。我們需要一個誠實的回饋機制，可以準確地告訴我們在頻繁的間隔中情況如何。

此回饋的關鍵在於反覆開發。這並非新觀念。反覆開發已存在一段時間，並有許多名稱：增量式、演化式、分階段式、螺旋式...名稱眾多。反覆開發的關鍵在於頻繁產生最終系統的可運作版本，其中包含部分必要功能。這些可運作系統的功能較少，但應忠實符合最終系統的需求。它們應完全整合，並經過與最終交付版一樣仔細的測試。

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

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

這方面的關鍵問題是反覆開發應該持續多久。不同的人有不同的答案。XP 建議反覆開發時間為一到三週。SCRUM 建議一個月的時間。Crystal 會再拉長。然而，趨勢是讓每次反覆開發時間盡可能短。這會提供更頻繁的回饋，讓您更常知道自己的進度。

適應型客戶

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

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

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

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

對客戶來說，最重要的優點是軟體開發更具回應性。一個可用，儘管是最小的系統，可以提早投入生產。客戶可以根據業務的變化，以及從系統實際使用方式中學習到的知識，來改變其功能。

可插拔程式單元

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

但這引發了一個關鍵問題：參與軟體開發的人員是否是可以替換的組成部分？輕量級方法的一個關鍵特徵是它們拒絕這個假設。

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

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

-- [cockburn-non-linear]

雖然 Cockburn 是在以人為中心的軟體開發觀點上最明確的人，但以人為先的概念是許多軟體思想家的共同主題。問題在於，方法論太常反對將人視為專案成功的首要因素。

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

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

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

泰勒主義概念的一個關鍵部分是，執行工作的人並非最能找出執行該工作的最佳方法的人。在工廠中，這可能是出於幾個原因。部分原因是許多工廠工人並非最聰明或最有創意的人，部分原因是管理階層與工人之間存在緊張關係，因為當工人賺得較少時，管理階層就能賺得更多。

最近的歷史越來越顯示，這對軟體開發來說有多麼不真實。越來越聰明和有能力的人被軟體開發所吸引，既被它的浮華所吸引，也被潛在的豐厚回報所吸引。（這兩者都讓我放棄了電子工程。）像股票選擇權這樣的計畫越來越多地將程式設計師的利益與公司的利益結合在一起。

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

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

管理以人為導向的流程

人員導向在輕量級流程中以許多不同的方式表現出來。它會導致不同的效果，並非全部都一致。

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

這最終得出一個有趣的結果，那就是只有開發人員自己才能選擇遵循適應性流程。這對於 XP 來說尤其如此，因為執行 XP 需要大量的紀律。這是 Crystal 如此有效補充的原因，因為它的目標是將紀律降到最低。

另一點是開發人員必須能夠做出所有技術決策。XP 在其規劃過程中深入探討這一點，其中指出只有開發人員可以估計完成某項工作需要多少時間。

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

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

企業領導的角色

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

這超出了大多數專案涉及業務角色的範圍。輕量級團隊無法僅靠偶爾的溝通而存在。他們需要持續取得業務專業知識。此外，這種取得並非由管理階層處理，而是每位開發人員都具備的。由於開發人員是其專業領域中的專業人員，因此他們需要能夠與其他專業領域的其他專業人員平等合作。

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

對開發人員來說，沒有什麼比看到自己的辛勤工作付諸東流更令人沮喪的了。因此，重要的是要確保開發人員可以取得優質的業務專業知識，而且品質足夠好，讓開發人員可以信任他們。

XP（極限程式設計）

在所有輕量級方法論中，這是最受關注的一種。部分原因在於 XP 領導者，特別是 Kent Beck，具有非凡的吸引力。另一個原因是 Kent Beck 吸引人們採用這種方法，並在其中扮演領導角色的能力。然而，在某些方面，XP 的流行已成為一個問題，因為它相當排擠了其他方法論及其有價值的想法。

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

從非正式實務到方法論的關鍵一步發生在 1996 年春天。Kent 被要求檢視 Chrysler 薪資專案的進度。該專案由一家承包公司使用 Smalltalk 執行，而且遇到了麻煩。由於程式碼庫的品質低落，Kent 建議丟棄整個程式碼庫並從頭開始他的領導。結果是 Chrysler C3 專案（Chrysler 全面補償），後來成為 XP 的早期旗艦和訓練場。

C3 的第一階段於 1997 年初上線。該專案持續進行，後來遇到困難，導致 1999 年進一步的開發被取消。在我撰寫本文時，它仍支付 10,000 名原有受薪員工的薪資。

XP 從四個價值觀開始：溝通、回饋、簡潔和勇氣。接著建立十二項 XP 專案應遵循的實務。其中許多實務都是古老、經過嘗試和驗證的技術，但許多人常常忘記，包括大多數計畫流程。XP 不僅復活這些技術，還將它們編織成一個協同整體，每個技術都由其他技術強化。

對我來說，最引人注目且一開始就吸引我的，是它強烈強調測試。雖然所有流程都提到測試，但大多數都相當不重視。然而，XP 將測試置於開發的基礎，每個程式設計師在撰寫生產程式碼時都會撰寫測試。這些測試會整合到持續整合和建置流程中，為未來的開發提供一個高度穩定的平台。

在這個平台上，XP 建立一個演化設計流程，依賴於每次迭代都重構一個簡單的基礎系統。所有設計都以目前的迭代為中心，不會針對預期的未來需求進行設計。結果是一個有紀律但令人驚訝的設計流程，將紀律與適應性結合起來，可以說是所有適應方法中發展得最好的。

XP 已經發展出廣泛的領導力，其中許多源自於開創性的 C3 專案。因此，有許多資訊來源。目前最佳的 摘要 是由局外人 Jim Highsmith 所撰寫，我稍後會介紹他自己的方法論。Kent Beck 撰寫了 極限程式設計精要，這是 XP 的關鍵宣言，說明了方法論背後的原理，並提供了足夠的說明，讓大家知道是否有興趣進一步探討。

另外兩本書正在進行中。C3 專案的三位成員：Ron Jeffries、Ann Anderson 和 Chet Hendrickson 正在撰寫 極限程式設計安裝，這是根據 C3 經驗對 XP 的說明。Kent Beck 和我正在撰寫 極限程式設計規劃，討論如何以這種適應方式進行規劃。

除了書籍之外，還有相當多的網路資源。許多 XP 想法的早期倡導和發展都發生在 Ward Cunningham 的 wiki 網路 協作寫作環境中。這個 wiki 仍然是一個令人著迷的發現之地，儘管它漫無邊際的性質確實會讓你深陷其中。若要找到更結構化的 XP 方法，最好從 C3 校友的兩個網站開始：Ron Jeffries 的 xProgramming.com 和 Don Wells 的 extremeProgramming.org。Bill Wake 的 xPlorations 包含許多有用的論文。著名的 C++ 和物件導向設計作者 Robert Martin 也加入了 XP 推廣者的行列。他的公司 ObjectMentor 在其網站上發表了許多論文。他們也贊助 xp 討論電子郵件群組。

Cockburn 的 Crystal 家族

Alistair Cockburn 從 90 年代初期受 IBM 委託撰寫方法論以來，就一直在研究方法論。然而，他的方法與大多數方法論者不同。他並非僅根據個人經驗建立一個關於如何做事理論，而是補充他的直接經驗，積極尋求訪問專案以了解它們如何運作。此外，他不害怕根據他的發現改變他的觀點：所有這些都使他成為我最喜歡的方法論者。

他的書，Surviving Object-Oriented Projects，是他對執行專案的第一個建議，並仍然是我執行反覆專案的首選書籍推薦。

自從那本書後，他進一步探討輕量化方法，提出了Crystal 系列方法論。之所以稱為系列，是因為他相信不同類型的專案需要不同類型的的方法論。他沿著兩個軸線探討這種變化：專案中的人數和錯誤的後果。每種方法論都適合網格的不同部分，因此一個可能損失自由支配資金的 40 人專案，與一個六人攸關性命專案，會有不同的方法論。

Crystals 與 XP 共享以人為導向的取向，但這種以人為中心的做法是以不同的方式進行的。Alistair 認為人們很難遵循嚴謹的流程，因此 Alistair 沒有遵循 XP 的高度紀律，而是探討了最不嚴謹但仍能成功的方法論，有意識地以生產力換取執行容易性。因此，他認為雖然 Crystal 的生產力不如 XP，但更多人能夠遵循它。

Alistair 也非常重視反覆檢討，因此鼓勵流程自我改善。他斷言反覆開發的目的是及早發現問題，然後讓人們能夠糾正它們。這更強調人們監控他們的流程，並在開發過程中調整流程。

開源

你可能會對這個標題感到驚訝。畢竟，開源是一種軟體風格，而不是一個流程。然而，在開源社群中確實有明確的做事方式，而且他們的許多方法與閉源專案一樣適用於開源專案。特別是他們的流程針對實體分散的團隊，這一點很重要，因為大多數適應性流程都強調同處一地的團隊。

大多數開源專案都有一個或多個維護者。維護者是唯一被允許將變更提交到原始碼儲存庫的人。然而，除了維護者之外的人員也可以對程式碼庫進行變更。關鍵的區別在於其他人需要將他們的變更傳送給維護者，然後維護者會檢閱它並將它套用於程式碼庫。通常這些變更會以補丁檔的形式進行，這讓這個流程更容易。因此，維護者負責協調補丁檔並維護軟體的設計凝聚力。

不同的專案以不同的方式處理維護人員的角色。有些專案為整個專案指派一位維護人員，有些將專案分為模組，並為每個模組指派一位維護人員，有些會輪流擔任維護人員，有些會在相同的程式碼上指派多位維護人員，而其他則會結合這些想法。大多數的開放原始碼人員都是兼職的，因此如何讓這樣的團隊協調一個全職專案，是一個問題。

開放原始碼開發的一個特殊功能是，除錯具有高度的平行性。因此，許多人可以參與除錯。當他們找到錯誤時，他們可以將修補程式傳送給維護人員。這是非維護人員一個很好的角色，因為大部分時間都花在尋找錯誤上。對於沒有強大設計技能的人來說，這也是一個很好的角色。

開放原始碼的流程尚未寫得很完善。最著名的論文是 Eric Raymond 的大教堂與市集，雖然這是一個極佳的描述，但它也很簡短。Klaus Fogel 的書關於 CVS 程式碼儲存庫也包含幾個關於開放原始碼流程的章節，即使是那些從來不想執行 cvs 更新的人也會覺得很有趣。

Highsmith 的適應式軟體開發

Jim Highsmith 花了很多年的時間研究預測方法。他開發了這些方法，安裝了這些方法，教授了這些方法，並得出結論，這些方法有根本上的缺陷：特別是對於現代企業而言。

他最近的書重點在於新方法的適應性，特別強調應用源自複雜適應系統（通常稱為混沌理論）中的想法。它沒有提供像 XP 工作那樣的詳細實務，但它確實提供了適應性開發為何重要的基本基礎，以及在更深層的組織和管理層級的後果。

SCRUM

SCRUM 在物件導向的圈子裡已經存在一段時間了，雖然我必須承認，我對它的歷史或發展並不熟悉。它再次強調一個事實，即定義且可重複的流程只適用於在定義且可重複的環境中，由定義且可重複的人來解決定義且可重複的問題。

SCRUM 將專案分為 30 天的迭代（他們稱之為衝刺）。在開始衝刺之前，您必須定義該衝刺所需的功能，然後讓團隊交付它。重點是在衝刺期間穩定需求。

然而，管理階層並不會在衝刺期間脫離團隊。團隊每天都會舉行一個簡短（十五分鐘）的會議，稱為 scrum，團隊會在會議中討論隔天將執行的任務。特別是，他們會向管理階層提出阻礙進度的障礙，讓管理階層解決。他們也會報告已完成的工作，讓管理階層每天都能掌握專案進度。

SCRUM 文獻主要關注於反覆規劃和追蹤流程。在許多方面，它與其他輕量級方法非常接近，且應能與 XP 的編碼實務配合得很好。

目前沒有任何一本關於 SCRUM 的書籍，但有許多網路資源。Ken Schwaber 架設了 controlChaos.com，這可能是對 SCRUM 最好的概述。Jeff Sutherland 一直有一個關於物件技術議題的活躍網站，其中包含一個 關於 SCRUM 的區塊。在 PLoPD 4 書中也有關於 SCRUM 實務的良好概述。

Coad 的功能驅動開發

功能驅動開發（FDD）是由長期的 OO 大師 Peter Coad 所開發。與其他適應性方法論一樣，它專注於提供具體功能的短暫反覆。在 FDD 的情況中，反覆時間為兩週。

FDD 有五個流程。前三個流程在專案開始時執行。

• 開發整體模型
• 建立功能清單
• 依功能規劃

後兩個流程在每個反覆中執行。

• 依功能設計
• 依功能建置

每個流程都會細分成任務，並提供驗證標準

開發人員分為兩種類型：類別擁有者和首席程式設計師。首席程式設計師是最有經驗的開發人員。他們會被指派建置功能。然而，他們並非單獨建置。相反地，首席程式設計師會找出哪些類別與實作功能有關，並召集其類別擁有者組成功能團隊來開發該功能。首席程式設計師擔任協調員、首席設計師和指導者的角色，而類別擁有者則負責大部分功能的編碼。

FDD 的主要描述在 Peter Coad 等人的 UML in Color 一書中。他的公司 TogetherSoft 也提供 FDD 的諮詢和培訓。

其他資源

關於輕量化方法這個主題，還有許多其他論文和討論。雖然這些可能不是完整的規範，但它們確實提供了對這個成長中的領域的見解。

Patterns Language of Programming 會議經常包含觸及這個主題的資料，原因僅僅在於許多對模式感興趣的人也對更具適應性和人性的方法感興趣。吉姆·科普林在 PLoP1 上發表的一篇論文是早期的一篇重要論文。沃德·坎寧安的 Episodes 模式語言出現在 PLoP2 中。吉姆·科普林現在主持 OrgPatterns 網站，一個收集組織模式的 wiki。

迪爾克·里勒寄了一篇論文給 XP2000，比較了 XP 和適應性軟體開發的價值系統。Coad 信的 七月號比較了 XP 和 FDD。IEEE Software 的七月號包含了幾篇關於「流程多樣性」的文章，這些文章觸及了這些方法。

哪一種適應式流程？

所有這些流程都是新的，我只能提供一些第一手經驗來指導您。在我選擇時，問題在於團隊規模以及他們準備好承擔多少紀律。

對於十幾個或更少的開發人員傾向於嘗試它，我肯定會推動 XP。團隊可能不會一開始就全力投入 XP 流程，但您仍然可以通過部分 XP 方法獲得很多好處。對我來說，使用此流程的關鍵測試是自動化單元測試。如果團隊準備好這樣做，那麼技術基礎將會到位。如果他們無法做到這一點，那麼我懷疑他們會處理好其餘的事情。

如果沒有紀律，或者團隊規模太大，那麼我傾向於遵循 Crystal 的建議。這肯定是輕量級的，而 Cockburn 特別適應開發的經驗教訓。在這些情況下，我仍然會使用 XP 計劃流程。

然而，話雖如此，我正在與一個由四十人組成的團隊合作，他們成功嘗試了許多 XP 實務，並且非常接近完整的 XP，因此，只要有決心和一個有承諾的團隊，您就可以在至少一些這些界限之外調整您的流程。

而這才是關鍵訊息。無論您從哪個流程開始，這都不是真正適合您的流程。您必須負責您的流程，監控它並根據您的情況進行調整。最終它必須成為您的流程，任何其他標籤都是次要的。