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