1、矯捷開發(fā)流程與方法Strictly Private and ConfidentialBGCN交付管理部目錄1.1矯捷的來源2矯捷系列1.2矯捷方法體系1矯捷開發(fā)簡介3 矯捷開發(fā)的誤區(qū)1.3矯捷宣言1.4為什么要矯捷? 矯捷開發(fā)的來源上個世紀90年代2001年2004年以后萌芽-產(chǎn)生矯捷方法矯捷方法是從上個世紀90年代開場開展起來的一組方法學的總稱，包括極限編程等等。這些方法學之間有一些差別，但是差別不是特別大正規(guī)成立矯捷聯(lián)盟每種方法學的指點人共同起草了矯捷軟件開發(fā)宣言，總結(jié)出方法之間的共同點，最終就是價值，并且用矯捷這個詞給這種方法學一個統(tǒng)稱開展開場廣為流行500強公司中眾多公司運用矯捷;如H

2、P,Microsoft,IBM等 什么是矯捷開發(fā)？矯捷開發(fā)Agile Development是一種以人為中心、迭代、循序漸進的開發(fā)方法。子工程特征 - 各個子工程的成果都經(jīng)過測試 - 具備集成和可運轉(zhuǎn)的特征 - 小工程相互聯(lián)絡 目錄1.1矯捷的來源1.2矯捷方法體系1矯捷開發(fā)簡介1.3矯捷宣言1.4為什么要矯捷?2矯捷系列3 矯捷開發(fā)的誤區(qū) 矯捷方法XP -eXtreme Programing極限編程:思想源自Kent Beck和Ward Cunningham在軟件工程中的協(xié)作閱歷。SCRUM：是一種迭代的增量化過程，用于產(chǎn)品開發(fā)或任務管理 。水晶方法Crystal:由Alistair Coc

3、kburn在1990年代末提出。把不同類型的工程采用不同的方法。 FDD特性驅(qū)動 Feature Driven Development，由Peter Coad、Jeff de Luca 、Eric Lefebvre共同開發(fā)，是一套針對中小型軟件開發(fā)工程的開發(fā)方式。它強調(diào)的是簡化、適用、 易于被開發(fā)團隊接受，適用于需求經(jīng)常變動的工程。 DSDM-Dynamic System Development Methodology，它倡導以業(yè)務為中心，快速而有效地進展系統(tǒng)開發(fā)， 在英國等歐洲國家比較流行。ASD-Adaptive Software Development，由Jim Highsmith在19

4、99年正式提出。ASD強調(diào)開發(fā)方法的順應性Adaptive 矯捷開發(fā)特點 矯捷開發(fā)包括很多方法，例如XP和FDD，同分量級的文檔驅(qū)動的開發(fā)過程相比較，矯捷方法在靈敏性等方面更有吸引力。這個方法的開創(chuàng)人強調(diào)了在軟件實際過程中的變卦而不是孤立的進展一些實際。 很多方法很難獨立的運用。如:測試驅(qū)動的開發(fā)，結(jié)對開發(fā)，方案調(diào)整周期以及繼續(xù)改良，不過，后來的結(jié)果證明，這些方法都獲得了勝利。 運用這些方法并不能保證一定勝利。開發(fā)者的閱歷和技術(shù)仍舊是影響開發(fā)結(jié)果的最主要要素。對于適宜的人，基于矯捷原那么的開發(fā)方法可以產(chǎn)生更好的結(jié)果，同時構(gòu)成一個愉快地、有熱情的任務環(huán)境目錄1.1矯捷的來源1.2矯捷方法體系1矯

5、捷開發(fā)簡介1.3矯捷宣言1.4為什么要矯捷?2矯捷系列3 矯捷開發(fā)的誤區(qū) 矯捷宣言中心思念：順應和以人為本客戶協(xié)作勝過合同談判呼應變化勝過遵照方案可以任務的軟件勝過面面俱到的文檔個體和交互勝過過程和工具矯捷規(guī)那么最高目的是能繼續(xù)地、及早地向客戶交付軟件；擁抱變化；頻繁地發(fā)布可運轉(zhuǎn)的軟件；客戶和開發(fā)人員在一同任務；以人為本；最重要的衡量開發(fā)過程的手段，是可任務的軟件；穩(wěn)定的開發(fā)速度；矯捷高效的設計；簡單有效；注重Teamwork；積極的調(diào)整。 目錄1.1矯捷的來源1.2矯捷方法體系1矯捷開發(fā)簡介1.3矯捷宣言1.4為什么要矯捷?2矯捷系列3 矯捷開發(fā)的誤區(qū) 我們?yōu)槭裁葱枨蟪C捷項目為什么失敗？軟件

6、工程試圖解決這些問題：對用戶需求理解得不清楚，甚至有錯誤；用戶需求變化；軟件很難維護或擴展；在項目后期階段發(fā)現(xiàn)很嚴重的設計缺陷；軟件質(zhì)量或性能不合格；Test - Build - Release過程的可操作性、可維護性很差；人員流動； 為了規(guī)范化開發(fā)過程，引進傳統(tǒng)工程的概念（瀑布型）；為了理解需求，提出原型法；為了提高設計開發(fā)的效率和擴展性，提出重用和面向?qū)ο蟮人枷耄粸榱俗岄_發(fā)過程更靈活，提出了開發(fā)框架的概念；為了降低風險，提出了風險評估、成本控制和增量開發(fā)等思想； 我們?yōu)槭裁葱枨蟪C捷部門： 1) 培育團隊協(xié)作精神，穩(wěn)定開發(fā)隊伍； 2) 提高開發(fā)人員的程度； 3) 提高工程勝利率，降低開發(fā)本錢

7、，提升軟件開發(fā)效率工程經(jīng)理： 1) 更好地和用戶溝通，更明晰地了解用戶需求； 2) 更充分地運用資源，更科學地調(diào)配資源，更準確地掌握開發(fā)進度。系統(tǒng)分析設計： 1) 設計更加完善； 2) 更有效地更新知識，得到其他成員更多的尊重。程序員： 1) 學習系統(tǒng)設計和工程管理； 2) 提高學習和任務效率，遭到注重，減少加班時間，任務更高效 誰在用矯捷Fortune 500 公司中勝利運用XP的公司包括Ford，Daimler-Chrysler，F(xiàn)irst Union National Bank，IBM，HP等等。通訊業(yè)NS，Ericsson, Alcatel等都號稱在轉(zhuǎn)向矯捷更多是小規(guī)模開發(fā)隊伍小規(guī)模開

8、發(fā)隊伍 小規(guī)模工程越來越多的公司開場運用矯捷開發(fā)過程矯捷開發(fā)勝利的要素知識和技藝文化和氣氛自組織團隊開放的心態(tài) 目錄2.1XP -eXtreme Programing2矯捷系列2.2SCRUM1矯捷開發(fā)簡介3 矯捷開發(fā)的誤區(qū) 矯捷實際在矯捷的兩個門派：XP、Scrum中，整理歸納了很多可以用于協(xié)助軟件開發(fā)的實際，后面統(tǒng)稱為矯捷實際。 什么是XPXP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing re

9、quirements. - Kent Beck.Kent Beck, Ward Cunningham, Martin Fowler, Ron Jeffries于2000年創(chuàng)建XP是軟件開發(fā)過程中的紀律，它規(guī)定他：必需在編程前些測試，必需兩個人一同編程，必需遵守編程規(guī)范。XP是把最好的實際閱歷提取出來，構(gòu)成了一個嶄新的開發(fā)方法。Extreme Programming 什么是XPExtreme Programming極限的含義：軟件開發(fā)中的優(yōu)點發(fā)揚到極致(Kent Beck).XP：給程序員提供了明確的方法，使得程序員雖然面對需求的改動，卻可以從容應對，即使著重變化發(fā)生在工程的后期，依然可以編出代

10、碼。XP中心：溝通、簡明、反響和勇氣 XP注重溝通，客戶、開發(fā)人員、管理者共同組成團隊。XP是一個實際系統(tǒng)13個實際XP方法的奉獻以擁抱變化的思想，協(xié)作的團隊，簡單的規(guī)那么等為原那么的13個詳細實際是知名度最高的矯捷開發(fā)方法 XP的方案/反響循環(huán) XP開發(fā)任務流 XP的關鍵實際:編程方法交付和管理小組實際 XP的關鍵實際結(jié)對編程測試驅(qū)動開發(fā)重構(gòu)簡單設計代碼集體一切編碼規(guī)范穩(wěn)定高速的步伐繼續(xù)集成隱喻現(xiàn)場客戶完好的團隊小規(guī)模發(fā)布方案游戲編程方法小組實際交付和管理交付和管理 交付和管理1:完好的團隊(Whole Team)ProductManager/ProjectmanagerCoachTeaml

11、eadDevelopersTrackerTester(On-Site) Customers一切的小組成員應在同一個任務地點任務。成員中必需有一個用戶代表On-site User,由他/她來提出需求，確定開發(fā)優(yōu)先級，把握開發(fā)的動向。通常還設一個教練Coach角色，來指點XP方法的實施及與外部的溝通協(xié)調(diào)等。小組每個成員都應圍繞用戶代表，充分奉獻本人的技藝。 交付和管理2: 方案游戲(Planning Game)添加/改動需求產(chǎn)生和評價User Story發(fā)布方案迭代方案1迭代方案2迭代方案n實施迭代1實施迭代2實施迭代n1.N個發(fā)布探求階段方案階段調(diào)整階段調(diào)整開發(fā)速度 / 內(nèi)容 交付和管理3:現(xiàn)場

12、客戶(On-Site Customer) 客戶是Team成員，在開發(fā)現(xiàn)場和開發(fā)人員一同任務。 傳統(tǒng)的客戶義務普通是講解需求，運轉(zhuǎn)驗收測試，接納發(fā)布的系統(tǒng)。XP新添加的義務： (1) 寫User Story (2) 評價User Story的商業(yè)優(yōu)先級 (3) 為每個User Story定義驗收測試 (4) 方案開發(fā)內(nèi)容 (5) 調(diào)控開發(fā)過程 (6) 建立商業(yè)模型，把隱藏在客戶需求下的原那么教授給開發(fā)人員 (8) 程序員分擔義務的過程支解了對他們商業(yè)模型的了解 (9) 參與設計過程 (10)和程序員一同找出Metaphor，導引設計方向 (11)在Metaphor的協(xié)助下，定義更有效更實踐的功能

13、測試，給程序員的設計制定了規(guī)范 交付和管理4:小規(guī)模發(fā)布降低開發(fā)風險。 保證客戶有足夠的根據(jù)調(diào)控開發(fā)過程(添加、刪除或改動User Story)。客戶運用發(fā)布的系統(tǒng)，可以保證頻繁地反響和交流。 發(fā)布過程應該盡能夠地自動化、規(guī)范化。不斷地發(fā)布可用的系統(tǒng)可以通知客戶他在做正確的事情。低風險智能化順應調(diào)整頻繁交流知會客戶頻繁發(fā)布經(jīng)過驗證 隨著開發(fā)的推進，發(fā)布越來越頻繁。 一切的發(fā)布都要經(jīng)過功能測試。小規(guī)模發(fā)布小組實際 小組實際1:繼續(xù)集成(Continuous integration)繼續(xù)集成指不斷地把完成的功能模塊整合在一同。目的在于不斷獲得客戶反響以及盡早發(fā)現(xiàn)BUG。隨時整合，越頻繁越好；集成及

14、測試過程的自動化程度越高越好。“A Test a day ,takes the bugs away-Siemens失敗經(jīng)過時間功 能 測 試 小組實際1:繼續(xù)集成(Continuous integration)1自動化編譯質(zhì)量度量23自動化測試繼續(xù)反響 團隊實際2:隱喻(System Metaphor) “The system metaphor is a story that everyone - customers, programmers, and managers -can tell about how the system works. Kent Beck Team將Domain/Su

15、b-Domain Model，Design/Sub-Design Model以及一些關鍵概念等等籠統(tǒng)化為比喻。經(jīng)過這些比喻，加強客戶和程序員之間的相互了解，消化積累知識，指點設計開發(fā)的方向。 例：Market 發(fā)布/閱讀，價錢洽談，生成和履行合同；String，Tree，Package，Chartroom，Spider，Robot ；電影后期制造 郵遞 電影院播放電影。 小組實際2:隱喻(System Metaphor)Metaphor的構(gòu)成過程，是客戶建立并籠統(tǒng)商業(yè)模型和商業(yè)概念的過程，是程序員建立并籠統(tǒng)設計模型和設計概念的過程。Metaphor使客戶和程序員用共通的模型和言語進展交流 “O

16、ne Team, one language。 Metaphor可以協(xié)助減少“知識泄露和“支解知識。Metaphor是設計過程的航標 真正靈敏有效的設計是針對商業(yè)原那么的設計，而不是針對商業(yè)原那么表現(xiàn)方式的設計，更不是脫離商業(yè)需求目的的學術(shù)設計。隨著開發(fā)的繼續(xù)，Team會找到更好的Metaphor。這是知識細化、深化的結(jié)果，是“繼續(xù)學習(Continuous learning)的過程；是對商業(yè)模型和設計模型的繼續(xù)重構(gòu)。 小組實際3:編碼規(guī)范(Coding standards)編碼規(guī)范的目的： 防止團隊被一些無關緊要的愚笨爭論搞得不知所措。不要預先破費太多時間目的應該是團隊中沒有人識別各自的代碼以

17、團隊為單位對某一規(guī)范達成協(xié)議，然后遵守這一規(guī)范不是事無巨細的規(guī)那么列表，而是確保代碼可交流的指點方針七個原那么編碼規(guī)范開場時應很簡單，然后根據(jù)團隊閱歷逐漸進化創(chuàng)建可以任務的最簡單規(guī)范，然后逐漸開展只制定適宜本團隊的 小組實際4:集體擁有代碼“我們的代碼，而不是“我的代碼。任何人可以改動任何一段代碼，但改動后的代碼必需經(jīng)過一切相關的測試。簡單設計，編碼規(guī)范和結(jié)對編程，使閱讀和修正Team內(nèi)其他人的代碼變得實踐可行。思索：同公司信息平安能夠有沖突？在一定范圍內(nèi)進展集體擁有代碼還是可行的 小組實際5:穩(wěn)定高速的步伐(40-Hour Week)“每天早晨都感到有活力有熱情，每天晚上都感到疲憊而滿足。

18、- Kent Beck 8:00 AM Standup MeetingPair UpTester自我測試編碼重構(gòu)集成并納入CI 驗證5:30PM 終了測試用例編程方法 編程方法1:測試驅(qū)動開發(fā)(TDD)失敗經(jīng)過時間單元測試 100% 經(jīng)過設計先寫單元測試重構(gòu)運轉(zhuǎn)單元測試編程發(fā)現(xiàn)BUG集成先寫功能測試User Story運轉(zhuǎn)功能測試 編程方法2:重構(gòu)(Refactoring )減少反復設計，優(yōu)化設計構(gòu)造，提高技術(shù)上的重用性和可擴展性。重構(gòu)和編程前的方案型設計(Planned Design)結(jié)合，使XP的簡單設計可行有效。XP提倡毫不留情的重構(gòu)(Refactor mercilessly)。任何人可

19、以重構(gòu)任何代碼，前提是重構(gòu)后的代碼一定要經(jīng)過100%測試單元測試后才干被Check-in。可以根據(jù)需求，將一個迭代的全部目的定為重構(gòu)。不要太在意什么是最簡單的設計 情愿在最后重構(gòu)，比知道如何做簡單的設計重要得多。在Metaphor指引下的重構(gòu)，是為商業(yè)模型效力的。不要把重構(gòu)變成不斷的盲目精簡代碼。 編程方法3:簡單設計 簡單設計 Do the simplest thing that could possibly work；You arent going to need it假設沒有它和眾多慣例規(guī)那么之間的耦合，XP的演化設計就蛻化成CODE-FIX。XP的演化設計是在Up-front desi

20、gn和Refactoring之間找到新的平衡。需求 分析 設計 編碼 測試 集成 運用和維護PlannedDesignXP Design變化導致的本錢添加軟件研發(fā)異動曲線 編程方法3:簡單設計 規(guī)范(依重要性)：經(jīng)過一切測試，可讀性高的代碼，防止反復，最少數(shù)量的類別或方法。System Metaphor給設計提供了指引，加強Team對設計的了解；第一個迭代搭建了根本的系統(tǒng)框架。以后的迭代過程，是在反響和編程的根底上做交互式設計，減少了設計的投機性。迭代過程中的CRC卡協(xié)助Team交流設計思想，簡化了設計文檔。構(gòu)對設計進展優(yōu)化。 XP 以為設計非常重要，因此應該是一個繼續(xù)的事務。我們總是先嘗試運

21、用可以任務的最簡單的設計，然后隨著現(xiàn)實的不斷顯現(xiàn)來更改它。 對簡單設計的需求并不是說一切設計都很小，也不表示它們是無足輕重的。它們只不過需求盡能夠簡單，但是仍能任務。 編程方法4: 結(jié)對編程(Pair Programming)一切設計決策都牽涉到至少兩個人。至少有兩個人熟習系統(tǒng)的每一部分。幾乎不能夠出現(xiàn)兩個人同時忽略測試或其它義務。改動各對的組合在可以在團隊范圍內(nèi)傳播知識。代碼總是由至少一人復查。結(jié)對的編程比單獨編程更有效。 XP中最有爭議的實際之一 目錄2.1XP -eXtreme Programing2矯捷系列2.2SCRUM1矯捷開發(fā)簡介3矯捷與CMM4 矯捷開發(fā)的誤區(qū) SCRUMSCR

22、UM來源于橄欖球運動，指：“在橄欖球競賽中，雙方前鋒站在一同嚴密相連，當球在他們之間投擲時他們奮力爭球。 Scrum提供了一種閱歷方法，它使得團隊成員可以獨立地，集中地在發(fā)明性的環(huán)境下任務。它發(fā)現(xiàn)了軟件工程的社會意義。這一過程是迅速，有順應性，自組織的，它代表了從順序開發(fā)過程以來的艱苦變化。(Ken Schwaber)Scrum是一種靈敏的軟件管理過程，它可以協(xié)助駕馭迭代、遞增的軟件開發(fā)過程。Scrum于1995年提出，并在2001年同其他方法論一同組成“矯捷聯(lián)盟Agile Alliance 。Scrum這個輕量的過程可以作為包裝器，也就是說他可以把Scrum與其它靈敏的過程框架組合起來。 S

23、CRUM的過程圖 SCRUM實際 1. Scrum團隊：5-7個人的小工程團隊， 團隊的擔任人能夠擔負起Scrum Master的角色。2. Backlog: 急待完成的一系列義務，包括：未細化的產(chǎn)品功能要求、Bugs、缺陷、用戶提出的改良、具競爭力的功能及技術(shù)晉級等，按優(yōu)先級定義出來，這些義務能夠不是完好的，甚至能夠隨時會更改或添加。3. Sprint(沖刺): 通常為30天的迭代時間，把Backlog中的每一項安排在Sprint中，由團隊估算出所需求的時間按小時記。 每一次Sprint之后，一定要有可以交付運用的功能。4. Scrum會議: 這是與傳統(tǒng)方式最大的區(qū)別，每天15-20分鐘的S

24、crum會議，通常在每天的同一時間和同一個房間內(nèi)舉行。Scrum團隊一切人都參與，也可以有旁聽者但不允許旁聽者指手劃腳。 在這個15分鐘的會議上，Scrum Master會訊問每個成員三個問題:a) 自上次Scrum會議后的1天里他做了什么？b) 從如今到下次Scrum會議的1天時間里他預備做什么？c) 他在任務中遇到了哪些困難？每個成員在Backlog條目上所破費的時間會被記錄到Spring backlog中。 Scrum Master在會上對存在的問題提出即時的處理方案或指點，使團隊不斷向著目的前進。Scrum會議不同于工程會議，對團隊來說，它起到了快速簡報的作用。5. 經(jīng)過Sprint

25、Backlog的分析，可以了解Backlog的進度，盡早的了解所發(fā)生的問題6. 管理者不在是工程或者團隊的老板, 而是協(xié)助團隊處理問題的協(xié)調(diào)者或是助手。7. 每一次Sprint之后要review，團隊按照既定的Sprint Backlog目的來演示完成的內(nèi)容。 Scrum中的3、3、3三種工件三種會議三種角色待開發(fā)義務列表(The Sprint Backlog)待修復缺陷列表(The defect backlog)進度圖、燃盡圖(Brun Down Chart)Product OwnerScrum Master團隊成員(Scrum Team迭代方案會議(Sprint Planning Meeting)每日晨會(Daily Scrum Meeting)迭代回想會議(Sprint Review Meeting) Product Backlog SPRINT劃分表示 Sprint會議根據(jù)Backlog，制定每次Sprint的方案 目錄2矯捷系列1矯捷開發(fā)簡介3 矯捷開發(fā)的誤區(qū)討論誤區(qū)一:矯捷是一個過程誤區(qū)二:矯捷僅是個軟件過程誤區(qū)三:矯捷是反文檔的 誤區(qū)四:為了矯捷而矯捷誤區(qū)五:重做就是重構(gòu)誤區(qū)一:矯捷是一個過程矯捷不是一個過程，是一類過程的統(tǒng)稱，它們有一個共性，就是符合矯捷價值觀，遵照矯捷的原那么。誤區(qū)二:矯捷僅是個軟件過程矯捷相對以前的軟件工