scrum敏捷模式

1、scrum敏捷開發(fā)模式2012年07月24日by wangrb主要內(nèi)容 什么是敏捷開發(fā) 敏捷開發(fā)宣言 敏捷開發(fā)原則 敏捷實踐模式 敏捷中的異味 如何避免異味 采用敏捷的好處 什么是scrum scrum角色 scrum構(gòu)件 scrum活動 敏捷常見誤解 團隊合作之道什么是敏捷開發(fā) 是一種以人為核心、迭代、循序漸進的增量式開發(fā)方法以人為核心、迭代、循序漸進的增量式開發(fā)方法 在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征 簡言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。什么是敏捷開發(fā)

2、 常用敏捷開發(fā)方法常用敏捷開發(fā)方法 XP極限編程(Extreme Programming) Scrum 特征驅(qū)動開發(fā)(Feature Driver Development) 動態(tài)系統(tǒng)開發(fā)(Dynamic Systems Development Method) 透明水晶開發(fā)(Crystal Clear)什么是敏捷開發(fā) 瀑布模型瀑布模型 采用結(jié)構(gòu)化的分析和設計方法 邏輯實現(xiàn)與物理實現(xiàn)分離 按工序?qū)栴}簡化 固定的、沒有彈性 很困難去達到互動 項目周期較長 敏捷方法敏捷方法 完整地開發(fā)，每少數(shù)幾周或是少數(shù)幾個月里可以測試功能。 強調(diào)在獲得最簡短的可執(zhí)行功能的部分，能夠及早給予企業(yè)價值。 在整個項目的

3、生命周期里，可以持續(xù)的改善、增加未來的功能。 什么是敏捷開發(fā) 瀑布模型瀑布模型 scrum敏捷模型什么是敏捷開發(fā) 傳統(tǒng)項目管理：傳統(tǒng)項目管理： 事先對整個項目進行估計、計劃、分析 反對變更; 變更需要重新估計、重新規(guī)劃 嚴密的合同來減少風險, 如果改變需求要走 CR 流程. 項目作為一個“黑盒子” ，對客戶與供應商的可視性差. 文檔和計劃驅(qū)動的方法. 軟件交付時間晚, 意識到風險的時間晚. WBS,甘特圖,關鍵路徑分析 敏捷項目管理敏捷項目管理: 對整個項目做一個粗略的估計,每一次迭代都有詳細的計劃. 鼓勵變化, 客戶價值驅(qū)動開發(fā). 信任和賦予權力;合約使變更變得簡單，增加價值. 客戶和開發(fā)人

4、員之間是緊密的連續(xù)的合作關系 每次迭代都產(chǎn)生可交付的軟件 專注于交付軟件. 第一次迭代就可交付能工作的版本，風險發(fā)現(xiàn)的早. 敏捷開發(fā)宣言個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應變化勝過遵循計劃敏捷開發(fā)宣言-1 個體和交互勝過過程和工具個體和交互勝過過程和工具 人是軟件項目獲得成功最為重要的因素 合作、溝通能力以及交互能力比單純的軟件編程能力和工具更為重要 方法和工具是死的，人是活的，人要是太“面”或者協(xié)作不好，再強大的方法和工具都是白扯； 敏捷開發(fā)宣言-2 可以工作的軟件勝過面面俱到的文檔可以工作的軟件勝過面面俱到的文檔 過多的面面俱到的文檔往往比過少的

5、文檔更糟 軟件開發(fā)的主要和中心活動是創(chuàng)建可以工作的軟件 直到迫切需要并且意義重大時，才進行文檔編制 編制的內(nèi)部文檔應盡量短小并且主題突出 敏捷開發(fā)宣言-3 客戶合作勝過合同談判客戶合作勝過合同談判 客戶不可能做到一次性地將他們的需求完整清晰地表述在合同中 為開發(fā)團隊和客戶的協(xié)同工作方式提供指導的合同才是最好的合同 敏捷開發(fā)宣言-4 響應變化勝過遵循計劃響應變化勝過遵循計劃 變化是軟件開發(fā)中存在的現(xiàn)實 計劃必須有足夠的靈活性與可塑性 短期的迭代的計劃比中長期計劃更有效 敏捷開發(fā)原則1.最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意2.即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用

6、變化來為客戶創(chuàng)造競爭優(yōu)勢。3.經(jīng)常性的交付可以工作的軟件，交付的時間間隔可以從幾周到幾個月，交付的時間間隔越短越好4.在整個項目開發(fā)期間，業(yè)務人員和開發(fā)人員必須天天在一起工作敏捷開發(fā)原則5.圍繞被激勵起來的個人來構(gòu)建項目。給他們提供所需要的環(huán)境和支持，并且信任他們能夠完成工作。6.在團隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談（而不是文檔）7.工作的軟件是首要的進度度量標準。8.敏捷過程提倡可持續(xù)開發(fā)進度，責任人、開發(fā)者和用戶應該能夠保持一個長期的、恒定的開發(fā)速度敏捷開發(fā)原則9.不斷地關注優(yōu)秀的技能和好的設計會增強敏捷能力10. 簡單化是根本11. 最好的架構(gòu)、需求和設計

7、出自于自組織的團隊12. 每隔一段時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調(diào)整敏捷實踐模式反饋實踐模式技術實踐模式輔助實踐模式敏捷實踐模式-反饋實踐模式迭代迭代 在一個固定時間周期內(nèi)，由團隊完成系統(tǒng)中一部分功能的開發(fā) 設定目標、啟動會、演示和回顧啟動會啟動會 同步團隊之間的工作，計劃迭代要完成的工作 設定目標，做出承諾待辦工作事項待辦工作事項 需要完成的工作即需求，有優(yōu)先級規(guī)劃規(guī)劃“撲克撲克” 快速估計實現(xiàn)需求所要付出的工作量站立會議站立會議 迭代中的見面交流會：完成了什么，要做什么，有什么問題 一般不超過15分鐘敏捷實踐模式-反饋實踐模式完成狀態(tài)完成狀態(tài) 迭

8、代中每個需求的完成目標以及對完成的定義 盡可能的接近部署或發(fā)布演示演示 迭代結(jié)束是向項目的相關負責人進行系統(tǒng)功能展示回顧回顧 迭代結(jié)束或者發(fā)布后舉行，總結(jié)經(jīng)驗，優(yōu)化流程頻繁發(fā)布頻繁發(fā)布 條件允許的情況下，盡可能經(jīng)常的發(fā)布軟件給用戶 前提需要做到持續(xù)集成“聯(lián)合駐扎聯(lián)合駐扎”團隊團隊 團隊成員在同一個物理空間工作，便于相互交流敏捷實踐模式-反饋實踐模式自組織團隊自組織團隊 不需要外部過多的指導和干預，團隊成員自己推進目標的實現(xiàn) 需要經(jīng)常回顧改進工作方法，提升團隊的效率跨職能團隊跨職能團隊 類似外科手術團隊，具備完成一個系統(tǒng)所需要的各種成員 scrum團隊客戶作為團隊成員客戶作為團隊成員 客戶加入團

9、隊一起工作，需要客戶對所需要解決的業(yè)務問題理解非常透徹喚醒式文檔喚醒式文檔 喚起人們的記憶，比傳統(tǒng)的文檔更有意義 花更多的時間進行面對面的交流，較少的時間編寫和維護文檔敏捷實踐模式-反饋實踐模式用戶故事用戶故事 為需求創(chuàng)建一個喚醒式文檔，對需求的概要描述 一般包括需求描述以及完成定義用例用例 描述對客戶有重要價值的業(yè)務流程 描述系統(tǒng)行為的一種需求表現(xiàn)形式信息輻射器信息輻射器 提高透明度，便于信息的交流 重要數(shù)據(jù)、進度、問題等敏捷實踐模式-技術實踐模式自動化測試自動化測試 測試可被輕松的執(zhí)行 促進系統(tǒng)設計不斷的趨向于松耦合測試后行開發(fā)測試后行開發(fā) 開發(fā)完代碼后再進行測試測試先行開發(fā)測試先行開發(fā)

10、先編寫測試，然后開發(fā)產(chǎn)品代碼 必須有良好的設計，結(jié)構(gòu)松耦合重構(gòu)重構(gòu) 保持系統(tǒng)原有功能的同時，改進系統(tǒng)設計和代碼結(jié)構(gòu) 發(fā)現(xiàn)問題，馬上動手，經(jīng)常性的重構(gòu)敏捷實踐模式-技術實踐模式持續(xù)集成持續(xù)集成代碼變更提交后，執(zhí)行完整的構(gòu)建、集成運行并通過所有的測試簡單設計簡單設計設計復雜程度滿足當前需求即可，不要畫蛇添足持續(xù)改進設計功能測試功能測試滿足客戶驗收需求的測試確保系統(tǒng)輸出使用戶所想要的集體代碼所有權集體代碼所有權開發(fā)團隊中的任何人都有權利和責任修改任何一部分代碼結(jié)對編程結(jié)對編程兩個人一起工作，相互合作，提升產(chǎn)品質(zhì)量，減少對專家的依賴敏捷實踐模式-輔助實踐模式教練教練 有經(jīng)驗的敏捷開發(fā)實踐者，作為顧問加

11、入團隊，幫助團隊進步融入敏捷社區(qū)融入敏捷社區(qū) 獲取知識、建議和經(jīng)驗的地方讀書會讀書會 大家一同學習、分享一本好書研討會研討會課堂培訓課堂培訓敏捷中的異味僵化：僵化： 很難對系統(tǒng)進行改動，因為每個改動都會迫使許多對系統(tǒng)其他部分的其它改動脆弱：脆弱： 對系統(tǒng)的改動會導致系統(tǒng)中和改動的地方在概念上無關的許多地方出現(xiàn)問題。牢固：牢固： 很難解開系統(tǒng)的糾結(jié)，使之成為一些可在其他系統(tǒng)中重用的組件。粘滯：粘滯： 做正確的事情比做錯誤的事情要困難。敏捷中的異味復雜：復雜： 設計中包含有不具任何直接好處的基礎結(jié)構(gòu)。重復：重復： 設計中包含有重復的結(jié)構(gòu)，而該重復的結(jié)構(gòu)本可以使用單一的抽象進行統(tǒng)一?；逎夯逎?很

12、難閱讀、理解。沒有很好地表現(xiàn)出意圖如何避免異味單一職責原則（單一職責原則（SRP) 就一個類而言，應該僅有一個引起它變化的原因。開放開放-封閉原則（封閉原則（OCP) 軟件實體應該是可以擴展的，但是不可修改。里氏替換原則（里氏替換原則（LSP) 子類型必須能夠替換掉它們的基類型。如何避免異味依賴倒置原則（依賴倒置原則（DIP) 抽象不應該依賴于細節(jié)。細節(jié)應該依賴于抽象。接口隔離原則（接口隔離原則（ISP) 不應該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結(jié)構(gòu)。重用發(fā)布等價原則（重用發(fā)布等價原則（REP) 重用的粒度就是發(fā)布的粒度。如何避免異味共同封閉原則（共同封閉原則（C

13、CP) 包中的所有類對于同一類性質(zhì)的變化應該是共同封閉的。一個變化若對一個包產(chǎn)生影響，則將對該包中的所有類產(chǎn)生影響，而對于其他的包不造成任何影響。共同重用原則共同重用原則(CRP) 一個包中的所有類應該是共同重用的。如果重用了包中的一個類，那么就要重用包中的所有類。如何避免異味無環(huán)依賴原則（無環(huán)依賴原則（ADP) 在包的依賴關系圖中不允許存在環(huán)。穩(wěn)定依賴原則（穩(wěn)定依賴原則（SDP) 朝著穩(wěn)定的方向進行依賴。穩(wěn)定抽象原則（穩(wěn)定抽象原則（SAP) 包的抽象程度應該和其穩(wěn)定程度一致。采用敏捷的好處縮短產(chǎn)品上市時間增強產(chǎn)品實用性提高產(chǎn)品質(zhì)量提高靈活性增強透明度降低成本延長產(chǎn)品生命周期業(yè)務價值是組織的目

14、標.什么是scrum是一種敏捷開發(fā)框架，一個迭代式、增量開發(fā)過程，屬于敏捷開發(fā)的一種，它由一個開發(fā)過程、幾種角色以及一套規(guī)范的實施方法組成： 角色：product owner，scrum master，scrum team，stake holder 構(gòu)件：product backlog，sprint backlog，burn-down chart 活動：sprint planning meeting，daily standup meeting，sprint review meeting，retrospective meetingscrum敏捷流程scrum角色-product ownerpro

15、duct owner 產(chǎn)品利益相關方的代表，負責產(chǎn)品相關業(yè)務，給出明確的、可度量的、合理的產(chǎn)品backlog職責： 確定產(chǎn)品的功能。 決定發(fā)布的日期和發(fā)布內(nèi)容。 為產(chǎn)品的profitability of the product (ROI)負責。 根據(jù)市場價值確定功能優(yōu)先級。 每個Sprint，根據(jù)需要調(diào)整功能和優(yōu)先級（每個Sprint開始前調(diào)整）。 接受或拒絕接受開發(fā)團隊的工作成果。 scrum角色-scrum masterscrum master 為scrum過程負責的人，整個團隊的導師和組織者，確保scrum的正確使用并使得Scrum的收益最大化職責職責 保證團隊資源完全可被利用并且全部是

16、高產(chǎn)出的。 保證各個角色及職責的良好協(xié)作。 解決團隊開發(fā)中的障礙。 做為團隊和外部的接口，屏蔽外界對團隊成員的干擾。 保證開發(fā)過程按計劃進行，組織每日站立會議、演示會、回顧會scrum角色-scrum teamscrum team 自組織的跨職能團隊，以完成目標為己任職責職責 一般情況下人數(shù)在5-9個左右 團隊要跨職能 （包括開發(fā)人員、測試人員、用戶界面設計師等） 團隊成員需要全職（有些情況例外，比如架構(gòu)師） 在項目向?qū)Х秶鷥?nèi)有權利做仸何事情已確保達到Sprint的目標 高度的自我組織能力 向Product Owner演示產(chǎn)品功能 團隊成員構(gòu)成在sprint內(nèi)不允許變化scrum角色- sta

17、ke holdern項目組有關的成員,但并不專注于項目n以觀察者的形式參加Scrum meeting火腿雞蛋！三思過后我決定不和你開餐館了。因為我全身心投入，而你只牽涉入內(nèi)！scrum構(gòu)件-product backlog一個關于產(chǎn)品的需求列表。 一般情況使用用戶故事(user story)來表示backlog條目 backlog條目按照商業(yè)價值排列優(yōu)先級，理想情況每個需求項都對產(chǎn)品的用戶有價值，優(yōu)先級由產(chǎn)品負責人來排列 在每個Sprint結(jié)束的時候要更新優(yōu)先級的排列 scrum構(gòu)件-sprint backlog一次迭代計劃要完成的需求，來自product backlog進入sprint bac

18、klog的需求都是清楚的，沒有歧義每個需求已有團隊成員認領，并估計了完成工作量每項sprint backlog有合理的任務拆解，有些任務可以并行scrum構(gòu)件-burn-down chartscrum活動-計劃會scrum活動-計劃會計劃會議要有足夠的時間，至少4個小時 取出部分產(chǎn)品需求做成sprint需求，并制成卡片 確定并細分每一個卡片的故事（Story） 通過認領分配工作 確定每日站立會議的時間和地點 確定好演示會議和回顧會議的日期 scrum活動-站立會議團隊每日例會，在同樣的時間和地點舉行，所有成員站立開會 最好每日上班開始或者臨近下班時開，一般15分鐘左右，嚴格控制時間只有團隊成員可以在例會上發(fā)言，其他人員有興趣可以參加，但只能旁聽，不能發(fā)言 每日Scrum會議由Scrum Master主持， Scrum團隊所有成員輪流回答以下3個問題： 昨天我完成了什么工作？ 今天我打算做什么？ 我在工作中遇到了什么困難？ 更新燃盡圖 scrum活動-演示會演示會用來演示在這個Sprint中開發(fā)的產(chǎn)品功能給Product Owner. Product Owne