The New Methodology新方法論


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 CockburnJim Highsmith的書。 Craig Larman's 的書里面提到了很多有用的迭代開發的歷史。要了解我對敏捷的看法那就關注一下我的articlesblog.

下面是一個不完全列表,它只是反應了在過去的十年間敏捷開發的變化發展,里面的方法都對我曾經有巨大的影響。


敏捷宣言


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



注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com