新方法學
linuxaid站長 axing
01-11-15
--------------------------------------------------------------------------------
版權申明：本文的翻譯沒有獲得作者的授權，所以這篇譯文僅作為學習使用。禁止任何人轉載此文獲作為商業用途，如果有任何人認為這篇文章侵犯了你的權利，請來信告訴我們。
Martin Fowler
在過去幾年中，敏捷方法（agile methodologies）（也被稱為輕量級方法，lightweight methodology）正在迅速升溫。它能夠有效的解決軟件開發中的官僚作風，讓大家的注意力重新集中在軟件的秀麗風景中。這篇文章展示了輕型方法產生的原因,當然不是討論它們的重量，而是他們那符合自然規律和以人為先的特性。同時文章還給出了學習過程中的一些參考意見和一些影響你在輕型方法這條康莊大道上繼續前進的因素。
（譯者注：agile methodology，agile在字典中的原意為敏捷的, 輕快的, 靈活的。但是我始終沒有找到有比較權威的翻譯，原先我打算根據它的另一個稱謂;輕量級方法，將它翻譯成輕型方法，但是在查資料中發現了管理學中也存在這個詞同類詞：Agile Manufacturing，翻譯為敏捷制造，所以我也把這個詞同樣翻譯成敏捷方法。如果讀者覺得有更好的翻譯，請mail給我。axing@linuxaid.com.cn）
從無, 到紀念碑的, 到敏捷的
可預測型 VS 適應型的
設計和建構的分離
需求的不可預測性
可預測是無法做到的嗎?
控制一個不可預測的過程
適應型客戶
人是第一位的
同一的編程機器
程序員－－有責任感的專業人員
面向過程的人員管理
業務領導者的角色
自適應型過程
方法
XP
Cockburn的Crystal Family
開放源碼
Highsmith的適應型軟件開發
SCRUM
DSDM
敏捷軟件開發的宣言
RUP是一個敏捷方法嗎？
其他資源
你應該使用敏捷方法嗎？
從無, 到紀念碑的, 到敏捷的
大多數的軟件開發都是一個混亂、無序的過程, 人們將之戲稱為“code and fix”。軟件的開發毫無計劃性可言，系統設計就是把許多短期決定揉在一起。這在小的系統中可以勝任，可隨著系統的增長，往系統中加入新的功能就變成一件極端困難的事情。此外，bug越來越普遍，修正也越來越困難。 這樣系統的一個典型現象是在系統完成之后會經歷一個相當長的測試時期。測試和除錯完全不可預見，如此之長的測試期嚴重破壞了開發進度。
我們的這種開發軟件的風格存在了很長的一段時間，但是我們也花了很長的時間來研究替代方案: 方法學。 方法學把嚴格規范的過程用于軟件開發，使軟件開發更具可預見性、更有效率。他們遵循規則，制定計劃，細分過程來保證軟件開發。
這種方法學也經歷了很長的發展時間。它們并不十分成功，也不致力于大眾化。這些方法學的最時常發生的批評是官僚。為了遵循方法學的準則做的大量的無用功使得開發的步調緩慢。因此他們時常被稱為重方法學（heavy methodologies）, 或使用Jim Highsmith的話:豐碑般的方法學。 （譯者注：段落小標題的豐碑由此而來）
在這些方法學的帶動下，近幾年出現了一群新的方法學。在一段時間內，它們被稱為輕量級方法（lightweight methodologies），但是現在普遍稱之為敏捷方法。人們希望敏捷方法能夠有效解決豐碑式方法的官僚問題。這些新的方法嘗試著在毫無過程和太多過程之間找到一個有效的平衡點，只提供必要的過程以得到一個合理的結果。
這樣的結果是敏捷方法在某些方面和重量級方法有顯著的不同。 最大的不同是敏捷方法不是文檔驅動的, 通常一件給定的工作只需要很少的文檔。在很多方面，它倒是以代碼驅動的: 規則，最重要的文檔是源代碼。
不過我不認為這是敏捷方法的重點所在。較少的文檔只是兩種方法之間更深層次的不同點的一個癥狀:
1、敏捷方法是適應型的，而并非可預測型的。重方法傾向于為軟件開發制定一個包容了大量細節、時間跨度極長的龐大計劃，如果萬事都不變，這個計劃將會執行得非常好。所以它們必然要盡力阻止變化得發生。敏捷方法則不同，它擁抱變化。他們總是去適應變化，利用變化來發展，甚至改變自己。
2、敏捷方法是以人為本而不是以過程為本的。他們建立起一種觀念：工作應該能夠發揮人的特性，而不是去限制它，強調軟件開發過程應該是一個有趣的過程。
在下列各段中，我將更詳細地研究這些不同之處, 你能了解到一個發揮合適的、以人為本的方法是什么樣的，它的優缺點。不論你是軟件的開發者還是使用者，你都應該使用這種方法。
可預測型 VS 適應型的
設計和建構的分離
方法學的靈感來自語工程學的工程規范，諸如土木工程和機械工程。這種規范強調在實際建造之間做充分的計劃。這樣工程師將會用一系列的圖紙來精確描述該建造些什么，以及如何組織它們。同時，根據圖紙作出許多設計決定，比如該如何處理一座橋的負荷。 設計好的圖紙隨即被移交到另一個團隊,通常是一家不同的公司,讓他們來負責構建。一般要假定構建程序要嚴格的遵循圖紙。在實際中負責構建的人會遇到一些問題，但通常都是些小問題。
因為圖紙規定了各個模塊是何如組裝在一起的，這些模塊在具體構建計劃中扮演了一個基礎的角色。這樣的一個計劃能夠計算出需要哪些工作，各項工作之間的關系如何。這就需要考慮可預測的進度表和建造預算。同時圖紙也詳細地說明了哪些構建者應嘎如何完成他們的工作。這樣，構建工作就不太需要那些智力型的工作者，只需要那些勞作型的工作者。
我們來看看設計和構建的根本不同。設計很難預測，而且需要有創造力的人，而那些人往往都很昂貴，而構建則比較容易預測。只要設計工作完成，我們就能開始計劃構建。一旦有了構建計劃，就能夠開始構建，而這個過程是容易預測的。在土木工程中，構建階段花費時間和金錢遠遠超過設計和計劃。
所以眾多的方法學看起來就像這樣: 我們想要一種可預測的進度表來幫助組織、使用那些技術欠佳的人。為了做到這一點我們需要把設計和構建階段分開。因此我們需要計算如何做設計和計劃以保證構建的順利進行。
而計劃應該采用何種形式呢? 對於多數人來，就是諸如UML之類的設計記號法所要扮演的角色。如果我們的所有重要決定都使用UML，我們就能夠建立一個建構計劃并且把這些設計交給編碼人員來開發，完成構建活動。
但是這里有一些至關重要的問題。你的設計能夠保證把編碼組織起來，完成一個完整的構建活動嗎？即使這點你能做到，那么，你的構建過程在時間和金錢上的花銷真的大到那種不得不采用這種方法的程度了嗎？
這些怎能不引人深思呢。首先是把像UML那樣的設計圖移交給程序員來實現是一件極為困難的事情。問題的關鍵在于那種設計看上去不錯，可你打算編程來實現它的時候就出現了問題。土木工程師使用的模型建立在多年實踐的基礎上，它們用土木工程的專用語言來描述。而且主要的問題在于，通常這種設計需要符合數學原理。而我們對UML之類的圖表唯一能做的就是同級檢查。雖然這是有幫助的，但還是往往會忽略一些錯誤，這些錯誤只有到編碼和測試階段才能被發現。即使是熟練的設計者，例如我覺得我就是一位，在把設計轉為軟件的時候，也會被其中的問題嚇一大跳。
另外的一個問題是費用的不可比。當你建立一座橋的時候,設計的費用約占全部工作量的10%，其余的工作量都在建構階段。在軟件中編碼的時間消耗則小得多。(McConnell建議在一個大的項目中，編碼和單元測試的開銷占整個項目開銷的15%，這個比例和建橋的比例剛好是相反的。即使你把所有的測試也算在構建階段中，設計仍然占了50%的工作量)。這就引起了一個至關重要的問題，因為通常我們都是把軟件設計看做是工程學的一個分支的。
種種問題使得Jack Reeves提出，事實上源代碼就是一份設計文檔，而構建階段實際上是編譯器和連接器的使用。的確，你視為建構階段的任何事都能而且也應該被自動化。
這就引出了一些重要的結論:
在軟件中: 建構階段是廉價而自由的。
在軟件中所有的努力都是在設計, 這需要那些富有創造力而且聰明的人。
有創造力的過程可不是那么容易計劃的，而且具有可預測性也是一個不可能達成的目標。
我們用傳統的工程來隱喻設計軟件應該非常小心。它們是不同的類型的活動，需要的過程也是不同的。
需求的不可預測性
在我經歷的每一個有問題的項目中，我聽到的總是同樣的聲音。開發人員跑過來對我說：“這個項目之所以有問題，是因為需求總是在變�！痹僖矝]有比這更令人驚訝的了。在商業軟件開發領域，需求變化是很正常的，問題是我們該怎樣對待它。
一條路是對把需求變更視為拙劣的需求工程所造成的惡果。需求工程要求你在開發軟件之前對整個系統的需求有完整的了解，讓客戶確任需求，并嚴格按照需求設計程序，其中，不允許需求的變更。
這樣就產生了一個問題，想要了解需求的一些信息是件困難的事，而要求開發組織提供需求的具體費用信息更是難于登天。如果你想要給你的車加上天窗，可是賣汽車的那家伙根本說不出花10塊錢的天窗和要10000塊錢的那種有什么區別。對這兩種費用完全沒有概念，試問，你能決定選用那種天窗嗎。相信大多數人都不會作出決定的。
這種預算往往因為某些理由而難以做到，一個原因是軟件開發是一項設計活動，難以計劃和制定費用。另一個原因是基本的要素變化很大。還有一個原因是需求過于依賴于參與的個人，而個人是難于編制預算和量化的。
軟件的無形價值的特性也加大了難度。除非投入使用，否則很難估算出軟件的功能有什么價值。只有當你使用軟件的早期版本時，你才能了解哪些功能是有價值，哪些是沒有價值的。
具有諷刺意味的是，這使得人們希望需求是可以變化的。畢竟，軟件被稱為“軟”件。需求一旦發生變化，軟件也要能發生變化。這往往要求開發者費盡心機來說服客戶固定需求。更糟的是，如果那個客戶剛好涉獵過軟件領域，說服他們可就更不是件容易的事了，因為他們知道那玩藝兒是很容易改變的。
即使你可以搞定你的客戶，拿出一份準確、穩定的需求，可你還是注定失敗。當今商業活動賴以生存的經濟瞬息萬變，要求軟件的功能能夠迅速改變。什么才是好的需求集呢，決不是只適用6個月的那種。即使客戶能固定他們的需求，現實的商業世界也不會為了他們而停止。而在商業領域中，很多改變是完全不可預知的: 否則那個人不是在說謊，就是已經在股票市場賺了數十億了。
軟件開發中的其他階段都必須依賴于需求。如果你不能夠拿出一份穩定的需求，你就不能得到一份可預期的計劃。
可預測是無法做到的嗎?
大體上，這是做不到的。也有一些軟件開發是可以被預測的。例如 美國航空航天總署的太空船軟件團體組織就是這方面的一個典型例子。它需要大量的儀式，足夠多的時間，龐大的團隊和穩定的需求。所以能夠制定出太空船那樣的計劃。然而我不認為這么多商用軟件適合這種方法。為此你需要一個完全不同的過程。
一個極大的風險在于你總認為你可以遵循一個可預測的過程，但實際上，你不行。使用方法進行工作的人們并不能很好的識別邊界條件: 方法從適合到不適合的交界之處。決大多數的方法學家希望他們的方法學能被每個人使用，因此他們不了解也不宣傳他們的邊界條件。這就誤導了人么，在錯誤的環境中使用一種方法，例如，在一種不可預測的情形中使用一種可預測的方法學。
然而總有種強烈的誘惑驅動你去那樣做�？深A測性是一項極為寶貴的財富，非常令人動心。然而如果你相信你可以預見到什么，但是實際上你做不到。這就導致人們過早建立計劃的情形，然后因為處理不當致使計劃失控的情形。你可以看見計劃和現實慢慢脫離的。很長的一段時間里，你仍認為計劃仍然有效。但是當脫離越來越明顯，計劃最終失敗。這該是多么的痛苦。
所以不論你是否處在這么一個可預測的環境中，你都不能使用可預測的方法。這是很痛苦的事情。意謂著為了控制項目，為了整體的客戶關系而制作的大量模型，而這些根本不對�？深A測性的好處確實很大，但要做到卻很困難。象這麼多問題，其中最難的部份卻是了解問題是否存在。
然而去掉可預測性并不意謂你回到無法控制的混亂局面。實際上你需要一個能控制不可預測性的流程。這就是合適性的本意。
控制一個不可預測的過程
那么我們該如何在一個不可預知的世界中控制我們自己? 最重要的,而且困難的是要如何正確地知道我們處在那個位置上。我們需要一種反饋機制，它可以每隔一段時間就告訴我們準確的位置。
反饋的關鍵是迭代開發。這不是一個新的想法。迭代開發以前有很多的名稱: 增量模型，改良模型，階段模型，螺旋模型...。迭代開發的關鍵在于把最終的系統劃分為多個可工作的版本，每一個版本都實現了功能的一個子集。這些可工作系統都實現了全部功能的一小部分，但都完全符合系統最終的要求。他們都應該被完全整合并通過的小心的測試，做為最終版本交付。
一個經過測試、整合的系統無疑給那些計劃注入了一針現實的強心針，再沒有什么比這更好的了。文檔能隱藏幾乎所有的缺點。未經測試的代碼同樣能隱藏許多缺點。但是當人們真正坐在一個系統之前并用它來工作的時候，缺點就顯現出來了:不論是bug還是曲解的需求。
迭代開發在可預測的過程中也樣有效。但它是是適應性過程的核心思想，因為一個適應性過程需要處理功能需求上的變化。這使得迭代開發往往呈現出遠期計劃不固定，穩定的計劃只是每次迭代的短期計劃的風格。迭代開發在每一次的迭代中提供了一個堅實的基礎以保證計劃的制定。
另一個主要問題是一次迭代需要多長的時間。這個問題的答案因人而異。XP建議一次迭代差不多需要在一到三個星期之間。SCRUM建議議一月的長度。Crystal則更遠一些。整體的趨勢是使每一次迭代都保持在你能夠對付的時間范圍之內。這種機制提供了頻繁的反饋，因此你更好的知道你在哪里。
適應型客戶
這種適應型的過程需要和客戶建立一種全新的關系，而不是原先那樣，尤其是開發部分由另一個公司負責的時候。當你雇請一個單獨的公司做軟件開發的時候，決大多數的客戶會較喜歡一份固定價格的合同。告訴開發者他們想要的，要求競標，接受競標，然後負責是在發展組織上開發軟件。
一份固定價格的合同要求穩定的需求，因此也就需要一個可預測型的過程。適應型和不穩定的需求暗示你不能采用固定價格的平常觀念來處理問題。對一個適應型過程建立一個固定價格機制的嘗試在經歷一個痛苦的摸索后宣布失敗。最糟糕的是這種做法深深傷害了客戶，同時也傷害了軟件公司。除非特別需要，用戶不一定想要那些軟件，前提是不用這些軟件也不會損害生意。所以即使他們什么都沒有付給開發公司，他們還是失去了很多。的確，他們失去的價值超過了軟件的費用。 (如果那個軟件沒什么價值，我為什么要付費呢？)
所以在可預測型過程無法使用的條件下雙方簽署一份固定價格的合同是及其危險的。這意謂客戶必須不同的工作。
在一個適應型過程中客戶對軟件開發過程會把握的更好。在每次迭代，雙方都必須檢查進度以決定是否改變軟件開發的方向。這有利于和軟件開發者建立一種更密切的關系，真正的生意伙伴。這種程度的契約關系并不是每個客戶組織和每個軟件開發者都必須達到的，但是它能夠使一個適應型過程很好的工作。
客戶的主要利益比軟件開發的回應要重要多了。一個可以使用的, 雖然可能很小的系統可以盡量早的投入使用。然后客戶會根據生意的變化來改變系統的性能，而且能夠從現實中存在的系統中學習。
人是第一位的
適應型過程的執行可不是一件容易的事情。它特別需要一支高效的開發人員團隊。這個團隊的每一個成員都應該具有高素質，能夠相互配合。這里有個有意思的合作優勢：不僅僅是適應型過程需要一個強有力的團隊，大多數的開發人員也原意加入到適應型過程中來。
同一的編程機器
傳統方法的目標是建立起一個過程，把參與者分成多個可以替換的角色。在這樣一個過程中，參與者在你眼中都是各種各樣的資源以供使用。你有一個分析員，幾個編碼人員，幾個測試人員，一個項目經理。至于每個人是不重要的，角色才是重要的。這樣你在計劃一個項目的時候考慮的不是你需要哪一個分析員，或是哪幾個測試人員，你要考慮的只是你有多少的人可以用，你的計劃所需要的資源。
但這樣就會引出一個關鍵問題：項目的參與者真的只是一些可以替換的角色嗎？敏捷方法的一個關鍵特點就是推翻了這項假設。
Alistair Cockburn就是一個強烈反對把人看做資源的這種做法的人。在他的論文《Characterizing People as Non-Linear, First-Order Components in Software Development中，提出一個觀點，可預測型過程需要它的各個組成部分也必須是可以預測的。然而人從來就不屬于可以預測的部分。他還進一步研究了軟件項目，得出的結論是，人是軟件開發中最重要的要素之一。
盡管Cockburn是如此盡力的宣傳這種軟件開發須以人為中心的思想，可是這種以人為先的思想卻還只是軟件領域那群思想家筆下的共同主題。造成這種現象的最常見的一個問題就是舊有的方法排斥這種以人為先的的思想。
這就產生惡性循環：因為你希望你的開發人員都能成為統一標準的編程機器，你就不會把他們視為一個個有個性的人。這樣，士氣和生產力就下降了。你的優秀的員工會離開你，找個更好的地方，而你那希望大家都成為同一編程機器的想法最終是失敗了。
要轉變觀念需要很大的決心，而且需要許許多多的決策來支持推動。視人為資源的觀念已經深入人心了，其根源甚至可以追溯到Frederick Taylor的科學的管理方法的影響（譯者注：Frederick Taylor提出的管理思想是針對大工業時代的生產的）。在一個工廠中，Frederick Taylor的方法或許用效。但是對于有著非凡的創造力的計算機專家而言，這種方法就未必有用了。（實際上，現代的工廠也已經淘汰了Frederick Taylor的方法了）
程序員－－有責任感的專業人員
Taylorist理論最關鍵的一點是他認為那些工人并不會主動改進工作，從而更好的完成工作。在一個工廠里，這個理論也許成立。原因有二：一是工廠中有相當一部分的工人都不是那種絕頂聰明，又富有創造力的人；二是管理者和工人間的關系很緊張，因為工人的酬勞越低，相應工廠所有人的收入就越高。
近來的歷史經驗表明，這個理論在軟件開發中是站不住腳的。受到軟件行業的耀眼光環和潛在高收入的吸引，有越來越多的聰明能干的人投身到這個行業中。（我也是其中的一位，離開電氣工程行業進入軟件行業。）例如現在的股票期權也是為了讓程序員的發展能夠和公司發展相一致。
如果你想要使用最優秀的員工并能夠留住他們。你就必須認識到他們都是真正的專家，而且，他們都是最棒的，完全能夠完成你的技術活兒。Taylorist 的那種把計劃部門單獨出來的做法只有在計劃者比那些工人更優秀、更能勝任工作的條件下才成立。如果你確實很聰明，把你的聰明才智放在如何激勵你的屬下上吧，而不是去阻礙他們。
面向過程的人員管理
敏捷方法中以人為本有很多種的實現方法。這些方法的效果各不相同，而且其中一些方法之間也無法共通。
一個是改被迫接受為主動接受。常常管理者都會給程序員強行施加一些任務，通常開發人員都對這種任務很敵視，如果這項任務需要占用大量的時間使得程序員不得不從手頭的任務中擠出時間的話，這種敵視的程度還會加劇。改被迫接受為主動接受需要開發人員主動承擔，而且需要整個團隊的積極參與。
這就有了一個有趣的結果，只有開發人員自己有權利選擇開始一個適應型過程。正在XP中已經做到了，當然還有許多的準則來保障。而這也是Crystal的長處：只有很少的準則，卻能夠有效的完成任務。
另一個觀點是開發人員必須做出所有的技術決策。XP就體現了這個觀點的核心思想：它規定在計劃階段，只有開發人員才能預估出任務需要的時間。
這樣，技術領導者的身份有了很大的轉變，眾多的開發人員成了管理者。這種方法需要一個項目中開發人員和管理者是平等的，有著同等的地位，同樣的責任。注意，我說的平等指的是仍然存在管理者這個職位，但可能是由那些資深的開發人員來擔任。
這樣做的一個很重要的理由是計算機產業中技術以極高的速度發展。短短幾年，技術就可能已經過時了。這個產業的技術能力和其它產業簡直不可同日而語。技術人員必須意識到，進入管理領域將會使他們的技術能力迅速萎縮。那些資深的開發人員也必須認識到他們的技能也會很快的消失，你必須相信、依靠其他的開發人員。
業務領導者的角色
技術人員是沒有辦法獨自完成整個開發過程的。他們需要業務需求上的指導。這就引出了適應型過程中的另一個重要的概念：開發人員需要和業務專家保持非常緊密的接觸。
大部分的項目中都準備了業務的角色，一個敏捷團隊決不僅僅只是和客戶做短暫的交流，他們會和業務領域的專家不斷的交流。而且這種交流并不只是停留在管理層面上，而是深入到每個開發人員，每一個的細節。開發人員和業務領域專家一樣都遵循一定的準則。
這樣的主要是因為適應型的方法強調本性。既然適應型方法假定事務總是迅速變化的，你就必須不斷的和業務專家保持交流以保證改變。
恐怕對開發人員最大的打擊就是看到自己的努力成果付諸東流。所以，重點在于，必須要有一個高素質的業務專家，開發人員能夠從他那里的到幫助。
自適應型過程
迄今為止，我們已經討論了在一個適應型過程中適應性是如何迎合快速改變的用戶需求的。但這里還有個需要注意的問題：過程自身也是在不斷變化的。一個項目目前用的一個過程和一年后的項目用的過程肯定不同。隨著時間流逝，一個團隊會發現怎樣才能更好的工作，從而相應改變過程。
自適應型過程的第一步就是階段性的復審你的過程。你可以在每一次迭代結束的時候做這件工作。開一個短會，問自己幾個問題：（精選自Norm Kerth）
我們什么地方做的好？
我們學到了些什么？
我們怎么才能做的更好？
我們還有什么疑問？
這些問題可以幫助你在下一次迭代中改進你的過程。每個過程開始的時候都帶有疑問，然后在過程中解決疑問，改進過程。這樣做可以使過程運作的更好。
如果這種自適應發生在一個項目中，它對于整個組織有更顯著的作用。為了加深自適應的過程，我建議每個團隊每個階段召開正式的審查會，建立主要的項目里程碑，舉辦定期的項目回顧會議（outlined by Norm Kerth）。這種回顧會議包括一個二到三天一次的會議和一個訓練機制。這不僅使團隊有了學習的機會，也使整個組織有了學習的機會。
這種自適應的結果是你不可能找到一個簡單的合作方法。實際上每個團隊都不能夠僅限于自身的過程，而應該積極的改變過程以配合整個項目的進行。盡管有那些成文的過程和項目的經驗可以作為參考，開發人員還是有責任不斷的改進過程以完成手頭的工作。
這種自適應性在ASD和Crystal方法中尤為強調。XP方法嚴格的規定表面上看似乎是排斥這種自適應性，但實際上XP方法是鼓勵人們去改變過程的。XP方法的最大的不同在于，它建議這種改變在實際作用于過程之前需要經歷多個的迭代階段。而審查并不是XP方法強調的，也不是XP過程的一部分。盡管有許多人建議XP的關鍵實踐應該加入審查這個環節
方法
目前已經有幾種方法能夠體現敏捷的思想了。雖然這些方法都具有很多共通的特性，但是它們還是有很多的不同點。因為這篇文章只是起提綱挈領的作用，我沒有辦法一一指出這些不同點，不過我至少會指出一些重要之處。我也沒辦法談論這些方法的精髓之處。盡管我在XP方法上花費了很多的心血，對于RUP我也略有心得。不過對于其它的方法來說，我就顯得有些無能為力了。
XP（eXtreme Programming）
在所有的敏捷方法中，XP方法是最受矚目的一種。一個很大的原因是他的發明者－－Kent Beck的非比尋常的耀眼光芒。Kent Beck做了大量的工作來推廣XP方法，領導著XP方法的發展。在某些方面，XP方法的普及倒是帶來了另一個反作用：它排擠了其它的敏捷方法和這些方法中的閃光點。
XP方法的產生于Smalltalk界，在80年代末，Kenck Beck和Ward Cunningham合力將XP方法細化，在90年代初，二人又從眾多的項目中提煉出了XP方法的實踐。把軟件開發方法的思想提高到一個新的境界：適應性和以人為本。
XP方法從非正式的實踐開始的又一次關鍵性的飛躍是在1996年春。Kent受邀參加了對克萊斯勒公司的一個員工工資項目的審查。這個項目是一家締約公司用Smalltalk編寫的，但卻陷入了困境�？紤]到整個項目都被低質量的代碼所充斥，Kent建議拋棄掉所有的源代碼，重新從草稿開始開發。在他的領導下，項目重新開始。而這個項目因為成為XP方法的一塊試金石而在XP的發展歷程上寫下了重重的一筆。
軟件于1997年初投入使用，運行順利。一直到1999年，由于取消了持續開發的開發，這個軟件逐漸出現了一些問題。不過，直到我寫這篇文章為止，這個軟件仍然為10000名正式雇員提供服務。
XP方法的核心價值觀包括點點：交流、反饋、簡單、勇氣。在這四點核心價值觀的基礎上，XP方法又定義了十二個的必須遵循的實踐。其實這些實踐的大多數都已經是一些經過測試和實踐證明的老方法了。然而他們卻常常被忽略，即便是在有充分計劃的項目中。隨著這些方法的興起，XP方法把他們又融為了一個相互影響、相互促進的整體。
其中最令人感到吃驚的是，XP方法極端的強調測試。我們知道，雖然幾乎所有的過程都提到了測試，可是始終沒有把測試擺在一個重要的位置上。而XP方法則不一樣，測試被視作開發的基礎。每一個程序員在寫代碼的同時還要做測試。測試已經整合成為一個不斷持續的迭代過程，并且為將來的開發奠定了一個堅實的平臺。
以這個平臺為基礎，XP方法發展起一個不斷改進的設計過程。這個過程是在每一次的迭代中重構一個簡單的基礎系統來實現的。所有的設計都是圍繞著當前的迭代，完全不用考慮以后的需求發展。這樣，一個設計過程是規范的過程。這種組合的規范法使得XP方法成為眾多適應型方法中的佼佼者。
XP方法已經成就了眾多的領導者，他們絕大多數都是在那個工資項目中發展起來的。這里有一些他們的相關資源。Jim Highsmith的Cutter論文是最好的總結，不過那時他還是個門外漢。他自己的方法我會在下文中提及。Kent Beck寫了Extreme Programming Explained一書。這本書是對XP方法的最好宣傳，它解釋了在XP方法論之后的理論基礎，提供了眾多的解釋來幫助有興趣的人們繼續深入研究XP方法。
還有兩本書更深入的討論了XP方法。他們也是那個項目的成員：Ron Jeffries, Ann Anderson, 和Chet Hendrickson。他們寫了Extreme Programming Installed一書。這本書用項目中的經驗來解釋XP方法。我和Kent Beck寫了Planning Extreme Programming一書，討論了你怎樣用適應性的觀念來計劃項目。
除了書以外，這里還有相當多的WEB資源。XP方法的最著的擁護者是Ward Cunningham的wiki網站。如果你要尋找更加結構化的XP方法，你可以考慮以下兩個網站，順便一提，他們的作者也是那個項目的畢業生：Ron Jeffries的xProgramming.com和Don Wells的extremeProgramming.org。Bill Wake的xPlorations轉載了一系列有價值的文章。著名的C++和面相對象設計的專業作家－－Robert Martin也是XP的擁護者之一。他的公司－－ObjectMentor的網站上有很多的文章：RUP經過裁減后的一個XP實例：dX。還有一個出名的討論組：xp discussion egroup。
Cockburn的Crystal Family
Alistair Cockburn從90年代初為IBM公司撰寫有關方法論的文章開始，已經有多年的方法論的經驗了。他的方法不同與其它的大多數的方法。他并不是根據個人的經驗來建立指導項目進行的理論，而是主動接觸項目，獲取經驗，來發現項目應該如何進行。而且，他絲毫不但心新的發現會影響他的觀點。這些都是我欣賞這位出色的方法學家的原因。
他的著作，Surviving Object-Oriented Projects，是他探究那些正在實施的項目的第一步成果。
在那本書之后，他的研究又更上一層樓。接著，他又寫了Crystal family of methodologies一書。之所以稱它為family，是因為他相信不同的項目需要不同的方法。他把項目中所需要的人和錯誤結果作為兩個軸。每個方法都有其適合的位置。一個40人的，允許任意的損失的項目和一個6個人，嚴格制定生命周期的項目所采用的方法就完全不同。
Crystal方法也贊同以人為本，這點他和XP方法是一致的。但是他的做法有很多種。Alistair認為很難讓人們在項目過程遵守嚴格的準則，更不要說XP的高標準的準則要求了。Alistair試圖找到一個以最少的準則來保證成功的方法，用一定的生產力來換取易操作性。所以他認為他的Crystal方法比起XP方法來雖然在生產力上略遜一籌，但是更多的人愿意使用Crystal方法。
Alistair也非常注意每個迭代階段結束時的審查，鼓勵不斷的改進過程。他斷言說，把項目分成多個迭代周期可以更早的發現問題，這樣人們就可以及早的糾正錯誤。這就要求人們需要花更大的注意力來監視整個開發過程。
2001年2月，Alistair宣布他將和Jim Highsmith一起合作把他們倆的方法合并起來。
開放源碼
你也許會被這個標題嚇一大跳。畢竟，開放源碼是一種軟件形態，而不是一個過程。然而，在開放源碼的世界中，有很多固定的方法，其中的很多方法不但適用于開放源碼，也同樣適用于私有源碼的。很特別的是，開放源碼的開發過程都是一些地理位置相隔很遠的團隊完成的。這一點很重要，因為大多數的適應型過程都強調團隊要本地合作。
絕大多數的開放源碼項目都有一個或多個維護者，只有一個維護者允許修改源代碼庫。而除了維護者以外的人也可以改變代碼庫。關鍵的區別在于他們必須向維護者提交他們的修改，維護者會審核提交的代碼并加到代碼庫中。通常這種改變的方式表現為打補丁的形式，這種形式會相對容易些。這樣維護者的工作就變成整理這些補丁并維護軟件的核心設計。
不同的項目對與維護者也有不同的約定。有些項目只為整個項目指定一個維護者，有些則把項目分為多個模塊并為每個模塊指定一個維護者。有些則采用幾個維護者輪流的方式，有些則有多個維護者對同一部分源代碼進行維護，還有一些則綜合了以上的這些方法。幾乎所有的開放源碼工作者都是業余的。所以，那些職業的團隊開發者也應該能夠干得更好。
開放源碼的開發過程中有一個很特別的地方就是高度平行性的調試。非常多的人加入調試工作，但他們找到一個錯誤之后，就會給維護者發送一個補丁。這對于那些不做維護工作的人來說是一個很好的角色，因為除錯工作的大部分的時間會花在找臭蟲上，也不需要很強的設計技能。
開放式過程還有很多值得一提的地方。這方面的最著名的文章是Eric Raymond的The Cathedral and the Bazar，還有一本權威書籍是Karl FogelCVS 代碼庫，書中的一些章節描述了開放源碼的過程，寫得非常棒，即使是那些從來不打算升級cvs的人也會感興趣的。
Highsmith的適應型軟件開發
Jim Highsmith在可預測型方法上已經有多年的研究經驗了。他不斷的研究、事實、傳播這些方法，最終他發現這些方法有著不可彌補的缺陷，特別是在現代的商業應用上。
他最近的一本書中，他的研究重點轉移到了新的適應型方法上。書中，他提出了一個被稱為混亂理論的想法，解釋了復雜的適應型系統的起源以及如何應用他們。和XP方法不同的是，他沒有提供具體的實踐，他提供了一個基礎，解釋了適應型開發的重要性和在組織和管理級別上的深化對開發的影響。
ASD的核心包括了三個非線性的、重疊的階段：思考、合作和學習。
Highsmith認為在一個適應型的環境中，計劃是自相矛盾的東西。因為結果通常是無法預測的。在傳統的計劃中，任何和計劃背離的行為都被視作錯誤，都應該被更正。而在一個適應型的環境中，背離的行為通�？梢灾笇覀冏呱险_的解決之道。
在這樣一個無法預測的環境中，你需要讓人們更加富有合作精神，以應付那些可能發生的不確定的事情。管理人員的注意力更多的集中與鼓勵人們溝通，而不是告訴人們該如何做。這樣人們就可以提出有創造性的解決方案。
在一個可以預測的環境中，學習往往是件令人沮喪的事情，一切都已經事先計劃好了，你只需要根據設計來就行了。
在一個適應型的環境中，學習是所有涉眾（包括了開發人員和客戶）的一個挑戰，所有的涉眾都必須檢查他們的設想，使用和改進每個開發周期的結果，以適應下一個周期。
這樣，學習就成了一個不間斷的重要的功能。所有計劃和設計都會調整，以做為開發項目的收益。
適應型開發生命周期的最最最最大的好處就是迫使我們對抗那種自欺欺人的精神根源，他使我們更加的現實的評估我們的能力。
在這種思想的指導下，Highsmith的工作集中在適應型開發的最難的部分。特別是怎樣鼓勵大家在一個項目中合作、學習。同樣的，他的書鼓勵人們使用諸如XP、FDD、Crystal之類的方法來建立軟件的“軟”基礎。而2001年2月他宣布他的方法要和Crystal合并也是體現了這種思想。
SCRUM
在面向對象的領域中，SCRUM已經存在了一段相當長的時間了。雖然我并不是很熟悉它的發展歷程。不過它的重點是集中在可定義、可重復的環境中，可定義、可重復的人制定可定義、可重復的過程來解決可定義、可重復的問題。
SCRUM把一個項目分為多個迭代周期（在SCRUM方法中被稱為sprints），每個迭代周期的跨度大約為30天。在你開始一個sprint之前，你必須要定義這個sprint的功能需求，然后交給團隊來實現。關鍵之處在于每一個sprint的需求都是穩定的。
不過，管理人員必須要參與每一個sprint。每天，團隊需要舉行一個短會（大約15分鐘），稱之為scrum。會上，團隊需要通過明天的工作安排。特別是要提出對項目進程有阻礙的一些問題以便管理人員來解決。同時，他們還要匯報已完成的工作以便管理人員能夠得到項目進度的日更新表。
SCRUM的主要焦點都集中在每個迭代計劃和過程跟蹤上。這和其它的敏捷方法注重的方面非常的相似。如果能夠輔以XP方法的編碼實踐的話，SCRUM會工作的更好。
目前好沒有任何關于SCRUM的書籍面世。不過這里有一些WEB資源：Ken Schwaber主持的controlChaos.com網站是關于SCRUM的最好的導讀網站。Jeff Sutherland在object technology雜志上也有一個網站有一些部分是討論SCRUM的。PLoPD 4一書中也有一些篇幅介紹了SCRUM的一些實踐，有一定的參考價值。
DSDM（動態系統開發方法）
DSDM方法開始于1994年的英國。它是那些希望建立RAD和迭代開發系統的英國公司建立的協會。最早它有17個成員，現在已經發展到了1000多個成員，范圍也擴展到了英國之外。作為一個發展起來的協會，和其它眾多的敏捷方法相比，它有自己的特色。有一個職業的組織來為這種方法提供手冊、訓練課程、認證程序等等諸如此類。當然，這些都是有標價的。因為這一點，我沒有辦法繼續深入的研究這項方法。不過Jennifer Stapleton曾經寫過一本書，是這種方法的概覽。
這種方法最先最是要做可行性研究和商業研究�？尚行匝芯恳紤]DSDM方法究竟是不是適合這個即將開始的項目。商業研究則要對項目所在的商業環境進行一系列的研究。這些也就成為系統架構和項目計劃的一個提綱。
剩下的過程可以劃分為三個周期：功能建模周期主要集中在編寫分析文檔和建立軟件原型。設計和構建周期將構建可以操作的系統。實現周期將部署開發完成的系統。
DSDM有一些根本的原則，包括了使用中用戶交互、頻繁交付、充分授權的團隊、貫穿整個周期的測試。和其它的敏捷方法一樣，DSDM方法把整個周期劃分為一些較短的周期，大約在2到6個星期之間。這種方法針對不斷變化的需求特別強調高質量和適應性。
除了英國外，好像并沒有多少人使用這種方法，不過DSDM不但遵循了敏捷方法的原理，而且也適合那些成熟的傳統開發方法有堅實基礎的軟件組織。
敏捷軟件開發的宣言
在這么多的方法中，讓它們以某種形式在一起合作是一件非常有意思的事情。例如，2001年2月，這些方法的代表就受邀參加了在猶他州的Snowbird舉行的一場為期兩天的工作會。我也是其中一員，但我并不報太多的期望。畢竟，當你把這么一大捆的方法學家放在同一間房間里，保持禮貌就已經是你所能奢望的全部了。
令人驚訝的是事情完全不是按照我所想的那樣發展。與會的每個人都認識到他們有很多的共同點。并且這比他們之間的不同之處要多得多。在各個流程方法的領導者之間達成了多項影響深遠的共識，他們甚至要發布一項聯合公報，號召合作以支持更多的敏捷軟件過程的發展。（在會上，我們一致同意采用敏捷這個詞來表達我們的共同想法。）
會議的成果是敏捷軟件開發宣言，敏捷過程的共同價值和原則的宣言。大家還希望在未來能夠進一步的合作，鼓勵技術人員和商業人員使用和要求敏捷方法用于軟件開發。commentary and explanation of the manifesto和比較短的future of the agile manifesto也作為文章發表。
RUP是一個敏捷方法嗎？
不論什么時候，我們在面向對象領域談論方法，我們都會不可避免的提到Rational Unified Process所扮演的角色。這個統一過程是由Philippe Kruchten, Ivar Jacobson和瑞理公司的其它人發展起來的，作為UML的過程實現。RUP是一個過程框架，他能夠容納各種各樣不同的過程。實際上，這也是我對RUP最主要的批評，既然它能夠是任何的方法，那也意味著它任何方法也不是。我倒寧愿一個過程告訴你應該如何做，而不是提供永遠不會結束的各種選項。
既然是過程框架，那就意味著RUP既可以被用作非常傳統的瀑布模式，也可以被用在敏捷方法上。所以我們可以在敏捷過程中使用RUP，也可以在重量級過程中使用它。這一切都取決于你怎樣在你自己的環境中裁減RUP。
Craig Larman強烈建議以敏捷方法的思維方式來使用RUP。他的那部introductory book on OO development就介紹了一個基于他的輕型的、RUP的思維方式的過程。他的觀點是敏捷方法除非能夠和RUP整合起來，否則它永遠也無法成為主流的OO開發方法。Craig會在時間跨度為一個月的迭代周期開始花費二到三天的時間來和他的全部團隊使用UMl來勾畫出整個迭代過程中該做的工作的設計。這并不是什么不能夠違背的藍圖，這只是一份草圖，勾勒出系統在迭代后會是什么樣子。
另一個敏捷型RUP方法是is Robert Martin的dX process。dX過程是RUP的一個完整的、相容的實例，對XP方法也一樣（把dX翻轉過來試一試。）。dX是為那些必須使用RUP，但又想要使用XP的人設計的。這樣，它既是XP又是RUP，這也算是RUP的敏捷型應用的一個好例子吧。
對于我來說，使用RUP方法的關鍵是RUP的工業應用領導者必須重視他們開發軟件的方法。我就不止一次的發現那些使用RUP的人其實是在使用瀑布模式開發軟件。由于我和工業界保持一定的接觸，我知道Philippe Kruchten和他的團隊對迭代式開發堅信不疑。弄清楚這些事情，鼓勵諸如Craig's和Robert那樣發展出RUP的敏捷實例都有重大的影響。
其他資源
這里還有一些討論輕型方法的文章和討論。雖然他們都不是完整的方法論，但他們都對這個正在成長的領域提供了一些見解。
Patterns Language of Programming討論會包括了這方面的一些討論，因為那些對模式感興趣的人們通常對更適應性、更人性話的方法感興趣。最早的論文是Jim Coplein在PLoP1上發表的論文。還有PLoP2上Ward Cunningham的模式語言。Jim Coplein現在正在主持OrgPatterns站點，收集組織型的模式。
在XP2000上，Dirk Riehle發表了他的論文，討論XP方法和適應型軟件開發的價值系統的比較。Coad letter的7月號對比了XP方法和FDD方法。IEEE軟件的7月號也發表了幾篇“過程差異性”的文章，也涉及到了這些方法。
Mary Poppendieck寫了一篇優秀的文章來討論敏捷方法和lean制造業的對比。
你應該使用敏捷方法嗎？
并不是所有的人都適合使用敏捷方法的。如果你要走上這條路的話，有一些事你必須記住。不過我確信這些新的方法將會廣泛應用，而且會有比現在多得多的人們使用。
在目前的環境中，最常見的方法仍然還是“code and fix”。比無序方法應用更多的規則當然有用。而敏捷方法的優勢在于比重量級方法少了很多的步驟。敏捷方法的最大的好處就是它們較輕的重量。當你已經習慣于根本沒有流程的時候，簡單的流程似乎更容易被接受。
這些新方法的最大的限制就是如何使它們適合更大的團隊。Crystal大約能夠支持到50人，如果超出這個范圍，目前還沒有證據能夠證實你是否能夠采用這種方法。也許它能夠工作更好也說不定。
這篇文章很明白的表達了一個信息：適應型的方法在你的需求不確定或不穩定的時候很好用。如果你沒有穩定的需求，你也就沒有辦法遵循一個計劃好的過程來進行一項穩定的設計。在這種情況下，適應型過程執行起來雖然會比較難受，不過會更加有效。通常最大的障礙是顧客。依我之見，最重要的就是要讓客戶明白遵循一個可預測的過程，需求的改變對他們，對開發者來說都是一件冒險的事。'
文章來源于領測軟件測試網 http://www.kjueaiud.com/
