新方法論[中文版]
The New Methodology
作者：
源文檔 <http://www.martinfowler.com/articles/newMethodology.html>
過(guò)去的幾年中，敏捷開發(fā)蓬勃發(fā)展，敏捷方法被當(dāng)作修正機(jī)構(gòu)結(jié)構(gòu)僵化的一劑良藥抑或是打通軟件過(guò)程奇經(jīng)八脈的不二法門。本文我將探索敏捷方法的源頭，不是強(qiáng)調(diào)它何等重要而是要把關(guān)注點(diǎn)放在它的適應(yīng)性和以人為本這兩個(gè)方面。
Contents
· 無(wú)章法 里程碑 敏捷
· 可預(yù)見性VS 適應(yīng)性
o 涇渭分明的設(shè)計(jì)與實(shí)施
o 需求的不可預(yù)見性
o 控制不可預(yù)見的過(guò)程—迭代
o 適應(yīng)性的客戶
· 以人為本
o 人件
o 程序員：重任在肩
o 度量之難
o 業(yè)務(wù)領(lǐng)導(dǎo)者的角色
· 自適應(yīng)過(guò)程
· 敏捷開發(fā)的特點(diǎn)
o 敏捷宣言
o Scrum
o Crystal
· 你也要敏捷么?
相關(guān)文獻(xiàn)
· The New Methodology (Original)
過(guò)去幾年中軟件過(guò)程思想領(lǐng)域最引人注目的變化恐怕就是“敏捷”一詞的出現(xiàn)了。我們討論過(guò)敏捷方法在軟件開發(fā)的應(yīng)用，如何把敏捷引入開發(fā)團(tuán)隊(duì)中，也討論了如何防止那些激進(jìn)的敏捷主義者對(duì)一個(gè)良好的開發(fā)實(shí)踐躍躍欲試的“變革”。
這一軟件過(guò)程領(lǐng)域的新運(yùn)動(dòng)得益于二十世紀(jì)九十年代軟件過(guò)程領(lǐng)域各式各樣人們的努力，基于自身的愿景，他們要探求軟件過(guò)程的新道路；這是提出的觀點(diǎn)并不新奇，事實(shí)上很多人都堅(jiān)信多數(shù)成功的軟件都是采用了那些被用過(guò)多年的方法。不幸的是由于沒(méi)有受到足夠的重視，特別是沒(méi)有專業(yè)人士的認(rèn)可，這些觀點(diǎn)胎死腹中不了了之。
本文也是那次運(yùn)動(dòng)緣起的一部分，最初發(fā)表于2000年七月，正如我一貫的行文風(fēng)格，我寫這篇文章試圖深刻理解“敏捷”；從1996年起我有幸和Kent Beck, Ron Jeffries, Don Wells以及其他Chrysler C3的團(tuán)隊(duì)成員合作，使用極限編程的方法，寫文章時(shí)已經(jīng)有了數(shù)年的實(shí)踐經(jīng)驗(yàn)。
我嘗試和有相似觀點(diǎn)的人談話、閱讀他們的作品，我覺(jué)得只是從極限編程的角度來(lái)探討敏捷是不夠的。所以本文我將細(xì)數(shù)諸多敏捷實(shí)踐方法的異同。
本文的初版: The New Methodology (Original)
那時(shí)我的觀點(diǎn)也是我一直的觀點(diǎn)就是：一些基本原則構(gòu)成了這一新方法論，而這些原則與之前已有的原則截然不同；
本文一直是我的網(wǎng)站上最受歡迎的文章之一，這也意味著我有義務(wù)不斷的更新它的內(nèi)容。本文的初版探尋了新舊原則間的不同并通過(guò)一個(gè)敏捷方法的調(diào)查來(lái)深入的理解它。時(shí)過(guò)境遷調(diào)查中涉及的敏捷開發(fā)的內(nèi)容已經(jīng)發(fā)生了變化，但是新舊差異依然存在，我們將繼續(xù)討論下去，回頭再說(shuō)，現(xiàn)在開始…
無(wú)章法，繁重，敏捷
多數(shù)的軟件開發(fā)都是一個(gè)混亂無(wú)序的活動(dòng)，常常就簡(jiǎn)單的劃分成“CODE&FIX”兩個(gè)階段，這就是它的特點(diǎn)。軟件的編寫沒(méi)有一個(gè)指導(dǎo)性的計(jì)劃，系統(tǒng)的設(shè)計(jì)是由一系列短期的決定構(gòu)成的。當(dāng)系統(tǒng)規(guī)模小的時(shí)候這個(gè)方法還真的表現(xiàn)不錯(cuò)，但是隨著系統(tǒng)規(guī)模變大新功能的開發(fā)日益艱難。雪上加霜的是這時(shí)BUG也無(wú)處不在而且難以修改；這種系統(tǒng)的典型特征就是在做到"feature complete" 之后將有一個(gè)漫長(zhǎng)的測(cè)試階段，這個(gè)階段將把時(shí)間計(jì)劃完全打亂，因?yàn)闇y(cè)試和調(diào)試的時(shí)間難以預(yù)計(jì)；
解決上述問(wèn)題，這就是引入軟件過(guò)程方法論的初衷。方法論將一些嚴(yán)格的過(guò)程應(yīng)用到軟件開發(fā)活動(dòng)，目的就是提高軟件開發(fā)的可預(yù)見性和效率；他們是怎么做的呢？他們把其他工程學(xué)的原理引入進(jìn)來(lái)強(qiáng)調(diào)計(jì)劃的重要性，通過(guò)一個(gè)詳細(xì)的計(jì)劃來(lái)解決問(wèn)題。因此這時(shí)的方法又稱計(jì)劃驅(qū)動(dòng)的方法。
工程方法學(xué)存在了很長(zhǎng)時(shí)間，但是并沒(méi)有取得顯著的成功。它們甚至沒(méi)有流傳開，最為人詬病的是它太官僚主義了。采用該方法要照顧太多的瑣碎的事情，這讓整個(gè)開發(fā)節(jié)奏慢了下來(lái)。
背負(fù)著力挽狂瀾的期望，“敏捷方法”應(yīng)時(shí)而生。對(duì)于大多數(shù)人來(lái)講，敏捷方法最大的吸引力就是它能解決工程方法論的官僚主義問(wèn)題。這個(gè)方法論試圖給出一個(gè)介于“無(wú)過(guò)程”和“過(guò)度過(guò)程”之間的折衷方案，使用一個(gè)適中的過(guò)程來(lái)獲得合理的收益（成本和收益的一個(gè)平衡）。
之所以能做到這一點(diǎn)，是因?yàn)槊艚莘椒ㄅc之前工程方法論強(qiáng)調(diào)的那些觀點(diǎn)有著顯著的不同。
最直接的不同點(diǎn)就是它不是文檔驅(qū)動(dòng)的，通常對(duì)于給定的任務(wù)只需要較少的文檔就可以了。它倒是有點(diǎn)像是代碼驅(qū)動(dòng)的，遵循著一個(gè)規(guī)則就是把源代碼作為文檔的一部分。
但我不認(rèn)為這是敏捷開發(fā)的關(guān)鍵，文檔的精簡(jiǎn)只是一個(gè)表象，背后有兩個(gè)深層次的原因：
· 敏捷方法是適應(yīng)性的，而不是可預(yù)見性的；工程方法論嘗試用較長(zhǎng)的時(shí)間把軟件開發(fā)的絕大部分做到計(jì)劃里面，在事情沒(méi)有變化的時(shí)候這個(gè)方法表現(xiàn)不錯(cuò)。所以本質(zhì)上它是拒絕變化的，而敏捷方法恰恰是歡迎變化的，它強(qiáng)調(diào)在變化中適應(yīng)和成長(zhǎng).
· 敏捷方法是以人為本的而不強(qiáng)調(diào)過(guò)程的重要性。工程學(xué)方法論是想定義一個(gè)放之四海皆準(zhǔn)的過(guò)程，無(wú)論誰(shuí)用都可以。敏捷方法斷言沒(méi)有什么過(guò)程會(huì)提高開發(fā)團(tuán)隊(duì)的技能，過(guò)程的角色就是在開發(fā)團(tuán)隊(duì)的工作中提供支持。
下面的環(huán)節(jié)我們將從更多的細(xì)節(jié)來(lái)探討這些不同，這樣你就能理解到底什么是適應(yīng)性、以人為本的過(guò)程，它的優(yōu)勢(shì)與劣勢(shì)，以及最關(guān)鍵的一個(gè)問(wèn)題：無(wú)論你是一個(gè)開發(fā)者還是軟件用戶,敏捷是不是你需要的。
可預(yù)見性VS適應(yīng)性
涇渭分明的設(shè)計(jì)與實(shí)施
軟件過(guò)程通常引入的方法論原則是源于土木工程學(xué)或者機(jī)械工程學(xué)。而這些原則強(qiáng)調(diào)建造之前的計(jì)劃。工程師會(huì)提供一系列的圖紙精確的描述要建造什么已經(jīng)怎么把建造的東西進(jìn)行組合。許多設(shè)計(jì)上的決定，比如橋梁負(fù)載，在設(shè)計(jì)圖紙的時(shí)候就已經(jīng)確定了。之后圖紙移交給另外一個(gè)小組甚至是另外一個(gè)公司來(lái)施工。整個(gè)的實(shí)施工程是嚴(yán)格按照?qǐng)D紙進(jìn)行的。實(shí)施過(guò)程中會(huì)遇到一些問(wèn)題，但多數(shù)是無(wú)關(guān)痛癢的小問(wèn)題。
由于圖紙已經(jīng)明確說(shuō)明了各個(gè)小塊的內(nèi)容以及怎么組合，它們的功能就像是一個(gè)細(xì)化的實(shí)施方案，它指出要做完成什么任務(wù)，以及這些任務(wù)之間的依賴關(guān)系。這就可以進(jìn)行進(jìn)度預(yù)計(jì)和工程預(yù)算。圖紙甚至包括人們具體怎么實(shí)施工程，這樣實(shí)施工程的一方不需要太智能，盡管他們往往技術(shù)高超。
所以我們這里看到的是兩個(gè)截然不同的活動(dòng)。設(shè)計(jì)很難做出預(yù)計(jì)，需要大量的有創(chuàng)造性的人參與，而實(shí)施是很容易預(yù)計(jì)的。一旦完成了設(shè)計(jì)就可以制定實(shí)施計(jì)劃，有了計(jì)劃我們就可以對(duì)實(shí)施過(guò)程進(jìn)行預(yù)計(jì)和控制。在土木工程中，實(shí)施比設(shè)計(jì)和計(jì)劃的成本消耗時(shí)間消耗都要大。
脫胎于上述理論的軟件工程學(xué)方法論也就變成了這樣：我們需要一個(gè)可預(yù)見的計(jì)劃，用技能比較低的人就可以完成它。要做到這一點(diǎn)我們就必須把設(shè)計(jì)和實(shí)施分離開，因此一個(gè)出現(xiàn)了：我們必須知道怎樣做軟件設(shè)計(jì)才能讓實(shí)施工作在設(shè)計(jì)之后一馬平川的進(jìn)行下去。
這個(gè)計(jì)劃是什么樣的呢？很多時(shí)候它的角色就是UML中的設(shè)計(jì)符號(hào)。如果我們可以使用UML來(lái)做所有的重要的決定，我們就可以構(gòu)建出來(lái)一個(gè)實(shí)施計(jì)劃并把這個(gè)計(jì)劃移交給開發(fā)組進(jìn)行編碼。但這個(gè)有一個(gè)關(guān)鍵問(wèn)題，你能用設(shè)計(jì)把編碼變成一個(gè)可預(yù)見的實(shí)施活動(dòng)么？如果可以的話，消耗的成本是在一個(gè)可接受的范圍內(nèi)么？
這些引出來(lái)一些新問(wèn)題，首先怎樣把UML式的設(shè)計(jì)轉(zhuǎn)化到程序員可以接受的狀態(tài)。UML式的設(shè)計(jì)有一個(gè)特點(diǎn)就是紙上看起來(lái)很不錯(cuò)，但是到編碼實(shí)踐的時(shí)候嚴(yán)重的錯(cuò)誤就會(huì)凸顯出來(lái)。
土木工程學(xué)的模型都是基于多年工程的實(shí)踐總結(jié)，佐之以強(qiáng)制執(zhí)行，加之精確的數(shù)學(xué)分析。而UML式的設(shè)計(jì)只能依賴同事評(píng)審，這樣就造成一些錯(cuò)誤只有在編碼和測(cè)試階段才浮出水面。甚至對(duì)于一些高水平的設(shè)計(jì)人員也會(huì)認(rèn)為把設(shè)計(jì)變成軟件是一件很神奇的事情。
另外一個(gè)問(wèn)題就是平衡支出，建一座橋的設(shè)計(jì)費(fèi)用大約是總支出的10%，剩下的實(shí)施費(fèi)用。在軟件開發(fā)中編碼占用的時(shí)間遠(yuǎn)遠(yuǎn)小于這個(gè)比例； McConnell 指出對(duì)于一個(gè)大型的項(xiàng)目只有15%的時(shí)間來(lái)做編碼和單元測(cè)試，這幾乎和建橋的比例完全相反的。即使你把測(cè)試也作為實(shí)施的一部分設(shè)計(jì)依然保持50%的比例。這就點(diǎn)出了軟件開發(fā)中的設(shè)計(jì)與它在其它工程學(xué)分支中的角色迥異不同！
這些問(wèn)題讓 Jack Reeves甚至得出這樣的結(jié)論：事實(shí)上源代碼就是設(shè)計(jì)文檔而實(shí)施階段就是使用編譯器和連接器。當(dāng)然這時(shí)所有的實(shí)施階段就可以完全可以也應(yīng)該自動(dòng)化完成。
這種看法可以得出下面的結(jié)論：
· 軟件開發(fā)中: 實(shí)施是很便宜的甚至是免費(fèi)的
· 在軟件開發(fā)中所有的努力都在設(shè)計(jì)上，因而需要有創(chuàng)造性和才華的人
· 創(chuàng)造性的過(guò)程很難計(jì)劃，所以可預(yù)計(jì)性幾乎是一個(gè)不可能完成的任務(wù)
· 我們要意識(shí)到軟件工程學(xué)與傳統(tǒng)工程學(xué)的區(qū)別，這是一個(gè)完全不同的活動(dòng)，需要一不同的過(guò)程。
需求的不可預(yù)見性
每一個(gè)我參加的項(xiàng)目我都會(huì)聽到這樣的小插曲，開發(fā)人員告訴我“項(xiàng)目最大的問(wèn)題就是需求總是變化”，讓我感到驚異的是任何人對(duì)此都表示不適應(yīng)；在開發(fā)商業(yè)軟件的過(guò)程中，變更是正常的，問(wèn)題是我們?nèi)绾蚊鎸?duì)它。
一種方式是把需求變更的原因歸結(jié)為糟糕的需求分析。這種觀點(diǎn)的隱含意思是需求分析要在編碼開始之前對(duì)需求有一個(gè)全面的理解，然后用戶簽字，簽字之后啟動(dòng)開發(fā)過(guò)程并盡量不做變更。這里有一個(gè)問(wèn)題那就是充分理解需求是很難的一件事情，而無(wú)法對(duì)需求的成本進(jìn)行評(píng)估是這件事情更加難上加難。比如你要給你的車添加一個(gè)遮陽(yáng)篷，而銷售人員無(wú)法告訴你要添加10美元還是100美元。不知道花多少錢你怎么判斷是不是要買？
眾多因素導(dǎo)致估計(jì)很難做到，因素之一是軟件開發(fā)是一個(gè)設(shè)計(jì)活動(dòng)難以計(jì)劃和估計(jì)；因素之二：基本資源一直變化難以估計(jì)；因素之三：估計(jì)取決于過(guò)程中的人，人是很難進(jìn)行預(yù)計(jì)和量化分析的。
軟件是沒(méi)有物質(zhì)實(shí)體的，在它沒(méi)有做出來(lái)之前你很難看到它的位置。直到你用的時(shí)候你才知道那些功能點(diǎn)是有價(jià)值的哪些是沒(méi)有價(jià)值的。這就要求人們應(yīng)該認(rèn)為軟件需求是可以變化的，軟件就是應(yīng)該是“軟”的。需求不僅僅是可變，而且是應(yīng)該變；花費(fèi)大量精力來(lái)跟客戶確定需求，特別是客戶也曾經(jīng)涉足軟件開發(fā)那就更糟了，因?yàn)樗麄冎儡浖円幌潞苋菀祝?span lang="EN-US">
即使能得到一個(gè)精確的穩(wěn)定的需求，你依然難逃厄運(yùn)。今天的經(jīng)濟(jì)形勢(shì)就決定了軟件的內(nèi)容快速變化。今天的好需求，六個(gè)月之后就可能一文不值；即使需求不斷的改進(jìn)也是跟不上經(jīng)濟(jì)發(fā)展的步伐；經(jīng)濟(jì)是無(wú)法預(yù)言的，否定這個(gè)觀點(diǎn)的人要么是撒謊要么是有足夠的實(shí)力可以左右市場(chǎng)；軟件開發(fā)中的其他事情都取決于需求，你得不到一個(gè)穩(wěn)定的需求，你也得不到一個(gè)可預(yù)見的計(jì)劃。
可預(yù)見性不可能做到嗎?
總體上講，不是的；有些軟件開發(fā)是可以做到可預(yù)見的。像NASA太空穿梭機(jī)軟件開發(fā)就是軟件可預(yù)見性的樣板。這個(gè)需要大量環(huán)節(jié)，大量時(shí)間，一個(gè)大型的團(tuán)隊(duì)，一個(gè)穩(wěn)定的需求。但是我不認(rèn)為多數(shù)的商業(yè)軟件和太空穿梭機(jī)軟件屬于統(tǒng)一范疇。所以需要有一個(gè)不同的開發(fā)過(guò)程。
存在一個(gè)危險(xiǎn)就是做不到可預(yù)言的時(shí)候“做可預(yù)言狀”；研究方法論的人不善于識(shí)別邊界條件：
在那個(gè)點(diǎn)上方法從合適變成不合適；絕大多數(shù)的方法論者都希望自己的理論放之四海皆準(zhǔn)，所以他們也不愿意公開這個(gè)邊界。這就導(dǎo)致了方法論誤用的事情，比如把可預(yù)見的方法用在了不可預(yù)見的環(huán)境中。
那樣做是很有誘惑性的； 可預(yù)見性是令人向往的，當(dāng)你明明知其不可為而為之的時(shí)候，這就會(huì)導(dǎo)致人們?cè)缭绲淖隽擞?jì)劃，之后局面慢慢失控；你發(fā)現(xiàn)計(jì)劃與現(xiàn)實(shí)相去甚遠(yuǎn)，你可以在一個(gè)較長(zhǎng)的時(shí)間內(nèi)依然裝作計(jì)劃是有效的；但有時(shí)候兩者過(guò)于不符，就不能視而不見了，失敗總是痛苦的。
所以如果你在一個(gè)不可預(yù)見的環(huán)境中就不要使用可預(yù)見的方法論。那需要多個(gè)項(xiàng)目控制模型，多個(gè)客戶關(guān)系模型，這最終還解決不了問(wèn)題，真的很殘酷?？深A(yù)見性很美好，但是太難實(shí)踐了。就像大多數(shù)問(wèn)題一樣，最重要的是意識(shí)到問(wèn)題的存在！
不依賴可預(yù)見性并不是說(shuō)你要應(yīng)付一堆不可控的、混亂的事情。相反你需要一個(gè)過(guò)程可以應(yīng)對(duì)不可預(yù)見性。這就是適應(yīng)性所關(guān)心的。
控制不可預(yù)見的過(guò)程—迭代
在不可預(yù)見的世界里我們?nèi)绾巫蕴?？最重要的也是最難的就是清楚地知道我們的位置！我們需要一個(gè)誠(chéng)實(shí)的反饋機(jī)制可以頻繁的告訴我們當(dāng)前的位置。
得到這種反饋的方法就是：迭代開發(fā)！這不是什么新主意。迭代開發(fā)有一大堆相關(guān)的關(guān)鍵詞：增量開發(fā)，漸進(jìn)式開發(fā)，螺旋…. 迭代開發(fā)的關(guān)鍵就是不斷的有可用的新版本的系統(tǒng)出來(lái)，它可以是最終系統(tǒng)的功能子集；這些可用的系統(tǒng)在功能上不完善，但是已經(jīng)做出來(lái)的是滿足需求的。在最交付之前需要做細(xì)致的集成測(cè)試。
這個(gè)的意義就在于沒(méi)有什么比一個(gè)測(cè)試過(guò)，集成的系統(tǒng)更逼近真實(shí)的需求；文檔可能隱藏缺陷，未測(cè)試的代碼可能有很多隱患，當(dāng)時(shí)當(dāng)人們做到電腦前用一下的時(shí)候，問(wèn)題就昭然了：無(wú)論是系統(tǒng)Bug還是誤解需求問(wèn)題一下子浮出水面。
迭代式開發(fā)對(duì)于可以預(yù)見的過(guò)程同樣是有效的。只不過(guò)在不可預(yù)見的環(huán)境中它是必要的，因?yàn)檫@時(shí)要應(yīng)對(duì)變化。長(zhǎng)期的計(jì)劃通常是不穩(wěn)定的，單次迭代的短期計(jì)劃是穩(wěn)定的。迭代開發(fā)都是基于上次迭代的結(jié)果，有一個(gè)堅(jiān)實(shí)的基礎(chǔ)。
一個(gè)問(wèn)題就是迭代的周期應(yīng)該多長(zhǎng)。不同的人有不同的答案。XP 建議是一到兩周。SCRUM 建議一個(gè)月左右。Crystal 可能更長(zhǎng)一點(diǎn). 有一個(gè)趨勢(shì)就是每一次迭代盡量的短，這樣可以頻繁的接受到反饋，明確自己當(dāng)前的位置。
適應(yīng)性的客戶
適應(yīng)性的過(guò)程需要與客戶建立不同以往的關(guān)系，特別是開發(fā)過(guò)程是由單獨(dú)的一個(gè)公司來(lái)做的時(shí)候。當(dāng)你雇用一個(gè)單獨(dú)的公司來(lái)做開發(fā)許多客戶會(huì)傾向于選擇定價(jià)合同。告知開發(fā)者需求是什么然后投標(biāo)，接標(biāo)，開發(fā)團(tuán)隊(duì)的義務(wù)就是把軟件開發(fā)出來(lái)。一個(gè)定價(jià)的合同需要有一個(gè)穩(wěn)定的需求一個(gè)可預(yù)見的過(guò)程。適應(yīng)性的過(guò)程和不穩(wěn)定的需求意味著不能進(jìn)行在常規(guī)概念下的定價(jià)開發(fā)。把定價(jià)開發(fā)的模型放到適應(yīng)性過(guò)程中，最終會(huì)以痛苦的爆發(fā)結(jié)束。爆發(fā)的結(jié)果就是開發(fā)方和客戶兩敗俱傷。畢竟客戶要的是他們業(yè)務(wù)需要的東西，如果不能滿足這個(gè)目標(biāo)那么即使不付給開發(fā)方一分錢他們還是受損失了。事實(shí)上這時(shí)損失比軟件做成功要付的錢還要多，因?yàn)榭蛻舾跺X做軟件是要用軟件贏利的。
這樣定價(jià)開發(fā)在一個(gè)非可預(yù)計(jì)環(huán)境中應(yīng)用對(duì)于雙方都是有風(fēng)險(xiǎn)的。這意味著客戶要做出變化！
不是說(shuō)你無(wú)法進(jìn)行開發(fā)的前期預(yù)算，只是說(shuō)你不能定死時(shí)間、價(jià)格、范圍。常規(guī)的敏捷方法是定下來(lái)時(shí)間和價(jià)格，允許范圍做可控的變化。
在適應(yīng)性的過(guò)程中客戶可以做更多細(xì)粒度的控制。每一次迭代都可以做結(jié)果檢驗(yàn)并糾正開發(fā)方向。這就拉近了客戶和開發(fā)者的關(guān)系，真正的合作關(guān)系。這種級(jí)別的契約并不是適合每一種客戶，也不是適合每一個(gè)開發(fā)團(tuán)隊(duì)，重要的是能讓適應(yīng)性的過(guò)程順利的跑起來(lái)。
所有這些都會(huì)給客戶帶來(lái)很多好處。首先是他們得到了更多關(guān)于軟件開發(fā)情況的信息反饋。一個(gè)可用的系統(tǒng)，盡管可能很小，但是可以盡早的投入生產(chǎn)。客戶可以根據(jù)業(yè)務(wù)的變化來(lái)提出一些變更，同時(shí)也可以知道這個(gè)軟件在真實(shí)環(huán)境中的運(yùn)行情況。
這個(gè)過(guò)程中每一小塊功能都可以看出項(xiàng)目進(jìn)行真實(shí)狀態(tài)。而預(yù)見性過(guò)程要通過(guò)檢驗(yàn)和計(jì)劃是否一致來(lái)驗(yàn)證。這樣就很難發(fā)現(xiàn)開發(fā)上是不是已經(jīng)背離了計(jì)劃。通常的結(jié)果就算是在項(xiàng)目的后期會(huì)有一個(gè)較明顯的脫軌情況。敏捷開發(fā)中每一次迭代都有一個(gè)持續(xù)修正計(jì)劃的過(guò)程。如果壞兆頭能早日顯露出來(lái)，那么我們就還有時(shí)間來(lái)做出應(yīng)對(duì)。風(fēng)險(xiǎn)控制是迭代開發(fā)的關(guān)鍵優(yōu)勢(shì)！
敏捷方法通過(guò)保持短期迭代，將這一優(yōu)勢(shì)更加凸顯出來(lái)，能夠通過(guò)各種不同的途徑把變更看出來(lái)。Mary Poppendieck 在她的文章"A late change in requirements is a competitive advantage".里面幫我總結(jié)了各種不同的觀點(diǎn)。我相信好多人都已經(jīng)注意到用戶自己在開始的時(shí)候都很難描述清楚他們想要什么。我們發(fā)現(xiàn)用戶都是在判斷什么是有用什么是沒(méi)用的過(guò)程中不斷的了解到自己的需要。通常最有價(jià)值的功能點(diǎn)開始的時(shí)候并不是很明顯，直到客戶開始有機(jī)會(huì)對(duì)軟件提出改變。敏捷方法就是要尋求這方面的優(yōu)勢(shì)。鼓勵(lì)客戶通過(guò)在系統(tǒng)構(gòu)建的過(guò)程中不斷搞清自己的需求，通過(guò)快速的整合變更來(lái)進(jìn)一步構(gòu)建新系統(tǒng)。
See Related Article: Is Design Dead?
上述提出的內(nèi)容都是承擔(dān)著保證項(xiàng)目成功的重任。通過(guò)考察一個(gè)可預(yù)見的項(xiàng)目的計(jì)劃就可以判斷它是否成功。在既定時(shí)間和支出限制先完成的項(xiàng)目是成功的。這種度量方式對(duì)于敏捷開發(fā)的環(huán)境是沒(méi)有意義的。對(duì)于敏捷開發(fā)者這些問(wèn)題直指商業(yè)價(jià)值—客戶從軟件中得到的價(jià)值比做軟件的成本要多。一個(gè)好的可預(yù)見項(xiàng)目會(huì)按計(jì)劃進(jìn)行，一個(gè)好的敏捷開發(fā)項(xiàng)目的會(huì)和最初的計(jì)劃不同并優(yōu)于最初目標(biāo)。
以人為本
執(zhí)行一個(gè)適應(yīng)性過(guò)程是不容易的。特別是它要求有一個(gè)非常高效的開發(fā)團(tuán)隊(duì)。團(tuán)隊(duì)不僅要求每一個(gè)都很強(qiáng)，隊(duì)伍組合起來(lái)的力量也要求很強(qiáng)。這里有一個(gè)有趣的協(xié)作：不僅是適應(yīng)性項(xiàng)目需要一個(gè)強(qiáng)大的團(tuán)隊(duì)，很多優(yōu)秀的開發(fā)者都喜歡適應(yīng)性的開發(fā)過(guò)程。
人件
傳統(tǒng)方法論中的開發(fā)過(guò)程中，其中一個(gè)目標(biāo)就是把人作為一個(gè)可替換的部分。成功的過(guò)程可以把人當(dāng)作各式各樣無(wú)差別的資源來(lái)對(duì)待。你們有分析師，程序員，測(cè)試人員，和項(xiàng)目經(jīng)理。個(gè)體不重要，重要的是他的角色。你要做一個(gè)項(xiàng)目計(jì)劃，設(shè)計(jì)師和測(cè)試人員是誰(shuí)并不重要，重要的是他們的數(shù)量是多少。
但這就引出了一個(gè)關(guān)鍵問(wèn)題：軟件開發(fā)過(guò)程中，人是可以隨意替換的部分么？而敏捷開發(fā)是拒絕這種假設(shè)的。當(dāng)然明確提出人不是資源的是Alistair Cockburn. 他的文章 Characterizing People as Non-Linear, First-Order Components in Software Development,指出可預(yù)見過(guò)程需要各種組件的行為都是可以預(yù)見的。但是人不屬于可預(yù)見的組件。而進(jìn)一步的研究結(jié)果表明：人是軟件開發(fā)中的最重要元素。
在他的文章中把人也當(dāng)作組件，這就是人在過(guò)程和方法論中的位置。這種看法的錯(cuò)誤就是人是會(huì)經(jīng)常變化的，是非線性的。有著獨(dú)一無(wú)二的成功和失敗狀態(tài)或者說(shuō)是模式。這些是必須首先考慮的，是不能忽略的。我們可以看到過(guò)程或者方法論設(shè)計(jì)者的失敗往往是由于忽略了人的因素。
我們懷疑就這一方面軟件開發(fā)是不是違反人的本性，當(dāng)我們用計(jì)算機(jī)編程的時(shí)候我們?cè)诳刂埔粋€(gè)可預(yù)見的設(shè)備。我們?cè)诿ＣＨ撕Ｖ姓业阶约旱奈恢萌プ鲆患ぷ鳎且驗(yàn)槲覀兩瞄L(zhǎng)做它。
盡管 Cockburn最明確的表達(dá)了軟件開發(fā)中以人為本的思想，其實(shí)這個(gè)是很多軟件開發(fā)思想家的共識(shí)。問(wèn)題在于，多數(shù)時(shí)候方法論并不沒(méi)有把人看作是影響項(xiàng)目成功的首要因素。
如果你期望你的開發(fā)者是無(wú)差別的插件，你就不能把他們看成一個(gè)個(gè)的個(gè)體。這會(huì)降低士氣和生產(chǎn)力。最合適的人用在最合適的位置，這就是你想要的：人件！
把人放在第一位是一個(gè)重大的抉擇，需要一系列的決策來(lái)輔助推動(dòng)！把人當(dāng)作資源在商業(yè)領(lǐng)域是根深蒂固的，它源于Frederick Taylor's 科學(xué)管理論. 運(yùn)作一個(gè)工廠, Taylorist 方法是有意義的。但是對(duì)于高創(chuàng)造性和專業(yè)的工作，比如軟件開發(fā)，這個(gè)理論就不合適了，而事實(shí)上制造也也逐漸從Taylorist模型中脫離出來(lái)。
程序員：重任在肩
Taylorist理論的一個(gè)重點(diǎn)就是： 做工作的人不是那些知道怎樣能把工作做到最好的人。在工廠里面由于諸多原因這或許是對(duì)的。部分原因是多數(shù)工人并不是很有才能、有創(chuàng)造性的，還有一個(gè)原因是管理者和工人收入差距造成的緊張關(guān)系。
最近的歷史漸漸告訴我們?cè)谲浖_發(fā)領(lǐng)域這是不對(duì)的，越來(lái)越多的聰明而能干的人被吸引到這個(gè)光華奪目前景光明的領(lǐng)域。 (這也是我離開電子工程學(xué)的原因。)盡管經(jīng)歷了世紀(jì)初的低迷，軟件開發(fā)行業(yè)依然聚集了大量精英才俊。
(有一個(gè)很有意思的換代現(xiàn)象，有些有趣的現(xiàn)象讓我好奇在過(guò)去十五年是不是越來(lái)越多的聰明人進(jìn)入這一領(lǐng)域。而每一次換代都會(huì)有一些代表性的變革.)
你想要雇用或者留住優(yōu)秀的人，你就必須意識(shí)到他們是專業(yè)才干，他們是最適合管理自己技術(shù)工作的人。Taylorist觀念是將計(jì)劃抽離出來(lái)，這種觀念起作用除非是計(jì)劃者比做這件事情的人更精于業(yè)務(wù)！如果你有聰明主動(dòng)的人做事情，那么這個(gè)理論就不是很有效了。
管理以人為本的過(guò)程
以人為本在敏捷過(guò)程中有一些特有的表現(xiàn)，這些表現(xiàn)也會(huì)導(dǎo)致不同的效果。并不是所有的效果都是一致的。
相比較而言，接受這個(gè)過(guò)程比應(yīng)用這個(gè)過(guò)程更重要。通常軟件過(guò)程都是管理者要求強(qiáng)制執(zhí)行的。而多數(shù)情況下是推行不利的，特別是管理者有相當(dāng)長(zhǎng)的時(shí)間離開開發(fā)活動(dòng)的時(shí)候。接受一個(gè)過(guò)程需要責(zé)任委托，這需要全體團(tuán)隊(duì)成員的成員。
這樣會(huì)有一個(gè)有趣的結(jié)果：只有開發(fā)人員自己可以選擇一個(gè)適應(yīng)性的過(guò)程。特別是極限編程的實(shí)踐中尤其如此，它需要許多可執(zhí)行的原則。相比起來(lái)Crystal要求的原則比較少，因而受眾較多一些。
另一個(gè)觀點(diǎn)就是開發(fā)者能夠做所有的技術(shù)決策。XP深得要領(lǐng)在其計(jì)劃過(guò)程中只有開發(fā)者能估計(jì)一個(gè)工作所需的時(shí)間。
這種技術(shù)領(lǐng)導(dǎo)權(quán)的分離是管理層的一個(gè)重大變革，這樣就要求開發(fā)者和管理者責(zé)任共擔(dān)，處于相當(dāng)?shù)奈恢谩Ｗ⒁馕艺f(shuō)的是相當(dāng)，管理者依然是管理者，只不過(guò)把開發(fā)者的專業(yè)能力重視起來(lái)。
在工業(yè)領(lǐng)域這一變化的重要原因是技術(shù)在生產(chǎn)中的比重日益增加。過(guò)不了幾年技術(shù)知識(shí)就會(huì)落伍。技術(shù)是工業(yè)領(lǐng)域的生命線，很多進(jìn)入管理層的人會(huì)發(fā)現(xiàn)他們的技術(shù)能力日益萎縮。開發(fā)者會(huì)意識(shí)到他們的技術(shù)能力會(huì)漸漸消失而必須信賴新一代的開發(fā)者。
度量之難
如果在一個(gè)過(guò)程中，一個(gè)人指責(zé)另外一個(gè)人沒(méi)有按照合理的方式做一件事情。領(lǐng)導(dǎo)就需要有一些方法進(jìn)行判斷誰(shuí)對(duì)誰(shuí)錯(cuò)，雖然科學(xué)的管理推動(dòng)了對(duì)人們勞動(dòng)成果進(jìn)行客觀評(píng)價(jià)，這件事仍然比較困難。
對(duì)于軟件的度量更是如此，即使你全力以赴，軟件開發(fā)中一些很小的事情你都難以度量，比如生產(chǎn)力。沒(méi)有一個(gè)好的評(píng)判方法怎么進(jìn)行相關(guān)的管理控制呢？就像說(shuō)不能超標(biāo)，而標(biāo)準(zhǔn)卻晦暗不明。
引入度量管理而沒(méi)有好的度量方法會(huì)帶來(lái)很多問(wèn)題。Robert Austin 做過(guò)這方面的討論.他指出要做度量你就要把所有的重要因素都納入到度量體系之中。任何漏掉的因素都會(huì)不可避免的影響度量體系的功用，沒(méi)有達(dá)到預(yù)期的效果。度量體系不利是基于度量進(jìn)行管理的命門所在。
Austin 的結(jié)論是必須要在基于度量的管理和開發(fā)者自我管理之間做一個(gè)選擇。前者適合那種重復(fù)性的工作場(chǎng)合，不需要太多的知識(shí)技能而產(chǎn)出又容易量化—這都是和軟件開發(fā)背道而馳的。
這一傳統(tǒng)方法的核心在于所有的運(yùn)作都是基于一個(gè)假設(shè)：基于度量的管理是最有效的管理；而敏捷組織認(rèn)為這種特征的開發(fā)活動(dòng)往往障礙不斷。敏捷主義者認(rèn)為這時(shí)委托式（開發(fā)者自我管理）的管理更有效果。
業(yè)務(wù)領(lǐng)導(dǎo)者的角色
繼續(xù)上面的話題，技術(shù)人員是不可能自己完成過(guò)程中所有事情的。他們需要業(yè)務(wù)需求的向?qū)?。這就引出來(lái)適應(yīng)性過(guò)程的另外一個(gè)重要方面：開發(fā)人員要和業(yè)務(wù)專家緊密合作。
這就超出了多數(shù)項(xiàng)目中業(yè)務(wù)角色的范疇，敏捷團(tuán)隊(duì)需要的不是臨時(shí)溝通而是需要與業(yè)務(wù)專家持續(xù)的溝通。此外這是開發(fā)者每天都要面對(duì)的，不是管理級(jí)別的一個(gè)事情。由于開發(fā)者在他們的領(lǐng)域內(nèi)有自己的原則，他們所要做的就是與其他領(lǐng)域的專家協(xié)同合作。
上面說(shuō)的大部分都是適應(yīng)性過(guò)程自身固有的特性。由于適應(yīng)性過(guò)程意味著事情會(huì)迅速的發(fā)生變化，因而你要不斷的和業(yè)務(wù)專家進(jìn)行需求確認(rèn)。
最讓開發(fā)者惱火的是讓他們做無(wú)用功。業(yè)務(wù)專家要保證自己的工作質(zhì)量來(lái)讓開發(fā)者信賴自己！
自適應(yīng)過(guò)程
我已經(jīng)講了很多關(guān)于軟件項(xiàng)目適應(yīng)性的話題，如何不斷的調(diào)整軟件來(lái)滿足客戶需求。然而還沒(méi)有完，還有另外一個(gè)角度可以看適應(yīng)性：過(guò)程本身也在不斷的變化。一個(gè)項(xiàng)目使用的適應(yīng)性過(guò)程和一年前的適應(yīng)性過(guò)程不會(huì)相同。開發(fā)團(tuán)隊(duì)經(jīng)常做的就是找到以前的一個(gè)適用的過(guò)程，然后修改一下開始使用。
自適應(yīng)的第一步就是常規(guī)的回顧已有過(guò)程。通常每一次迭代都要做這件事情。每一次迭代之后的短會(huì)上可以問(wèn)自己幾個(gè)問(wèn)題： (摘自Norm Kerth )
· 我們哪里做好了？What did we do well?
· 我們學(xué)到了什么？What have we learned?
· 我們?cè)鯓幼龅礁茫?span lang="EN-US">What can we do better?
· 什么讓我們困惑不解？What puzzles us?
這些問(wèn)題可以引導(dǎo)你思考如何對(duì)下一次的迭代過(guò)程進(jìn)行改進(jìn)。這樣的話問(wèn)題隨著項(xiàng)目進(jìn)行逐步解決掉，過(guò)程與團(tuán)隊(duì)之間配合就更加融洽。
如果自適應(yīng)出現(xiàn)在項(xiàng)目中，在組織形式上會(huì)有所體現(xiàn)。一個(gè)自適應(yīng)相關(guān)的結(jié)論就是不要相信一個(gè)方法論就可以一勞永逸的解決問(wèn)題。每一個(gè)團(tuán)隊(duì)都應(yīng)該選擇自己的過(guò)程，并且隨著項(xiàng)目進(jìn)行不斷的協(xié)調(diào)。其他項(xiàng)目過(guò)程的經(jīng)驗(yàn)作用就是用來(lái)吸納，估計(jì)底線，開發(fā)者的責(zé)任就是根據(jù)手頭的任務(wù)調(diào)整過(guò)程。
敏捷開發(fā)的特點(diǎn)
敏捷是軟件開發(fā)的原理之一，在這個(gè)大的概念之下有很多具體的方法比如： Extreme Programming, Scrum, Lean Development, etc. 每一種具體的的方法都有自己的思想 社區(qū)和和領(lǐng)導(dǎo)者；每一個(gè)社區(qū)各有特色但是都遵循一些共同的基本原則。社區(qū)之間也互相學(xué)習(xí)，很多參與者也都在混跡于不同的社區(qū)之間，總而言之，這是一個(gè)復(fù)雜的生態(tài)系統(tǒng)。
其實(shí)我已經(jīng)把我對(duì)敏捷的總體理解描繪出來(lái)了?，F(xiàn)在我要介紹一些其他的敏捷社區(qū)，我只能浮光掠影的快速提一下，沒(méi)有深入挖掘。
既然要給出一些引用，有一個(gè)好主意就是把敏捷開發(fā)的資源列舉一下。非盈利網(wǎng)站 Agile Alliance 一直致力于敏捷開發(fā)的研究?？匆幌?/span>Alistair Cockburn 和Jim Highsmith的書。 Craig Larman's 的書里面提到了很多有用的迭代開發(fā)的歷史。要了解我對(duì)敏捷的看法那就關(guān)注一下我的articles 和 blog.
下面是一個(gè)不完全列表,它只是反應(yīng)了在過(guò)去的十年間敏捷開發(fā)的變化發(fā)展，里面的方法都對(duì)我曾經(jīng)有巨大的影響。
敏捷宣言
2001年初一群人聚在一起交流敏捷相關(guān)的話題，他們?cè)谌粘５墓ぷ髦卸家呀?jīng)進(jìn)行了大量的敏捷實(shí)踐，會(huì)議最后發(fā)布了一篇《敏捷宣言》Manifesto for Agile Software Development.
在此之前這個(gè)工作組就已經(jīng)提出一些軟件開發(fā)的觀點(diǎn)。多數(shù)觀點(diǎn)是來(lái)自面向?qū)ο笊鐓^(qū)，他們一直主張迭代式開發(fā)。2000年從寫這篇文章開始就試圖把各種過(guò)程攏在一起討論一下。那是這些方法還沒(méi)有一個(gè)通用的名字但是總是被描述為“輕量級(jí)”。很多人多這個(gè)名字不以為然，認(rèn)為它沒(méi)有完全表達(dá)出來(lái)這些方法的本質(zhì)。
2000年，這些方法被Kent Beck在俄勒岡的會(huì)議上廣泛提及。盡管這個(gè)工作組主要關(guān)注極限編程Extreme Programming (一個(gè)最吸引眼球的社區(qū)，很多非極限編程的人也參與進(jìn)來(lái)) 。當(dāng)時(shí)一個(gè)討論就是關(guān)于XP作為一個(gè)泛化的運(yùn)動(dòng)或者一個(gè)具體的運(yùn)動(dòng)，哪一個(gè)更好些。
如果沒(méi)有記錯(cuò)的話，這個(gè)工作組是由Jim Highsmith 和 Bob Martin組建的.他們把活躍在社區(qū)又有著相同觀點(diǎn)的人聚集在一起。初衷是把人們聚在一起能更好的交流各自對(duì)方法的理解。Robert Martin 想用一些簡(jiǎn)單語(yǔ)句把這些技術(shù)的共性整合出來(lái)，并給它一個(gè)名字，就是給那把“傘”一個(gè)名字。
在定名“敏捷”的過(guò)程中，敏捷宣言的部分內(nèi)容也相繼提出。一些基本的原則在工作組里面最初提出，后來(lái)在WIKI上得到后續(xù)的補(bǔ)充發(fā)展。
提出敏捷宣言的無(wú)疑需要極大的勇氣，我很驚訝敏捷宣言在內(nèi)容上的所達(dá)到的深度盡管敏捷宣言不是敏捷的嚴(yán)格定義，它還是可以幫助你抓住敏捷的核心思想。敏捷宣言提出之后不久， Jim Highsmith 和我寫了一些文章article for SD Magazine 來(lái)進(jìn)行進(jìn)一步闡述.
去年，敏捷宣言的十七位締造者的部分成員再聚首.當(dāng)時(shí)提出了一個(gè)建議：敏捷宣言的作者們應(yīng)該領(lǐng)導(dǎo)發(fā)起一些敏捷運(yùn)動(dòng)。而作者們一致的意見是是那些真正的敏捷實(shí)踐者創(chuàng)造了敏捷宣言。沒(méi)有一個(gè)小組可以成為整個(gè)敏捷社區(qū)的領(lǐng)袖。我們幫助船舶靠岸同時(shí)也時(shí)刻做好準(zhǔn)備有人把船開走，最終十七位敏捷宣言的締造者只是作為敏捷社區(qū)的普通成員默默做著貢獻(xiàn)。
之后這些作者又組織了“敏捷聯(lián)盟agile alliance.這是一個(gè)非盈利組織目的是進(jìn)行敏捷方法的推廣和研究。每年它都會(huì)出資在美國(guó)召開年會(huì)。
XP (Extreme Programming)
XP—極限編程是二十世紀(jì)九十年代年末開始最早流行起來(lái)的敏捷方法。XP太有名氣，在很多地方你無(wú)法繞過(guò)它.
XP最早發(fā)端于Smalltalk社區(qū), 二十世紀(jì)八十年代末開始和Kent Beck 、 Ward Cunningham 緊密合作.他們都在九十年代初期通過(guò)眾多的項(xiàng)目不斷的優(yōu)化自己的實(shí)踐。并得出軟件開發(fā)方法中適應(yīng)性和以人為本的重要理論成果。
Kent通過(guò)一些做項(xiàng)目顧問(wèn)期間不斷調(diào)研來(lái)發(fā)展上述的觀點(diǎn)。特別是在 Chrysler C3 project,項(xiàng)目中，這個(gè)項(xiàng)目作為極限編程的發(fā)源地而聲名遠(yuǎn)播。1997年左右他開始使用極限編程一詞。(C3 項(xiàng)目讓我和極限編程結(jié)緣，也讓我和Kent深厚友誼的開始。)
二十世紀(jì)晚期極限編程被廣泛傳播，最初是通過(guò)新聞組和Ward Cunningham's wiki, 在那里Kent 和 Ron Jeffries (C3項(xiàng)目的同事) 花費(fèi)很多時(shí)間來(lái)解釋概念以及跟各種思想做辯論。最后一批書籍在九十年代末出版對(duì)極限編程的一些細(xì)節(jié)進(jìn)行深入的探討。這類書籍多數(shù)以Kent Beck的 white book 為基礎(chǔ).2004年Kent出版了白皮書的第二版 second edition 重申了極限編程的重要思想。
XP有五種核心價(jià)值：溝通 反饋 簡(jiǎn)化 勇氣 尊重 (Communication, Feedback, Simplicity, Courage, and Respect). 這些價(jià)值通過(guò)十四條原則和二十四個(gè)典型實(shí)踐來(lái)解釋。觀點(diǎn)就是實(shí)踐是一個(gè)開發(fā)團(tuán)隊(duì)每天都要面對(duì)的事情。而五種價(jià)值是極限編程能實(shí)施的知識(shí)基礎(chǔ)和溝通基礎(chǔ)。五種核心價(jià)值是在實(shí)踐中體現(xiàn)出來(lái)，沒(méi)有實(shí)踐就無(wú)從談起。沒(méi)有價(jià)值目標(biāo)的實(shí)踐是生搬硬套邯鄲學(xué)步。五種核心價(jià)值和實(shí)踐相輔相成，而這中間有一個(gè)巨大的障礙，而敏捷的基本原則就是聯(lián)系二者的橋梁。許多XP的實(shí)踐都是實(shí)驗(yàn)性的，而最終被人遺忘。隨著這一技術(shù)的復(fù)興，XP浪潮推動(dòng)一個(gè)又一個(gè)的實(shí)踐以價(jià)值為導(dǎo)向互相推動(dòng)，互相影響。
最讓人記憶猶新的，也是最初吸引我的，就是對(duì)測(cè)試重要性的強(qiáng)調(diào)。雖然所有的過(guò)程都提到了測(cè)試但多數(shù)都是沒(méi)有太重視。而極限編程是把測(cè)試作為開發(fā)的基礎(chǔ)，每一個(gè)開發(fā)人員一邊寫代碼一邊寫測(cè)試。測(cè)試被放在持續(xù)集成中這樣就為未來(lái)的系統(tǒng)打造了一個(gè)穩(wěn)定的平臺(tái)。XP方法在這里常常被冠之以Test Driven Development (TDD) ，這種思想甚至影響了那些非極限編程的過(guò)程。
極限編程方面的出版物有很多，有一個(gè)混亂的地方就是白皮書第一版和第二版的變動(dòng)，上面已經(jīng)說(shuō)過(guò)了第二本從新的角度重新闡述極限編程。第一版影響深遠(yuǎn),當(dāng)你閱讀極限編程的資料時(shí)，特別是2005年出版的那些都是以第一版為藍(lán)本。事實(shí)上網(wǎng)絡(luò)上對(duì)極限編程的描述多數(shù)也是源于第一版。
second edition of the white book的出發(fā)點(diǎn)就是發(fā)現(xiàn)更多， 第二版用160頁(yè)的篇幅介紹了極限編程的背景和實(shí)踐。Kent Beck 在世紀(jì)之交為這一系列的書編輯了一個(gè)多色版本，如果只能挑選一本的話我選紫色的那本 purple one, 記住第一版是最經(jīng)典的。
多數(shù)資料都是以第一版為基礎(chǔ)，只有少數(shù)是以第二版為基礎(chǔ)例如： The New XP (PDF) by Michele Marchesi ，他是Sardinia敏捷會(huì)議的發(fā)起者.可以通過(guò) yahoo mailing list進(jìn)行極限編程的討論.
早期對(duì)XP社區(qū)的巨大熱情是源于對(duì)XP的喜愛(ài)。我認(rèn)為它巨大的影響力是因?yàn)樗v一些具體的技術(shù)和敏捷的方法的原則嫁接在一起。很多早期的敏捷文獻(xiàn)都忽略了這個(gè)問(wèn)題：敏捷真的是可行的么？ XP提供了一系列的工具將敏捷的希望成為現(xiàn)實(shí)。
Scrum
Scrum 也是八十年代、九十年代期間面向?qū)ο蠹夹g(shù)圈子里面很盛行的一種迭代開發(fā)方法。這種方法的佼佼者是Ken Schwaber, Jeff Sutherland, Mike Beedle.
Scrum 關(guān)注軟件開發(fā)的管理，將迭代切分成每30天的迭代 (稱作'sprints')；通過(guò)每天的SCRUM會(huì)議實(shí)施緊密監(jiān)控。它沒(méi)有像XP一樣特別強(qiáng)調(diào)人與實(shí)踐的緊密耦合關(guān)系，事實(shí)上XP的管理也的確與其截然不同。
Ken Schwaber 是支持Scrum的活躍分子，他的網(wǎng)站website 資源豐富，他的書 book 大多是第一手文獻(xiàn)。
Crystal
Alistair Cockburn 一直是敏捷社區(qū)重要的聲音。他設(shè)計(jì)的軟件開發(fā)方法水晶體系為不同規(guī)模的團(tuán)隊(duì)量身打造開發(fā)過(guò)程。 Crystal之所以被看作體系，是因?yàn)椴煌姆椒☉?yīng)用是根據(jù)團(tuán)隊(duì)規(guī)模和關(guān)鍵的變化嚴(yán)重程度決定的。
水晶方法中的變化點(diǎn)都具有一些共性，有三個(gè)比較明顯的：安全性（是否可以完成項(xiàng)目的目標(biāo)） ，效率 可用性（開發(fā)人員是不是適應(yīng)）。這些方法也有一些共性比較重要的三個(gè)是：頻繁移交，反饋改進(jìn)，緊密溝通。
可用性優(yōu)先是水晶思想體系的重要部分。 Alistair的目標(biāo)就是尋求一個(gè)可以完成目標(biāo)的最小過(guò)程：應(yīng)用最少的原則，足夠精簡(jiǎn)的人；結(jié)果就是Alistair認(rèn)為Crystal 比極限編程更關(guān)注特定場(chǎng)景下該方法是否適用，盡可能的減少失敗。
除了 Crystal原則本身，還沒(méi)有比較詳細(xì)的闡述，最著名的文章是Crystal Clear, wiki 上也有進(jìn)一步討論Crystal的資料。
Context Driven Testing
從一開始就是軟件開發(fā)者推動(dòng)著敏捷社區(qū)的發(fā)展，而軟件開發(fā)過(guò)程中的其他人也受到這個(gè)運(yùn)動(dòng)的影響。最明顯的是測(cè)試人員，他們更傾向于使用瀑布模型的思維方式。通常測(cè)試的工作就是驗(yàn)證軟件是不是和規(guī)格說(shuō)明書一致，而在敏捷開發(fā)中測(cè)試人員的角色就沒(méi)有這么清晰了。
結(jié)果是一些測(cè)試社區(qū)的人開始質(zhì)疑主流的測(cè)試思想。后來(lái)組成了一個(gè)名叫context-driven testing的小組.關(guān)于這個(gè)觀點(diǎn)最好的詮釋是在Lessons Learned in Software Testing .這個(gè)社區(qū)在網(wǎng)絡(luò)上也是相當(dāng)活躍，可以看一下 Brian Marick 的網(wǎng)站(敏捷宣言的提出者之一),還有 Brett Pettichord, James Bach, Cem Kaner.
Lean Development
我還記得數(shù)年前敏捷大會(huì)上跟一位女士講敏捷思想和制造業(yè)的精益生產(chǎn)運(yùn)動(dòng)的情形。Mary Poppendieck (and husband Tom)這位敏捷社區(qū)的積極支持者, 主要關(guān)注“工作反復(fù)問(wèn)題”，以及精益生產(chǎn)和軟件開發(fā)如何互相取長(zhǎng)補(bǔ)短。
Taiichi Ohno在豐田倡導(dǎo)的精益生產(chǎn)運(yùn)動(dòng)常備稱作豐田生產(chǎn)體系。精益生產(chǎn)觀點(diǎn)被很多早期敏捷主義者接受， Poppendiecks 關(guān)于這些觀點(diǎn)影響的文章最為著名。工程學(xué)上將設(shè)計(jì)和實(shí)施割裂開，因此大體上我對(duì)這種類比推論表示擔(dān)憂，但是精益研究方向還是有一些很有趣的觀點(diǎn)的。Poppendiecks的 book and website 是一個(gè)很好的切入點(diǎn).
(Rational) Unified Process
面向?qū)ο笊鐓^(qū)另外一個(gè)著名的過(guò)程就是Rational Unified Process (sometimes just referred to as the Unified Process). 這種思想是源于UML，認(rèn)為UML可以統(tǒng)領(lǐng)整個(gè)過(guò)程。由于 RUP 與敏捷同時(shí)出現(xiàn)所以兩者是否一致的討論就一直不斷。
RUP是由一系列大規(guī)模的實(shí)踐構(gòu)成，與其說(shuō)是過(guò)程，不如說(shuō)是框架。它不是為軟件開發(fā)提供一個(gè)過(guò)程，而是擺出一堆通用的過(guò)程讓你根據(jù)自己的項(xiàng)目來(lái)選擇。所以團(tuán)隊(duì)要使用RUP首先要做的就是定義自己的過(guò)程，或者用RUP的專業(yè)詞匯--開發(fā)用例。
RUP的要點(diǎn)就是用例驅(qū)動(dòng)（開發(fā)是由一個(gè)個(gè)用戶可以看到的功能點(diǎn)驅(qū)動(dòng)的），迭代,架構(gòu)為核心(較早的進(jìn)行一個(gè)架構(gòu)設(shè)計(jì)然后貫穿項(xiàng)目始終)。
我自己的RUP應(yīng)用經(jīng)歷就是它無(wú)窮的變化. 我發(fā)現(xiàn)RUP應(yīng)用的描述已經(jīng)從嚴(yán)格不變的瀑布式開發(fā)過(guò)渡到敏捷。RUP在市場(chǎng)上呼聲很高，仿佛是無(wú)所不能的。
盡管RUP社區(qū)臥虎藏龍，我還是推薦一下： Phillippe Kruchten and his book 這是RUP的起點(diǎn). Craig Larman 也在他關(guān)于面向?qū)ο蟮男伦骼锩娼榻B了RUP的敏捷方式introductory book .
你也要敏捷么?
敏捷并不適合每一個(gè)人，要走這條路有些問(wèn)題必須考慮。我同時(shí)又堅(jiān)信方法論會(huì)有廣泛的適用性，會(huì)被更多的人應(yīng)用到實(shí)踐中。
當(dāng)前的形勢(shì)是，好多方法論還是停留在Code&Fix階段。應(yīng)用一些規(guī)則會(huì)使混亂狀態(tài)有所改觀，敏捷方法的優(yōu)勢(shì)就是比那些重量級(jí)的方法使用更少的步驟。輕量級(jí)是敏捷的最大優(yōu)勢(shì)，簡(jiǎn)單的過(guò)程更容易遵循，過(guò)程也總是聊勝于無(wú)。
對(duì)于敏捷的新手，問(wèn)題就是從哪里開始。無(wú)論是使用新的技術(shù)還是新的過(guò)程，你都要做出變革。你要看它是不是適用于你的環(huán)境，我的建議和對(duì)其他新方法的建議一樣：想想當(dāng)時(shí)我們是怎么接受面對(duì)對(duì)象技術(shù)的.
第一步是找到合適的項(xiàng)目進(jìn)行敏捷實(shí)踐。由于敏捷是以人為本的所以首先你要組建一個(gè)愿意進(jìn)行敏捷開發(fā)的團(tuán)隊(duì)。不情愿的被拉入開發(fā)隊(duì)伍不僅工作難以順利進(jìn)行，而且在敏捷方法中這直接關(guān)乎開發(fā)成敗。.
還有就是你是不是有合適的用戶，他也同意使用敏捷的方式與你合作。如果用戶不合作，你不可能將適應(yīng)性過(guò)程的優(yōu)勢(shì)發(fā)揮到極致。說(shuō)到這里我的確發(fā)現(xiàn)有些用戶不愿進(jìn)行敏捷合作，但是當(dāng)他們理解了敏捷方法之后他們就改變主意了。
有些人聲稱敏捷方法不適用于大型項(xiàng)目，我們 (ThoughtWorks)就成功的成功的完成了數(shù)個(gè)敏捷項(xiàng)目，每個(gè)項(xiàng)目都在百人左右。盡管如此我還是建議你從一些小項(xiàng)目開始嘗試。大項(xiàng)目天生就很難把握，比較適用的就是那些在可控范圍內(nèi)的項(xiàng)目。
有人建議用一些商業(yè)影響較小的項(xiàng)目進(jìn)行實(shí)踐，即使錯(cuò)了也沒(méi)有太大的損失。然而一個(gè)無(wú)關(guān)緊要的項(xiàng)目一般測(cè)試要求也比較低，大家都不太關(guān)心結(jié)果怎樣。我還是建議大家找個(gè)有點(diǎn)風(fēng)險(xiǎn)的項(xiàng)目試一下。
當(dāng)然最重要的事情就是你能找到一些有敏捷經(jīng)驗(yàn)的人指導(dǎo)一下。一個(gè)嘗試新東西難免會(huì)犯錯(cuò)，找到那些已經(jīng)犯過(guò)很多錯(cuò)誤的前輩你可以少走很多彎路。當(dāng)你開始接觸一門新技術(shù)，一位良師益友價(jià)值千金。在ThoughtWorks很多朋友都是敏捷開發(fā)領(lǐng)域做培訓(xùn)的，所以我們可以自給自足。這也絲毫沒(méi)有改變我的看法:找一個(gè)良師益友。
一旦你找到了，聽聽他的建議。但是這里會(huì)出現(xiàn)一個(gè)狀況就是：言聽計(jì)從；我的經(jīng)驗(yàn)是很多技術(shù)沒(méi)有真正的實(shí)踐一下很難說(shuō)已經(jīng)理解深刻了。最好的一個(gè)例子就是我們的一個(gè)客戶要用兩個(gè)月的時(shí)間進(jìn)行極限編程的試驗(yàn)。在那個(gè)期間他們完全按照老師說(shuō)的做，即使他們認(rèn)為那是一個(gè)很糟糕的主意。試驗(yàn)期的最后他們停下來(lái)了，他們覺(jué)得還是用原來(lái)的老路子吧。
一個(gè)開放性的問(wèn)題是敏捷方法的邊界在哪里？很多新技術(shù)在開始你都難以摸清它們的邊界，直到有一天你使用它們的時(shí)候失敗了。敏捷方法還太年輕，還沒(méi)有足夠的應(yīng)用來(lái)給它劃定一個(gè)界限。這就像很難判定一個(gè)軟件開發(fā)過(guò)程哪些方法是成功哪些是失敗的一樣，千頭萬(wàn)緒，不一而足，難下定論。
這樣看你是不是要用敏捷方法呢？我像這會(huì)讓很多人為難，如果你的團(tuán)隊(duì)成員沒(méi)有緊密合作的強(qiáng)烈要求，那么這件事情就會(huì)阻力重重。永遠(yuǎn)不要在一個(gè)拒絕敏捷方法的團(tuán)隊(duì)嘗試敏捷實(shí)踐，經(jīng)驗(yàn)之談。
過(guò)去十年間，敏捷實(shí)踐一直進(jìn)行著，在 ThoughtWorks 如果客戶同意我們一直使用敏捷方法，大多數(shù)的時(shí)候他們會(huì)同意的。我或者說(shuō)我們對(duì)這種工作方式一直充滿興趣！
本文的重要修正：
13 Dec 05: General overhaul of the paper. Changed list of methodologies to a survey of flavors of agile.
April 2003: Revised several sections. Added section on difficulty of measurement and context driven testing.
June 2002: Updated references
November 2001: Updated some recent references
March 2001: Updated to reflect the appearance of the Agile Alliance
November 2000: Updated section on ASD and added sections on DSDM and RUP
December 2000: Abridged version published in Software Development magazine under the title of "Put Your Process on a Diet"
July 2000: Original Publication on martinfowler.com
