不可不讀 靈活經典--《新方法論》

新方法論[中文版]

The New Methodology

                                                        作者：Martin Fowler      翻譯：堅強2002

                                                               源文檔 <http://www.martinfowler.com/articles/newMethodology.html>

過去的幾年中，靈活開發蓬勃發展，靈活方法被當作修正機構結構僵化的一劑良藥抑或是打通軟體過程奇經八脈的不二法門。本文我将探索靈活方法的源頭，不是強調它何等重要而是要把關注點放在它的适應性和以人為本這兩個方面。

Contents

·         無章法 裡程碑 靈活

·         可預見性VS 适應性

o    泾渭分明的設計與實施

o    需求的不可預見性

o    可預見性不可能做到嗎?

o    控制不可預見的過程—疊代

o    适應性的客戶

·         以人為本

o    人件

o    程式員：重任在肩

o    管理以人為本的過程

o    度量之難

o    業務上司者的角色

·         自适應過程

·         靈活開發的特點

o    靈活宣言

o    XP (極限程式設計)

o    Scrum

o    Crystal

o    Context Driven Testing

o    Lean Development

o    (Rational) Unified Process

·         你也要靈活麼?

相關文獻

·         Is Design Dead?

·         The New Methodology (Original)

過去幾年中軟體過程思想領域最引人注目的變化恐怕就是“靈活”一詞的出現了。我們讨論過靈活方法在軟體開發的應用，如何把靈活引入開發團隊中，也讨論了如何防止那些激進的靈活主義者對一個良好的開發實踐躍躍欲試的“變革”。

這一軟體過程領域的新運動得益于二十世紀九十年代軟體過程領域各式各樣人們的努力，基于自身的願景，他們要探求軟體過程的新道路；這是提出的觀點并不新奇，事實上很多人都堅信多數成功的軟體都是采用了那些被用過多年的方法。不幸的是由于沒有受到足夠的重視，特别是沒有專業人士的認可，這些觀點胎死腹中不了了之。

本文也是那次運動緣起的一部分，最初發表于2000年七月，正如我一貫的行文風格，我寫這篇文章試圖深刻了解“靈活”；從1996年起我有幸和Kent Beck, Ron Jeffries, Don Wells以及其他Chrysler C3的團隊成員合作，使用極限程式設計的方法，寫文章時已經有了數年的實踐經驗。

我嘗試和有相似觀點的人談話、閱讀他們的作品，我覺得隻是從極限程式設計的角度來探讨靈活是不夠的。是以本文我将細數諸多靈活實踐方法的異同。

本文的初版:

The New Methodology (Original)

那時我的觀點也是我一直的觀點就是：一些基本原則構成了這一新方法論，而這些原則與之前已有的原則截然不同；

本文一直是我的網站上最受歡迎的文章之一，這也意味着我有義務不斷的更新它的内容。本文的初版探尋了新舊原則間的不同并通過一個靈活方法的調查來深入的了解它。時過境遷調查中涉及的靈活開發的内容已經發生了變化，但是新舊差異依然存在，我們将繼續讨論下去，回頭再說，現在開始…

無章法，繁重，靈活

    多數的軟體開發都是一個混亂無序的活動，常常就簡單的劃分成“CODE&FIX”兩個階段，這就是它的特點。軟體的編寫沒有一個指導性的計劃，系統的設計是由一系列短期的決定構成的。當系統規模小的時候這個方法還真的表現不錯，但是随着系統規模變大新功能的開發日益艱難。雪上加霜的是這時BUG也無處不在而且難以修改；這種系統的典型特征就是在做到"feature complete" 之後将有一個漫長的測試階段，這個階段将把時間計劃完全打亂，因為測試和調試的時間難以預計；

解決上述問題，這就是引入軟體過程方法論的初衷。方法論将一些嚴格的過程應用到軟體開發活動，目的就是提高軟體開發的可預見性和效率；他們是怎麼做的呢？他們把其他工程學的原理引入進來強調計劃的重要性，通過一個詳細的計劃來解決問題。是以這時的方法又稱計劃驅動的方法。

工程方法學存在了很長時間，但是并沒有取得顯著的成功。它們甚至沒有流傳開，最為人诟病的是它太官僚主義了。采用該方法要照顧太多的瑣碎的事情，這讓整個開發節奏慢了下來。

背負着力挽狂瀾的期望，“

靈活方法”

應時而生。對于大多數人來講，靈活方法最大的吸引力就是它能解決工程方法論的官僚主義問題。這個方法論試圖給出一個介于“無過程”和“過度過程”之間的折衷方案，使用一個适中的過程來獲得合理的收益（成本和收益的一個平衡）。

之是以能做到這一點，是因為靈活方法與之前工程方法論強調的那些觀點有着顯著的不同。

最直接的不同點就是它不是文檔驅動的，通常對于給定的任務隻需要較少的文檔就可以了。它倒是有點像是代碼驅動的，遵循着一個規則就是把源代碼作為文檔的一部分。

但我不認為這是靈活開發的關鍵，文檔的精簡隻是一個表象，背後有兩個深層次的原因：

·         靈活方法是适應性的，而不是可預見性的；工程方法論嘗試用較長的時間把軟體開發的絕大部分做到計劃裡面，在事情沒有變化的時候這個方法表現不錯。是以本質上它是拒絕變化的，而靈活方法恰恰是歡迎變化的，它強調在變化中适應和成長.

·         靈活方法是以人為本的而不強調過程的重要性。工程學方法論是想定義一個放之四海皆準的過程，無論誰用都可以。靈活方法斷言沒有什麼過程會提高開發團隊的技能，過程的角色就是在開發團隊的工作中提供支援。

下面的環節我們将從更多的細節來探讨這些不同，這樣你就能了解到底什麼是适應性、以人為本的過程，它的優勢與劣勢，以及最關鍵的一個問題：無論你是一個開發者還是軟體使用者,靈活是不是你需要的。

可預見性VS适應性 泾渭分明的設計與實施

軟體過程通常引入的方法論原則是源于土木工程學或者機械工程學。而這些原則強調建造之前的計劃。工程師會提供一系列的圖紙精确的描述要建造什麼已經怎麼把建造的東西進行組合。許多設計上的決定，比如橋梁負載，在設計圖紙的時候就已經确定了。之後圖紙移交給另外一個小組甚至是另外一個公司來施工。整個的實施工程是嚴格按照圖紙進行的。實施過程中會遇到一些問題，但多數是無關痛癢的小問題。

由于圖紙已經明确說明了各個小塊的内容以及怎麼組合，它們的功能就像是一個細化的實施方案，它指出要做完成什麼任務，以及這些任務之間的依賴關系。這就可以進行進度預計和工程預算。圖紙甚至包括人們具體怎麼實施工程，這樣實施工程的一方不需要太智能，盡管他們往往技術高超。

是以我們這裡看到的是兩個截然不同的活動。設計很難做出預計，需要大量的有創造性的人參與，而實施是很容易預計的。一旦完成了設計就可以制定實施計劃，有了計劃我們就可以對實施過程進行預計和控制。在土木工程中，實施比設計和計劃的成本消耗時間消耗都要大。

脫胎于上述理論的軟體工程學方法論也就變成了這樣：我們需要一個可預見的計劃，用技能比較低的人就可以完成它。要做到這一點我們就必須把設計和實施分離開，是以一個出現了：我們必須知道怎樣做軟體設計才能讓實施工作在設計之後一馬平川的進行下去。

這個計劃是什麼樣的呢？很多時候它的角色就是UML中的設計符号。如果我們可以使用UML來做所有的重要的決定，我們就可以建構出來一個實施計劃并把這個計劃移交給開發組進行編碼。但這個有一個關鍵問題，你能用設計把編碼變成一個可預見的實施活動麼？如果可以的話，消耗的成本是在一個可接受的範圍内麼？

這些引出來一些新問題，首先怎樣把UML式的設計轉化到程式員可以接受的狀态。UML式的設計有一個特點就是紙上看起來很不錯，但是到編碼實踐的時候嚴重的錯誤就會凸顯出來。

土木工程學的模型都是基于多年工程的實踐總結，佐之以強制執行，加之精确的數學分析。而UML式的設計隻能依賴同僚評審，這樣就造成一些錯誤隻有在編碼和測試階段才浮出水面。甚至對于一些高水準的設計人員也會認為把設計變成軟體是一件很神奇的事情。

另外一個問題就是平衡支出，建一座橋的設計費用大約是總支出的10%，剩下的實施費用。在軟體開發中編碼占用的時間遠遠小于這個比例； McConnell 指出對于一個大型的項目隻有15%的時間來做編碼和單元測試，這幾乎和建橋的比例完全相反的。即使你把測試也作為實施的一部分設計依然保持50%的比例。這就點出了軟體開發中的設計與它在其它工程學分支中的角色迥異不同！

這些問題讓 Jack Reeves甚至得出這樣的結論：事實上源代碼就是設計文檔而實施階段就是使用編譯器和連接配接器。當然這時所有的實施階段就可以完全可以也應該自動化完成。

這種看法可以得出下面的結論：

·         軟體開發中: 實施是很便宜的甚至是免費的

·         在軟體開發中所有的努力都在設計上，因而需要有創造性和才華的人

·         創造性的過程很難計劃，是以可預計性幾乎是一個不可能完成的任務

·         我們要意識到軟體工程學與傳統工程學的差別，這是一個完全不同的活動，需要一不同的過程。

需求的不可預見性

每一個我參加的項目我都會聽到這樣的小插曲，開發人員告訴我“項目最大的問題就是需求總是變化”，讓我感到驚異的是任何人對此都表示不适應；在開發商業軟體的過程中，變更是正常的，問題是我們如何面對它。

一種方式是把需求變更的原因歸結為糟糕的需求分析。這種觀點的隐含意思是需求分析要在編碼開始之前對需求有一個全面的了解，然後使用者簽字，簽字之後啟動開發過程并盡量不做變更。這裡有一個問題那就是充分了解需求是很難的一件事情，而無法對需求的成本進行評估是這件事情更加難上加難。比如你要給你的車添加一個遮陽篷，而銷售人員無法告訴你要添加10美元還是100美元。不知道花多少錢你怎麼判斷是不是要買？

衆多因素導緻估計很難做到，因素之一是軟體開發是一個設計活動難以計劃和估計；因素之二：基本資源一直變化難以估計；因素之三：估計取決于過程中的人，人是很難進行預計和量化分析的。

軟體是沒有物質實體的，在它沒有做出來之前你很難看到它的位置。直到你用的時候你才知道那些功能點是有價值的哪些是沒有價值的。這就要求人們應該認為軟體需求是可以變化的，軟體就是應該是“軟”的。需求不僅僅是可變，而且是應該變；花費大量精力來跟客戶确定需求，特别是客戶也曾經涉足軟體開發那就更糟了，因為他們知道軟體變一下很容易；

即使能得到一個精确的穩定的需求，你依然難逃厄運。今天的經濟形勢就決定了軟體的内容快速變化。今天的好需求，六個月之後就可能一文不值；即使需求不斷的改進也是跟不上經濟發展的步伐；經濟是無法預言的，否定這個觀點的人要麼是撒謊要麼是有足夠的實力可以左右市場；軟體開發中的其他事情都取決于需求，你得不到一個穩定的需求，你也得不到一個可預見的計劃。

可預見性不可能做到嗎?

總體上講，不是的；有些軟體開發是可以做到可預見的。像NASA太空穿梭機軟體開發就是軟體可預見性的樣闆。這個需要大量環節，大量時間，一個大型的團隊，一個穩定的需求。但是我不認為多數的商業軟體和太空穿梭機軟體屬于統一範疇。是以需要有一個不同的開發過程。

存在一個危險就是做不到可預言的時候“做可預言狀”；研究方法論的人不善于識别邊界條件：

在那個點上方法從合适變成不合适；絕大多數的方法論者都希望自己的理論放之四海皆準，是以他們也不願意公開這個邊界。這就導緻了方法論誤用的事情，比如把可預見的方法用在了不可預見的環境中。

那樣做是很有誘惑性的； 可預見性是令人向往的，當你明明知其不可為而為之的時候，這就會導緻人們早早的做了計劃，之後局面慢慢失控；你發現計劃與現實相去甚遠，你可以在一個較長的時間内依然裝作計劃是有效的；但有時候兩者過于不符，就不能視而不見了，失敗總是痛苦的。

是以如果你在一個不可預見的環境中就不要使用可預見的方法論。那需要多個項目控制模型，多個客戶關系模型，這最終還解決不了問題，真的很殘酷。可預見性很美好，但是太難實踐了。就像大多數問題一樣，最重要的是意識到問題的存在！

不依賴可預見性并不是說你要應付一堆不可控的、混亂的事情。相反你需要一個過程可以應對不可預見性。這就是适應性所關心的。

控制不可預見的過程—疊代

在不可預見的世界裡我們如何自處？最重要的也是最難的就是清楚地知道我們的位置！我們需要一個誠實的回報機制可以頻繁的告訴我們目前的位置。

得到這種回報的方法就是：疊代開發！這不是什麼新主意。疊代開發有一大堆相關的關鍵詞：增量開發，漸進式開發，螺旋…. 疊代開發的關鍵就是不斷的有可用的新版本的系統出來，它可以是最終系統的功能子集；這些可用的系統在功能上不完善，但是已經做出來的是滿足需求的。在最傳遞之前需要做細緻的內建測試。

這個的意義就在于沒有什麼比一個測試過，內建的系統更逼近真實的需求；文檔可能隐藏缺陷，未測試的代碼可能有很多隐患，當時當人們做到電腦前用一下的時候，問題就昭然了：無論是系統Bug還是誤解需求問題一下子浮出水面。

疊代式開發對于可以預見的過程同樣是有效的。隻不過在不可預見的環境中它是必要的，因為這時要應對變化。長期的計劃通常是不穩定的，單次疊代的短期計劃是穩定的。疊代開發都是基于上次疊代的結果，有一個堅實的基礎。

一個問題就是疊代的周期應該多長。不同的人有不同的答案。XP 建議是一到兩周。SCRUM 建議一個月左右。Crystal 可能更長一點. 有一個趨勢就是每一次疊代盡量的短，這樣可以頻繁的接受到回報，明确自己目前的位置。

适應性的客戶

适應性的過程需要與客戶建立不同以往的關系，特别是開發過程是由單獨的一個公司來做的時候。當你雇用一個單獨的公司來做開發許多客戶會傾向于選擇定價合同。告知開發者需求是什麼然後投标，接标，開發團隊的義務就是把軟體開發出來。一個定價的合同需要有一個穩定的需求一個可預見的過程。适應性的過程和不穩定的需求意味着不能進行在正常概念下的定價開發。把定價開發的模型放到适應性過程中，最終會以痛苦的爆發結束。爆發的結果就是開發方和客戶兩敗俱傷。畢竟客戶要的是他們業務需要的東西，如果不能滿足這個目标那麼即使不付給開發方一分錢他們還是受損失了。事實上這時損失比軟體做成功要付的錢還要多，因為客戶付錢做軟體是要用軟體赢利的。

這樣定價開發在一個非可預計環境中應用對于雙方都是有風險的。這意味着客戶要做出變化！

不是說你無法進行開發的前期預算，隻是說你不能定死時間、價格、範圍。正常的靈活方法是定下來時間和價格，允許範圍做可控的變化。

在适應性的過程中客戶可以做更多細粒度的控制。每一次疊代都可以做結果檢驗并糾正開發方向。這就拉近了客戶和開發者的關系，真正的合作關系。這種級别的契約并不是适合每一種客戶，也不是适合每一個開發團隊，重要的是能讓适應性的過程順利的跑起來。

所有這些都會給客戶帶來很多好處。首先是他們得到了更多關于軟體開發情況的資訊回報。一個可用的系統，盡管可能很小，但是可以盡早的投入生産。客戶可以根據業務的變化來提出一些變更，同時也可以知道這個軟體在真實環境中的運作情況。

這個過程中每一小塊功能都可以看出項目進行真實狀态。而預見性過程要通過檢驗和計劃是否一緻來驗證。這樣就很難發現開發上是不是已經背離了計劃。通常的結果就算是在項目的後期會有一個較明顯的脫軌情況。靈活開發中每一次疊代都有一個持續修正計劃的過程。如果壞兆頭能早日顯露出來，那麼我們就還有時間來做出應對。風險控制是疊代開發的關鍵優勢！

靈活方法通過保持短期疊代，将這一優勢更加凸顯出來，能夠通過各種不同的途徑把變更看出來。Mary Poppendieck 在她的文章"A late change in requirements is a competitive advantage".裡面幫我總結了各種不同的觀點。我相信好多人都已經注意到使用者自己在開始的時候都很難描述清楚他們想要什麼。我們發現使用者都是在判斷什麼是有用什麼是沒用的過程中不斷的了解到自己的需要。通常最有價值的功能點開始的時候并不是很明顯，直到客戶開始有機會對軟體提出改變。靈活方法就是要尋求這方面的優勢。鼓勵客戶通過在系統建構的過程中不斷搞清自己的需求，通過快速的整合變更來進一步建構新系統。

See Related Article:

Is Design Dead?

上述提出的内容都是承擔着保證項目成功的重任。通過考察一個可預見的項目的計劃就可以判斷它是否成功。在既定時間和支出限制先完成的項目是成功的。這種度量方式對于靈活開發的環境是沒有意義的。對于靈活開發者這些問題直指商業價值—客戶從軟體中得到的價值比做軟體的成本要多。一個好的可預見項目會按計劃進行，一個好的靈活開發項目的會和最初的計劃不同并優于最初目标。

以人為本

執行一個适應性過程是不容易的。特别是它要求有一個非常高效的開發團隊。團隊不僅要求每一個都很強，隊伍組合起來的力量也要求很強。這裡有一個有趣的協作：不僅是适應性項目需要一個強大的團隊，很多優秀的開發者都喜歡适應性的開發過程。

人件

傳統方法論中的開發過程中，其中一個目标就是把人作為一個可替換的部分。成功的過程可以把人當作各式各樣無差别的資源來對待。你們有分析師，程式員，測試人員，和項目經理。個體不重要，重要的是他的角色。你要做一個項目計劃，設計師和測試人員是誰并不重要，重要的是他們的數量是多少。

但這就引出了一個關鍵問題：軟體開發過程中，人是可以随意替換的部分麼？而靈活開發是拒絕這種假設的。當然明确提出人不是資源的是Alistair Cockburn. 他的文章 Characterizing People as Non-Linear, First-Order Components in Software Development,指出可預見過程需要各種元件的行為都是可以預見的。但是人不屬于可預見的元件。而進一步的研究結果表明：人是軟體開發中的最重要元素。

在他的文章中把人也當作元件，這就是人在過程和方法論中的位置。這種看法的錯誤就是人是會經常變化的，是非線性的。有着獨一無二的成功和失敗狀态或者說是模式。這些是必須首先考慮的，是不能忽略的。我們可以看到過程或者方法論設計者的失敗往往是由于忽略了人的因素。

-- [Cockburn non-linear]

我們懷疑就這一方面軟體開發是不是違反人的本性，當我們用計算機程式設計的時候我們在控制一個可預見的裝置。我們在茫茫人海中找到自己的位置去做一件工作，是因為我們擅長做它。

盡管 Cockburn最明确的表達了軟體開發中以人為本的思想，其實這個是很多軟體開發思想家的共識。問題在于，多數時候方法論并不沒有把人看作是影響項目成功的首要因素。

如果你期望你的開發者是無差别的插件，你就不能把他們看成一個個的個體。這會降低士氣和生産力。最合适的人用在最合适的位置，這就是你想要的：人件！

把人放在第一位是一個重大的抉擇，需要一系列的決策來輔助推動！把人當作資源在商業領域是根深蒂固的，它源于Frederick Taylor's 科學管理論. 運作一個工廠, Taylorist 方法是有意義的。但是對于高創造性和專業的工作，比如軟體開發，這個理論就不合适了，而事實上制造也也逐漸從Taylorist模型中脫離出來。

程式員：重任在肩

Taylorist理論的一個重點就是： 做工作的人不是那些知道怎樣能把工作做到最好的人。在工廠裡面由于諸多原因這或許是對的。部分原因是多數勞工并不是很有才能、有創造性的，還有一個原因是管理者和勞工收入差距造成的緊張關系。

最近的曆史漸漸告訴我們在軟體開發領域這是不對的，越來越多的聰明而能幹的人被吸引到這個光華奪目前景光明的領域。 (這也是我離開電子工程學的原因。)盡管經曆了世紀初的低迷，軟體開發行業依然聚集了大量精英才俊。

(有一個很有意思的換代現象，有些有趣的現象讓我好奇在過去十五年是不是越來越多的聰明人進入這一領域。而每一次換代都會有一些代表性的變革.)

你想要雇用或者留住優秀的人，你就必須意識到他們是專業才幹，他們是最适合管理自己技術工作的人。Taylorist觀念是将計劃抽離出來，這種觀念起作用除非是計劃者比做這件事情的人更精于業務！如果你有聰明主動的人做事情，那麼這個理論就不是很有效了。

管理以人為本的過程

以人為本在靈活過程中有一些特有的表現，這些表現也會導緻不同的效果。并不是所有的效果都是一緻的。

相比較而言，接受這個過程比應用這個過程更重要。通常軟體過程都是管理者要求強制執行的。而多數情況下是推行不利的，特别是管理者有相當長的時間離開開發活動的時候。接受一個過程需要責任委托，這需要全體團隊成員的成員。

這樣會有一個有趣的結果：隻有開發人員自己可以選擇一個适應性的過程。特别是極限程式設計的實踐中尤其如此，它需要許多可執行的原則。相比起來Crystal要求的原則比較少，因而閱聽人較多一些。

另一個觀點就是開發者能夠做所有的技術決策。XP深得要領在其計劃過程中隻有開發者能估計一個工作所需的時間。

這種技術上司權的分離是管理層的一個重大變革，這樣就要求開發者和管理者責任共擔，處于相當的位置。注意我說的是相當，管理者依然是管理者，隻不過把開發者的專業能力重視起來。

在工業領域這一變化的重要原因是技術在生産中的比重日益增加。過不了幾年技術知識就會落伍。技術是工業領域的生命線，很多進入管理層的人會發現他們的技術能力日益萎縮。開發者會意識到他們的技術能力會漸漸消失而必須信賴新一代的開發者。

度量之難

如果在一個過程中，一個人指責另外一個人沒有按照合理的方式做一件事情。上司就需要有一些方法進行判斷誰對誰錯，雖然科學的管理推動了對人們勞動成果進行客觀評價，這件事仍然比較困難。

對于軟體的度量更是如此，即使你全力以赴，軟體開發中一些很小的事情你都難以度量，比如生産力。沒有一個好的評判方法怎麼進行相關的管理控制呢？就像說不能超标，而标準卻晦暗不明。

引入度量管理而沒有好的度量方法會帶來很多問題。Robert Austin 做過這方面的讨論.他指出要做度量你就要把所有的重要因素都納入到度量體系之中。任何漏掉的因素都會不可避免的影響度量體系的功用，沒有達到預期的效果。度量體系不利是基于度量進行管理的命門所在。

Austin 的結論是必須要在基于度量的管理和開發者自我管理之間做一個選擇。前者适合那種重複性的工作場合，不需要太多的知識技能而産出又容易量化—這都是和軟體開發背道而馳的。

這一傳統方法的核心在于所有的運作都是基于一個假設：基于度量的管理是最有效的管理；而靈活組織認為這種特征的開發活動往往障礙不斷。靈活主義者認為這時委托式（開發者自我管理）的管理更有效果。

業務上司者的角色

繼續上面的話題，技術人員是不可能自己完成過程中所有事情的。他們需要業務需求的向導。這就引出來适應性過程的另外一個重要方面：開發人員要和業務專家緊密合作。

這就超出了多數項目中業務角色的範疇，靈活團隊需要的不是臨時溝通而是需要與業務專家持續的溝通。此外這是開發者每天都要面對的，不是管理級别的一個事情。由于開發者在他們的領域内有自己的原則，他們所要做的就是與其他領域的專家協同合作。

上面說的大部分都是适應性過程自身固有的特性。由于适應性過程意味着事情會迅速的發生變化，因而你要不斷的和業務專家進行需求确認。

最讓開發者惱火的是讓他們做無用功。業務專家要保證自己的工作品質來讓開發者信賴自己！

自适應過程

我已經講了很多關于軟體項目适應性的話題，如何不斷的調整軟體來滿足客戶需求。然而還沒有完，還有另外一個角度可以看适應性：過程本身也在不斷的變化。一個項目使用的适應性過程和一年前的适應性過程不會相同。開發團隊經常做的就是找到以前的一個适用的過程，然後修改一下開始使用。

自适應的第一步就是正常的回顧已有過程。通常每一次疊代都要做這件事情。每一次疊代之後的短會上可以問自己幾個問題： (摘自Norm Kerth )

·         我們哪裡做好了？What did we do well?

·         我們學到了什麼？What have we learned?

·         我們怎樣做到更好？What can we do better?

·         什麼讓我們困惑不解？What puzzles us?

這些問題可以引導你思考如何對下一次的疊代過程進行改進。這樣的話問題随着項目進行逐漸解決掉，過程與團隊之間配合就更加融洽。

如果自适應出現在項目中，在組織形式上會有所展現。一個自适應相關的結論就是不要相信一個方法論就可以一勞永逸的解決問題。每一個團隊都應該選擇自己的過程，并且随着項目進行不斷的協調。其他項目過程的經驗作用就是用來吸納，估計底線，開發者的責任就是根據手頭的任務調整過程。

靈活開發的特點

靈活是軟體開發的原理之一，在這個大的概念之下有很多具體的方法比如： Extreme Programming, Scrum, Lean Development, etc. 每一種具體的的方法都有自己的思想 社群和和上司者；每一個社群各有特色但是都遵循一些共同的基本原則。社群之間也互相學習，很多參與者也都在混迹于不同的社群之間，總而言之，這是一個複雜的生态系統。

其實我已經把我對靈活的總體了解描繪出來了。現在我要介紹一些其他的靈活社群，我隻能浮光掠影的快速提一下，沒有深入挖掘。

既然要給出一些引用，有一個好主意就是把靈活開發的資源列舉一下。非盈利網站 Agile Alliance 一直緻力于靈活開發的研究。看一下Alistair Cockburn 和Jim Highsmith的書。 Craig Larman's 的書裡面提到了很多有用的疊代開發的曆史。要了解我對靈活的看法那就關注一下我的articles 和 blog.

下面是一個不完全清單,它隻是反應了在過去的十年間靈活開發的變化發展，裡面的方法都對我曾經有巨大的影響。

靈活宣言

2001年初一群人聚在一起交流靈活相關的話題，他們在日常的工作中都已經進行了大量的靈活實踐，會議最後釋出了一篇《靈活宣言》Manifesto for Agile Software Development.

在此之前這個工作組就已經提出一些軟體開發的觀點。多數觀點是來自面向對象社群，他們一直主張疊代式開發。2000年從寫這篇文章開始就試圖把各種過程攏在一起讨論一下。那是這些方法還沒有一個通用的名字但是總是被描述為“輕量級”。很多人多這個名字不以為然，認為它沒有完全表達出來這些方法的本質。

2000年，這些方法被Kent Beck在俄勒岡的會議上廣泛提及。盡管這個工作組主要關注極限程式設計Extreme Programming (一個最吸引眼球的社群，很多非極限程式設計的人也參與進來) 。當時一個讨論就是關于XP作為一個泛化的運動或者一個具體的運動，哪一個更好些。

如果沒有記錯的話，這個工作組是由Jim Highsmith 和 Bob Martin組建的.他們把活躍在社群又有着相同觀點的人聚集在一起。初衷是把人們聚在一起能更好的交流各自對方法的了解。Robert Martin 想用一些簡單語句把這些技術的共性整合出來，并給它一個名字，就是給那把“傘”一個名字。

在定名“靈活”的過程中，靈活宣言的部分内容也相繼提出。一些基本的原則在工作組裡面最初提出，後來在WIKI上得到後續的補充發展。

提出靈活宣言的無疑需要極大的勇氣，我很驚訝靈活宣言在内容上的所達到的深度盡管靈活宣言不是靈活的嚴格定義，它還是可以幫助你抓住靈活的核心思想。靈活宣言提出之後不久， Jim Highsmith 和我寫了一些文章article for SD Magazine 來進行進一步闡述.

去年，靈活宣言的十七位締造者的部分成員再聚首.當時提出了一個建議：靈活宣言的作者們應該上司發起一些靈活運動。而作者們一緻的意見是是那些真正的靈活實踐者創造了靈活宣言。沒有一個小組可以成為整個靈活社群的領袖。我們幫助船舶靠岸同時也時刻做好準備有人把船開走，最終十七位靈活宣言的締造者隻是作為靈活社群的普通成員默默做着貢獻。

之後這些作者又組織了“靈活聯盟agile alliance.這是一個非盈利組織目的是進行靈活方法的推廣和研究。每年它都會出資在美國召開年會。

XP (Extreme Programming)

XP—極限程式設計是二十世紀九十年代年末開始最早流行起來的靈活方法。XP太有名氣，在很多地方你無法繞過它.

XP最早發端于Smalltalk社群, 二十世紀八十年代末開始和Kent Beck 、 Ward Cunningham 緊密合作.他們都在九十年代初期通過衆多的項目不斷的優化自己的實踐。并得出軟體開發方法中适應性和以人為本的重要理論成果。

Kent通過一些做項目顧問期間不斷調研來發展上述的觀點。特别是在 Chrysler C3 project,項目中，這個項目作為極限程式設計的發源地而聲名遠播。1997年左右他開始使用極限程式設計一詞。(C3 項目讓我和極限程式設計結緣，也讓我和Kent深厚友誼的開始。)

二十世紀晚期極限程式設計被廣泛傳播，最初是通過新聞討論區和Ward Cunningham's wiki, 在那裡Kent 和 Ron Jeffries (C3項目的同僚) 花費很多時間來解釋概念以及跟各種思想做辯論。最後一批書籍在九十年代末出版對極限程式設計的一些細節進行深入的探讨。這類書籍多數以Kent Beck的 white book 為基礎.2004年Kent出版了白皮書的第二版 second edition 重申了極限程式設計的重要思想。

XP有五種核心價值：溝通 回報 簡化 勇氣 尊重 (Communication, Feedback, Simplicity, Courage, and Respect). 這些價值通過十四條原則和二十四個典型實踐來解釋。觀點就是實踐是一個開發團隊每天都要面對的事情。而五種價值是極限程式設計能實施的知識基礎和溝通基礎。五種核心價值是在實踐中展現出來，沒有實踐就無從談起。沒有價值目标的實踐是生搬硬套邯鄲學步。五種核心價值和實踐相輔相成，而這中間有一個巨大的障礙，而靈活的基本原則就是聯系二者的橋梁。許多XP的實踐都是實驗性的，而最終被人遺忘。随着這一技術的複興，XP浪潮推動一個又一個的實踐以價值為導向互相推動，互相影響。

最讓人記憶猶新的，也是最初吸引我的，就是對測試重要性的強調。雖然所有的過程都提到了測試但多數都是沒有太重視。而極限程式設計是把測試作為開發的基礎，每一個開發人員一邊寫代碼一邊寫測試。測試被放在持續內建中這樣就為未來的系統打造了一個穩定的平台。XP方法在這裡常常被冠之以Test Driven Development (TDD) ，這種思想甚至影響了那些非極限程式設計的過程。

極限程式設計方面的出版物有很多，有一個混亂的地方就是白皮書第一版和第二版的變動，上面已經說過了第二本從新的角度重新闡述極限程式設計。第一版影響深遠,當你閱讀極限程式設計的資料時，特别是2005年出版的那些都是以第一版為藍本。事實上網絡上對極限程式設計的描述多數也是源于第一版。

 second edition of the white book的出發點就是發現更多， 第二版用160頁的篇幅介紹了極限程式設計的背景和實踐。Kent Beck 在世紀之交為這一系列的書編輯了一個多色版本，如果隻能挑選一本的話我選紫色的那本 purple one, 記住第一版是最經典的。

多數資料都是以第一版為基礎，隻有少數是以第二版為基礎例如： The New XP (PDF) by Michele Marchesi ，他是Sardinia靈活會議的發起者.可以通過 yahoo mailing list進行極限程式設計的讨論.

早期對XP社群的巨大熱情是源于對XP的喜愛。我認為它巨大的影響力是因為它講一些具體的技術和靈活的方法的原則嫁接在一起。很多早期的靈活文獻都忽略了這個問題：靈活真的是可行的麼？ XP提供了一系列的工具将靈活的希望成為現實。

Scrum

Scrum 也是八十年代、九十年代期間面向對象技術圈子裡面很盛行的一種疊代開發方法。這種方法的佼佼者是Ken Schwaber, Jeff Sutherland,  Mike Beedle.

Scrum 關注軟體開發的管理，将疊代切分成每30天的疊代 (稱作'sprints')；通過每天的SCRUM會議實施緊密監控。它沒有像XP一樣特别強調人與實踐的緊密耦合關系，事實上XP的管理也的确與其截然不同。

Ken Schwaber 是支援Scrum的活躍分子，他的網站website 資源豐富，他的書 book 大多是第一手文獻。

Crystal

Alistair Cockburn 一直是靈活社群重要的聲音。他設計的軟體開發方法水晶體系為不同規模的團隊量身打造開發過程。 Crystal之是以被看作體系，是因為不同的方法應用是根據團隊規模和關鍵的變化嚴重程度決定的。

水晶方法中的變化點都具有一些共性，有三個比較明顯的：安全性（是否可以完成項目的目标） ，效率 可用性（開發人員是不是适應）。這些方法也有一些共性比較重要的三個是：頻繁移交，回報改進，緊密溝通。

可用性優先是水晶思想體系的重要部分。 Alistair的目标就是尋求一個可以完成目标的最小過程：應用最少的原則，足夠精簡的人；結果就是Alistair認為Crystal 比極限程式設計更關注特定場景下該方法是否适用，盡可能的減少失敗。

除了 Crystal原則本身，還沒有比較詳細的闡述，最著名的文章是Crystal Clear, wiki 上也有進一步讨論Crystal的資料。

Context Driven Testing

從一開始就是軟體開發者推動着靈活社群的發展，而軟體開發過程中的其他人也受到這個運動的影響。最明顯的是測試人員，他們更傾向于使用瀑布模型的思維方式。通常測試的工作就是驗證軟體是不是和規格說明書一緻，而在靈活開發中測試人員的角色就沒有這麼清晰了。

結果是一些測試社群的人開始質疑主流的測試思想。後來組成了一個名叫context-driven testing的小組.關于這個觀點最好的诠釋是在Lessons Learned in Software Testing .這個社群在網絡上也是相當活躍，可以看一下 Brian Marick 的網站(靈活宣言的提出者之一),還有 Brett Pettichord, James Bach, Cem Kaner.

Lean Development

我還記得數年前靈活大會上跟一位女士講靈活思想和制造業的精益生産運動的情形。Mary Poppendieck (and husband Tom)這位靈活社群的積極支援者, 主要關注“工作反複問題”，以及精益生産和軟體開發如何互相取長補短。

Taiichi Ohno在豐田倡導的精益生産運動常備稱作豐田生産體系。精益生産觀點被很多早期靈活主義者接受， Poppendiecks 關于這些觀點影響的文章最為著名。工程學上将設計和實施割裂開，是以大體上我對這種類比推論表示擔憂，但是精益研究方向還是有一些很有趣的觀點的。Poppendiecks的 book and website 是一個很好的切入點.

(Rational) Unified Process

面向對象社群另外一個著名的過程就是Rational Unified Process (sometimes just referred to as the Unified Process). 這種思想是源于UML，認為UML可以統領整個過程。由于 RUP 與靈活同時出現是以兩者是否一緻的讨論就一直不斷。

RUP是由一系列大規模的實踐構成，與其說是過程，不如說是架構。它不是為軟體開發提供一個過程，而是擺出一堆通用的過程讓你根據自己的項目來選擇。是以團隊要使用RUP首先要做的就是定義自己的過程，或者用RUP的專業詞彙--開發用例。

RUP的要點就是用例驅動（開發是由一個個使用者可以看到的功能點驅動的），疊代,架構為核心(較早的進行一個架構設計然後貫穿項目始終)。

我自己的RUP應用經曆就是它無窮的變化. 我發現RUP應用的描述已經從嚴格不變的瀑布式開發過渡到靈活。RUP在市場上呼聲很高，仿佛是無所不能的。

盡管RUP社群卧虎藏龍，我還是推薦一下： Phillippe Kruchten and his book 這是RUP的起點. Craig Larman 也在他關于面向對象的新作裡面介紹了RUP的靈活方式introductory book .

你也要靈活麼?

靈活并不适合每一個人，要走這條路有些問題必須考慮。我同時又堅信方法論會有廣泛的适用性，會被更多的人應用到實踐中。

目前的形勢是，好多方法論還是停留在Code&Fix階段。應用一些規則會使混亂狀态有所改觀，靈活方法的優勢就是比那些重量級的方法使用更少的步驟。輕量級是靈活的最大優勢，簡單的過程更容易遵循，過程也總是聊勝于無。

對于靈活的新手，問題就是從哪裡開始。無論是使用新的技術還是新的過程，你都要做出變革。你要看它是不是适用于你的環境，我的建議和對其他新方法的建議一樣：想想當時我們是怎麼接受面對對象技術的.

第一步是找到合适的項目進行靈活實踐。由于靈活是以人為本的是以首先你要組建一個願意進行靈活開發的團隊。不情願的被拉入開發隊伍不僅工作難以順利進行，而且在靈活方法中這直接關乎開發成敗。.

還有就是你是不是有合适的使用者，他也同意使用靈活的方式與你合作。如果使用者不合作，你不可能将适應性過程的優勢發揮到極緻。說到這裡我的确發現有些使用者不願進行靈活合作，但是當他們了解了靈活方法之後他們就改變主意了。

有些人聲稱靈活方法不适用于大型項目，我們 (ThoughtWorks)就成功的成功的完成了數個靈活項目，每個項目都在百人左右。盡管如此我還是建議你從一些小項目開始嘗試。大項目天生就很難把握，比較适用的就是那些在可控範圍内的項目。

有人建議用一些商業影響較小的項目進行實踐，即使錯了也沒有太大的損失。然而一個無關緊要的項目一般測試要求也比較低，大家都不太關心結果怎樣。我還是建議大家找個有點風險的項目試一下。

當然最重要的事情就是你能找到一些有靈活經驗的人指導一下。一個嘗試新東西難免會犯錯，找到那些已經犯過很多錯誤的前輩你可以少走很多彎路。當你開始接觸一門新技術，一位良師益友價值千金。在ThoughtWorks很多朋友都是靈活開發領域做教育訓練的，是以我們可以自給自足。這也絲毫沒有改變我的看法:找一個良師益友。

一旦你找到了，聽聽他的建議。但是這裡會出現一個狀況就是：言聽計從；我的經驗是很多技術沒有真正的實踐一下很難說已經了解深刻了。 最好的一個例子就是我們的一個客戶要用兩個月的時間進行極限程式設計的試驗。在那個期間他們完全按照老師說的做，即使他們認為那是一個很糟糕的主意。試驗期的最後他們停下來了，他們覺得還是用原來的老路子吧。

一個開放性的問題是靈活方法的邊界在哪裡？很多新技術在開始你都難以摸清它們的邊界，直到有一天你使用它們的時候失敗了。靈活方法還太年輕，還沒有足夠的應用來給它劃定一個界限。這就像很難判定一個軟體開發過程哪些方法是成功哪些是失敗的一樣，千頭萬緒，不一而足，難下定論。

這樣看你是不是要用靈活方法呢？我像這會讓很多人為難，如果你的團隊成員沒有緊密合作的強烈要求，那麼這件事情就會阻力重重。永遠不要在一個拒絕靈活方法的團隊嘗試靈活實踐，經驗之談。

過去十年間，靈活實踐一直進行着，在 ThoughtWorks 如果客戶同意我們一直使用靈活方法，大多數的時候他們會同意的。我或者說我們對這種工作方式一直充滿興趣！

本文的重要修正：

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