敏捷開(kāi)發(fā)概念及實(shí)踐課件

目錄敏捷開(kāi)發(fā)歷史軟件開(kāi)發(fā)模式介紹軟件生命周期模式敏捷開(kāi)發(fā)介紹敏捷開(kāi)發(fā)-SCRUM名詞解釋敏捷開(kāi)發(fā)-實(shí)施Scrum的過(guò)程介紹敏捷開(kāi)發(fā)-原則和方法敏捷開(kāi)發(fā)-宣言敏捷開(kāi)發(fā)-最佳實(shí)踐目錄敏捷開(kāi)發(fā)歷史1敏捷開(kāi)發(fā)歷史敏捷開(kāi)發(fā)并不現(xiàn)代

起源于20世紀(jì)30年代的一些項(xiàng)目（美國(guó)航天局水星計(jì)劃）最早記載使用在20世紀(jì)70年代

最早的有記載的使用迭代和增量開(kāi)發(fā)的主要項(xiàng)目之一，是為第一艘美國(guó)三叉戟潛艇開(kāi)發(fā)的第一指揮和控制系統(tǒng)。該項(xiàng)目有大約一百萬(wàn)行代碼，進(jìn)行得非常成功。在1976年，第一部闡述敏捷方法的書籍 TomGilb在他的著作《軟件度量》（“SoftwareMetrics”）一書中闡述了他的迭代和增量開(kāi)發(fā)實(shí)踐20世紀(jì)80年代正式定義迭代開(kāi)發(fā)螺旋模型

20世紀(jì)80年代在1895年，巴里貝母（BarryBoehm）正式定義了使用迭代開(kāi)發(fā)的螺旋模型敏捷開(kāi)發(fā)歷史敏捷開(kāi)發(fā)并不現(xiàn)代2敏捷開(kāi)發(fā)歷史

美國(guó)國(guó)防部的項(xiàng)目審查早期使用瀑布模式開(kāi)發(fā)的軟件項(xiàng)目，有75%以失敗告終，有些開(kāi)發(fā)出來(lái)的產(chǎn)品根本沒(méi)有被使用過(guò)，只有2%的軟件產(chǎn)品無(wú)需大量修改就能被正常使用。20世紀(jì)90年代推薦使用迭代和增量開(kāi)發(fā)的出版物和文獻(xiàn)顯著增加2001年二月敏捷開(kāi)發(fā)宣言后形成敏捷聯(lián)盟

一組由17位在DSDM，XP，Scrum，F(xiàn)SD等領(lǐng)域的專家組成的代表團(tuán)齊聚美國(guó)猶他州，尋找這些方法的共同點(diǎn)。最終，這些專家制定并宣布了敏捷開(kāi)發(fā)宣言。由此形成了現(xiàn)在我們所認(rèn)識(shí)的敏捷開(kāi)發(fā)和后來(lái)的敏捷聯(lián)盟敏捷開(kāi)發(fā)歷史 美國(guó)國(guó)防部的項(xiàng)目審查早期使用瀑布模式開(kāi)發(fā)的軟件3為什么要敏捷開(kāi)發(fā)-項(xiàng)目為什么失敗項(xiàng)目為什么失??？軟件工程試圖解決這些問(wèn)題：對(duì)用戶需求理解得不清楚，甚至有錯(cuò)誤；用戶需求變化；軟件很難維護(hù)或擴(kuò)展；在項(xiàng)目后期階段發(fā)現(xiàn)很嚴(yán)重的設(shè)計(jì)缺陷；軟件質(zhì)量或性能不合格；Test-Build-Release過(guò)程的可操作性、可維護(hù)性很差；人員流動(dòng)；為了規(guī)范化開(kāi)發(fā)過(guò)程，引進(jìn)傳統(tǒng)工程的概念（瀑布型）；為了理解需求，提出原型法；為了提高設(shè)計(jì)開(kāi)發(fā)的效率和擴(kuò)展性，提出重用和面向?qū)ο蟮人枷耄粸榱俗岄_(kāi)發(fā)過(guò)程更靈活，提出了開(kāi)發(fā)框架的概念；為了降低風(fēng)險(xiǎn)，提出了風(fēng)險(xiǎn)評(píng)估、成本控制和增量開(kāi)發(fā)等思想；為什么要敏捷開(kāi)發(fā)-項(xiàng)目為什么失敗項(xiàng)目為什么失??？軟件工程試圖4為什么要敏捷開(kāi)發(fā)-軟件工程應(yīng)用現(xiàn)狀軟件工程的應(yīng)用現(xiàn)狀：“特色”問(wèn)題還是難以解決：國(guó)內(nèi)因?yàn)橘Y源限制，軟件工程的實(shí)施流于形式；國(guó)內(nèi)軟件工程的研究及推廣工作，和實(shí)踐脫鉤；舊的軟件工程方法一直不能有效地支持變化。在北美，雖然軟件工程提高了項(xiàng)目成功率，但耗費(fèi)巨大資源；以前的軟件工程方法無(wú)法擺脫傳統(tǒng)工程方法的束縛。需求難以量化；軟件從開(kāi)發(fā)到維護(hù)及擴(kuò)展，需求都有可能發(fā)生大變化；編程對(duì)設(shè)計(jì)的反饋非常重要；項(xiàng)目中的設(shè)計(jì)可能會(huì)經(jīng)常變化；代碼的可讀性和可維護(hù)性；

……為什么要敏捷開(kāi)發(fā)-軟件工程應(yīng)用現(xiàn)狀軟件工程的應(yīng)用現(xiàn)狀：“特色5為什么要敏捷開(kāi)發(fā)-需要敏捷的理由需要敏捷的理由部門培養(yǎng)團(tuán)隊(duì)合作精神，穩(wěn)定開(kāi)發(fā)隊(duì)伍；提高開(kāi)發(fā)人員的水平；提高項(xiàng)目成功率，降低開(kāi)發(fā)成本，提升軟件開(kāi)發(fā)效率項(xiàng)目經(jīng)理更好地和用戶溝通，更清晰地理解用戶需求；更充分地使用資源，更科學(xué)地調(diào)配資源，更精確地掌握開(kāi)發(fā)進(jìn)度。系統(tǒng)分析設(shè)計(jì)更加完善；更有效地更新知識(shí)，得到其他成員更多的尊重。程序員學(xué)習(xí)系統(tǒng)設(shè)計(jì)和項(xiàng)目管理；提高學(xué)習(xí)和工作效率，受到重視，減少加班時(shí)間，工作更高效為什么要敏捷開(kāi)發(fā)-需要敏捷的理由需要敏捷的理由部門培養(yǎng)團(tuán)隊(duì)合6軟件開(kāi)發(fā)模式介紹軟件生命周期-同任何事物一樣,一個(gè)軟件產(chǎn)品或軟件系統(tǒng)也要經(jīng)歷孕育、誕生、成長(zhǎng)、成熟、-衰亡等階段，這一般稱為軟件生命周期。-軟件開(kāi)發(fā)生命周期(SDLC)是指軟件開(kāi)發(fā)的全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架。SDLC的一般步驟包括：確定問(wèn)題、可行性分析與開(kāi)發(fā)計(jì)劃、收集需求、分析與設(shè)計(jì)、編碼開(kāi)發(fā)、測(cè)試、安裝、維護(hù)。軟件生命周期模式

典型的幾種生命周期模式包括：瀑布模式、演化模式、螺旋模式、快速原型模式、噴泉模式和混合模式等。在這里只介紹其中最常用的幾種模式：軟件開(kāi)發(fā)模式介紹軟件生命周期7軟件生命周期模式瀑布式

它首先是由Royce提出，該模式由于酷似瀑布聞名。在該模式中首先確定需求，然后擬定規(guī)格說(shuō)明，在通過(guò)驗(yàn)證后方可進(jìn)入計(jì)劃階段。因此，瀑布模式中至關(guān)重要的一點(diǎn)是只有當(dāng)一個(gè)階段的文檔獲得認(rèn)可才可以進(jìn)入下一個(gè)階段。瀑布模式通過(guò)強(qiáng)制性規(guī)約來(lái)確保每個(gè)階段都能很好的完成任務(wù)，但是實(shí)際上卻往往難以辦到。因?yàn)檎麄€(gè)瀑布模式幾乎都是以文檔驅(qū)動(dòng)的，這對(duì)于非專業(yè)的用戶來(lái)說(shuō)是難以閱讀和理解的。雖然瀑布模式有很多很好的思想可以借鑒，但是在過(guò)程能力上有天生的缺陷。演化模式它主要是針對(duì)事先不能完整定義需求的軟件開(kāi)發(fā)。它的方法是用戶先給出待開(kāi)發(fā)系統(tǒng)的核心需求，并且在核心需求實(shí)現(xiàn)后，再提出反饋以支持系統(tǒng)的最終設(shè)計(jì)和實(shí)現(xiàn)。也就是說(shuō)：開(kāi)發(fā)人員首先會(huì)根據(jù)用戶的需求開(kāi)發(fā)核心系統(tǒng)，然后提供給用戶試用；用戶試用后再提出增強(qiáng)系統(tǒng)能力的需求；最后開(kāi)發(fā)人員再根據(jù)用戶的反饋，實(shí)施迭代開(kāi)發(fā)。實(shí)際上，這個(gè)模式可看作是重復(fù)執(zhí)行的多個(gè)瀑布模式。演化模式要求開(kāi)發(fā)人員把項(xiàng)目的產(chǎn)品需求分解為不同組，以便分批循環(huán)開(kāi)發(fā)。但這種分組并不是隨意性的，而是要根據(jù)功能的重要性及對(duì)總體設(shè)計(jì)的基礎(chǔ)結(jié)構(gòu)的影響而作出判斷。軟件生命周期模式瀑布式8軟件生命周期模式螺旋模式：

它是瀑布模式與演化模式相結(jié)合，并加入兩者所忽略的風(fēng)險(xiǎn)分析所建立的一種軟件開(kāi)發(fā)模式。螺旋模式基本的做法是在瀑布模式的每一個(gè)開(kāi)發(fā)階段之前，引入非常嚴(yán)格的風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)分析和風(fēng)險(xiǎn)控制。直到采取了消除風(fēng)險(xiǎn)的措施之后，才開(kāi)始計(jì)劃下一階段的開(kāi)發(fā)工作。否則，項(xiàng)目就很可能被暫停。另外，如果有充足的把握判斷遺留的風(fēng)險(xiǎn)已降低到一定的程度，項(xiàng)目管理人員還可作出決定讓余下的開(kāi)發(fā)工作采用另外的生命周期模式，如演化模式，瀑布模式或自定的混合模式。過(guò)程開(kāi)發(fā)模式：

它又叫混合模式或元模式，是指把幾種不同模式組合成一種混合模式，它允許一個(gè)項(xiàng)目能沿著最有效的路徑發(fā)展。因?yàn)樯鲜龅哪Ｊ街卸加凶约邯?dú)特的思想，現(xiàn)在的軟件開(kāi)發(fā)團(tuán)隊(duì)中很少說(shuō)標(biāo)準(zhǔn)的采用那一種模式的，因?yàn)槟Ｊ胶蛯?shí)際應(yīng)用還是有很大的區(qū)別的。實(shí)際上，許多軟件開(kāi)發(fā)團(tuán)隊(duì)都是在使用幾種不同的開(kāi)發(fā)方法組成他們自己的混合模式。軟件生命周期模式螺旋模式：9軟件生命周期模式-總結(jié)最后，我們來(lái)總結(jié)一下。螺旋模式是典型的迭代式生命周期模式，而RUP則是近代迭代式生命周期的代表。與螺旋模式相比，RUP將風(fēng)險(xiǎn)管理放在更重要的地位。最新的迭代式生命周期模式的代表是模式驅(qū)動(dòng)架構(gòu)（MDA）和敏捷（Agile）軟件開(kāi)發(fā)。MDA模式是基于可執(zhí)行規(guī)格說(shuō)明的思想，是現(xiàn)代轉(zhuǎn)換模式的代表，其核心技術(shù)是組件技術(shù)。而敏捷開(kāi)發(fā)生命周期的典型代表是XP編程，是把傳統(tǒng)的系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)由敏捷軟件開(kāi)發(fā)過(guò)程中的驗(yàn)收測(cè)試、重構(gòu)和測(cè)試驅(qū)動(dòng)所取代；把傳統(tǒng)的集成和部署由敏捷軟件開(kāi)發(fā)中的持續(xù)集成和短周期所取代。其實(shí)上，無(wú)論是瀑布開(kāi)發(fā)模式還是螺旋開(kāi)發(fā)模式，軟件生命周期模式的發(fā)展實(shí)際上是體現(xiàn)了軟件工程理論的發(fā)展。在最早的時(shí)候，軟件的生命周期處于無(wú)序、混亂的情況。一些人為了能夠管理和控制軟件的開(kāi)發(fā)過(guò)程，就把軟件開(kāi)發(fā)嚴(yán)格的區(qū)分為多個(gè)不同的階段，并在階段間加上嚴(yán)格的審查，這就是軟件開(kāi)發(fā)模式產(chǎn)生的起因。它們體現(xiàn)了人們對(duì)軟件過(guò)程的一個(gè)希望：嚴(yán)格控制、確保質(zhì)量。軟件生命周期模式-總結(jié)最后，我們來(lái)總結(jié)一下。螺旋模式是典型的10敏捷開(kāi)發(fā)介紹敏捷開(kāi)發(fā)（agiledevelopment）

是一種以人為核心、迭代、循序漸進(jìn)的開(kāi)發(fā)方法。在敏捷開(kāi)發(fā)中，軟件項(xiàng)目的構(gòu)建被切分成多個(gè)子項(xiàng)目，各個(gè)子項(xiàng)目的成果都經(jīng)過(guò)測(cè)試，具備集成和可運(yùn)行的特征。簡(jiǎn)言之，就是把一個(gè)大項(xiàng)目分為多個(gè)相互聯(lián)系，但也可獨(dú)立運(yùn)行的小項(xiàng)目，并分別完成，在此過(guò)程中軟件一直處于可使用狀態(tài)。捷開(kāi)發(fā)由幾種輕量級(jí)的軟件開(kāi)發(fā)方法組成。

它們包括：極限編程（XP），Scrum，精益開(kāi)發(fā)（LeanDevelopment），動(dòng)態(tài)系統(tǒng)開(kāi)發(fā)方法（DSDM），特征驅(qū)動(dòng)開(kāi)發(fā)（FeatureDriverDevelopment），水晶開(kāi)發(fā)（CristalClear）等等敏捷開(kāi)發(fā)介紹敏捷開(kāi)發(fā)（agiledevelopment）11XP-eXtreme

Programing極限編程:思想源自KentBeck和WardCunningham在軟件項(xiàng)目中的合作經(jīng)歷。SCRUM：是一種迭代的增量化過(guò)程，用于產(chǎn)品開(kāi)發(fā)或工作管理。水晶方法Crystal:由AlistairCockburn在1990年代末提出。把不同類型的項(xiàng)目采用不同的方法。FDD－特性驅(qū)動(dòng)FeatureDrivenDevelopment，由PeterCoad、JeffdeLuca、EricLefebvre共同開(kāi)發(fā)，是一套針對(duì)中小型軟件開(kāi)發(fā)項(xiàng)目的開(kāi)發(fā)模式。它強(qiáng)調(diào)的是簡(jiǎn)化、實(shí)用、易于被開(kāi)發(fā)團(tuán)隊(duì)接受，適用于需求經(jīng)常變動(dòng)的項(xiàng)目。DSDM-DynamicSystemDevelopmentMethodology，它倡導(dǎo)以業(yè)務(wù)為核心，快速而有效地進(jìn)行系統(tǒng)開(kāi)發(fā)，在英國(guó)等歐洲國(guó)家比較流行。ASD-AdaptiveSoftwareDevelopment，由JimHighsmith在1999年正式提出。ASD強(qiáng)調(diào)開(kāi)發(fā)方法的適應(yīng)性（Adaptive）敏捷開(kāi)發(fā)介紹XP-eXtremePrograming極限編程:思想源12敏捷開(kāi)發(fā)的特點(diǎn)敏捷開(kāi)發(fā)包括很多方法，例如XP和FDD，同重量級(jí)的文檔驅(qū)動(dòng)的開(kāi)發(fā)過(guò)程相比較，敏捷方法在靈活性等方面更有吸引力。這個(gè)方法的創(chuàng)始人強(qiáng)調(diào)了在軟件實(shí)踐過(guò)程中的變更而不是孤立的進(jìn)行一些實(shí)踐。很多方法很難獨(dú)立的使用。如:測(cè)試驅(qū)動(dòng)的開(kāi)發(fā)，結(jié)對(duì)開(kāi)發(fā)，計(jì)劃調(diào)整周期以及持續(xù)改進(jìn)，不過(guò)，后來(lái)的結(jié)果證實(shí)，這些方法都取得了成功。使用這些方法并不能保證一定成功。開(kāi)發(fā)者的經(jīng)驗(yàn)和技術(shù)仍舊是影響開(kāi)發(fā)結(jié)果的最主要因素。對(duì)于合適的人，基于敏捷原則的開(kāi)發(fā)方法可以產(chǎn)生更好的結(jié)果，同時(shí)形成一個(gè)愉快地、有激情的工作環(huán)境敏捷開(kāi)發(fā)的特點(diǎn)敏捷開(kāi)發(fā)包括很多方法，例如XP和FDD，同重量13敏捷模式理念最高目標(biāo)是能持續(xù)地、及早地向客戶交付軟件；擁抱變化；頻繁地發(fā)布可運(yùn)行的軟件；客戶和開(kāi)發(fā)人員在一起工作；以人為本；最重要的衡量開(kāi)發(fā)過(guò)程的手段，是可工作的軟件；穩(wěn)定的開(kāi)發(fā)速度；敏捷高效的設(shè)計(jì)；簡(jiǎn)單有效；重視Teamwork；積極的調(diào)整。敏捷模式理念最高目標(biāo)是能持續(xù)地、及早地向客戶交付軟件；14敏捷開(kāi)發(fā)介紹-極限編程XP主要目的是降低需求變化的成本定義了一套簡(jiǎn)單的開(kāi)發(fā)流程

包括：編寫用戶案例，架構(gòu)規(guī)范，實(shí)施規(guī)劃，迭代計(jì)劃，代碼開(kāi)發(fā)，單元測(cè)試，驗(yàn)收測(cè)試等等提倡互動(dòng)交流、反饋、簡(jiǎn)單、勇氣、團(tuán)隊(duì)核心做法：

小規(guī)模，頻繁的版本發(fā)布，短迭代周期。

·測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（Test-drivendevelopment）。

·結(jié)對(duì)編程（Pairprogramming）。

·持續(xù)集成（Continuousintegration）。

·每日站立會(huì)議（Dailystand-upmeeting）。

·共同擁有代碼Collativecodeownership.

·系統(tǒng)隱喻（Systemmetaphor）。敏捷開(kāi)發(fā)介紹-極限編程XP主要目的是降低需求變化的成本15敏捷開(kāi)發(fā)介紹-精益精益開(kāi)發(fā)起源

從豐田公司的產(chǎn)品開(kāi)發(fā)方法中演化而來(lái)。它主要包括兩個(gè)部分：一部分是核心思想及原則，另外一部分由一些在相應(yīng)的工具構(gòu)成。核心思想

查明和消除浪費(fèi)。在軟件開(kāi)發(fā)過(guò)程中，錯(cuò)誤（bugs），沒(méi)用的功能，等待以及其他任何對(duì)實(shí)現(xiàn)結(jié)果沒(méi)有益處的東西都是浪費(fèi)。浪費(fèi)及其源頭必須被分析查明，然后設(shè)法消除。精益開(kāi)發(fā)的原則包括:

強(qiáng)調(diào)學(xué)習(xí)。不斷改進(jìn)所開(kāi)發(fā)的產(chǎn)品和開(kāi)發(fā)效率。

在最后時(shí)刻做決定。避免在可能改變的事情上做無(wú)謂的努力，避免浪費(fèi)。

用最快的速度交付用戶。縮短迭代周期加速開(kāi)發(fā)及交付，加快交流，提高生產(chǎn)力

給團(tuán)隊(duì)自主權(quán)。激勵(lì)團(tuán)隊(duì)并讓團(tuán)隊(duì)成員自我管理-敏捷方法成功的基本因素之一。

誠(chéng)信。確保系統(tǒng)正常工作，客戶需求是團(tuán)隊(duì)努力堅(jiān)持的誠(chéng)信和對(duì)用戶的承諾。

全局觀。精益開(kāi)發(fā)強(qiáng)調(diào)整體優(yōu)化的系統(tǒng)。無(wú)論開(kāi)發(fā)的組織還是被開(kāi)發(fā)的產(chǎn)品，從整體上考慮優(yōu)化比從各個(gè)局部去優(yōu)化更高效。

精益軟件更重要的是不斷完善開(kāi)發(fā)過(guò)程的一種思維方式。敏捷開(kāi)發(fā)介紹-精益精益開(kāi)發(fā)起源

從豐田公司的產(chǎn)品開(kāi)發(fā)方法中演16SCRUM開(kāi)發(fā)流程是AgileProcess的一種，以英式橄欖球爭(zhēng)球隊(duì)形(Scrum)為名，基本假設(shè)是『開(kāi)發(fā)軟件就像開(kāi)發(fā)新產(chǎn)品，無(wú)法一開(kāi)始就能定義FinalProduct的規(guī)程，過(guò)程中需要研發(fā)、創(chuàng)意、嘗試錯(cuò)誤，所以沒(méi)有一種固定的流程可以保證項(xiàng)目成功』。Scrum將軟件開(kāi)發(fā)團(tuán)隊(duì)比擬成橄欖球隊(duì)，有明確的最高目標(biāo)，熟悉開(kāi)發(fā)流程中所需具備的最佳典范與技術(shù)，具有高度自主權(quán)，緊密地溝通合作，以高度彈性解決各種挑戰(zhàn)，碓保每天、每個(gè)階段都朝向目標(biāo)有明確的推進(jìn)，因此SCRUM非常適用于產(chǎn)品開(kāi)發(fā)項(xiàng)目。敏捷開(kāi)發(fā)介紹-scrumSCRUM開(kāi)發(fā)流程是AgileProcess的一種，17敏捷開(kāi)發(fā)介紹-scrumSCRUM開(kāi)發(fā)流程通常以30天為一個(gè)迭代周期，每個(gè)迭代周期叫做一個(gè)Sprint，由客戶提供新產(chǎn)品的需求規(guī)格開(kāi)始，開(kāi)發(fā)團(tuán)隊(duì)與客戶于每一個(gè)階段開(kāi)始時(shí)挑選該完成的規(guī)格部份，開(kāi)發(fā)團(tuán)隊(duì)必須盡力于30天后交付成果，團(tuán)隊(duì)每天用15分鐘開(kāi)會(huì)檢視每個(gè)成員的進(jìn)度與計(jì)劃，了解所遭遇的困難并設(shè)法排除，決定第二天的任務(wù)安排.SCRUM較為有特色的，是它特別強(qiáng)調(diào)開(kāi)發(fā)隊(duì)伍和管理層的交流協(xié)作。每天，開(kāi)發(fā)隊(duì)伍都會(huì)向管理層匯報(bào)進(jìn)度，如果有問(wèn)題，也會(huì)向管理層要求幫助解決。敏捷開(kāi)發(fā)介紹-scrumSCRUM開(kāi)發(fā)流程通常以30天18敏捷開(kāi)發(fā)介紹-scrumSCRUM是一個(gè)敏捷開(kāi)發(fā)框架

它由一個(gè)開(kāi)發(fā)過(guò)程，幾種角色以及一套規(guī)范的實(shí)施方法組成。它可以被運(yùn)用于軟件開(kāi)發(fā)，項(xiàng)目維護(hù)，也可以被用來(lái)作為一種管理敏捷項(xiàng)目的框架。Scrum定義了4種主要的角色： 1、產(chǎn)品擁有者（ProductOwner）：該角色負(fù)責(zé)產(chǎn)品的遠(yuǎn)景規(guī)劃，平衡所有利益相關(guān)者（stakeholder）的利益，確定不同的產(chǎn)品需求積壓的優(yōu)先級(jí)等。它是開(kāi)發(fā)團(tuán)隊(duì)和客戶或最終用戶之間的聯(lián)絡(luò)點(diǎn)。 2、利益相關(guān)者（Stakeholder）：該角色與產(chǎn)品之間有直接或間接的利益關(guān)系，通常是客戶或最終用戶代表。他們負(fù)責(zé)收集編寫產(chǎn)品需求，審查項(xiàng)目成果等。 3、Scrum專家（ScrumMaster）：Scrum專家負(fù)責(zé)指導(dǎo)開(kāi)發(fā)團(tuán)隊(duì)進(jìn)行Scrum開(kāi)發(fā)與實(shí)踐。它也是開(kāi)發(fā)團(tuán)隊(duì)與產(chǎn)品擁有者之間交流的聯(lián)絡(luò)點(diǎn)。 4、團(tuán)隊(duì)成員（TeamMember）：即項(xiàng)目開(kāi)發(fā)人員。敏捷開(kāi)發(fā)介紹-scrumSCRUM是一個(gè)敏捷開(kāi)發(fā)框架

它由一19SCRUM體系概覽迭代每30天DailySCRUM每24小時(shí)高優(yōu)先級(jí)可運(yùn)行的軟件工作項(xiàng)分解產(chǎn)品訂單ProductBacklog迭代訂單SprintBacklog新的功能增量迭代規(guī)劃會(huì)議SprintPlan一般不超過(guò)8小時(shí)。前4個(gè)小時(shí)：產(chǎn)品負(fù)責(zé)人向團(tuán)隊(duì)展示最高優(yōu)先級(jí)的產(chǎn)品，團(tuán)隊(duì)則向他詢問(wèn)產(chǎn)品Backlog的內(nèi)容、目的、含義及意圖。后4小時(shí)：團(tuán)隊(duì)計(jì)劃本Sprint的安排迭代復(fù)審會(huì)議SprintReview一般4個(gè)小時(shí)，由團(tuán)隊(duì)成員向產(chǎn)品負(fù)責(zé)人額其他利益相關(guān)人展示Sprint周期內(nèi)的產(chǎn)品開(kāi)發(fā)情況迭代回顧會(huì)議SprintRetrospective一般3個(gè)小時(shí)，ScrumMaster將鼓勵(lì)團(tuán)隊(duì)在SCRUM過(guò)程框架和實(shí)踐范圍內(nèi)，對(duì)開(kāi)發(fā)過(guò)程做出修改，使它在下一個(gè)Sprint周期中更加有效和令人愉快每日站立會(huì)議DailyScrumMeeting在簡(jiǎn)會(huì)上，每個(gè)成員主要回答三個(gè)問(wèn)題;–自上次SCRUM簡(jiǎn)會(huì)后的一天了（昨天），你做了什么?–從現(xiàn)在到下次SCRUM簡(jiǎn)會(huì)的一天里（今天），你要做什么?–在實(shí)現(xiàn)SCRUM及項(xiàng)目目標(biāo)的工作中，你遇到哪些困難嗎?產(chǎn)品負(fù)責(zé)人Scrum主管開(kāi)發(fā)團(tuán)隊(duì)SCRUM體系概覽迭代DailySCRUM高優(yōu)先級(jí)可運(yùn)行的20十二條慣例和規(guī)則On-SiteCustomer

（現(xiàn)場(chǎng)客戶）計(jì)劃項(xiàng)目（PlanningGame）頻繁地小規(guī)模發(fā)布軟件（SmallReleases）簡(jiǎn)單設(shè)計(jì)（SimpleDesign）測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TestDrivenDevelopment）持續(xù)集成（ContinuousIntegration）集體擁有代碼（CollectiveCodeOwnership）編程規(guī)范（CodingStandards）重構(gòu)（Refactoring）SystemMetaphor

（系統(tǒng)隱喻）PairProgramming

（結(jié)對(duì)編程）平穩(wěn)的工作效率（SustainablePace）十二條慣例和規(guī)則On-SiteCustomer集體擁有代碼21敏捷開(kāi)發(fā)-SCRUM名詞解釋backlog：可以預(yù)知的所有任務(wù)，包括功能性的和非功能性的所有任務(wù)。sprint：一次跌代開(kāi)發(fā)的時(shí)間周期，一般最多以30天為一個(gè)周期。在這段時(shí)間內(nèi)，開(kāi)發(fā)團(tuán)隊(duì)需要完成一個(gè)制定的backlog，并且最終成果是一個(gè)增量的，可以交付的產(chǎn)品。sprintbacklog：

一個(gè)sprint周期內(nèi)所需要完成的任務(wù)。scrumMaster：負(fù)責(zé)監(jiān)督整個(gè)Scrum進(jìn)程，修訂計(jì)劃的一個(gè)團(tuán)隊(duì)成員。time-box：一個(gè)用于開(kāi)會(huì)時(shí)間段。比如每個(gè)dailyscrummeeting的time-box為15分鐘。

敏捷開(kāi)發(fā)-SCRUM名詞解釋backlog：可以預(yù)知的所有任22敏捷開(kāi)發(fā)-SCRUM名詞解釋sprintplanningmeeting：

在啟動(dòng)每個(gè)sprint前召開(kāi)。一般為一天時(shí)間（8小時(shí)）。該會(huì)議需要制定的任務(wù)是：產(chǎn)品Owner和團(tuán)隊(duì)成員將backlog分解成小的功能模塊，決定在即將進(jìn)行的sprint里需要完成多少小功能模塊，確定好這個(gè)ProductBacklog的任務(wù)優(yōu)先級(jí)。另外，該會(huì)議還需詳細(xì)地討論如何能夠按照需求完成這些小功能模塊。制定的這些模塊的工作量以小時(shí)計(jì)算。DailyScrummeeting：

開(kāi)發(fā)團(tuán)隊(duì)成員召開(kāi)，一般為15分鐘。每個(gè)開(kāi)發(fā)成員需要向ScrumMaster匯報(bào)三個(gè)項(xiàng)目：今天完成了什么？遇到了障礙無(wú)法繼續(xù)下去？明天要做什么？通過(guò)該會(huì)議，團(tuán)隊(duì)成員可以相互了解項(xiàng)目進(jìn)度。Sprintreviewmeeting：

在每個(gè)Sprint結(jié)束后，這個(gè)Team將這個(gè)Sprint的工作成果演示給ProductOwner和其他相關(guān)的人員。一般該會(huì)議為4小時(shí)。

Sprintretrospectivemeeting：對(duì)剛結(jié)束的Sprint進(jìn)行總結(jié)。會(huì)議的參與人員為團(tuán)隊(duì)開(kāi)發(fā)的內(nèi)部人員。一般該會(huì)議為3小時(shí)。敏捷開(kāi)發(fā)-SCRUM名詞解釋sprintplanning23敏捷開(kāi)發(fā)-實(shí)施Scrum的過(guò)程介紹確定SprintBacklog

將整個(gè)產(chǎn)品的backlog分解成SprintBacklog，這個(gè)SprintBacklog是按照目前的人力物力條件可以完成的。召開(kāi)sprintplanningmeeting

劃分，確定這個(gè)Sprint內(nèi)需要完成的任務(wù)，標(biāo)注任務(wù)的優(yōu)先級(jí)并分配給每個(gè)成員。注意這里的任務(wù)是以小時(shí)計(jì)算的，并不是按人天計(jì)算。sprint開(kāi)發(fā)周期

進(jìn)入sprint開(kāi)發(fā)周期，在這個(gè)周期內(nèi)，每天需要召開(kāi)DailyScrummeeting。成果演示整個(gè)sprint周期結(jié)束，召開(kāi)Sprintreviewmeeting，將成果演示給ProductOwner?；仡?/p>

團(tuán)隊(duì)成員最后召開(kāi)Sprintretrospectivemeeting，總結(jié)問(wèn)題和經(jīng)驗(yàn)。下一次Sprint。敏捷開(kāi)發(fā)-實(shí)施Scrum的過(guò)程介紹確定SprintBack24敏捷開(kāi)發(fā)每日會(huì)議：目的：信息同步平臺(tái)，非交流問(wèn)題、討論問(wèn)題渠道。形式：固定地點(diǎn)、時(shí)間的站立會(huì)議。生產(chǎn)率估算燃盡線敏捷開(kāi)發(fā)每日會(huì)議：25敏捷開(kāi)發(fā)原則和方法迭代式開(kāi)發(fā)。即整個(gè)開(kāi)發(fā)過(guò)程被分為幾個(gè)迭代周期，每個(gè)迭代周期是一個(gè)定長(zhǎng)或不定長(zhǎng)的時(shí)間塊每個(gè)迭代周期持續(xù)的時(shí)間一般較短，通常為一到六周。增量交付。產(chǎn)品是在每個(gè)迭代周期結(jié)束時(shí)被逐步交付使用，而不是在整個(gè)開(kāi)發(fā)過(guò)程結(jié)束的時(shí)候一次性交付使用。每次交付的都是可以被部署到用戶應(yīng)用環(huán)境中被用戶使用的、能給用戶帶來(lái)即時(shí)效益和價(jià)值的產(chǎn)品。開(kāi)發(fā)團(tuán)隊(duì)和用戶反饋推動(dòng)產(chǎn)品開(kāi)發(fā)。敏捷開(kāi)發(fā)方法主張用戶能夠全程參與到整個(gè)開(kāi)發(fā)過(guò)程中。這使需求變化和用戶反饋能被動(dòng)態(tài)管理并及時(shí)集成到產(chǎn)品中。同時(shí)，團(tuán)隊(duì)對(duì)于用戶的需求也能及時(shí)提供反饋意見(jiàn)。持續(xù)集成。新的功能或需求變化總是盡可能頻繁地被整合到產(chǎn)品中。一些項(xiàng)目是在每個(gè)迭代周期結(jié)束的時(shí)候集成，有些項(xiàng)目則每天都在這么做。開(kāi)發(fā)團(tuán)隊(duì)自我管理。擁有一個(gè)積極的、自我管理的、具備自由交流風(fēng)格的開(kāi)發(fā)團(tuán)隊(duì)，是每個(gè)敏捷項(xiàng)目必不可少的條件。人是敏捷開(kāi)發(fā)的核心。敏捷開(kāi)發(fā)總是以人為中心建立開(kāi)發(fā)的過(guò)程和機(jī)制，而非把過(guò)程和機(jī)制強(qiáng)加給人。敏捷開(kāi)發(fā)原則和方法迭代式開(kāi)發(fā)。即整個(gè)開(kāi)發(fā)過(guò)程被分為幾個(gè)迭代周26敏捷實(shí)踐原則1.我們最優(yōu)先要做的是通過(guò)盡早的、持續(xù)的交付有價(jià)值的軟件來(lái)使客戶滿意。有統(tǒng)計(jì)數(shù)字表明，越早、越頻繁地向用戶交付軟件，軟件的質(zhì)量就越好。敏捷實(shí)踐原則1.我們最優(yōu)先要做的是通過(guò)盡早的、持續(xù)的交付有價(jià)27敏捷實(shí)踐原則2.即使到了開(kāi)發(fā)的后期，也歡迎改變需求。敏捷過(guò)程利用變化來(lái)為客戶創(chuàng)造競(jìng)爭(zhēng)優(yōu)勢(shì)。

使用敏捷過(guò)程的開(kāi)發(fā)組織歡迎需求的變化，因?yàn)樗麄冋J(rèn)為需求變化可以讓他們更多地了解市場(chǎng)。敏捷開(kāi)發(fā)組織采用各種方法和技術(shù)，使軟件的結(jié)構(gòu)高度靈活，需求的變化對(duì)系統(tǒng)的影響被最小化。3.經(jīng)常性的交付可以工作的軟件，交付的間隔可以從幾個(gè)星期到幾個(gè)月，交付的時(shí)間間隔越短越好。敏捷開(kāi)發(fā)組織不滿足于交付文檔和計(jì)劃，他們的目標(biāo)是頻繁地交付可以工作的軟件，從而滿足客戶的需要。敏捷實(shí)踐原則2.即使到了開(kāi)發(fā)的后期，也歡迎改變需求。敏捷過(guò)程28敏捷實(shí)踐原則4.整個(gè)項(xiàng)目開(kāi)發(fā)期間，業(yè)務(wù)人員和開(kāi)發(fā)人員必須天天都在一起工作。敏捷實(shí)踐原則4.整個(gè)項(xiàng)目開(kāi)發(fā)期間，業(yè)務(wù)人員和開(kāi)發(fā)人員必須天天29敏捷實(shí)踐原則5.圍繞被激勵(lì)起來(lái)的個(gè)體來(lái)構(gòu)建項(xiàng)目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。在一個(gè)敏捷項(xiàng)目中，人員被認(rèn)為是最重要的因素，其它所有因素（過(guò)程、環(huán)境、管理等）都被認(rèn)為是次要的，當(dāng)這些因素對(duì)人員造成不利影響時(shí)，就必須對(duì)其做出改變。例如，如果某些過(guò)程步驟對(duì)團(tuán)隊(duì)人員來(lái)說(shuō)是個(gè)障礙，那么過(guò)程就必須改變。敏捷實(shí)踐原則5.圍繞被激勵(lì)起來(lái)的個(gè)體來(lái)構(gòu)建項(xiàng)目。給他們提供所30敏捷實(shí)踐原則6.在團(tuán)隊(duì)內(nèi)部，最有效率和最有效果的信息傳達(dá)方式就是面對(duì)面的交流。在敏捷項(xiàng)目中，默認(rèn)的交流方式就是交談，而不是文檔。文檔在必要的時(shí)候會(huì)被創(chuàng)建，但不會(huì)試圖用文檔來(lái)捕獲所有項(xiàng)目信息。敏捷實(shí)踐原則6.在團(tuán)隊(duì)內(nèi)部，最有效率和最有效果的信息傳達(dá)方式31敏捷實(shí)踐原則7.可以工作的軟件是進(jìn)度的主要度量標(biāo)準(zhǔn)。

對(duì)于敏捷項(xiàng)目來(lái)說(shuō)，進(jìn)度的度量標(biāo)準(zhǔn)是當(dāng)前可滿足用戶需求的軟件的量，而不是當(dāng)前項(xiàng)目所處的階段、文檔數(shù)量或基礎(chǔ)代碼的數(shù)量。項(xiàng)目完成了30%的含義是用戶所需功能的30%已被實(shí)現(xiàn)。8.敏捷過(guò)程提倡可持續(xù)開(kāi)發(fā)。出資人、開(kāi)發(fā)者和用戶應(yīng)該共同維持一個(gè)穩(wěn)定的開(kāi)發(fā)速度。敏捷小組會(huì)在整個(gè)項(xiàng)目開(kāi)發(fā)期間保持一個(gè)適當(dāng)?shù)摹⒖沙掷m(xù)的開(kāi)發(fā)速度，從而維持最高的質(zhì)量標(biāo)準(zhǔn)。敏捷項(xiàng)目不會(huì)使開(kāi)發(fā)者感到疲憊不堪。敏捷實(shí)踐原則7.可以工作的軟件是進(jìn)度的主要度量標(biāo)準(zhǔn)。

8.敏32敏捷實(shí)踐原則9.對(duì)卓越技術(shù)和良好設(shè)計(jì)的不斷追求有助于提高敏捷性。敏捷開(kāi)發(fā)團(tuán)隊(duì)認(rèn)為提高質(zhì)量會(huì)加快開(kāi)發(fā)進(jìn)度。因此要保持軟件的精簡(jiǎn)和健壯。敏捷開(kāi)發(fā)團(tuán)隊(duì)的每個(gè)成員都要致力于開(kāi)發(fā)高質(zhì)量的代碼，不能把混亂的、底質(zhì)量的代碼留到以后去修改。10.簡(jiǎn)單——盡量減少工作量的藝術(shù)是至關(guān)重要的。敏捷開(kāi)發(fā)方法總是選擇達(dá)到目標(biāo)的最簡(jiǎn)單途徑。敏捷開(kāi)發(fā)團(tuán)隊(duì)并不花費(fèi)大量精力去預(yù)防將來(lái)可能出現(xiàn)的問(wèn)題，而是專注于對(duì)當(dāng)前工作采用最簡(jiǎn)單、最高質(zhì)量的解決方案，并相信將來(lái)如果問(wèn)題出現(xiàn)，可以很方便地進(jìn)行修改。敏捷實(shí)踐原則9.對(duì)卓越技術(shù)和良好設(shè)計(jì)的不斷追求有助于提高敏捷33敏捷實(shí)踐原則11.最好的架構(gòu)、需求和設(shè)計(jì)都出自于自組織的團(tuán)隊(duì)。敏捷開(kāi)發(fā)團(tuán)隊(duì)是自組織的團(tuán)隊(duì)。職責(zé)并非是從團(tuán)隊(duì)外部加給每一個(gè)團(tuán)隊(duì)成員，而是團(tuán)隊(duì)作為一個(gè)整體接受職責(zé)并自己決定怎樣去完成它。12.每隔一定時(shí)間，團(tuán)隊(duì)都要總結(jié)怎樣更有效率地工作，然后相應(yīng)地調(diào)整自己的行為。

敏捷開(kāi)發(fā)團(tuán)隊(duì)認(rèn)識(shí)到環(huán)境在不斷地改變，因此團(tuán)隊(duì)也需要不斷地對(duì)組織、規(guī)則、慣例和各種關(guān)系進(jìn)行調(diào)整，以保持自身的敏捷性。敏捷實(shí)踐原則11.最好的架構(gòu)、需求和設(shè)計(jì)都出自于自組織的團(tuán)隊(duì)34敏捷開(kāi)發(fā)宣言

極限編程的思想體現(xiàn)了適應(yīng)客戶需求的快速變化，激發(fā)開(kāi)發(fā)者的熱情，也是目前敏捷開(kāi)發(fā)思維的重要支持者。

2001年，17名編程大師分別代表極限編程、Scrum(“棒球”團(tuán)隊(duì)開(kāi)發(fā)模式)、特征驅(qū)動(dòng)開(kāi)發(fā)、動(dòng)態(tài)系統(tǒng)開(kāi)發(fā)方法、自適應(yīng)軟件開(kāi)發(fā)、水晶方法、實(shí)用編程等開(kāi)發(fā)流派，發(fā)表“敏捷軟件開(kāi)發(fā)”宣言。敏捷軟件開(kāi)發(fā)是一個(gè)開(kāi)發(fā)軟件的管理新模式，用來(lái)替代以文檔驅(qū)動(dòng)開(kāi)發(fā)的瀑布開(kāi)發(fā)模式。敏捷方式也稱輕量級(jí)開(kāi)發(fā)方法。敏捷軟件開(kāi)發(fā)宣言內(nèi)容：

◆個(gè)體和交互勝過(guò)過(guò)程和工具

◆可以工作的軟件勝過(guò)面面具到的文檔

◆可戶合作勝過(guò)合同談判

◆響應(yīng)變化勝過(guò)遵循計(jì)劃核心理念：適應(yīng)和以人為本客戶合作勝過(guò)合同談判響應(yīng)變化勝過(guò)遵循計(jì)劃可以工作的軟件勝過(guò)面面俱到的文檔個(gè)體和交互勝過(guò)過(guò)程和工具知識(shí)和技能文化和氛圍自組織團(tuán)隊(duì)開(kāi)放的心態(tài)敏捷開(kāi)發(fā)宣言 極限編程的思想體現(xiàn)了適應(yīng)客戶需求的快速變化，激35敏捷項(xiàng)目的關(guān)鍵可用的軟件信息的透明化清晰的迭代目標(biāo)擁抱變化發(fā)現(xiàn)并解決問(wèn)題敏捷項(xiàng)目的關(guān)鍵可用的軟件信息的透明化清晰的迭代目標(biāo)擁抱變化發(fā)36布置環(huán)境既有無(wú)隔墻隔板的工作場(chǎng)地，也又單獨(dú)的工作間；一個(gè)足夠?qū)挸ǖ牡胤焦┐蠹议_(kāi)會(huì)；足夠大的白板；足夠長(zhǎng)的電腦桌，可以讓兩個(gè)人并排坐在同一臺(tái)電腦前面；每一個(gè)人都能很容易地看到其他人并和他們交流。一些白紙或者卡片。更理想的條件：POP電視機(jī)VideoGame落地玻璃窗布置環(huán)境既有無(wú)隔墻隔板的工作場(chǎng)地，也又單獨(dú)的工作間；37啟動(dòng)開(kāi)發(fā)迭代計(jì)劃CRC卡設(shè)計(jì)承擔(dān)Task分解TaskPair進(jìn)行測(cè)試驅(qū)動(dòng)的開(kāi)發(fā)持續(xù)集成和發(fā)布迭代結(jié)束發(fā)布計(jì)劃產(chǎn)生Story評(píng)估Story開(kāi)始提煉Metaphor多個(gè)迭代多期計(jì)劃啟動(dòng)開(kāi)發(fā)迭代計(jì)劃CRC卡設(shè)計(jì)承擔(dān)Task分解TaskPair38最佳實(shí)踐-管理發(fā)布(Release)：每一期開(kāi)發(fā)結(jié)束時(shí)提交給用戶的一個(gè)可運(yùn)行的系統(tǒng)。迭代(Iteration)：一期開(kāi)發(fā)過(guò)程中的一個(gè)開(kāi)發(fā)周期。它有明確的目標(biāo)，計(jì)劃和實(shí)現(xiàn)方式，它包含了需求分析、設(shè)計(jì)、編程、測(cè)試等完整的開(kāi)發(fā)過(guò)程。一個(gè)迭代的長(zhǎng)度為1到3周。在一期開(kāi)發(fā)過(guò)程中，所有迭代的長(zhǎng)度是相同的，比如都是3周。小發(fā)布(SmallRelease)：處于開(kāi)發(fā)中的系統(tǒng)，每集成一個(gè)新功能，都可以稱為一個(gè)小發(fā)布。理想開(kāi)發(fā)時(shí)間：估計(jì)完成一項(xiàng)工作所需的持續(xù)工作時(shí)間，不考慮意外因素。最佳實(shí)踐-管理發(fā)布(Release)：每一期開(kāi)發(fā)結(jié)束時(shí)提交給39最佳實(shí)踐-需求SPIKE：對(duì)不確定的需求和設(shè)計(jì)等，通過(guò)寫一些程序、進(jìn)行詳細(xì)設(shè)計(jì)或者演算等等方式做探測(cè)和嘗試，以確定可行性。這些探測(cè)過(guò)程稱為SPIKE。UserStory：是對(duì)用戶的一個(gè)需求的一段簡(jiǎn)潔清晰的描述，該段描述有三個(gè)屬性，即商業(yè)優(yōu)先級(jí)、開(kāi)發(fā)時(shí)間和風(fēng)險(xiǎn)。從某個(gè)角度看，XP過(guò)程是面向U