2001年在軟件工程界首次出現“敏捷”這個(gè)名詞，17個(gè)過(guò)程方法學(xué)家舉行了一個(gè)討論會(huì )。發(fā)現他們的“輕量級”的方法有很多共同的地方，因此一致同意把這些方法統稱(chēng)為“敏捷”的方法。并且成立了個(gè)叫敏捷聯(lián)盟的組織，還定下了所謂的“敏捷宣言”。從此，越來(lái)越多的人了解到敏捷方法。
敏捷方法有一些共同的特征。其中有兩個(gè)最主要的特征是：輕量和簡(jiǎn)單。敏捷方法論包含最少的流程和文檔，減少正式性。目的是做眼前能做的事情，而不去預測太遠的未來(lái)，首先完成緊迫的事情?？焖俚?、增量的開(kāi)發(fā)能更快地交付客戶(hù)使用，更快得到反饋。開(kāi)發(fā)方法要稱(chēng)之為敏捷，需要具備4個(gè)基本特征：
增量的、協(xié)作的、直接的、適應性強的。1.SCRUM(橄欖球里的爭球)方法論
關(guān)鍵詞：30天迭代粒度，每日站立會(huì )議，進(jìn)度透明，客戶(hù)參與
Scrum是一種迭代式增量軟件開(kāi)發(fā)過(guò)程，通常用于敏捷軟件開(kāi)發(fā)。Scrum在英語(yǔ)的意思是
橄欖球里的爭球。雖然Scrum是為管理軟件開(kāi)發(fā)項目而開(kāi)發(fā)的，它同樣可以用于運行軟件維護團隊，或者作為計劃管理方法。在SCRUM方法論中其核心仍然迭代和增量，首先對于產(chǎn)品需求會(huì )劃分為多個(gè)迭代或增量，每個(gè)迭代都需要在1個(gè)月能夠交付，而一個(gè)月即是一次沖刺，而一個(gè)迭代版本又需要轉化到每天的進(jìn)度跟蹤和問(wèn)題解決，這就是每天的15分鐘會(huì )議(
每日站立會(huì )議)，在會(huì )議上必須回答當天的進(jìn)度，明天的計劃和是否存在問(wèn)題。
Scrum是一個(gè)包括了一系列實(shí)踐和預定義角色的過(guò)程骨架。Scrum中的主要角色包括同項目經(jīng)理類(lèi)似的Scrum主管角色負責維護過(guò)程和任務(wù)，產(chǎn)品負責人代表利益所有者，開(kāi)發(fā)團隊包括了所有開(kāi)發(fā)人員。管理Scrum過(guò)程有很多實(shí)施方法，從白板上的即時(shí)貼到軟件包。Scrum最大的好處是它非常容易學(xué)習，而且應用Scrum不需要太多的投入。
每一個(gè)沖刺完成后，都會(huì )舉行一次沖刺回顧會(huì )議，在會(huì )議上所有團隊成員都要反思這個(gè)沖刺。舉行沖刺回顧會(huì )議是為了進(jìn)行持續過(guò)程改進(jìn)。會(huì )議的時(shí)間限制在4小時(shí)。Scrum提倡所有團隊成員坐在一起工作，進(jìn)行口頭交流，以及強調項目有關(guān)的規范（disciplines），這些有助于創(chuàng )造自我組織的團隊。
Scrum的一個(gè)關(guān)鍵原則是承認客戶(hù)可以在項目過(guò)程中改變主意，變更他們的需求，而預測式和計劃式的方法并不能輕易地解決這種不可預見(jiàn)的需求變化。同樣，Scrum采用了經(jīng)驗方法– 承認問(wèn)題無(wú)法完全理解或定義，而是關(guān)注于如何使得開(kāi)發(fā)團隊快速推出和響應不斷出現的需求的能力最大化。其實(shí)踐主要包括:
- 客戶(hù)成為開(kāi)發(fā)團隊中的一部分。 (例如客戶(hù)肯定對開(kāi)發(fā)的結果真正感興趣。)
- 頻繁的包含可以工作的功能的中間可交付成果。
- 頻繁的風(fēng)險和緩解計劃是由開(kāi)發(fā)團隊自己制定。
- 計劃和模塊開(kāi)發(fā)的透明 – 讓每一個(gè)人知道誰(shuí)負責什么，以及什么時(shí)候完成。
- 頻繁的利益所有人會(huì )議，以跟蹤項目進(jìn)展
- 平衡的 (發(fā)布，客戶(hù)，員工，過(guò)程) 儀表板更新 – 擁有預警機制提前了解可能的延遲或偏差。
- 沒(méi)有問(wèn)題會(huì )被藏在地毯下。認識到或說(shuō)出任何沒(méi)有預見(jiàn)到的問(wèn)題并不會(huì )受到懲罰。
- 在工作場(chǎng)所和工作時(shí)間內必須全身心投入。– 完成更多的工作并不意味著(zhù)需要工作更長(cháng)時(shí)間。
2.FDD(Feature-Driven Development)-特征驅動(dòng)開(kāi)發(fā)關(guān)鍵詞：Feature，客戶(hù)價(jià)值，兩周迭代粒度，Domain ModelFeature-Driven本質(zhì)上還是Model Driven，是先規劃出整套的Domain Model，做為系統起始的核心。接下來(lái)就是依據Model，開(kāi)始找出所有的Feature。而
Feature = 可以為客戶(hù)產(chǎn)生價(jià)值的最小開(kāi)發(fā)單位。群集后的Feature稱(chēng)之為Feature Set。而系統的某一個(gè)主題領(lǐng)域就是組合了很多Feature Set。接下來(lái)，項目經(jīng)理就是依據Feature來(lái)規畫(huà)開(kāi)發(fā)的周期，書(shū)上建議每次的周期是兩周，所以每個(gè)Feature必然不可以超過(guò)兩周，會(huì )超過(guò)兩周的Feature必須再予以細分。所謂兩周內的工作，包含為這個(gè)Feature設計、開(kāi)發(fā)、測試、布置。所謂兩周內的工作，包含為這個(gè)Feature設計、開(kāi)發(fā)、測試、布置。
在RUP中強調的是用例驅動(dòng)，通過(guò)用例進(jìn)行需求的分析和建模，再過(guò)渡到架構設計和后續的開(kāi)發(fā)中。而在FDD中強調特征驅動(dòng)，特征是比用例更加小的粒度單位，而且特征更加能夠體現客戶(hù)價(jià)值。在傳統的瀑布模型中我們往往在后續編碼完成后才能夠看到交付的功能，而FDD本身也是一種迭代的思路，只是迭代的單位是Feature，而這些Feature將貫徹從需求到編碼測試的全過(guò)程，只到每個(gè)功能都能夠滿(mǎn)足一個(gè)客戶(hù)價(jià)值的實(shí)現。因此
通過(guò)特征和特征集將傳統的瀑布方法進(jìn)行了橫切，一切軟件開(kāi)發(fā)活動(dòng)包括項目計劃都是以特征為單位和特征驅動(dòng)。在FDD中主要包括5步流程，具體如下：
- Develop an Overall Model (開(kāi)發(fā)一個(gè)主域模型)
- Build a Features List (通過(guò)主域模型分解特征集合)
- Plan By Feature (根據特征制定項目計劃和編排進(jìn)度)
- Design By Feature (根據特征進(jìn)行設計,開(kāi)始迭代)
- Build By Feature (根據特征進(jìn)行編碼，測試和構建)
3.DSDM-動(dòng)態(tài)系統開(kāi)發(fā)方法，也稱(chēng)業(yè)務(wù)中心框架開(kāi)發(fā)方法關(guān)鍵詞：業(yè)務(wù)為中心 用戶(hù)參與 迭代 快速交付團隊協(xié)作和溝通DSDM（動(dòng)態(tài)系統開(kāi)發(fā)方法，也稱(chēng)業(yè)務(wù)中心框架開(kāi)發(fā)方法）是眾多敏捷開(kāi)發(fā)方法中的一種，它倡導以業(yè)務(wù)為核心，快速而有效的進(jìn)行系統開(kāi)發(fā)。我們可以把DSDM看成一種控制框架，重點(diǎn)在于快速交付、并補充如何應用這些控制的指導原則的框架。
DSDM是一整套的方法論，不僅僅包括軟件開(kāi)發(fā)內容和實(shí)踐，也包括了組織結構，項目管理，估算，工具環(huán)境，測試，配置管理，風(fēng)險管理，重用等各個(gè)方面的內容。
DSDM 的基本觀(guān)點(diǎn)是，
任何事情都不可能一次性的圓滿(mǎn)完成，應該用20%的時(shí)間完成80%的有用功能，以適合商業(yè)目的為準。實(shí)施的思路是，在時(shí)間進(jìn)度和可用資源預先固定的情況下，力爭的最大化滿(mǎn)足業(yè)務(wù)需求（傳統方法一般是需求固定，時(shí)間和資源可變），交付所需要的系統。對于交付的系統，必須達到足夠的穩定程度以在實(shí)際環(huán)境中運行；對于業(yè)務(wù)方面的某些緊急需求，也要求能夠在短時(shí)間內得到滿(mǎn)足，然后在以后迭代階段中對功能進(jìn)行進(jìn)一步完善。對于DSDM主要包括以下9條基本原則:
- 用戶(hù)必須持續參與
- 必須授予DSDM團隊制定決策的權力
- 注重產(chǎn)品的經(jīng)常交付
- 滿(mǎn)足業(yè)務(wù)用途是接受交付品的主要依據
- 迭代和增量式開(kāi)發(fā)對得到正確的業(yè)務(wù)解決方案是必不可少的
- 開(kāi)發(fā)過(guò)程中的所有變化可逆
- 在高層次上制定需求的基線(xiàn)
- 測試自始自終貫穿于開(kāi)發(fā)周期之中
- 所有項目涉眾間的通力合作是不可或缺的
4.Crystal Methods-水晶方法族關(guān)鍵詞：協(xié)作 角色 文檔 迭代 風(fēng)險管理水晶方法論由Alistair Cockburn在20實(shí)際90年代末提出。之所以是個(gè)系列，是因為他相信不同類(lèi)型的項目需要不同的方法。雖然水晶系列不如XP那樣的產(chǎn)出效率，但會(huì )有更多的人能夠接受并遵循它。
水晶方法把開(kāi)發(fā)看作是一系列的協(xié)作游戲，而寫(xiě)文檔的目標就是只要能幫助團隊在下一個(gè)游戲中取得勝利就行了。水晶方法的工作產(chǎn)品包括用例、風(fēng)險列表、迭代計劃、核心領(lǐng)域模型，以及記錄了一些選擇結果的設計注釋。水晶方法也為這些產(chǎn)品定義了相應的角色。然而，值得注意的是，這些文檔沒(méi)有模板，描述也可不拘小節，但其目標一定要清晰，那就是滿(mǎn)足下次游戲就可以了。我總是將這些思想以下面的方式向我的團隊成員表達：通過(guò)它們，你只要了解你明天加入這個(gè)團隊所要知道的內容就行了。
對于水晶方法論，根據方法論的輕重可以分為透明水晶和橙色水晶等。透明水晶一般是輕量級的團隊適用。不管是哪種水晶，都會(huì )對團隊的角色，團隊的工件和產(chǎn)出，核心實(shí)踐，支持過(guò)程等進(jìn)行定義。
5. XP（極限編程）關(guān)鍵詞：UserStory 測試驅動(dòng) 結對編程 持續集成 重構小版本發(fā)布 溝通ExtremeProgramming（極限編程，簡(jiǎn)稱(chēng)XP）是由KentBeck在1996年提出的。KentBeck在九十年代初期與 WardCunningham共事時(shí)，就一直共同探索著(zhù)新的軟件開(kāi)發(fā)方法，希望能使軟件開(kāi)發(fā)更加簡(jiǎn)單而有效。Kent仔細地觀(guān)察和分析了各種簡(jiǎn)化軟件開(kāi)發(fā)的前提條件、可能行以及面臨的困難。1996年三月，Kent終于在為DaimlerChrysler所做的一個(gè)項目中引入了新的軟件開(kāi)發(fā)觀(guān)念——XP。
XP是一個(gè)輕量級的、靈巧的軟件開(kāi)發(fā)方法；同時(shí)它也是一個(gè)非常嚴謹和周密的方法。它的基礎和價(jià)值觀(guān)是交流、樸素、反饋和勇氣；即，任何一個(gè)軟件項目都可以從四個(gè)方面入手進(jìn)行改善：加強交流；從簡(jiǎn)單做起；尋求反饋；勇于實(shí)事求是。XP是一種近螺旋式的開(kāi)發(fā)方法，它將復雜的開(kāi)發(fā)過(guò)程分解為一個(gè)個(gè)相對比較簡(jiǎn)單的小周期；通過(guò)積極的交流、反饋以及其它一系列的方法，開(kāi)發(fā)人員和客戶(hù)可以非常清楚開(kāi)發(fā)進(jìn)度、變化、待解決的問(wèn)題和潛在的困難等，并根據實(shí)際情況及時(shí)地調整開(kāi)發(fā)過(guò)程。
XP采用緊湊的迭代開(kāi)發(fā)方式。強調交流、簡(jiǎn)潔、反饋、勇敢 四種價(jià)值觀(guān)。強調能滿(mǎn)足用戶(hù)需求的可用的軟件（working software)為最終目標，而不是漂亮的文檔。XP通過(guò)12條原則來(lái)保證目標的達成。
- 通過(guò)客戶(hù)、開(kāi)發(fā)人員、經(jīng)理三方共同參加的計劃游戲（planning game）來(lái)確定開(kāi)發(fā)計劃
- 小版本發(fā)布----盡快發(fā)布，盡早發(fā)布
- 通過(guò)系統隱喻（metaphor)來(lái)讓每個(gè)人了解整個(gè)系統
- 簡(jiǎn)單設計----為明確的功能進(jìn)行最優(yōu)的設計，不考慮未來(lái)可能需要的功能。
- 重構（refactoring）---不斷優(yōu)化系統設計，使之保持簡(jiǎn)單
- 單元測試----先寫(xiě)測試，后寫(xiě)代碼
- 結對編程(pair programming)----系統的每一行代碼都是2個(gè)人用一個(gè)鍵盤(pán)完成的。
- 代碼集體擁有--開(kāi)發(fā)隊伍中任何人可以修改任何其他人的代碼，代碼不屬于某個(gè)個(gè)人。
- 持續集成----至少每天將整個(gè)系統集成一次，保持一個(gè)能運轉的系統。
- 40小時(shí)工作制----保證休息，保持體力
- 現場(chǎng)客戶(hù)----客戶(hù)自己也是軟件開(kāi)發(fā)隊伍的重要一份子
- 編碼標準----必須有統一的編碼規范，確保代碼的可讀性
6.ASD（Adaptive Software Development）-自適應軟件開(kāi)發(fā)關(guān)鍵詞：領(lǐng)導 預測 協(xié)作 學(xué)習 自適應這種方法強調的是速度和靈活性。它最適合這種場(chǎng)合: 公司需要應用軟件能夠迅速見(jiàn)效，還能隨客戶(hù)使用需求的增長(cháng)而靈活變化。這種方法的發(fā)明者是Jim Highsmith。預測—協(xié)作—學(xué)習是自適應的模型的。“預測—協(xié)作—學(xué)習”不斷迭代，從而讓團隊不斷進(jìn)化，不斷適應多變的環(huán)境。
預測—就是對目標做一個(gè)分析，給出一個(gè)大的方向，但不要太具體，但是大方向一定要對。這不僅是提供給團隊目標，還有就是讓團隊中的每個(gè)人會(huì )因為這個(gè)目標而興奮，而產(chǎn)生激情。在這個(gè)過(guò)程中，項目組中要定期的散焦，在一個(gè)過(guò)程開(kāi)始時(shí)不要太關(guān)注于細節實(shí)現，而過(guò)程進(jìn)行時(shí)要從散焦變成聚焦，逐步協(xié)商合作，統一每個(gè)人的思想，逼近正確目標，以為后續的工作提供可靠的保證。
協(xié)作—第一個(gè)障礙是強權管理，第二個(gè)障礙是個(gè)人主義。相互信任、相互尊重、相互參與、相互承諾是創(chuàng )造雙贏(yíng)的核心。無(wú)論是和客戶(hù)也好，還是人與人之間也好，還是公司與公司也好，協(xié)作絕對是一個(gè)人，一個(gè)團隊，一個(gè)公司最具競爭力的核心。能不能在內部和外部出現協(xié)作，是能否自動(dòng)適應各種環(huán)境的重要因素。協(xié)作需要的是努力得整合自己和別人觀(guān)點(diǎn)的分歧。
學(xué)習—學(xué)習是一種態(tài)度。自我批評、反饋、信息共享是其核心。我們一定要不停地問(wèn)自己至少下面三個(gè)問(wèn)題：和客戶(hù)討論時(shí)，我們要反復地問(wèn)，“我們在做正確的事嗎？”，在設計編碼測試時(shí)，我們要反復地問(wèn)，“我們用正確的手段做這件事嗎？”，在事后分析時(shí)，我們也要反復地問(wèn)，“還能有更好的方法做這件事嗎？”，在項目過(guò)程中要給予這種時(shí)間進(jìn)行反饋、自我批評、并交流個(gè)人的心得體會(huì )。于是，我們就在一種高速—慢速—再高速—再慢速—超高速的發(fā)展。
