敏捷開發(fā)管理方法_第1頁
敏捷開發(fā)管理方法_第2頁
敏捷開發(fā)管理方法_第3頁
敏捷開發(fā)管理方法_第4頁
敏捷開發(fā)管理方法_第5頁
已閱讀5頁,還剩53頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、敏捷開發(fā)流程與方法敏捷開發(fā)流程與方法Strictly Private and ConfidentialBGCN交付管理部目錄1.1敏捷的起源2敏捷系列敏捷系列1.2敏捷方法體系1敏捷開發(fā)簡(jiǎn)介敏捷開發(fā)簡(jiǎn)介3 敏捷開發(fā)的誤區(qū)敏捷開發(fā)的誤區(qū)1.3敏捷宣言1.4為什么要敏捷? 敏捷開發(fā)的起源上個(gè)世紀(jì)上個(gè)世紀(jì)90年代年代2001年年2004年以后年以后萌芽-產(chǎn)生敏捷方法敏捷方法是從上個(gè)世紀(jì)敏捷方法是從上個(gè)世紀(jì)90年代開始發(fā)展起來的年代開始發(fā)展起來的一組方法學(xué)的總稱,包一組方法學(xué)的總稱,包括極限編程等等。這些括極限編程等等。這些方法學(xué)之間有一些差異,方法學(xué)之間有一些差異,但是差異不是特別大但是差異不是特別

2、大正規(guī)成立敏捷聯(lián)盟每種方法學(xué)的領(lǐng)導(dǎo)人共每種方法學(xué)的領(lǐng)導(dǎo)人共同起草了敏捷軟件開發(fā)同起草了敏捷軟件開發(fā)宣言,總結(jié)出方法之間宣言,總結(jié)出方法之間的共同點(diǎn),最終就是價(jià)的共同點(diǎn),最終就是價(jià)值,并且用敏捷這個(gè)詞值,并且用敏捷這個(gè)詞給這種方法學(xué)一個(gè)統(tǒng)稱給這種方法學(xué)一個(gè)統(tǒng)稱發(fā)展開始廣為流行500強(qiáng)公司中眾多公司強(qiáng)公司中眾多公司應(yīng)用敏捷應(yīng)用敏捷;如如HP,Microsoft,IBM等等 什么是敏捷開發(fā)? 敏捷開發(fā)(Agile Development)是一種以人為核心、迭代、循序漸進(jìn)的開發(fā)方法。q子子項(xiàng)項(xiàng)目特征目特征 - 各個(gè)子項(xiàng)目的成果都經(jīng)過測(cè)試各個(gè)子項(xiàng)目的成果都經(jīng)過測(cè)試 - 具備集成和可運(yùn)行的特征具備集成和可

3、運(yùn)行的特征 - 小項(xiàng)目相互聯(lián)系小項(xiàng)目相互聯(lián)系 目錄1.1敏捷的起源1.2敏捷方法體系1敏捷開發(fā)簡(jiǎn)介敏捷開發(fā)簡(jiǎn)介1.3敏捷宣言1.4為什么要敏捷?2敏捷系列敏捷系列3 敏捷開發(fā)的誤區(qū)敏捷開發(fā)的誤區(qū) 敏捷方法 XP -eXtreme Programing極限編程: 思想源自Kent Beck和Ward Cunningham在軟件項(xiàng)目中的合作經(jīng)歷。 SCRUM: 是一種迭代的增量化過程,用于產(chǎn)品開發(fā)或工作管理 。 水晶方法Crystal: 由Alistair Cockburn在1990年代末提出。把不同類型的項(xiàng)目采用不同的方法。 FDD特性驅(qū)動(dòng) Feature Driven Development,

4、 由Peter Coad、Jeff de Luca 、Eric Lefebvre共同開發(fā),是一套針對(duì)中小型軟件開發(fā)項(xiàng)目的開發(fā)模式。它強(qiáng)調(diào)的是簡(jiǎn)化、實(shí)用、 易于被開發(fā)團(tuán)隊(duì)接受,適用于需求經(jīng)常變動(dòng)的項(xiàng)目。 DSDM-Dynamic System Development Methodology, 它倡導(dǎo)以業(yè)務(wù)為核心,快速而有效地進(jìn)行系統(tǒng)開發(fā), 在英國等歐洲國家比較流行。 ASD-Adaptive Software Development, 由Jim Highsmith在1999年正式提出。ASD強(qiáng)調(diào)開發(fā)方法的適應(yīng)性(Adaptive) 敏捷開發(fā)特點(diǎn) 敏捷開發(fā)包括很多方法,例如XP和FDD,同重量級(jí)的

5、文檔驅(qū)動(dòng)的開發(fā)過程相比較,敏捷方法在靈活性等方面更有吸引力。這個(gè)方法的創(chuàng)始人強(qiáng)調(diào)了在軟件實(shí)踐過程中的變更而不是孤立的進(jìn)行一些實(shí)踐。 很多方法很難獨(dú)立的使用。如:測(cè)試驅(qū)動(dòng)的開發(fā),結(jié)對(duì)開發(fā),計(jì)劃調(diào)整周期以及持續(xù)改進(jìn),不過,后來的結(jié)果證實(shí),這些方法都取得了成功。 使用這些方法并不能保證一定成功。開發(fā)者的經(jīng)驗(yàn)和技術(shù)仍舊是影響開發(fā)結(jié)果的最主要因素。對(duì)于合適的人,基于敏捷原則的開發(fā)方法可以產(chǎn)生更好的結(jié)果,同時(shí)形成一個(gè)愉快地、有激情的工作環(huán)境目錄1.1敏捷的起源1.2敏捷方法體系1敏捷開發(fā)簡(jiǎn)介敏捷開發(fā)簡(jiǎn)介1.3敏捷宣言1.4為什么要敏捷?2敏捷系列敏捷系列3 敏捷開發(fā)的誤區(qū)敏捷開發(fā)的誤區(qū) 敏捷宣言核心理念核

6、心理念:適應(yīng)和以人為本適應(yīng)和以人為本客戶合作勝過合客戶合作勝過合同談判同談判響應(yīng)變化勝過遵響應(yīng)變化勝過遵循計(jì)劃循計(jì)劃可以工作的軟件勝過面可以工作的軟件勝過面面俱到的文檔面俱到的文檔個(gè)體和交互個(gè)體和交互勝過過勝過過程和工具程和工具敏捷規(guī)則最高目標(biāo)是能持續(xù)地、及早地向客戶交付軟件;擁抱變化;頻繁地發(fā)布可運(yùn)行的軟件;客戶和開發(fā)人員在一起工作;以人為本;最重要的衡量開發(fā)過程的手段,是可工作的軟件;穩(wěn)定的開發(fā)速度;敏捷高效的設(shè)計(jì);簡(jiǎn)單有效;重視Teamwork;積極的調(diào)整。 目錄1.1敏捷的起源1.2敏捷方法體系1敏捷開發(fā)簡(jiǎn)介敏捷開發(fā)簡(jiǎn)介1.3敏捷宣言1.4為什么要敏捷?2敏捷系列敏捷系列3 敏捷開發(fā)的

7、誤區(qū)敏捷開發(fā)的誤區(qū) 我們?yōu)槭裁葱枰艚蓓?xiàng)目為什么失???軟件工程試圖解決這些問題:對(duì)用戶需求理解得不清楚,甚至有對(duì)用戶需求理解得不清楚,甚至有錯(cuò)誤;錯(cuò)誤;用戶需求變化;用戶需求變化;軟件很難維護(hù)或擴(kuò)展;軟件很難維護(hù)或擴(kuò)展;在項(xiàng)目后期階段發(fā)現(xiàn)很嚴(yán)重的設(shè)計(jì)在項(xiàng)目后期階段發(fā)現(xiàn)很嚴(yán)重的設(shè)計(jì)缺陷;缺陷;軟件質(zhì)量或性能不合格;軟件質(zhì)量或性能不合格;Test - Build - ReleaseTest - Build - Release過程的可操過程的可操作性、可維護(hù)性很差;作性、可維護(hù)性很差;人員流動(dòng);人員流動(dòng); 為了為了規(guī)范化開發(fā)過程,引進(jìn)傳統(tǒng)工程的規(guī)范化開發(fā)過程,引進(jìn)傳統(tǒng)工程的概念(瀑布型);概念(瀑布

8、型);為了理解需求,提出原型法;為了理解需求,提出原型法;為了提高設(shè)計(jì)開發(fā)的效率和擴(kuò)展性,提為了提高設(shè)計(jì)開發(fā)的效率和擴(kuò)展性,提出重用和面向?qū)ο蟮人枷?;出重用和面向?qū)ο蟮人枷?;為了讓開發(fā)過程更靈活,提出了開發(fā)框?yàn)榱俗岄_發(fā)過程更靈活,提出了開發(fā)框架的概念;架的概念;為了降低風(fēng)險(xiǎn),為了降低風(fēng)險(xiǎn),提出了風(fēng)險(xiǎn)評(píng)估、成本提出了風(fēng)險(xiǎn)評(píng)估、成本控制和增量開發(fā)等思想;控制和增量開發(fā)等思想; 我們?yōu)槭裁葱枰艚?部門: 1) 培養(yǎng)團(tuán)隊(duì)合作精神,穩(wěn)定開發(fā)隊(duì)伍; 2) 提高開發(fā)人員的水平; 3) 提高項(xiàng)目成功率,降低開發(fā)成本,提升軟件開發(fā)效率 項(xiàng)目經(jīng)理: 1) 更好地和用戶溝通,更清晰地理解用戶需求; 2) 更充分地

9、使用資源,更科學(xué)地調(diào)配資源,更精確地掌握開發(fā)進(jìn)度。 系統(tǒng)分析設(shè)計(jì): 1) 設(shè)計(jì)更加完善; 2) 更有效地更新知識(shí),得到其他成員更多的尊重。 程序員: 1) 學(xué)習(xí)系統(tǒng)設(shè)計(jì)和項(xiàng)目管理; 2) 提高學(xué)習(xí)和工作效率,受到重視,減少加班時(shí)間,工作更高效 誰在用敏捷 Fortune 500 公司中成功應(yīng)用XP的公司包括Ford,Daimler-Chrysler,F(xiàn)irst Union National Bank,IBM,HP等等。 通信業(yè)NS,Ericsson, Alcatel等都號(hào)稱在轉(zhuǎn)向敏捷 更多是小規(guī)模開發(fā)隊(duì)伍(小規(guī)模開發(fā)隊(duì)伍 小規(guī)模項(xiàng)目) 越來越多的公司開始使用敏捷開發(fā)過程敏捷開發(fā)成功的因素知識(shí)和

10、技能知識(shí)和技能文化和氛圍文化和氛圍自組織團(tuán)隊(duì)自組織團(tuán)隊(duì)開放的心態(tài)開放的心態(tài) 目錄2.1XP -eXtreme Programing2敏捷系列敏捷系列2.2SCRUM1敏捷開發(fā)簡(jiǎn)介敏捷開發(fā)簡(jiǎn)介3 敏捷開發(fā)的誤區(qū)敏捷開發(fā)的誤區(qū) 敏捷實(shí)踐l在敏捷的兩個(gè)門派:在敏捷的兩個(gè)門派:XP、Scrum中,整理歸納了很多可以用中,整理歸納了很多可以用于協(xié)助軟件開發(fā)的實(shí)踐,后面統(tǒng)稱為敏捷實(shí)踐。于協(xié)助軟件開發(fā)的實(shí)踐,后面統(tǒng)稱為敏捷實(shí)踐。 什么是XPXP is a lightweight methodology for small to medium sized teams developing software i

11、n the face of vague or rapidly changing requirements. - Kent Beck.Kent Beck, Ward Cunningham, Martin Fowler, Ron Jeffries于2000年創(chuàng)立XP是軟件開發(fā)過程中的紀(jì)律,它規(guī)定你:必須在編程前些測(cè)試,必須兩個(gè)人一起編程,必須遵守編程規(guī)范。XP是把最好的實(shí)踐經(jīng)驗(yàn)提取出來,形成了一個(gè)嶄新的開發(fā)方法。Extreme Programming 什么是XPExtreme Programmingl極限的含義:極限的含義:軟件開發(fā)中的優(yōu)點(diǎn)發(fā)揮到極致(Kent Beck).lXP:給程序員提供了明

12、確的方法,使得程序員盡管面對(duì)需求的改變,卻能夠從容應(yīng)對(duì),即使著重變化發(fā)生在項(xiàng)目的后期,仍然能夠編出代碼。lXP核心:核心:溝通、簡(jiǎn)明、反饋和勇氣 lXP重視溝通,客戶、開發(fā)人員、管理者共同組成團(tuán)隊(duì)。lXP是一個(gè)實(shí)踐系統(tǒng)是一個(gè)實(shí)踐系統(tǒng)p13個(gè)實(shí)踐lXP方法的貢獻(xiàn)方法的貢獻(xiàn)p以擁抱變化的思想,協(xié)作的團(tuán)隊(duì),簡(jiǎn)單的規(guī)則等為原則的13個(gè)具體實(shí)踐p是知名度最高的敏捷開發(fā)方法 XP的計(jì)劃/反饋循環(huán) XP開發(fā)工作流 XP的關(guān)鍵實(shí)踐:編程方法編程方法交付和管理交付和管理小組實(shí)踐小組實(shí)踐 XP的關(guān)鍵實(shí)踐結(jié)對(duì)編程結(jié)對(duì)編程測(cè)試驅(qū)動(dòng)開發(fā)測(cè)試驅(qū)動(dòng)開發(fā)重構(gòu)重構(gòu)簡(jiǎn)單簡(jiǎn)單設(shè)計(jì)設(shè)計(jì)代碼集體所有代碼集體所有編碼標(biāo)準(zhǔn)編碼標(biāo)準(zhǔn)穩(wěn)定高速

13、的步伐穩(wěn)定高速的步伐持續(xù)集成持續(xù)集成隱喻隱喻現(xiàn)場(chǎng)客戶現(xiàn)場(chǎng)客戶完整的完整的團(tuán)隊(duì)團(tuán)隊(duì)小規(guī)模發(fā)小規(guī)模發(fā)布布計(jì)劃游戲計(jì)劃游戲編程方法編程方法小組實(shí)踐小組實(shí)踐交付和管理交付和管理交付和管理交付和管理 交付和管理1:完整的團(tuán)隊(duì)(Whole Team)Product Manager/Project managerCoachTeam leadDevelopersTrackerTester(On-Site) Customersl所有的小組成員應(yīng)在同一個(gè)工作地點(diǎn)工作。l成員中必須有一個(gè)用戶代表(On-site User),由他/她來提出需求,確定開發(fā)優(yōu)先級(jí),把握開發(fā)的動(dòng)向。l通常還設(shè)一個(gè)教練(Coach)角色,來

14、指導(dǎo)XP方法的實(shí)施及與外部的溝通協(xié)調(diào)等。l小組每個(gè)成員都應(yīng)圍繞用戶代表,充分貢獻(xiàn)自己的技能。 交付和管理2: 計(jì)劃游戲(Planning Game)增加/改變需求產(chǎn)生和評(píng)估User Story發(fā)布計(jì)劃迭代計(jì)劃1迭代計(jì)劃2迭代計(jì)劃n實(shí)施迭代1實(shí)施迭代2實(shí)施迭代n1.N個(gè)發(fā)布個(gè)發(fā)布探索階段探索階段計(jì)劃階段計(jì)劃階段調(diào)整階段調(diào)整階段調(diào)整開發(fā)速度 / 內(nèi)容 交付和管理3:現(xiàn)場(chǎng)客戶(On-Site Customer) 客戶是Team成員,在開發(fā)現(xiàn)場(chǎng)和開發(fā)人員一起工作。 傳統(tǒng)的客戶任務(wù)一般是講解需求,運(yùn)行驗(yàn)收測(cè)試,接收發(fā)布的系統(tǒng)。XP新增加的任務(wù): (1) 寫User Story (2) 評(píng)估User St

15、ory的商業(yè)優(yōu)先級(jí) (3) 為每個(gè)User Story定義驗(yàn)收測(cè)試 (4) 計(jì)劃開發(fā)內(nèi)容 (5) 調(diào)控開發(fā)過程 (6) 建立商業(yè)模型,把隱藏在客戶需求下的原則傳授給開發(fā)人員 (8) 程序員分擔(dān)任務(wù)的過程支解了對(duì)他們商業(yè)模型的理解 (9) 參加設(shè)計(jì)過程 (10)和程序員一起找出Metaphor,導(dǎo)引設(shè)計(jì)方向 (11)在Metaphor的幫助下,定義更有效更實(shí)際的功能測(cè)試,給程序員的設(shè)計(jì)制定了規(guī)范 交付和管理4:小規(guī)模發(fā)布降低開發(fā)風(fēng)險(xiǎn)。降低開發(fā)風(fēng)險(xiǎn)。 保證客戶有足夠的依據(jù)調(diào)控開保證客戶有足夠的依據(jù)調(diào)控開發(fā)過程發(fā)過程(增加、刪除或改變?cè)黾?、刪除或改變User Story)??蛻羰褂冒l(fā)布的系統(tǒng),可以保

16、證客戶使用發(fā)布的系統(tǒng),可以保證頻繁地反饋和交流。頻繁地反饋和交流。 發(fā)布過程應(yīng)該盡可能地發(fā)布過程應(yīng)該盡可能地自動(dòng)化、規(guī)范化。自動(dòng)化、規(guī)范化。不斷地發(fā)布可用的系統(tǒng)可以告不斷地發(fā)布可用的系統(tǒng)可以告訴客戶你在做正確的事情。訴客戶你在做正確的事情。低風(fēng)險(xiǎn)低風(fēng)險(xiǎn)智能化智能化適應(yīng)調(diào)整適應(yīng)調(diào)整頻繁交流頻繁交流知會(huì)客戶知會(huì)客戶頻繁發(fā)布頻繁發(fā)布經(jīng)過驗(yàn)證經(jīng)過驗(yàn)證 隨著開發(fā)的推進(jìn),發(fā)布越來隨著開發(fā)的推進(jìn),發(fā)布越來越頻繁。越頻繁。 所有的發(fā)布都要經(jīng)過功所有的發(fā)布都要經(jīng)過功能測(cè)試。能測(cè)試。小組實(shí)踐小組實(shí)踐 小組實(shí)踐1:持續(xù)集成(Continuous integration) 持續(xù)集成指不斷地把完成的功能模塊整合在一起。

17、目的在于不斷獲得客戶反饋以及盡早發(fā)現(xiàn)BUG。 隨時(shí)整合,越頻繁越好;集成及測(cè)試過程的自動(dòng)化程度越高越好。 “A Test a day ,takes the bugs away”-Siemens失敗通過時(shí)間功 能 測(cè) 試 小組實(shí)踐1:持續(xù)集成(Continuous integration)1自動(dòng)化編譯自動(dòng)化編譯質(zhì)量度量質(zhì)量度量23自動(dòng)化測(cè)試自動(dòng)化測(cè)試持續(xù)反饋持續(xù)反饋 團(tuán)隊(duì)實(shí)踐2:隱喻(System Metaphor) “The system metaphor is a story that everyone - customers, programmers, and managers -can

18、tell about how the system works.” Kent Beck Team將Domain/Sub-Domain Model,Design/Sub-Design Model以及一些關(guān)鍵概念等等抽象化為比喻。通過這些比喻,加強(qiáng)客戶和程序員之間的相互理解,消化積累知識(shí),指導(dǎo)設(shè)計(jì)開發(fā)的方向。 例:Market 發(fā)布/瀏覽,價(jià)格洽談,生成和履行合同;String,Tree,Package,Chartroom,Spider,Robot ;電影后期制作 郵遞 電影院播放電影。 小組實(shí)踐2:隱喻(System Metaphor) Metaphor的形成過程,是客戶建立并抽象商業(yè)模型和商業(yè)

19、概念的過程,是程序員建立并抽象設(shè)計(jì)模型和設(shè)計(jì)概念的過程。 Metaphor使客戶和程序員用共通的模型和語言進(jìn)行交流 “One Team, one language”。 Metaphor可以幫助減少“知識(shí)泄露”和“支解知識(shí)”。 Metaphor是設(shè)計(jì)過程的航標(biāo) 真正靈活有效的設(shè)計(jì)是針對(duì)商業(yè)原則的設(shè)計(jì),而不是針對(duì)商業(yè)原則表現(xiàn)形式的設(shè)計(jì),更不是脫離商業(yè)需求目的的學(xué)術(shù)設(shè)計(jì)。 隨著開發(fā)的繼續(xù),Team會(huì)找到更好的Metaphor。這是知識(shí)細(xì)化、深化的結(jié)果,是“持續(xù)學(xué)習(xí)”(Continuous learning)的過程;是對(duì)商業(yè)模型和設(shè)計(jì)模型的持續(xù)重構(gòu)。 小組實(shí)踐3:編碼標(biāo)準(zhǔn)(Coding standar

20、ds) 編碼標(biāo)準(zhǔn)的目的: 防止團(tuán)隊(duì)被一些無關(guān)緊要的愚蠢爭(zhēng)論搞得不知所措。不要預(yù)先花費(fèi)太多時(shí)間不要預(yù)先花費(fèi)太多時(shí)間目標(biāo)應(yīng)該是團(tuán)隊(duì)中沒有人辨認(rèn)各自的代碼目標(biāo)應(yīng)該是團(tuán)隊(duì)中沒有人辨認(rèn)各自的代碼以團(tuán)隊(duì)為單位對(duì)某一標(biāo)準(zhǔn)達(dá)成協(xié)議,然后遵守這一標(biāo)準(zhǔn)以團(tuán)隊(duì)為單位對(duì)某一標(biāo)準(zhǔn)達(dá)成協(xié)議,然后遵守這一標(biāo)準(zhǔn)不是事無巨細(xì)的規(guī)則列表,而是確保代碼可交流的指導(dǎo)方針不是事無巨細(xì)的規(guī)則列表,而是確保代碼可交流的指導(dǎo)方針編碼標(biāo)準(zhǔn)開始時(shí)應(yīng)很簡(jiǎn)單,然后根據(jù)團(tuán)隊(duì)經(jīng)驗(yàn)逐步進(jìn)化編碼標(biāo)準(zhǔn)開始時(shí)應(yīng)很簡(jiǎn)單,然后根據(jù)團(tuán)隊(duì)經(jīng)驗(yàn)逐步進(jìn)化創(chuàng)建能夠工作的最簡(jiǎn)單標(biāo)準(zhǔn),然后逐步發(fā)展創(chuàng)建能夠工作的最簡(jiǎn)單標(biāo)準(zhǔn),然后逐步發(fā)展只制訂適合本團(tuán)隊(duì)的只制訂適合本團(tuán)隊(duì)的 小組實(shí)

21、踐4:集體擁有代碼 “我們”的代碼,而不是“我”的代碼。 任何人可以改動(dòng)任何一段代碼,但改動(dòng)后的代碼必須通過所有相關(guān)的測(cè)試。 簡(jiǎn)單設(shè)計(jì),編碼標(biāo)準(zhǔn)和結(jié)對(duì)編程,使閱讀和修改Team內(nèi)其他人的代碼變得實(shí)際可行。 思考:同公司信息安全可能有沖突?在一定范圍內(nèi)進(jìn)行集體擁有代碼還是可行的在一定范圍內(nèi)進(jìn)行集體擁有代碼還是可行的 小組實(shí)踐5:穩(wěn)定高速的步伐(40-Hour Week)“每天早晨都感到有活力有激情,每天晚上都感到疲憊而滿足。” - Kent Beck 8:00 AM Standup MeetingPair UpTester自我測(cè)試自我測(cè)試編碼編碼重構(gòu)重構(gòu)集成并納入集成并納入CI 驗(yàn)證驗(yàn)證5:30

22、PM 結(jié)束結(jié)束測(cè)試用例編程方法編程方法 編程方法1:測(cè)試驅(qū)動(dòng)開發(fā)(TDD)失敗通過時(shí)間單元測(cè)試 100% 通過設(shè)計(jì)先先寫寫單元測(cè)試單元測(cè)試重構(gòu)運(yùn)行運(yùn)行單元測(cè)試單元測(cè)試編程發(fā)現(xiàn)BUG集成先先寫寫功能測(cè)試功能測(cè)試User Story運(yùn)行運(yùn)行功能測(cè)試功能測(cè)試 編程方法2:重構(gòu)(Refactoring )減少重復(fù)設(shè)計(jì),優(yōu)化設(shè)計(jì)結(jié)構(gòu),提高技術(shù)上的重用性和可擴(kuò)展性。減少重復(fù)設(shè)計(jì),優(yōu)化設(shè)計(jì)結(jié)構(gòu),提高技術(shù)上的重用性和可擴(kuò)展性。重構(gòu)和編程前的計(jì)劃型設(shè)計(jì)重構(gòu)和編程前的計(jì)劃型設(shè)計(jì)(Planned Design)結(jié)合,使結(jié)合,使XP的簡(jiǎn)單設(shè)計(jì)可行有效。的簡(jiǎn)單設(shè)計(jì)可行有效。XP提倡毫不留情的重構(gòu)提倡毫不留情的重構(gòu)(Re

23、factor mercilessly)。任何人可以重構(gòu)任何代碼,前提是重構(gòu)后的代碼一定要通過任何人可以重構(gòu)任何代碼,前提是重構(gòu)后的代碼一定要通過100%測(cè)試單元測(cè)試后才能被測(cè)試單元測(cè)試后才能被Check-in??梢愿鶕?jù)需要,將一個(gè)迭代的全部目標(biāo)定為重構(gòu)??梢愿鶕?jù)需要,將一個(gè)迭代的全部目標(biāo)定為重構(gòu)。不要太在意什么是最簡(jiǎn)單的設(shè)計(jì)不要太在意什么是最簡(jiǎn)單的設(shè)計(jì) 愿意在最后重構(gòu),比知道如何做簡(jiǎn)單的設(shè)計(jì)重要得多。愿意在最后重構(gòu),比知道如何做簡(jiǎn)單的設(shè)計(jì)重要得多。在在Metaphor指引下的重構(gòu),是為商業(yè)模型服務(wù)的。不要把重構(gòu)變成不斷的盲目精簡(jiǎn)代碼。指引下的重構(gòu),是為商業(yè)模型服務(wù)的。不要把重構(gòu)變成不斷的盲目精

24、簡(jiǎn)代碼。 編程方法3:簡(jiǎn)單設(shè)計(jì) 簡(jiǎn)單設(shè)計(jì) Do the simplest thing that could possibly work;You arent going to need it 如果沒有它和眾多慣例規(guī)則之間的耦合,XP的演化設(shè)計(jì)就蛻化成CODE-FIX。 XP的演化設(shè)計(jì)是在Up-front design和Refactoring之間找到新的平衡。需求 分析 設(shè)計(jì) 編碼 測(cè)試 集成 使用和維護(hù)PlannedDesignXP Design變化導(dǎo)致的成本增加軟件研發(fā)異動(dòng)曲線 編程方法3:簡(jiǎn)單設(shè)計(jì) 標(biāo)準(zhǔn)(依重要性):通過所有測(cè)試,可讀性高的代碼,避免重復(fù),最少數(shù)量的類別或方法。 System

25、 Metaphor給設(shè)計(jì)提供了指引,加強(qiáng)Team對(duì)設(shè)計(jì)的理解; 第一個(gè)迭代搭建了基本的系統(tǒng)框架。 以后的迭代過程,是在反饋和編程的基礎(chǔ)上做交互式設(shè)計(jì),減少了設(shè)計(jì)的投機(jī)性。 迭代過程中的CRC卡幫助Team交流設(shè)計(jì)思想,簡(jiǎn)化了設(shè)計(jì)文檔。 構(gòu)對(duì)設(shè)計(jì)進(jìn)行優(yōu)化。 XP 認(rèn)為設(shè)計(jì)非常重要,因此應(yīng)該是一個(gè)持續(xù)的事務(wù)。我們總是先嘗試使用能認(rèn)為設(shè)計(jì)非常重要,因此應(yīng)該是一個(gè)持續(xù)的事務(wù)。我們總是先嘗試使用能夠工作的最簡(jiǎn)單的設(shè)計(jì),然后隨著現(xiàn)實(shí)的不斷顯現(xiàn)來更改它。夠工作的最簡(jiǎn)單的設(shè)計(jì),然后隨著現(xiàn)實(shí)的不斷顯現(xiàn)來更改它。 對(duì)簡(jiǎn)單設(shè)計(jì)的需求并不是說所有設(shè)計(jì)都很小,也不表示它們是無足輕重的。對(duì)簡(jiǎn)單設(shè)計(jì)的需求并不是說所有設(shè)計(jì)都

26、很小,也不表示它們是無足輕重的。它們只不過需要盡可能簡(jiǎn)單,但是仍能工作。它們只不過需要盡可能簡(jiǎn)單,但是仍能工作。 編程方法4: 結(jié)對(duì)編程(Pair Programming) 所有設(shè)計(jì)決策都牽涉到至少兩個(gè)人。 至少有兩個(gè)人熟悉系統(tǒng)的每一部分。 幾乎不可能出現(xiàn)兩個(gè)人同時(shí)疏忽測(cè)試或其它任務(wù)。 改變各對(duì)的組合在可以在團(tuán)隊(duì)范圍內(nèi)傳播知識(shí)。 代碼總是由至少一人復(fù)查。 結(jié)對(duì)的編程比單獨(dú)編程更有效。 XP中最有爭(zhēng)議的實(shí)踐之一 目錄2.1XP -eXtreme Programing2敏捷系列敏捷系列2.2SCRUM1敏捷開發(fā)簡(jiǎn)介敏捷開發(fā)簡(jiǎn)介3敏捷與敏捷與CMMCMM4 敏捷開發(fā)的誤區(qū)敏捷開發(fā)的誤區(qū) SCRUM

27、SCRUM來源于橄欖球運(yùn)動(dòng),指:“在橄欖球比賽中,雙方前鋒站在一起緊密相連,當(dāng)球在他們之間投擲時(shí)他們奮力爭(zhēng)球?!?Scrum提供了一種經(jīng)驗(yàn)方法,它使得團(tuán)隊(duì)成員能夠獨(dú)立地,集中地在創(chuàng)造性的環(huán)境下工作。它發(fā)現(xiàn)了軟件工程的社會(huì)意義。這一過程是迅速,有適應(yīng)性,自組織的,它代表了從順序開發(fā)過程以來的重大變化。(Ken Schwaber) Scrum是一種靈活的軟件管理過程,它可以幫助駕馭迭代、遞增的軟件開發(fā)過程。Scrum于1995年提出,并在2001年同其他方法論一起組成“敏捷聯(lián)盟(Agile Alliance)” 。 Scrum這個(gè)輕量的過程可以作為包裝器,也就是說你可以把Scrum與其它靈活的過程

28、框架組合起來。 SCRUM的過程圖 SCRUM實(shí)踐 1. Scrum團(tuán)隊(duì):5-7個(gè)人的小項(xiàng)目團(tuán)隊(duì), 團(tuán)隊(duì)的負(fù)責(zé)人可能擔(dān)負(fù)起Scrum Master的角色。2. Backlog: 急待完成的一系列任務(wù),包括:未細(xì)化的產(chǎn)品功能要求、Bugs、缺陷、用戶提出的改進(jìn)、具競(jìng)爭(zhēng)力的功能及技術(shù)升級(jí)等,按優(yōu)先級(jí)定義出來,這些任務(wù)可能不是完整的,甚至可能隨時(shí)會(huì)更改或添加。3. Sprint(沖刺): 通常為30天的迭代時(shí)間,把Backlog中的每一項(xiàng)安排在Sprint中,由團(tuán)隊(duì)估算出所需要的時(shí)間(按小時(shí)記)。 每一次Sprint之后,一定要有可以交付使用的功能。4. Scrum會(huì)議: 這是與傳統(tǒng)方式最大的區(qū)別,

29、每天15-20分鐘的Scrum會(huì)議,通常在每天的同一時(shí)間和同一個(gè)房間內(nèi)舉行。Scrum團(tuán)隊(duì)所有人都參加,也可以有旁聽者(但不允許旁聽者指手劃腳)。 在這個(gè)15分鐘的會(huì)議上,Scrum Master會(huì)詢問每個(gè)成員三個(gè)問題:a) 自上次Scrum會(huì)議后的1天里你做了什么?b) 從現(xiàn)在到下次Scrum會(huì)議的1天時(shí)間里你準(zhǔn)備做什么?c) 你在工作中遇到了哪些困難?每個(gè)成員在Backlog條目上所花費(fèi)的時(shí)間會(huì)被記錄到Spring backlog中。 Scrum Master在會(huì)上對(duì)存在的問題提出即時(shí)的解決方案或指導(dǎo),使團(tuán)隊(duì)不斷向著目標(biāo)前進(jìn)。Scrum會(huì)議不同于項(xiàng)目會(huì)議,對(duì)團(tuán)隊(duì)來說,它起到了快速簡(jiǎn)報(bào)的作用

30、。5. 通過Sprint Backlog的分析,可以了解Backlog的進(jìn)度,盡早的了解所發(fā)生的問題6. 管理者不在是項(xiàng)目或者團(tuán)隊(duì)的老板, 而是幫助團(tuán)隊(duì)解決問題的協(xié)調(diào)者或是助手。7. 每一次Sprint之后要review,團(tuán)隊(duì)按照既定的Sprint Backlog目標(biāo)來演示完成的內(nèi)容。 Scrum中的3、3、3待開發(fā)任務(wù)列表待開發(fā)任務(wù)列表(The Sprint Backlog)待修復(fù)缺陷列表待修復(fù)缺陷列表(The defect backlog)進(jìn)度圖、燃盡圖進(jìn)度圖、燃盡圖(Brun Down Chart)Product OwnerScrum Master團(tuán)隊(duì)成員團(tuán)隊(duì)成員(Scrum Team)

31、迭代計(jì)劃會(huì)議迭代計(jì)劃會(huì)議(Sprint Planning Meeting)每日晨會(huì)每日晨會(huì)(Daily Scrum Meeting)迭代回顧會(huì)議迭代回顧會(huì)議(Sprint Review Meeting) Product Backlog SPRINT劃分示意 Sprint會(huì)議根據(jù)Backlog,制定每次Sprint的計(jì)劃 目錄2敏捷系列敏捷系列1敏捷開發(fā)簡(jiǎn)介敏捷開發(fā)簡(jiǎn)介3 敏捷開發(fā)的誤區(qū)敏捷開發(fā)的誤區(qū)討論誤區(qū)一:敏捷是一個(gè)”過程誤區(qū)二:敏捷僅是個(gè)軟件過程誤區(qū)三:敏捷是反文檔的 誤區(qū)四:為了敏捷而敏捷誤區(qū)五:重做就是重構(gòu)誤區(qū)一:敏捷是一個(gè)”過程l敏捷不是一個(gè)過程,是一類過程的統(tǒng)稱,它們有一個(gè)共性,就是符合敏捷不是一個(gè)過程,是一類過程的統(tǒng)稱,它們有一個(gè)共性,就是符合敏捷價(jià)值觀,遵循敏捷的原則。敏捷價(jià)值觀,遵循敏捷的原則。誤區(qū)二:敏捷僅是個(gè)軟件過程l敏捷相對(duì)以前的軟件工程最大的革新之處在于把人的作用提高到了過程至上,敏捷相對(duì)以前的軟件工程最大的革新之處在于把人的作用提高到了過程至上,正如敏捷宣言的第一條正如敏捷宣言的第一條“個(gè)體和交互勝過過程和工具個(gè)體和交互勝過

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論