極限編程(Extreme Programming)

 極限編程(Extreme Programming)

作者 不詳 來源 http://www.cutter.com/

譯者 march-bird lucian yjf taopin wl jazz韓偉 nullgate Simon[AKA]

當今信息技術中最迫切的兩個問題是:

• 如何能快速地向商業用戶交付功能？
  
• 如何才能跟上近乎連續的變化?
  

　　變化本身也在不斷地變化中。不僅僅是變化的速度在不斷地提高，而且，組織正在不得不應付各種類型的變化--劇變與不斷被打破的平衡。產生劇變的技術，象在80年代早期的個人計算機，衝擊了一個工業(PC機以及若干相關的工業)而不時打斷的平衡--一個對生態系統或者對整個經濟產生巨大影響的介入--則影響了無數的物種，或者說，公司。已經成爲電子商務支柱的Internet, 就已使大範圍的行業產生劇變--更多的是打斷的平衡而不僅僅是一次劇變。

　　當整個商業模式正在發生變化，當"時間意味着市場"正成爲公司的咒語，當適應性與互連性正在成爲甚至是最呆板的組織的需要的時候，我們將有必要檢查以下的每一個方面:商業是如何管理的，客戶爲什麼而感到高興，以及產品是如何開發的。

　　終極編程(Extreme Programming )運動成爲面向對象編程這個團體的一部分已經有數年了， 但是直到最近才引起了越來越多的注意，特別是最近Kent Beck的《終極編程釋義:擁抱變化》(Extreme Programming Explained: Embrace Change)一書的出版。千萬不要因爲終極編程(業內人簡稱爲XP)這一稱呼而對它產生反感。 儘管Beck沒有說象配對編程(pair programming)，增量式計劃(incremental planning)之類的來源於XP,但是仍然有一些非常有趣的，我認爲也是很重要的概念可以借用XP來表達。現有有許多關於變化的討論， 但是XP卻有許多如何實際去做的非常好的想法。也就是這個副標題:擁抱變化。

　　有一種趨勢，特別在那些嚴格的方法論者中，希望剔除那些與"能力成熟度模型"(Capability Maturity Model CMM)或者是國際標準化組織的標準相比不那麼笨重的方法，比如象hacking(hacking推崇行動而不是思考從而導致了較低的質量)。剔除與某人關於這個世界的假設相沖突的實踐，這倒不失爲一種簡單的方法。

　　從另一個角度來看XP，它倒可能是一個難題的某個潛在的部分。混亂的時期產生新的問題，而後者又導致了新的實踐--新的實踐公然違抗 傳統的知識，但卻得以倖存下來是因爲它們能更好地適應這個新的現實世界。至少有四種實踐方式我覺得是屬於這個範疇的:

• XP 
  
• 輕量級的開發(Lean development)
  
• 輕量級的Crystal方法(Crystal Light methods)
  
• 自適應軟件開發(Adaptive software development)
  

　　儘管這些實踐中存在着差異，但是它們中也有相似的地方:它們都描述了與傳統軟件開發不同的方法。 雖然輕量級的開發與自適應開發針對的是戰略與項目管理的，但是XP卻用不同的視角將開發方法帶入了程序員與測試員的領域。

　　XP中許多部分其實都來自於業已存在的那些優秀的開發實踐。"XP中沒有一個想法是全新的。大多數想法產生的時間實際上和編程一樣古老"Beck在他書中的前言中這樣說道。但是我在某一個方面考慮的也許與Beck有所不同： 儘管XP所用的實踐方式不是全新的，但是概念的建立以及它們如何融合在一起極大地增強了這些"老"的實踐。我想除了許多其它的好思想外，還可以從XP中提煉出四個關鍵的思想:

• 變化的成本
  
• 重構
  
• 協作
  
• 簡單化
  

　　但是首先，我們來討論XP的基礎:那十二個用於XP的實踐方式。

XP－基礎

　　支持XP的人們總是會向你指出XP適合的地方以及他的某些侷限性。而XP的實踐者Beck以及Ron Jeffties卻相信XP會有更廣泛的應用前景。他們通常對於自己的要求都是很謹慎的。例如：小的（小於10人）公司局部（他們有直接的經驗）兩者對於XP的適應性都是很清楚的；他們並沒有試圖讓人們相信XP可以適用於一個200人的團隊。

工程

　　最爲著名的XP項目是克萊斯勒綜合補償系統（稱爲C3工程），它在上個世紀的90年代中期開始，到1997演變爲XP。Jeffries,是"終極編程三人組"之一（另外兩個是Beck同Ward Cunningham） 。
=======================================================================
註解： Chrysler Comprehensive Compensation system 克萊斯勒綜合補償系統
=======================================================================

　　最初，C3是一個基於OO（面向對象技術）的開發項目，尤其是它採用Smaltalk語言進行開發。（Smaltalk ：Xerox公司開發的一種高級程序設計語言,它支持和鼠標合用的選項屏驅動式應用程序,有助於建立便於使用的計算機程序。）作爲著名的 Smalltalk專家，Beck被邀請來討論有關SmalTalk性能優化的問題，並且在原項目被認爲不可救要的時候將其變爲一個採用面向對象OO （XP）方法的試驗性項目。Beck並且帶來了Jeffries用於幫助那些基本的東西，Jeffries在C3組一直幹到1999年的春天。最開始的需求是要做一個對約10，000個僱員每月薪水發放進行管理的系統。這個系統由大約2，000個類以及30，000個方法構成，並且在計劃方面提供有合理的容忍度

　　正向我們所談到，我問Jeffries他怎樣成功的將C3變爲XP並應用到其他的克萊斯勒IT項目。他笑着告訴了我。多年來我爲許多大型IT組織開發了不少RAD系統（快速原型開發），因此我知道爲什麼我們無法將成功的經驗運用於其它項目中. 對於RAD, XP, 輕量級的開發以及其它一些未得到廣泛應用的方法, 它們成功的原因至少有一百條.

實踐

　　應記住的一件事情就是我們應傾向於在小型的, 局部的團隊中運用XP。除了代碼與測試用例外, 儘量減少有些的影響。XP的實踐既有正面的表現,也有負面的。在某些方面看來，他們聽起來就像一堆規則，要做這個，不要做那個。對此Beck解釋道, 與規則相比, XP更像是指導方針，一個靈活的依賴於具體環境的開發方針。但是諸如"每週工作40小時"等看起來可能會感覺續續道道。Jeffries使得實踐也會互相作用的，平衡，互相加強。以至於挑選使用的同丟棄的都是棘手的事情。

　　計劃的制定：XP中關於制定計劃的實現方法中可以反映出大多數迭代式RAD項目的特點。短期的，每三週爲一個循環，頻繁地更新，按優先級劃分任務與技術， 分配stories（一個story定義了一個特殊的功能需求並以一種簡單的方式記錄在卡片上），所有的這些就是構成了XP中的計劃。

　　小版本："每個版本應該儘可能的小，而且包含最有商業價值的需求"，Beck如是說。這也反映了Tom Gilb在他的<軟件工程管理原則>書中提到的關於漸進式發佈的兩點："所有的大的項目都可以被分爲局部的, 有用的小的步驟"以及"進化的步驟會傳遞到下一級。"

　　小型版本的發佈意味着具有在大型項目中經常缺少的頻繁的反饋的實現.。 然而，一個開發小組當然需要考慮到"發佈"同"可發佈"的不同。無論是否是最終的版本發佈還是一個簡單的可發行版本的發佈, 都需要付出安裝，培訓，轉化等代價。

　　隱喻：在XP 中"隱喻"以及"story"的使用可能會讓人有一點不舒服。但是，這些術語的使用可以幫助我們以一種更人性化的方式加以理解，尤其是對客戶而言。從某種程度上來說，隱喻同體繫結構是同意語――他們都着重於從全局描述一個項目。但是體系結構經常會陷於符號與連接的泥潭。而XP使用"隱喻"定義一個從開發者到商業客戶都可聯繫的全面一致的主題。隱喻用於描述項目全面的面貌，而Story用於描述個別具體的特徵。

　　簡單的設計：簡單的設計包含兩個部分。一，爲已定義的功能進行設計，而不是爲潛在地未來可能的功能進行設計。二，創建最佳的可以實現功能的設計。換句話說，不用管未來會是怎樣，只創建一個目前爲止可以實現的最好的設計。" 如果你相信未來是不確定的，並且你相信你可以很方便的改變你的主意的話，那麼對未來功能的考慮是危險的。"Beck寫到。"只有在你真正需要的時候纔去做 "

　　在二十世紀八十年代，我發表了一篇有關自動化資料管理的文章"實際的同步數據"文章的意思是說數據的質量是使用功能，不是捕捉與存儲。此外，我說數據如果不是很系統的使用便會變壞。數據質量是系統使用的功能，不是可預料的設計。無論預期的對還是錯，試着設計一個我們從來都不會用到的數據，最終結果很可能我們一次也不會用到它們。XP的簡單設計方法反映了相同的觀點。如在本文後來所描述的那樣，這並不意味着不需要預測，而是說爲預測的內容所做的設計一旦發生變化，其導致的代價是十分巨大的。

　　重構：如果我不得不找出一個能夠將XP和其他方法區別開來的東西那就是重構――不斷的軟件再設計以改進它對於變化的反應。RAD方法常常很少甚至根本不與設計相關；XP應當被看作持續設計。當變化既快而且頻繁的時候，應投入更多的精力於重構之上。參見下面的"重構"和"數據重構"部分。

　　測試：XP充滿發人深思的有趣的難題。例如：什麼是"先測試後編碼"？我曾經同軟件公司和一些IT機構一起工作，在那兒是通過代碼的行數來對程序員的績效加以考覈，而測試的績效則是通過發現的缺陷的數量來考覈的。這兩種方法都不能鼓勵減少測試前產生的缺陷的數量。XP使用兩種測試：單元測試和功能測試。單元測試要求在寫代碼之前就開發出相應功能的測試方法，並並測試應當是自動化的。代碼一完成，它就被立即用有關測試集加以測試，從而能立即得到反饋。

　　最活躍的XP討論組仍然是Wiki exchange（XP是關於pattern總體討論的一部分），其中的一個討論圍繞聽取（需求）-> 測試 -> 代碼 -> 設計的生命週期。貼近客戶聆聽並收集他們的需求。開發測試用例（test cases）。完成對象編碼（使用配對編程）。當更多對象被加入系統時進行設計（或重構）。這個看起來混亂不堪的生命週期僅僅在經常變化的環境下才有意義。

　　配對編程：軟件（還是直接用Inspection爲好？）（也稱審查或走查）也是被廣爲接受（至少在理論上）和有效度量的少數軟件工程實踐之一。在最好情況下， Inspection這種協同交互的檢查能夠加速學習，同時發現缺陷。一個較少被知道的關於Inspection的統計數據是儘管它在發現缺陷方面非常有效，但通過團隊對於好的開發實踐持續的學習和協作，可以更好的在第一時間預防缺陷。

　　一家我工作過的軟件公司客戶引用一個內部研究結果，表明在測試階段發現一個缺陷需15小時，在 Inspection階段發現一個缺陷則需2－3小時，而在Inspection之前發現缺陷只需15分鐘。後面的數據來自於產生於常規審查的持續的團隊學習。配對編程將這個帶入下一步――與其用Inspection來遞增式學習，爲什麼不用配對編程來學習呢？

　　"配對編程是兩個人試圖同時編程和理解如何更好編程的一種對話"，Beck寫道。讓兩個人同時坐在一臺終端前面（一個人敲代碼或測試用例，一個人審查和思考）產生一種持續的、動態的交流。Williams在猶他大學進行的博士論文研究證明了配對編程不僅僅是一種美好的想法而且確有實效。

　　代碼共享：項目組中的每個人都可以在任何時候修改其他項目成員的代碼，這就是XP中所定義的代碼共享。對許多程序員以及經理而言，共有代碼的想法會引起一些疑慮，諸如"我不想讓那些笨蛋改我的代碼"，"出現問題我應該怪誰？"等等。共享代碼從另一個層面提供了對配對編程中協作的支持。

　　配對編程鼓勵兩個人緊密協作：每個人促使另一個更加努力以圖超越。共同所有鼓勵整個團隊更加緊密協作：每個個人和每個雙人更努力生產高質量設計、代碼和測試集。當然，所有這些強迫的"共同"不一定對所有的項目組適用。

　　經常集成：每日構造（build）在許多公司已經成爲規範，模仿有關"微軟"流程的出版物上的東西。（參見，例如，Michael A. Cusumano和Richard Selby的Microsoft Secrets）許多公司將每日編鏈作爲最小要求，XP實踐者將每日集成作爲最大要求，選擇每兩個小時一次的頻繁編鏈。XP的反饋週期迅速：開發測試集、編碼、集成（編鏈）和測試。

　　對於集成缺陷危險的認識已有多年了，但我們並不是總能擁有相應工具和時間將這些知識好好用起來。XP不僅提醒我們有可能有嚴重的集成錯誤，而且從實踐與工具的角度提供了一種新的認識。

　　每週只幹40小時：XP 有12條實踐的基本原則，但是有時候，比如象每週只幹40小時的原則，聽起來更象規則。我同意XP中的觀點。只是不認爲有必要硬性規定工作小時數。相比起來，我更喜歡一句類似於"不要把部隊燒光"的話。在一些情況下，工作40小時太勞累，而在另外一些組裏，甚至需要一週60個工作時。

　　Jeffries提供了關於加班的更多思索："我們說的是加班被定義爲我們不想在辦公室的時候呆在辦公室。而且你不應當加班超過一週。如果你超過了，就有什麼東西出了問題――你過於勞累，有可能比你按時下班乾的還差。我同意你關於60工作時一週的感受。在我們年輕和滿身幹勁的時候，這也許沒問題。值得注意的是拖沓的一週又一週。"

　　我不認爲一週的工作時間會造成大的差別。決定區別的是自願的貢獻。人們願意來工作嗎？他們對每一天都充滿幹勁嗎？人們必須來工作，但是他們通過投入項目來創造巨大成就，而投入僅僅產生於目標感。

　　現場客戶：這就對應到了最初軟件開發時所提出的問題――用戶參與。XP，同其他的快速開發一樣，要求客戶在現場持續地參與到項目組中。

　　編碼標準：XP實踐相互支持。例如，如果你進行配對編程並讓他人修改共有代碼，那麼編碼標準看起來就是必須的。

價值同規則

　　在2000年一月一日週六時候，華爾街日報（週一到週五出版的）用一個58頁的版面發佈了一個千僖年紀念版。在篇首的有關工業及金融的介紹裏標着Tom Petzinger.寫的："長久的需求與召喚：經濟新的增長點――顯得同以往不同"。底下的一行 Petzinger 寫着："創造性正代替'萬金藥'的資本在成爲首要的因素"。

　　Petzinger並沒有談論少數天才的創造性，而是談了以下羣體的創造性――從組到部門。一旦我們撇下天才們的個體創造，創造性就是環境的功能，而人們運用並互相協助而達到我們的結果的能力。如果你的公司認爲軟件開發只是一個統計上的重複試驗，刻板的，技術性的過程，那麼XP對於您也許並不合適。雖然XP中也有技術實踐裏的嚴格，但是XP本身是追求"創造"與"溝通"。

　　環境是靠價值同規則共同驅動的系統。XP（或者其他類似的）可能、也可能不適合您的單位，可是，應該澄清的是成功並不是只靠每週40小時的瘋狂工作或者配對編程，也不是依靠XP之中應用在您單位中的價值或者是規則。

　　Beck指出了四個價值，五個基本規則，以及十個輔助規則--不過我要提到是這五個規則。

　　溝通：是的，溝通，可是，這裏似乎沒有新的東西在裏面？溝通主要是看人們自己的看法，XP構建的基本是人與人，通過最簡潔的文檔，最直接的面對面溝通獲得對任務環境的理解。

　　簡潔：XP問每個開發組成員："可能實現的最簡潔的方法是什麼？"。今天所保持的簡潔，可以爲降低明天由於變更所帶來的費用

　　反饋：Beck 說："對於編程而言，樂觀主義是一種冒險。"，"而反饋則是相應的解決良藥。"無論是用反覆的構建或者頻繁的用戶功能測試，XP都能不斷地接收到反饋。雖然每次對軟件開發策略進行研討時，我們都會說及反饋--即使是非常有害的瀑布模型--不同的是XP的實踐者認爲反饋比起前饋(feedforward)來更爲重要。無論是對測試失敗的代碼進行修改或者是對用戶拒收的軟件從新返工，開發環境的快速變化要求開發人員對反饋有更好的認識。

　　勇氣：無論您是使用CMM方法或者是XP的方法，方法使用的本身是要求勇氣的。許多地方將勇氣定義爲做某件事情的權利，即使被迫去做其他的事情。開發人員經常藉口壓力而發出帶有許多缺陷的產品，並對此加以堅持。然而，更進一步的應該包括其他的正確的不同的東西進來。通常，人們並不是缺少勇氣，而是缺少一種讓正確實踐獲得承認的理由，而且，也不堅信這點，勇氣不像看起來那麼重要。而如果你對之沒有信心，那麼是很難盡力工作的。

　　"勇氣並不只是方法"，Jeffries說道，它是一種最終的價值。如果你在一種基於"溝通"，"簡潔"，"反饋"的模式下工作，你將獲得勇氣，越往前信賴就越不重要。

　　優質的工作：好，如果你們中有贊成劣質工作的話，那麼請舉手離開這兒吧。不論你是一個Rational Unified Process，CMM，或是XP的贊成者，其本質的觀點"你怎樣定義質量"與"什麼樣的活動會贏得高質量"，定義"無缺點"質量是這個問題的一個方向。Jerry Weinberg的定義是"質量是對多數人有益"

管理XP

　　對於針對小型項目以及編程而言，在XP（至少是Beck的書中）裏對管理的欠缺是可以理解的，。就如Beck寫的，"對於教練(coach)來說，或許最重要的工作就是獲得玩具同食物"（指導是Beck的管理戰略中的一個組成部分）

　　同許多的程序員一樣，他們推薦的管理策略像是：躲避。下面的假定呢？躲避會建立一個協作的環境，在傳統的基於任務的管理裏，這個假定是有效的。然而，根據我的經驗，創造並維持一個協作的環境會挑戰管理遠離編制任務列表以及檢查。

Figure 1 -- Historical lifecycle change costs.

Figure 2 -- Comtemporary lifecycle change costs.

變化的代價

　　Beck從他的早期的著作開始，就不斷向那些軟件工程中的一些"古訓"發出挑戰。從19世紀70年代中期的結構化方法，以至後來的那些更復雜的方法，他們都基於如圖1所示的那個"事實"，在整個80年代，我必須瞭解、使用、討論、實施這些方法。

　　Beck卻給我們提了一個問題，那些在70年代和80年代也許還能起到效果的方法，他們的經費開銷狀況（如圖1）現在已經發生了變化（如圖2），也就是說，維護的成本（也可以等價爲不斷髮生的變化）降低了，而不是越來越高。實際上，圖2所示的開銷情況在當今是否是事實其實並不重要，重要的是我們必須認識到，如果圖1的現象還在繼續重演的話，我們只有死路一條，因爲當今時代變化實在太快了（也就是說維護的成本將是一個天價）。

　　圖1中的y軸通常用來表示在開發週期的後期發現錯誤後需要花費的改錯成本。可是，這正驗證了一個假設，即後期所有需要做的開動均來自前期的一個錯誤，比方說一個設計缺陷。從這一點來看，傳統方法太依賴於在軟件生命週期的早期"不出錯"。但是在當今瞬息萬變的環境中，我們不能完全預防住那些我們預測不到的東西--即由應用需求不斷增長而帶來的變化，並且這種變化在早期不可能遇見並加以預防。因此，雖然我們要儘可能在早期做出某些應付變化的預防措施，但是更重要的是我們要減少後期改變所帶來的開銷。正如 Alistai Cockburn 所指出的，需要高成本的圖1所示的那種改正缺陷方法，正好從節省開支的角度給了一些實用的方法（如配對編程）一個好的理由。

　　在本期eAD雜誌中，我打算把討論定位於項目或應用軟件層次上的變化--對類似操作系統、編程語言、數據庫、組件等的討論不在討論之列。（關於軟件結構的靈活性，可以參考ADS雜誌1999年6月的那期）另外，讓我們進一步做個簡化，即假定軟件的用戶需求已經確定。

　　我們的目標是既能快速不斷的發佈新功能，同時又要讓軟件的設計易於更改。即使是在快速發佈這個目標下，仍然需要在"快速發佈但Bug叢生"和"面面俱到但曠日持久"之間進行取捨。因此，讓我再簡化一下我們要討論的問題，我們假定我們已經在設計、編碼和測試這三者之間取得了合理的平衡。

　　在上面這些簡化的基礎上，還留有一個尾巴：我們在設計時對於未知的未來要看多遠？現在的設計已經實現了我們現在想到的一些功能。具有預見性的設計可以使未來的需求更快的獲得實現，也就是說預見性設計方法在以現在的時間換取未來的時間，如果一點點現在的時間可以換來未來節約大量時間，當然是划算的。但是這種建設怎麼才能成爲現實呢？也許未來出了問題就整個重新設計一遍也不慢，那又何必現在瞎猜呢？

　　這就是我們爲什麼要提出重構的原因。重構，Martin Fowler說過，是不改變軟件對外表現但是重整內務的一種改進。XP方法的支持者在變化的環境中實踐了連續的、增量式的重構方法。如果變化是不斷演化的的，那就不可能存在什麼一步到位的設計方法。說白了，如果變化不可預測--正如當今社會的情況--過多的在設計時考慮以後可能的變化，完全是一種浪費。

Figure 3 -- Balancing design and refactoring, pre-internet.

Figure 4 -- Balancing design and refactoring today.

　　我認爲圖3給出的是互聯網時代到來之前的情況。由於變化的速度慢（圖中由天平的支點比較靠左來表示），早期的預測多一些是合理的。但是在圖4中，由於變化速度變快樂，設計時預測太多是得不償失的，這種情況正是現在許多系統所面臨的。

　　在一個長期項目中，檢驗一個設計是否具有很好的靈活性是通過變化需求，同時看看原設計能否很容易的實現新變化的需求。這種傳統的"先設計，再維護"策略的最大問題在於軟件系統存在非常大的熵（極易變化，沒有規律）。一個系統隨着時間的推移，維護、改錯、打補丁、增強功能等工作會使系統的熵越來越大。現在由於外部環境變化加快，情況正越來越糟。不過，現在的重構技術也不是第一個試圖解決這個問題的方法。早在所謂的"黑暗時期"（circa 1986），Dave Higgins 就寫過一本名爲"Data Structured Software Maintenance"的書，該書指出了由於隨着時間的推移變化的累計影響不斷增大，維護所需要的開銷也將越來說龐大，Higgins 提出了一種新的設計方法（the Warnier/Orr Approach）用於阻止系統的熵增大所帶來的負面影響，該方法的思想是在維護過程中有系統的對程序進行重新設計。

　　Higgins 的方法首先爲程序改如何設計設定一種模式（雖然那時還沒有模式這個提法），然後在細緻的代碼設計與"好"的模式之間建立一種映射，程序員即根據這種映射關係來理解系統並修改程序，使修改的結果更接近於那個模式。使用 Higgins 這個方法可以通過維護抵消系統誰時間而熵增大的趨勢。Higgins 說："該方法的目標並不是重寫整個系統，而只是重寫那些根據需要必須增強的部分。"

　　雖然這種原始的"重構"技術並沒有被廣泛的實踐檢驗，其思想與現在的重構還是相通的，只不過現在的需求變化更快、更大。不過有兩個東西驅動、提高了現代的重構技術：一是更好的程序設計語言和開發工具；二是更快的變化需求。

　　在早期的 RAD（快速原型開發）方法中還有另一種應付變化的辦法：代碼拋棄思想。這個思想認爲環境和需求變化太快，因此我們唯一的辦法只能是快速編寫新代碼，並且也快速的拋棄老代碼。我們認爲這不是長久之計。

重構

　　重構(Refactoring)與構造 (factoring)，或者說與設計模式的使用密切相關。Erich Gamma, Richard Helm, Ralph Johnson, 和 John Vlissides合著的《 Design Patterns: Elements of Reusable Object-Oriented 》一書爲設計模式做出了奠基性的工作。正如Larry Constantine 和Ed Yourdon 所倡導的結構化設計一樣，設計模式對當代的面向對象技術程序設計做出了巨大的貢獻，爲開發人員帶來了福音。通過設計模式，程序的結構的比以往更爲有效。

　　如果圖表4 所顯示的設計（designing）與重構(refactoring)在面對高速變化環境時的適應能力方面的差別是客觀的話，初始設計的質量則顯的尤爲重要。通過提供過去已被證明是有效的模式，設計模式(Design patterns)提供了一種提高初始設計質量的方法。

　　現在，也許你會問，爲什麼還需要一本獨立講重構的書呢？難道我們不可以只使用設計模式來重新設計嗎？可以，也不可以。正如所有的開發人員(包括管理者) 都知道，修改原有的程序代碼是一件棘手的事。development folklore年刊上有一句話，"if it ain't broke,don't fix it".然而，正如Fowler所提到的，"程序也許還沒有'壞掉'，但卻造成了潛在的危害." 害怕對那些還能"工作"的代碼重新構造實際上只會加劇代碼性能的衰退。同時，Fowler也清楚的認識到："在軟件重構之前，需要找到安全的做法……我把這些安全的步驟寫進了目錄"。Fowler所寫的<>,不僅編錄瞭如何對以前的（差的）代碼和以後的（基於模式設計的較好）的代碼進行重構的方法，而且也包含了代碼分割重構的步驟。這些步驟減少了在重構過程中出現差錯的機會。

　　Beck用"two-hat"方法來描述重構，也就是說, 添加新的功能與重構是兩種不同的行爲。在本質上，重構不改變軟件可見的外部功能，它只是增強了軟件的內部結構。當有新的功能需要添加時，第一步常是對軟件進行重構，使添加更簡化。事實上，這種添加的新功能爲重構提供着推動力。

　　與重量級的再設計相反，重構可以被認爲是增量（incremental）式的再設計，"沒有重構，程序設計會 腐爛"，Fowler寫到," 結構性的缺陷會帶來累積效應 "。歷史上，我們對軟件維護的方法是"quick and dirty"(快速但不徹底的?)，致使一些初始設計工作做的好的項目，隨着時間推移，也會"退化"（degrade）.

Figure 5 -- Software entropy over time.

　　圖表 5 顯示了沒有重構時的情況：因爲軟件是如此的不可靠，升級維護費用變的讓人望而卻步，於是巨型(monumental)設計(或替換)成了唯一選擇，項目的風險，至少是投入上，變的越來越大。圖 5也顯示，在80年代，軟件的生存期大約要10年，而在今天需求的快速變化加劇了軟件的腐爛。舉個例子，許多90年代初一窩蜂做出來的C/S應用軟件在今天比80年代留下來的大型機軟件的維護費用還要高的多。

數據重構: Ken Orr註解

　　編者注： 如上所提，XP和重構思想吸引我的一點是他們能夠清楚認識到所要考慮實施問題的邊界條件(boundary conditions).例如，Fowler寫了一章"Problems with Refactoring".其中首要的問題就是數據庫的重構。正如書的副標題所示，Fowler的目標是爲了提高代碼質量。爲此，我諮詢了一些在數據重構（或者用其他的術語）方面有較深研究的人。以下關於數據重構部分由Ken Orr所寫。

　　當Jim 要我講一講重構時，我問他重構究竟意味着什麼。對我來說，把它歸納爲以下簡單的幾點：

1. 做你會做的
   
2. 速戰速決
   
3. 當發生變化時，回過頭來重新設計
   
4. 回到 1
   

　　在過去幾年中，Jim和我一起工作，共同研究各種系統方法學(systems methodologies)，發現所有的方法學與重構思想(refactoring philosophy)有着一致的地方。70年代，我們建立了一種基於數據結構的方法學。其主要思想是：在知道了人們的需求後，逆向工作，設計一個僅含必需數據的數據庫，然後再確定更新數據庫必需的輸入數據，產生需要的輸出數據。

　　從輸出結果逆向工程到數據庫再到輸入來建構系統的方法被證明是一種非常有效和有效率的系統開發方法。幾乎在關係數據庫開始流行的同時，這種方法也發展了起來。使我們能夠建立起運作良好，規範化的數據庫。除此之外，這種思想也適用於創建最小系統(minimal systems).事實上，我們的一個客戶在重建一個系統時已經使用了這種方法並取得了成功。該客戶從輸出入手，通過逆向工程設計了一個滿足最小輸入需求的最小數據庫。

　　新系統只有老系統三分之一的數據元（data elements ）。這是一個大的突破。開發人員開始逐漸認識到建立最小系統有着巨大的優勢：系統更小因而可以更快的實現；功能單一更能適應變化。

　　然而，創建最小系統並不符合許多分析員和程序員們的想法，不管有多遙遠，他們總認爲自己可以超前思考並預見到未來的需求。我認爲這源於軟件難於維護的原因。維護一個大的系統是如此的困難並充斥着問題，以致於許多分析員和程序員寧願在系統開發的前期花費大量的精力來設計一個"完善"的系統，以求一勞永逸。然而事實證明，預測未來是徒勞的。不論我們有多聰明，思想有多超前，總會有一些不曾預料到的需求出現。（有多少人能夠在10年前就將基於internet 的電子商務作爲未來的需求寫入自己的軟件）

　　最後，維護如此困難的原因之一在於，當改變數據庫設計時，其他的問題都會接踵而來。在大多數開發人員看來，一旦設計好數據庫並在此基礎上開始了編碼以後，再去改變數據庫的設計幾乎是不可能的。在某種程度上，設計數據庫就好比建造系統的地基：一旦你把混凝土灌了進去，你就沒辦法再去改變它。因此，除非不可避免，大型系統中的數據庫極少會發生大的改動。人們不能把重新設計數據庫僅僅當成系統維護的普通一部分。否則的話，對系統進行大的改動會變的難以想象的困難。

進入數據重構

　　Jim和我永遠都不會承認一旦系統開始運行就不能再改變數據庫設計的觀點.我們認爲,如果你想使系統保持最精簡的狀態,就必須要把所要做的變化或新的功能引入到系統中並重復基本的開發過程,使新的需求和舊的需求融合在一起而成爲一個新的系統.你可能會說我們所作的就是數據重構,可我們從來不那麼說.

　　這麼做的好處是顯而易見的.首先,開發一個新系統和維護或對舊系統統進行較大改造的區別並不是很大.這就意味着管理一個項目和培訓工作將大大減少.同時,也將減少開發時間,這是因爲我們對變化的處理方式不同，一個是'built in'(建立在變化之上),另一個是'adding them on'(添加變化)。

　　在過去的幾年裏，我們建立了一種方法（結構化系統設計方法或Warnier-Orr法）並且培訓了數以千計的系統分析員和編程人員。即便我們在定義了足夠詳細的各種說明後有可能用CASE工具實現大部分工作，但開發過程仍需要大量的手工工作。

自動化的數據重構

　　爲了縮短開發時間，南美的一組系統開發人員在80年代年開發出了數據重構自動化工具。由Breogán Gonda 和 Nicolás Jodal領導的公司開發了一種名叫GeneXus的工具，這正是我們在70年代所構想要的。他們創建的方法使我們在輸入數據結構以後，系統能夠自動爲你創建規範的數據庫併產生瀏覽、更新和輸出數據的代碼。

　　這就使事情簡單了，這種工具使得當用戶的需求或系統的要求改變後只需要修改原有的定義，重新編譯，就能夠重新設計數據庫以適應新的需求，併產生僅僅受數據庫修改影響而需要改變的代碼。這就是基於數據的閉環的重構過程。

　　GeneXus使我們認識到重構能構給我們帶來的真正的東西。就我的經驗而言，這使開發人員從對未來需求的擔憂中解脫出來，從而能夠使開發人員僅僅定義他們所知道的並快速的實現所定義的所有內容。因此，當系統的需求更改以後，他們只須簡單的加入那些修改，重新編譯，就可以得到一個新的、完全集成的、滿足新的需求的最小系統。

所有的這一切意味着什麼？

　　重構正在逐漸變成一個時髦的詞語。與所有的時髦的東西一樣，既有好的一面，也有壞的一面。好的一面是：如果能夠正確的實施，重構使我們有可能快速構建健壯的系統。壞的一方面是：我們不得不重新考慮如何進行開發。原先採用的所有開發和管理策略需要重新考慮。我們必須瞭解交互式的、增量的開發方法；我們還必須習慣於使我們能夠成功的模式化的開發方法和使用工具來完成系統開發工作中那些複雜的工作（數據庫設計和代碼生成）。

　　80年代，CASE使開發產生革命性的變化。90年代，對象和OO方法也使開發產生革命性的變化。這些技術都沒有像達到期望的效果。但現在，像GeneXus這樣的工具切切實實的做到了80年代人們所期望的東西。確實有可能在給定系統需求後自動進行數據庫設計，生成一種實際工作的商用關係型數據庫（Oracle, DB2, Informix, MS SQL Server, and Access），併產生能夠瀏覽、更新和輸出數據庫中數據的不同語言（COBOL, RPG, C, C++, and Java）的代碼（原型和結果）。

　　新的系統開發方法能夠使我們有更多的時間和用戶交流，分析用戶的需求，讓用戶選擇不同的交互界面，這在只憑自己來完成所有事情的時侯是不可能的。但是並不是所有人都喜歡這一開發方法。一個是因爲這將很大程度上撥開開發過程的神祕面紗。另一個是因爲這也給快速開發增加了壓力。

　　當人們告訴你在Internet時代已經不可能再建立簡單、精簡的系統的時侯，那麼告訴他們Internet是速度和服務的天下，告訴他們重構不僅僅是在21世紀建立這樣系統的最好方法，也是唯一的方法。

輕量級的Crystal方法

　　注：在九十年代早期，Alistair Cockburn IBM顧問組工作時，爲OO（面向對象）的開發制訂了一套工作方法。IBM認爲不管白貓黑貓，抓的到老鼠就是好貓。Cockburn 深入接觸許多開發小組，寫下了他們認爲導致項目成功或者失敗的關鍵之處。結果讓人大吃一驚。以下內容是由 Cockburn寫的，基於他的含有極少方法論的"實戰工作"書 。

　　在IBM的研究組裏，開發小組要向以前成功的小組"道歉"，因爲他們沒有遵守一道正式的工序， 因爲他們沒有用一個高科技的CASE工具，又或者"僅僅"因爲他們坐在一起，討論他們下步 該怎麼做。 同時，一些失敗的小組覺得非常迷惑，儘管他們使用了正式的工序，他們還是 失敗了--也許是遵守這些工序還遵守的不夠好？後來我開始碰到一些成功的小組，他們宣稱 正是因爲沒有陷於花裏胡哨的過程和可發佈性，而是大家坐在一起，從而使得他們可以 更容易的加以討論並且經常交換測試後的軟件，最終才得以成功。

　　這些結論從 1991 到 1999，從香港到美國, 挪威, 和南非,在COBOL, Smalltalk, Java, Visual Basic, Sapiens, 和 Synon都是一貫堅持 , 這些結論的最短描述是：

儘可能在你的範圍內，用面對面的溝通來代替寫文檔，從而可以減少對寫好了的工作產品的依賴，並增大發布系統的可能性

越是經常發佈正在運行着並且經過測試的系統片段，就越能讓你減少對寫好的"約定"標記的依賴，越能增大最終發佈系統的可能性

　　應當以人性的方式加以溝通。即使是對內向的程序員來說，採用不拘禮節的面對面的交流，都比採用寫在紙上的文檔進行溝通效果要好。從成本和時間上來看，寫文章總比在白板上討論耗費更多的時間，而且溝通的效果也更差。

　　那些寫好的而且評審過的需求和設計文檔，只是"承諾"了要做什麼，我們可以將其作爲項目進度的標誌 使用。有很多進度標誌在最初設立時是好的。然而，更準確的進度標誌應該是運行測試後的代碼。因爲這不是預先承諾的標誌，而是真正完成的標誌。

　　最近，一個銀行的IT部決定小試一下以上結果。他們啓動一個小項目，使用簡單的把三個人放在一個房間裏的方法，讓他們自生自滅。令人驚奇的是，這個小組及時的、優秀的發佈了系統。銀行的管理層覺得有點困惑。一定不會這麼簡單的吧？

　　當然不是如此簡單。另外一個採訪了所有其他項目後得到的結論是：不同項目有不同的需要。這是非常明顯的不依賴於方法論的（不知道怎的）。當然，如果你的項目只需要3到6個人，只要讓他們在一個房間裏就可以了。但如果你有45或者100個人，這就沒用了。如果你要通過食物藥品管理部門的過程檢驗，你就不能這樣開始。如果你想把我用火箭發射到火星上去，我建議千萬不要嘗試。我們必須記住團隊的大小和項目的需求這類因數：

• 隨着參與人數的增長，協調溝通的需求也更多
  
• 隨潛在的破壞性的增長，對於公開檢查的要求也在不斷增加，而同時對由於個人風格的不同所導致差異的可容忍程度也在降低
  
• 一些項目依賴市場方面所確定的發佈時間，而且對於一些缺陷能加以容忍（WEB瀏覽器就是這樣一個例子）；其他的一些 項目致力於條理性和法律責任。
  

　　根據收集到的有關因素總結出的結論如圖Figure 6所示。它顯示了影響選擇不同方法論的三個因數：溝通難度（由成員的數量決定），系統關鍵程序，以及項目的優先級。

Figure 6 -- The family of Crystal methods.

　　根據成員數量確定在X軸上的部分（通常的只是開發組）。如果是一個分佈的開發項目，因爲面對面溝通的機會減少，向右移動一格。

　　在Y軸上，確認系統損壞的影響：舒適程度下降，明顯的經濟損失，根本性的經濟損失（比如破產），或者喪命。

　　在頂層的不同的飛機（板塊panel？）反映了各種項目的不同重點，所耗費的是否是上市時間（就象在第一層），效率和兼容性(隱藏的第二層)，或者法律責任（隱藏的第三層）.網格中的格子決定了在相似溝通難度和安全需求下的項目的類型（例如C6），你可以用來選擇方法論。

　　這個網格顯示了項目的特性，對選擇一個方法論很有用。我自己在項目的大小和複雜程度改變的時候，用來改變我的方法論。當然還有其他的因素，但這三個用來決定選擇什麼方法論是很好的。

　　假定現在要選擇項目的方法論。得益於上面所提到的對有關項目的訪談，你可以把建立一個最輕量級的方法論，想象成按照網格中的格子工作，在這裏，儘量提高人和人之間的交流，運行測試後的代碼是最基本的進度標誌。結果是一個簡單的，符合人的習慣的（意味着更讓人愉快的，反對壓抑人的）高效率的方法論。在網格上指定這個方法論到C6。

　　重複這些所有的格子，產生一個輕量級的方法的家族，根據他們對人們的信心，溝通，和發佈運行代碼的頻率。我叫這個家族爲Crystal Light方法論族。這個家族用顏色（在圖上沒畫）分成不同的豎直的條紋：2-6個人的項目的方法論叫 Crystal Clear ，6-20人的項目的方法論叫 Crystal Yellow , 20-40人的項目的方法論叫 Crystal Orange,然後是 Red，Magenta，Blue，等等。

　　垂直方向間的切換在方法學上被稱爲強化。一個短生命期的2到6個人的項目應該使用強化了的Crystal Clear或其派生方法來管理。使我驚喜的是，在這樣的 項目中幾乎看不到增加需求和按時完成項目之間的矛盾。

　　Crystal Clear出自一本即將出版的書，現在網上已經有草稿。在《Surviving Object-Oriented Projects》一書的方法論一章中描述了Crystal Orange的輪廓。

　　在採用Crystal Light方法多年以後，現在我發現了更多的驚喜。

　　第一個驚喜是，一個開發隊伍成功（不僅僅是倖存）並不需要太多的管理和控制。大部分開發人員都樂於專心工作和寫出好的軟件，他們會使用自己的理解能力和溝通能力去 完成這一切。這和Jim做出的關於自適應軟件開發的結論完全一致(參見"資源和參考"，第15頁)。你需要比你預計的要少得多的控制，尤其是當你希望能儘快發佈軟件時，越 少就越好。

　　更特別的是，當我和Jim交換項目管理的心得時，我們意識到我們都觀察到了成功的項目管理中的一個關鍵要素：開發人員能理解有關人員的工作並加以溝通。他們能通過 許多簡單、低技術含量並且廉價的方法完成這一切。通常這並不需要引入什麼特別的工具來管理。

　　不過項目中還是需要兩個關鍵要素：信任和溝通。

　　在一個項目中，缺乏信任比選擇了錯誤的方法學更要命。從某種程度上講，只要你能加強信任和溝通，你就一定能受益於Crystal Clear，XP（極限編程 ？）或別的輕量級開發方法。

　　第二個驚喜是當我們定義Cystal Light方法的時候它就和XP一致了。我把Crystal Clear設計成我所能想象的最不官僚的方法學。隨後XP在 同一領域出現並展露鋒芒，在它面前Clear彷彿成了重量級的開發方法！這是怎麼一回事？

　　這大概是因爲Beck發現了方法學的控制面板上的另一個開關：紀律。在某種程度，如果一個開發小組能增強內部的紀律性並保證行動的一致性，方法學可以變得更加 輕巧。Crystal Light衍生的方法學給予開發者最多的個性化。XP則要求每個人都遵守嚴格的有紀律的實踐：

• 每個人都必須遵守一個嚴格的編碼標準。
  
• 關於什麼是好的代碼, 開發小組在此方面應達成共識，這樣所有的變化都集中在一起，避免了反覆。
  
• 每個函數都必須經過單元測試，並且必須100%通過。
  
• 所有產品的代碼都是由兩名開發人員一起工作完成的
  
• 以每兩週到四周爲一個週期, 頻繁地發佈那些經過測試的函數，。
  

　　換一句話說，Crystal Clear展示了輕量級方法的核心法則，而XP放大了它：

在一定程度上，如果開發隊伍的交流得到了改善，發佈的頻率得到提高，那麼就可以減少中間產品的工作量，從而能更快地完成項目。

　　XP和Crystal Clear有如下關聯：

• XP通過增強紀律性提高生產效率，但是它對於開發者更難於遵守。
  
• Crystal Clear給予開發者更多的個性空間，允許比較鬆散的工作習慣，但是同時損失了一些生產效率。
  
• 開發隊伍可以比較輕鬆地使用Crystal Clear方法，但是如果能夠有效地使用XP，效果會更好。
  
• 開發隊伍可以從Crystal Clear開始，然後轉移到XP方法。開發隊伍也可以放棄XP，重新使用Crystal Clear。
  

　　儘管Crystal Clear和Xp之間存在很多差異，但是它們的基本價值觀是一致的--簡單、交流和儘量減少形式化。

　　編者按：如果你想深入瞭解Crystal Clear，請看"相關資源與引用"部分列出的Alistair Cockburn的網站，在。如果你想深入瞭解 Crystal Orange，你可以參閱《Surviving Object-Oriented Projects》一書，同樣有關信息在"相關資源與引用"部分也已列出。

結論：走向極限

　　Orr 和 Cockburn 都描述了他們的輕量級方法和經驗。但在前面描述Chrysler的 C3 項目時，我間接的提到，擴展使用類似XP或者甚至是RAD的方法都存在着困難。在我們 對eAD的訂閱者所做的所有調查以及所有軟件組織的行爲調查中，一般說來，快速的響應 速度，減少發佈時間是一個關鍵的開始。但這並不是說只有首次發佈纔是關鍵的。雖然 Amazon.com 因爲更早進入網上書店市場而擁有優勢，但它爲了維持它的領導地位，必須 持續不斷的適應市場條件----這意味着軟件的持續更改。

　　快速發佈.快速修改.頻繁變更.通過這三者的驅動，加上更好的軟件工具，迫使我們重新 思考傳統的軟件工程實踐----並不是放棄它們，而是對其重新加以思考。例如，XP 並沒有 要我們拋棄好的軟件工程實踐。相反，它要求我們去深入地思考，在 當今軟件發佈環境下，小型協作團隊能夠高效運作所需的最低環境要求有哪些。

　　Cockburn 觀察發現，XP（至少按照Beck和Jeffries所定義的那樣）的實現至少需要三個 環境特徵：界面修改不會帶來昂貴的的代價，更密切的交流和自動的迴歸測試。實際上 XP 不是問"我該如何降低變更帶來的成本"，而是要求一個低更改成本的環境，然後說"我們將這樣工作"。例如， C3項目使用面向對象數據庫GemStone，而不是去使用傳統關係數據庫（以及 和多個外部組打交道）。

　　有些人也許會說這種方法是欺騙，確實如此。例如，西南航空公司在創建動力室時，使用 同一種類型的飛機（波音737）來降低成本。如果湍流和改變都是標準的，那麼正確 的問題可能就是：我們如何創建一個導致最低變更成本（和時間）的環境？西南航空公司在擴 張時，沒有遺留的飛機存貨。對於美國航空公司來說，這個問題的答案也許會不同，但是 它仍然是個重要的問題。

　　在這個關於XP和輕量方法的討論中，我們能得到如下五個主要觀點：

• 對於那些處於飛速變化環境中的項目而言，我們需要重新檢視有關的軟件開發實踐以及與之對應的有關假定。
  
• 類似於重構、簡單化和合作（配對編程，隱喻，代碼共享）等實踐促使我們以一種新思路來思考。
  
• 我們不僅需要重新思考如何在現有環境中降低變更導致的成本，而且還需要重新考慮如何創造一個新的環境, 從而能夠將變更成本降到最低。
  
• 在頻繁變動中，對代碼, 數據以及整個應用重構的能力將會成爲一項關鍵的技能。
  
• 將方法應用到項目中去時，先依賴人，再依賴文檔，儘量減少形式化的東西，從而有效地將方法與項目相結合
  

編後語

　　極端的規則。在寫這篇文章的過程中，我曾經收到12月20日發行的商業週刊雜誌。其中有一個封面故事，"極端零售"，關於"brick"商店反擊它們的堂兄弟"click"。如果我們可以有極端零售，爲什麼不極端編程呢。

　　重構，設計模式，對單元測試的充分理解，配對編程----這些都不是黑客們的工具。它們是開發者 們爲了解決產品快速發佈，同時又能保持較少的缺陷和靈活性時探索出的新方法。關於質量，Beck說，"只有兩種情況下是有價值的：'優秀'或者'極其優秀'，這取決於其對軟件產品生存的影響程度"，以及 "執行測試直到它們通過（100％正確）"。你也許可以指責XP的實踐者是受到了矇蔽，但是他們決不是那種不重視質量的黑客。

　　對於傳統方法的支持者來說，縮短髮布時間是質量的敵人。然而，我看過一些開發速度很慢而且質量非常差的軟件，就象我看過的另一些開發速度很快但質量低下的軟件一樣。雖然在時間 和質量間存在一些明顯的聯繫，但我認爲這個聯繫比我們一般所想象的要的複雜的多。

　　傳統方法可用於開發那些變化程度不大並可預期最終結果的軟件.然而，商業世界卻是變化莫測的，並且傳統開發方法已無法滿現在的快速變化軟件需求的要求。輕量級軟件開發實踐的創始人Bob Charette認爲"由於軟件工程研究所(SEI)這樣組織的官僚化、頑固性，以及諸如CMM的實踐，使得他們日益脫離當今的軟件開發。

　　就象Beck在他書中所寫的簡介中指出的一樣，XP中的各個獨立實踐，都是從著名的，經過很好的測試的，傳統實踐中抽取出來的。這些原則驅動着實踐的使用，與一個特別的實踐最小集自然的一體化在一起，使得XP成爲一個解決現代軟件開發問題的新方案。

　　但是我必須以一條警告來做結束語。所有的這些新實踐都沒有很長的歷史，它們的成功就象逸事一樣，沒有被加以研究和度量。然而我堅信，我們混亂的電子商務經濟需要我們重新審視 如何開發和管理軟件發佈。這些方法雖然很新，但它們提供了有價值的另一條思路。

　　明年，我們毫無疑問地可以看到更多關於XP的出版物，Beck, Jeffries, Fowler和Cunningham都在相互合作出版更多關於XP的書。因此，你將看到更多的關於實踐的信息，管理哲學和項目實例等。

資源與參考

Books and Articles

Beck, Kent. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.

Cockburn, Alistair. Surviving Object-Oriented Projects. Addison-Wesley, 1998.

Cusumano, Michael A. and Richard Selby. Microsoft Secrets. Free Press, 1995.

Fowler, Martin. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.

Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.

Gilb, Tom. Principles of Software Engineering Management. Addison-Wesley, 1988.

Higgins, David. Data Structured Software Maintenance. Dorset House Publishing, 1986.

Yourdon, Edward and Larry L. Constantine. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Prentice Hall, 1986.

General Resources

Adaptive software development. See the article in the August 1998 Application Development Strategy (now eAD), "Managing Complexity."

ARTech. Montevideo, Uruguay. Web site: http://www.artech.com.uy/. Developers of GeneXus.

Crystal Clear method. Web site: http://members.aol.com/humansandt/crystal/clear.

Alistair Cockburn. Web site: http://members.aol.com/acockburn.

Bob Charette. Lean Development. ITABHI Corporation, 11609 Stonewall Jackson Drive, Spotsylvania, VA 22553, USA. E-mail: [email protected].

Ward Cunningham's Extreme Programming Roadmap. Web site: http://c2.com/cgi/wiki/ExtremeProgrammingRoadmap.

eXtreme Programming and Flexible Processes in Software Engineering -- XP2000 Conference. 21-23 June 2000, Cagliari, Sardinia, Italy. Web site: http://numa.sern.enel.ucalgary.ca/extreme.

Martin Fowler. Web site: http://ourworld.compuserve.com/homepages/martin_fowler/.

Ron Jeffries. E-mail: [email protected]. Web site: http://www.xprogramming.com/.

Lean Development. See the November 1998 ADS article "Time is of the Essence."

Object Mentor, Green Oaks, IL, USA. Web site: www.objectmentor.com/.

Ken Orr, Ken Orr Institute, Topeka, KS, USA. Web site: http://www.kenorrinst.com/.

Laurie Williams. Web site: www.cs.utah.edu/~lwilliam.