下圖是Winston Royce的瀑布式開發(fā)模型：

（ "Managing the Development of Large Software Systems"，1970 IEE paper）

分配任務(wù)處理流程，功能，數(shù)據(jù)庫處理，明確數(shù)據(jù)庫流程，分配執(zhí)行時間，明確操作系統(tǒng)間的接口與處理流程模塊，描述輸入與輸出流程，并且明確初步的操作流程。撰寫容易理解的，信息量大的，當前時新的概要文檔。

管理軟件開發(fā)的第一條規(guī)則就是無條件服從的執(zhí)行文檔需求。

第二個非常重要的成功標準以產(chǎn)品是否完全原始為重中之重。如果把還有疑問的計算機程序開發(fā)為第一版，考慮到嚴格的設(shè)計/操作領(lǐng)域，那么給客戶正式部署的版本實際上是第二版本。

在成本和計劃方面上，這是最有風(fēng)險的一步。當備選方案幾乎或一點不可用時，它會出現(xiàn)在日程安排的最近時間點上。

讓客戶參與到項目中是非常重要的，因為客戶可能在最終發(fā)布之前較早的認可項目工作。

仔細閱讀Royce的文章后發(fā)現(xiàn)：

1. 每一階段都應(yīng)該迭代式地傳遞到下一階段。
2. 軟件發(fā)布前對軟件整體流程實踐兩次。
3. 簡單單一的階段傳遞會造成項目失敗。

不幸地是，上面列出的步驟當中，設(shè)計迭代從來沒被限制成連續(xù)的步驟。

下面這些東西都是什么？

答案是：

敏捷開發(fā)并不意味著只是一種方法。上面雨傘下的術(shù)語代表著不同的敏捷開發(fā)方法。

我們一直在實踐中探尋更好的軟件開發(fā)方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀：

• 個人與交互 高于 流程和工具
• 可用軟件 高于 詳盡的文檔
• 客戶合作 高于 合同談判
• 響應(yīng)變化 高于 遵循計劃

也就是說，上面右側(cè)（藍色字體）內(nèi)容有其價值，但我們更重視左側(cè)（紅色字體）產(chǎn)生的價值。

我們遵循以下原則：

1. 我們最重要的目標，是通過持續(xù)不斷地及早交付有價值的軟件使客戶滿意。
2. 欣然面對需求變化，即使在開發(fā)后期也一樣。為了客戶的競爭優(yōu)勢，敏捷過程掌控變化。
3. 經(jīng)常地交付可工作的軟件，相隔幾星期或一兩個月，傾向于采取較短的周期。
4. 業(yè)務(wù)人員和開發(fā)人員必須相互合作，項目中的每一天都不例外。
5. 激發(fā)個體的斗志，以他們?yōu)楹诵拇罱椖?。提供所需的環(huán)境和支援，輔以信任，從而達成目標。
6. 不論團隊內(nèi)外，傳遞信息效果最好效率也最高的方式是面對面的交談。
7. 可工作的軟件是進度的首要度量標準。
8. 敏捷過程倡導(dǎo)可持續(xù)開發(fā)。責(zé)任人、開發(fā)人員和用戶要能夠共同維持其步調(diào)穩(wěn)定延續(xù)。
9. 堅持不懈地追求技術(shù)卓越和良好設(shè)計，敏捷能力由此增強。
10. 以簡潔為本，它是極力減少不必要工作量的藝術(shù)。
11. 最好的架構(gòu)、需求和設(shè)計出自自組織團隊。
12. 團隊定期地反思如何能提高成效，并依此調(diào)整自身的舉止表現(xiàn)。

很多開發(fā)者都經(jīng)過這樣的噩夢：沒有任何實踐可以輔佐的項目。由于缺乏有效的實踐，項目變得不可預(yù)測，重復(fù)出現(xiàn)錯誤，還有白白浪費的辛苦。計劃延期，超出預(yù)算，質(zhì)量低下使客戶感到失望。開發(fā)者也由于更長時間的工作而換來更糟糕的軟件而心灰意冷。

DSDM（Dynamic Software Development Method），動態(tài)軟件開發(fā)方法，通過提供一個負責(zé)整體開發(fā)周期的框架來彌補RAD(Rapid Application Development)快速程序開發(fā)的不足。下面是DSDM的主要功能：

1. 用戶參與
2. 迭代和遞增開發(fā)
3. 提高了發(fā)布頻率
4. 集成測式于每一階段
5. 已發(fā)布產(chǎn)品的可接受程度直接取決于需求的實現(xiàn)

FDD（Feature Driven Development），功能驅(qū)動開發(fā)，是一種包裝方法學(xué)。它允許你在非常高的級別上應(yīng)用一個方法來管理項目，但它也允許你在較低的級別上應(yīng)用其它方法學(xué)。FDD的著重點是能夠把估算，日程計劃，項目狀態(tài)匯報作為一個整體或放到顆粒級別上，但是FDD不會規(guī)定一個非常細節(jié)化的方法讓你應(yīng)用去創(chuàng)建日程計劃，相反FDD讓你去覺決定該用什么方法。FDD的觀點是你可以查看一下你的項目，陳術(shù)一下項目的確切狀態(tài)，如項目進度是否及時，延時或過早等等。

Lean思想是一種進行系統(tǒng)優(yōu)化的途徑，它關(guān)注于減少浪費，提高整個系統(tǒng)總體流程。Lean在制造業(yè)上有著豐富的歷史，近幾年在在軟件開發(fā)行業(yè)也越來越流行。Lean來源于制造業(yè)中的Lean(Lean Manufacturing: http://www./pages/article/newSTR_44.htm)，它是一組為滿足質(zhì)量，速度和客戶需求而定制的原則。

1. 估算浪費
2. 構(gòu)建質(zhì)量
3. 創(chuàng)建知識
4. 延遲承諾
5. 快速交付
6. 尊重人
7. 優(yōu)化整體

軟件產(chǎn)品的交付工作應(yīng)用這些原則并不是我們的最終目的。我們并不是說讓我們用Lean吧，而是把Lean原則做為決策的向?qū)Щ騾⒖既ミx擇可以改善整體系統(tǒng)的技術(shù)。比如，TDD測試驅(qū)動開發(fā)，通過在每一個功能點上創(chuàng)建功能自我測試從而構(gòu)建軟件的完整性和完善性。

在計劃驅(qū)動開發(fā)中，如果一個項目確切的按照計劃執(zhí)行，那么它就是成功的。因此，在軟件開發(fā)中計劃驅(qū)動開發(fā)依賴于需求的穩(wěn)定性，明確性和固定性。你或許知道這些奢侈的性質(zhì)是在大多數(shù)軟件項目中不存在的。

計劃驅(qū)動方法學(xué)，在初期的設(shè)計階段的需求變更中成本花費較低，但是一旦到了開發(fā)階段需求變更將會花費昂貴的代價。所以，很多的工作被要求在初期計劃設(shè)計階段完成。然而，軟件開發(fā)不同于普通的項目，我們不能保證將來的開發(fā)階段會完全按照初期的設(shè)計進行，無論你的設(shè)計有多么出色。

"Walking on water and developing software from a specification are easy if both are frozen."- Edward V. Berard

在水上行走和開發(fā)軟件都只有當它們被凍結(jié)時才會變得容易。

敏捷開發(fā)打破了對需求穩(wěn)定性的依賴，它有一個專門的流程用于負責(zé)需求變化，主要體現(xiàn)在它的自適應(yīng)計劃和進化式設(shè)計。

自適應(yīng)計劃，意思是多次的仔細檢查整體項目流程，經(jīng)常會再次制定計劃并再次適應(yīng)。

進化式設(shè)計，有一些實踐對它很有幫助，如自我測試代碼，持續(xù)集成，重構(gòu)，簡易設(shè)計等。

敏捷開發(fā)是價值驅(qū)動，傳統(tǒng)的瀑布式開發(fā)是計劃驅(qū)動。這并不是說計劃驅(qū)動就沒有價值，在特定的實際情況下它們都有各自的有優(yōu)缺點。關(guān)鍵是怎么平衡使用兩種方法，在特定情況下采取它們的長處而回避它們的短處。

計劃驅(qū)動開發(fā)模式和敏捷驅(qū)動開發(fā)模式在基本原理差異上有兩大不同。

第一大不同：計劃驅(qū)動模型中只能在項目完成時才能部署一個新模塊，而且是較大的模塊。敏捷驅(qū)動模型中可以頻繁的部署新模塊，甚至較小的模塊。

第二大不同：計劃驅(qū)動是序列化的，敏捷驅(qū)動是并發(fā)的。在計劃驅(qū)動模型中，一個流程的開始必須在前一個流程完全成功結(jié)束的前提下進行。在敏捷驅(qū)動模型中，任何時候都可能在做計劃，流程是并發(fā)的或互相穿插的。

“Plan your work, then work your Plan” by Martin Fowler and Neal Ford

先計劃你的工作，后工作你的計劃。

敏捷開發(fā)和計劃驅(qū)動開發(fā)(瀑布式開發(fā))：

• 都提供了操作流程，操作工具和操作技術(shù)。
• 都需要嚴格的有條不紊的方法進行軟件開發(fā)。
• 都各自有優(yōu)缺點。
• 敏捷開發(fā)適合的情況，計劃驅(qū)動模型不一定適應(yīng)。
• 敏捷開發(fā)強調(diào)流程上的不同。
• 計劃驅(qū)動模型強調(diào)正式的溝通與控制。
• 敏捷開發(fā)強調(diào)連續(xù)的溝通和處理變化的能力
• 計劃驅(qū)動模型是關(guān)卡式控制質(zhì)量，敏捷開發(fā)是高迭代式開發(fā)確保質(zhì)量。
• 計劃驅(qū)動模型僅在產(chǎn)品最終完成后進檢查，敏捷開發(fā)每完成一小塊工作就進行檢查。
• 計劃驅(qū)動模型以預(yù)估什么將被交付為起點，敏捷開發(fā)以完成一個需求為目標做為起點

適應(yīng)變化能力(Y軸) 時間(X軸)

可見性(Y軸) 時間(X軸)

在敏捷開發(fā)中：

客戶滿意度是以迅速，持續(xù)的交付可用軟件為導(dǎo)向。
強調(diào)人和互動要高于強調(diào)流程和工具。

客戶，開發(fā)者，還有測試人員一直保持互動。
可用軟件頻繁的被交付使用（按周交付高于按月交付）

面對面交流是最好的溝通形式。
業(yè)務(wù)人員和開發(fā)者保持近距離的，日常的協(xié)作。
持續(xù)關(guān)注出色的技術(shù)和設(shè)計。
適應(yīng)易變情況。
需求中較晚的改動也受歡迎。

善于使用計劃驅(qū)動模型的管理團隊同樣也能夠善于使用敏捷開發(fā)方法。

缺乏能力使用計劃驅(qū)動模型的管理團隊也沒有能力使用敏捷開發(fā)方法。

敏捷軟件開發(fā)的原理和價值用于幫助團隊打破流程循環(huán)膨脹，著重于用簡單的技術(shù)去實現(xiàn)目標。目標？什么是目標？

每一個軟件開發(fā)者，開發(fā)團隊的主要目標是為老板和客戶制造盡可能高的價值。

敏捷開發(fā)的核心是把傳統(tǒng)的軟件開發(fā)方法(瀑布式開發(fā))的五個步驟壓縮成一個一周的開發(fā)周期。用敏捷開發(fā)方法去開發(fā)一個系統(tǒng)時，項目中會不斷貫穿著重復(fù)的周期開發(fā)和較小模塊的開發(fā)，并在開發(fā)過程中允許開發(fā)者測試和檢查。高速度，低成本，靈活性是敏捷開發(fā)的主要優(yōu)勢。

敏捷開發(fā)發(fā)展極為迅速，從2001年的只有1%的開發(fā)者使用敏捷開發(fā)到現(xiàn)在的60-80%的開發(fā)者在使用敏捷開發(fā)。更大的吸引力是因為敏捷開發(fā)提供：

• 改善的質(zhì)量
• 在項目過程中有更多的機會做出修改更正
• 提高客戶或商業(yè)滿意度
• 使業(yè)務(wù)和IT更好的組合在一起
• 更優(yōu)化的面向市場的時間

敏捷開發(fā)使用者從來不會害怕變化。他們把需求變化看作是好事，因為這些變化意味著團隊又收獲了更多關(guān)于怎樣滿足客戶的經(jīng)驗。敏捷開發(fā)團隊成員一起協(xié)作項目的方方面面。每一個成員都允許為項目整體提出意見或做貢獻。沒有一個團隊成員是單一的負責(zé)架構(gòu)或者需求或者測試。團隊分享這些責(zé)任，同時每個成員都會對它們產(chǎn)生影響。

我們有很多的敏捷開發(fā)流程：Scrum，crystal，BDD(Behavior-Driven Development行為驅(qū)動開發(fā))，TDD(Test-Driven Development測試驅(qū)動開發(fā))，F(xiàn)DD(Feature-Driven Development功能驅(qū)動開發(fā))，ADP(Adaptive Software Development自適應(yīng)軟件開發(fā))，XP(Extreme Programming極限編程)，等等等等。然而，大量成功的敏捷開發(fā)團隊從所有這些方法中吸取經(jīng)驗與知識，進而調(diào)整生成他們自己特有的敏捷開發(fā)方式。這些改編后的方法通常與SCRUM還有XP組合在一起，SCRUM實踐用來管理使用極限編程XP的團隊。

As developers we need to remember that XP is not the only game in town.- Pete McBreen
作為開發(fā)者，我們需要記住極限編程并不是城里唯一的游戲。

極限編程強調(diào)團隊合作(經(jīng)理，客戶，開發(fā)者)。它從五個關(guān)鍵點改善軟件項目：溝通，簡明，反饋，尊重，還有勇氣


維基百科對極限編程的定義：極限編程XP是一種軟件開發(fā)方法，它的意圖是提搞軟件質(zhì)量及對用戶需求變化的響應(yīng)能力。作為一種敏捷軟件開發(fā)方法，它提倡在短開發(fā)周期中頻繁地發(fā)布，從而提高軟件生產(chǎn)力并提出新客戶需求能夠被采納的檢查點。


極限編程是一系列嵌入到敏捷開發(fā)中的簡易并堅實的實踐。極限編程是一個非常好的通用軟件開發(fā)方法。許多項目團隊都采用它，同時更多的團隊通過添加或修改實踐來把它變得更適用。

• 它是大多數(shù)敏捷開發(fā)方法的始祖
• 在90年代末期和21世紀初期，Kent Beck提出了熱門的話題
• 協(xié)調(diào)流程與實踐

Kent Beck 的基本觀念:

• 采取已關(guān)注過的有效團隊實踐
• 迫使它們走向極端

“迫使它們走向極端”是什么意思呢？是不是如下圖一樣？

或者下圖

不，這不是極限編程。讓我們看看它的真正意思：

出色的實踐	迫使它走向極端
代碼復(fù)查	結(jié)對編程
測試	TDD測試驅(qū)動開發(fā)和常數(shù)回歸
軟件設(shè)計	不停地重構(gòu)
簡單	最簡單的事會有意想不到的效果
集成測試	不斷的集成/整合
短迭代	把制定計劃當作游戲

極限編程是一系列遵循敏捷開發(fā)原則和價值的實踐。極限編程是離散的方法，而敏捷開發(fā)是一類方法。有很多的敏捷開發(fā)方法，極限編程只是其中一種。

極限編程在敏捷開發(fā)方法中是范圍寬闊，出類拔萃的。Scrum有些類似極限編程，擁有極限編程的大多數(shù)特征。但是在細節(jié)是它們有很多的不同，公平的說Scrum是是極限編程的子集。甚至，許多Scrum團隊爭論著要把極限編程實踐加入Scrum流程中，如滿意度測試，結(jié)對編程，持續(xù)集成，以及測試驅(qū)動開發(fā)。


在所有敏捷開發(fā)方法當中，極限編程是唯一的一種方法為開發(fā)者的日常工作提供深度的，意義深遠的開發(fā)準則。在這些準則中，測試驅(qū)動開發(fā)是最革命性的。下圖中都是一些出色的極限編程實踐。

Scrum是和種迭代式及遞增式的敏捷軟件開發(fā)框架，它用于管理軟件項目，產(chǎn)品，或程序的開發(fā)。它的著重點是一個靈活的，全面的產(chǎn)品開發(fā)策略，它把一個開發(fā)團隊通常作為一個單位進而實現(xiàn)一個常規(guī)目的。相反，它不著重于傳遞的序列化式的方法。Scrum會問傳統(tǒng)瀑布式開發(fā)“為什么我們要花費這么長時間，這么多努力去做一件事？為什么我們不能衡量出做一件事所需時間和人力？” Scrum擁抱變化和創(chuàng)造力，因為這是人們的工作方式。Scrum有一個流程學(xué)習(xí)結(jié)構(gòu)，能夠讓團隊評估他們做了什么以及他們怎樣做的。

• 1986年，Scrum第一次被定義成一個靈活的全面的產(chǎn)品開發(fā)策略。--Hirotaka Takeuchi，Ikujiro Nonaka
• 1995年，Sutherland和Schwaber共同地發(fā)表了一篇關(guān)于Scrum方法學(xué)的論文。

Scrum角色

三個核心角色：

1. 產(chǎn)品持有人 Product Owner
2. 開發(fā)團隊 Development Team
3. Scrum領(lǐng)導(dǎo)人 ScrumMaster

產(chǎn)品持有人 Product Owner

• 專門負責(zé)掃清團隊在交付Sprint目標或產(chǎn)品中遇到的障礙。
• 不是團隊領(lǐng)導(dǎo)人，但是扮演著團隊與可能分散團隊注意力的影響之間的緩沖區(qū)。
• 確保Scrum流程的使用在計劃中。
• 規(guī)則強制執(zhí)行人。團隊保護者，以保持團隊專注于他們手中的工作。
• 也會被看作一個人民公仆去加強這些雙重觀點。
• 不同于一個項目經(jīng)理，沒有與ScrumMaster不相關(guān)的人員管理職責(zé)
• 沒有任何額外的員工責(zé)任。

產(chǎn)品的待完成項列表是一個需求的排列列表，我們維護這個列表是為了更好的開發(fā)產(chǎn)品。它的組成有功能，BUG修復(fù)，非功能需求等任何為了成功發(fā)布可用軟件系統(tǒng)的所必須的內(nèi)容。在Scrum中，開始一個項目不必先開發(fā)一個冗長文檔去記錄所有的需求。這個敏捷產(chǎn)品backlog對于第一個Sprint足夠了。當有更多產(chǎn)品需求時和客戶需求時，Scrum產(chǎn)品backlog允許變更和增加。

Sprint backlog是開發(fā)團隊下個Sprint需要處理的工作列表。這個列表是產(chǎn)品backlog最上面的需求項衍生出來的，直到開發(fā)團隊在這個Sprint中有足夠的工作去做。開發(fā)團隊通過問一些問題來完成backlog的選擇，如“我們是不是也能做這個？”。

從概念上講，團隊從優(yōu)先級最高的Scrum backlog開始畫一條線劃分出優(yōu)先級較低的項，同時線上面的backlog也是團隊認為他們可以完成的項。在實踐中，團隊通常不會去選擇優(yōu)先級最高的五項再選擇優(yōu)先級較低的兩項組合在一起即使它們是互相關(guān)聯(lián)的。

這項調(diào)查發(fā)起于2012年8月9日至2012年11月1日之間，由VersionOne贊助的。調(diào)查從軟件開發(fā)社團的不同渠道中選擇了4048人。數(shù)據(jù)由Analysis.Net Research分析并總結(jié)成報告。

一般情況下，相比業(yè)務(wù)人員，越接近開發(fā)團隊角色的人了解敏捷開發(fā)的越多

一個好的敏捷團隊會選擇最適合他們的管理與技術(shù)實踐。當試著去使用敏捷開發(fā)時，會有一萬個借口為什么這行不通。只有那些真正理解敏捷開發(fā)優(yōu)勢并真心實意地想要使用敏捷開發(fā)的人們才會有可能成功。那些正在搜索為什么Agile會失敗的人們，他們可能最終會找到答案也可能放棄之前所做的一切努力不再使用敏捷開發(fā)。Elisabeth Hendrickson稱這種行為“假敏捷開發(fā)”。

為了支持一下我的結(jié)論，讓我們引用一些名言(從Robert C. Martin收集):
"In preparing for battle I have always found that plans are useless, but planning is indispensable." - General Dwight David Eisenhower

在戰(zhàn)斗準備中，我總是發(fā)現(xiàn)那些計劃是雞肋，但是制定計劃是不可缺少的。

局限于別人的方法世界里不是可取的，因為公司需求，公司情況，項目都有可能一直在變化著。如果你想你的項目成功，你一定要靈活地應(yīng)用這些現(xiàn)成的方法去管理項目。任何單一的方法都不是一把尚方寶劍，因此關(guān)鍵是看哪種方法適合你并能協(xié)調(diào)你的方法去滿足你的個人需求。

記住，Scrum和Agile不是一個死產(chǎn)品 ，它是在持續(xù)改進的基礎(chǔ)上不斷進行中的一門哲學(xué)。