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

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

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

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

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

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

讓客戶參與到項(xiàng)目中是非常重要的，因?yàn)榭蛻艨赡茉谧罱K發(fā)布之前較早的認(rèn)可項(xiàng)目工作。

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

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

不幸地是，上面列出的步驟當(dāng)中，設(shè)計(jì)迭代從來(lái)沒(méi)被限制成連續(xù)的步驟。

下面這些東西都是什么？

答案是：

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

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

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

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

我們遵循以下原則：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

先計(jì)劃你的工作，后工作你的計(jì)劃。

敏捷開(kāi)發(fā)和計(jì)劃驅(qū)動(dòng)開(kāi)發(fā)(瀑布式開(kāi)發(fā))：

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

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

可見(jiàn)性(Y軸) 時(shí)間(X軸)

在敏捷開(kāi)發(fā)中：

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

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

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

善于使用計(jì)劃驅(qū)動(dòng)模型的管理團(tuán)隊(duì)同樣也能夠善于使用敏捷開(kāi)發(fā)方法。

缺乏能力使用計(jì)劃驅(qū)動(dòng)模型的管理團(tuán)隊(duì)也沒(méi)有能力使用敏捷開(kāi)發(fā)方法。

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

每一個(gè)軟件開(kāi)發(fā)者，開(kāi)發(fā)團(tuán)隊(duì)的主要目標(biāo)是為老板和客戶制造盡可能高的價(jià)值。

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

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

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

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

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

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

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


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


極限編程是一系列嵌入到敏捷開(kāi)發(fā)中的簡(jiǎn)易并堅(jiān)實(shí)的實(shí)踐。極限編程是一個(gè)非常好的通用軟件開(kāi)發(fā)方法。許多項(xiàng)目團(tuán)隊(duì)都采用它，同時(shí)更多的團(tuán)隊(duì)通過(guò)添加或修改實(shí)踐來(lái)把它變得更適用。

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

Kent Beck 的基本觀念:

• 采取已關(guān)注過(guò)的有效團(tuán)隊(duì)實(shí)踐
• 迫使它們走向極端

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

或者下圖

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

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

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

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


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

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

Backlog未完成項(xiàng)列表

敏捷開(kāi)發(fā)調(diào)查

誰(shuí)知道敏捷開(kāi)發(fā)？

敏捷開(kāi)發(fā)失敗原因

進(jìn)一步使用敏捷開(kāi)發(fā)的障礙物

使用敏捷開(kāi)發(fā)最大的擔(dān)心

總結(jié)