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

2、大正規成立敏捷聯盟每種方法學的領導人共每種方法學的領導人共同起草了敏捷軟件開發同起草了敏捷軟件開發宣言，總結出方法之間宣言，總結出方法之間的共同點，最終就是價的共同點，最終就是價值，并且用敏捷這個詞值，并且用敏捷這個詞給這種方法學一個統稱給這種方法學一個統稱發展開始廣為流行500強公司中眾多公司強公司中眾多公司應用敏捷應用敏捷;如如HP,Microsoft,IBM等等 什么是敏捷開發？ 敏捷開發（Agile Development）是一種以人為核心、迭代、循序漸進的開發方法。q子子項項目特征目特征 - 各個子項目的成果都經過測試各個子項目的成果都經過測試 - 具備集成和可運行的特征具備集成和可

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

4、 由Peter Coad、Jeff de Luca 、Eric Lefebvre共同開發，是一套針對中小型軟件開發項目的開發模式。它強調的是簡化、實用、 易于被開發團隊接受，適用于需求經常變動的項目。 DSDM-Dynamic System Development Methodology， 它倡導以業務為核心，快速而有效地進行系統開發， 在英國等歐洲國家比較流行。 ASD-Adaptive Software Development， 由Jim Highsmith在1999年正式提出。ASD強調開發方法的適應性（Adaptive） 敏捷開發特點 敏捷開發包括很多方法，例如XP和FDD，同重量級的

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

6、心理念：適應和以人為本適應和以人為本客戶合作勝過合客戶合作勝過合同談判同談判響應變化勝過遵響應變化勝過遵循計劃循計劃可以工作的軟件勝過面可以工作的軟件勝過面面俱到的文檔面俱到的文檔個體和交互個體和交互勝過過勝過過程和工具程和工具敏捷規則最高目標是能持續地、及早地向客戶交付軟件；擁抱變化；頻繁地發布可運行的軟件；客戶和開發人員在一起工作；以人為本；最重要的衡量開發過程的手段，是可工作的軟件；穩定的開發速度；敏捷高效的設計；簡單有效；重視Teamwork；積極的調整。 目錄1.1敏捷的起源1.2敏捷方法體系1敏捷開發簡介敏捷開發簡介1.3敏捷宣言1.4為什么要敏捷?2敏捷系列敏捷系列3 敏捷開發的

7、誤區敏捷開發的誤區 我們為什么需要敏捷項目為什么失?。寇浖こ淘噲D解決這些問題：對用戶需求理解得不清楚，甚至有對用戶需求理解得不清楚，甚至有錯誤；錯誤；用戶需求變化；用戶需求變化；軟件很難維護或擴展；軟件很難維護或擴展；在項目后期階段發現很嚴重的設計在項目后期階段發現很嚴重的設計缺陷；缺陷；軟件質量或性能不合格；軟件質量或性能不合格；Test - Build - ReleaseTest - Build - Release過程的可操過程的可操作性、可維護性很差；作性、可維護性很差；人員流動；人員流動； 為了為了規范化開發過程，引進傳統工程的規范化開發過程，引進傳統工程的概念（瀑布型）；概念（瀑布

8、型）；為了理解需求，提出原型法；為了理解需求，提出原型法；為了提高設計開發的效率和擴展性，提為了提高設計開發的效率和擴展性，提出重用和面向對象等思想；出重用和面向對象等思想；為了讓開發過程更靈活，提出了開發框為了讓開發過程更靈活，提出了開發框架的概念；架的概念；為了降低風險，為了降低風險，提出了風險評估、成本提出了風險評估、成本控制和增量開發等思想；控制和增量開發等思想； 我們為什么需要敏捷 部門： 1) 培養團隊合作精神，穩定開發隊伍； 2) 提高開發人員的水平； 3) 提高項目成功率，降低開發成本，提升軟件開發效率 項目經理： 1) 更好地和用戶溝通，更清晰地理解用戶需求； 2) 更充分地

9、使用資源，更科學地調配資源，更精確地掌握開發進度。 系統分析設計： 1) 設計更加完善； 2) 更有效地更新知識，得到其他成員更多的尊重。 程序員： 1) 學習系統設計和項目管理； 2) 提高學習和工作效率，受到重視，減少加班時間，工作更高效 誰在用敏捷 Fortune 500 公司中成功應用XP的公司包括Ford，Daimler-Chrysler，First Union National Bank，IBM，HP等等。 通信業NS，Ericsson, Alcatel等都號稱在轉向敏捷 更多是小規模開發隊伍（小規模開發隊伍 小規模項目） 越來越多的公司開始使用敏捷開發過程敏捷開發成功的因素知識和

10、技能知識和技能文化和氛圍文化和氛圍自組織團隊自組織團隊開放的心態開放的心態 目錄2.1XP -eXtreme Programing2敏捷系列敏捷系列2.2SCRUM1敏捷開發簡介敏捷開發簡介3 敏捷開發的誤區敏捷開發的誤區 敏捷實踐l在敏捷的兩個門派：在敏捷的兩個門派：XP、Scrum中，整理歸納了很多可以用中，整理歸納了很多可以用于協助軟件開發的實踐，后面統稱為敏捷實踐。于協助軟件開發的實踐，后面統稱為敏捷實踐。 什么是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年創立XP是軟件開發過程中的紀律，它規定你：必須在編程前些測試，必須兩個人一起編程，必須遵守編程規范。XP是把最好的實踐經驗提取出來，形成了一個嶄新的開發方法。Extreme Programming 什么是XPExtreme Programmingl極限的含義：極限的含義：軟件開發中的優點發揮到極致(Kent Beck).lXP：給程序員提供了明

12、確的方法，使得程序員盡管面對需求的改變，卻能夠從容應對，即使著重變化發生在項目的后期，仍然能夠編出代碼。lXP核心：核心：溝通、簡明、反饋和勇氣 lXP重視溝通，客戶、開發人員、管理者共同組成團隊。lXP是一個實踐系統是一個實踐系統p13個實踐lXP方法的貢獻方法的貢獻p以擁抱變化的思想，協作的團隊，簡單的規則等為原則的13個具體實踐p是知名度最高的敏捷開發方法 XP的計劃/反饋循環 XP開發工作流 XP的關鍵實踐:編程方法編程方法交付和管理交付和管理小組實踐小組實踐 XP的關鍵實踐結對編程結對編程測試驅動開發測試驅動開發重構重構簡單簡單設計設計代碼集體所有代碼集體所有編碼標準編碼標準穩定高速

13、的步伐穩定高速的步伐持續集成持續集成隱喻隱喻現場客戶現場客戶完整的完整的團隊團隊小規模發小規模發布布計劃游戲計劃游戲編程方法編程方法小組實踐小組實踐交付和管理交付和管理交付和管理交付和管理 交付和管理1:完整的團隊(Whole Team)Product Manager/Project managerCoachTeam leadDevelopersTrackerTester(On-Site) Customersl所有的小組成員應在同一個工作地點工作。l成員中必須有一個用戶代表（On-site User）,由他/她來提出需求，確定開發優先級，把握開發的動向。l通常還設一個教練（Coach）角色，來

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

15、ory的商業優先級 (3) 為每個User Story定義驗收測試 (4) 計劃開發內容 (5) 調控開發過程 (6) 建立商業模型，把隱藏在客戶需求下的原則傳授給開發人員 (8) 程序員分擔任務的過程支解了對他們商業模型的理解 (9) 參加設計過程 (10)和程序員一起找出Metaphor，導引設計方向 (11)在Metaphor的幫助下，定義更有效更實際的功能測試，給程序員的設計制定了規范 交付和管理4:小規模發布降低開發風險。降低開發風險。 保證客戶有足夠的依據調控開保證客戶有足夠的依據調控開發過程發過程(增加、刪除或改變增加、刪除或改變User Story)?？蛻羰褂冒l布的系統，可以保

16、證客戶使用發布的系統，可以保證頻繁地反饋和交流。頻繁地反饋和交流。 發布過程應該盡可能地發布過程應該盡可能地自動化、規范化。自動化、規范化。不斷地發布可用的系統可以告不斷地發布可用的系統可以告訴客戶你在做正確的事情。訴客戶你在做正確的事情。低風險低風險智能化智能化適應調整適應調整頻繁交流頻繁交流知會客戶知會客戶頻繁發布頻繁發布經過驗證經過驗證 隨著開發的推進，發布越來隨著開發的推進，發布越來越頻繁。越頻繁。 所有的發布都要經過功所有的發布都要經過功能測試。能測試。小組實踐小組實踐 小組實踐1:持續集成(Continuous integration) 持續集成指不斷地把完成的功能模塊整合在一起。

17、目的在于不斷獲得客戶反饋以及盡早發現BUG。 隨時整合，越頻繁越好；集成及測試過程的自動化程度越高越好。 “A Test a day ,takes the bugs away”-Siemens失敗通過時間功 能 測 試 小組實踐1:持續集成(Continuous integration)1自動化編譯自動化編譯質量度量質量度量23自動化測試自動化測試持續反饋持續反饋 團隊實踐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以及一些關鍵概念等等抽象化為比喻。通過這些比喻，加強客戶和程序員之間的相互理解，消化積累知識，指導設計開發的方向。 例：Market 發布/瀏覽，價格洽談，生成和履行合同；String，Tree，Package，Chartroom，Spider，Robot ；電影后期制作 郵遞 電影院播放電影。 小組實踐2:隱喻(System Metaphor) Metaphor的形成過程，是客戶建立并抽象商業模型和商業

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

20、ds) 編碼標準的目的： 防止團隊被一些無關緊要的愚蠢爭論搞得不知所措。不要預先花費太多時間不要預先花費太多時間目標應該是團隊中沒有人辨認各自的代碼目標應該是團隊中沒有人辨認各自的代碼以團隊為單位對某一標準達成協議，然后遵守這一標準以團隊為單位對某一標準達成協議，然后遵守這一標準不是事無巨細的規則列表，而是確保代碼可交流的指導方針不是事無巨細的規則列表，而是確保代碼可交流的指導方針編碼標準開始時應很簡單，然后根據團隊經驗逐步進化編碼標準開始時應很簡單，然后根據團隊經驗逐步進化創建能夠工作的最簡單標準，然后逐步發展創建能夠工作的最簡單標準，然后逐步發展只制訂適合本團隊的只制訂適合本團隊的 小組實

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

22、PM 結束結束測試用例編程方法編程方法 編程方法1:測試驅動開發(TDD)失敗通過時間單元測試 100% 通過設計先先寫寫單元測試單元測試重構運行運行單元測試單元測試編程發現BUG集成先先寫寫功能測試功能測試User Story運行運行功能測試功能測試 編程方法2:重構(Refactoring )減少重復設計，優化設計結構，提高技術上的重用性和可擴展性。減少重復設計，優化設計結構，提高技術上的重用性和可擴展性。重構和編程前的計劃型設計重構和編程前的計劃型設計(Planned Design)結合，使結合，使XP的簡單設計可行有效。的簡單設計可行有效。XP提倡毫不留情的重構提倡毫不留情的重構(Re

23、factor mercilessly)。任何人可以重構任何代碼，前提是重構后的代碼一定要通過任何人可以重構任何代碼，前提是重構后的代碼一定要通過100%測試單元測試后才能被測試單元測試后才能被Check-in?？梢愿鶕枰?，將一個迭代的全部目標定為重構。可以根據需要，將一個迭代的全部目標定為重構。不要太在意什么是最簡單的設計不要太在意什么是最簡單的設計 愿意在最后重構，比知道如何做簡單的設計重要得多。愿意在最后重構，比知道如何做簡單的設計重要得多。在在Metaphor指引下的重構，是為商業模型服務的。不要把重構變成不斷的盲目精簡代碼。指引下的重構，是為商業模型服務的。不要把重構變成不斷的盲目精

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

25、 Metaphor給設計提供了指引，加強Team對設計的理解； 第一個迭代搭建了基本的系統框架。 以后的迭代過程，是在反饋和編程的基礎上做交互式設計，減少了設計的投機性。 迭代過程中的CRC卡幫助Team交流設計思想，簡化了設計文檔。 構對設計進行優化。 XP 認為設計非常重要，因此應該是一個持續的事務。我們總是先嘗試使用能認為設計非常重要，因此應該是一個持續的事務。我們總是先嘗試使用能夠工作的最簡單的設計，然后隨著現實的不斷顯現來更改它。夠工作的最簡單的設計，然后隨著現實的不斷顯現來更改它。 對簡單設計的需求并不是說所有設計都很小，也不表示它們是無足輕重的。對簡單設計的需求并不是說所有設計都

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

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

28、框架組合起來。 SCRUM的過程圖 SCRUM實踐 1. Scrum團隊：5-7個人的小項目團隊， 團隊的負責人可能擔負起Scrum Master的角色。2. Backlog: 急待完成的一系列任務，包括：未細化的產品功能要求、Bugs、缺陷、用戶提出的改進、具競爭力的功能及技術升級等，按優先級定義出來，這些任務可能不是完整的，甚至可能隨時會更改或添加。3. Sprint(沖刺): 通常為30天的迭代時間，把Backlog中的每一項安排在Sprint中，由團隊估算出所需要的時間（按小時記）。 每一次Sprint之后，一定要有可以交付使用的功能。4. Scrum會議: 這是與傳統方式最大的區別，

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

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

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