Scrum敏捷開發(fā)管理辦法20150921_第1頁
Scrum敏捷開發(fā)管理辦法20150921_第2頁
Scrum敏捷開發(fā)管理辦法20150921_第3頁
免費預(yù)覽已結(jié)束,剩余7頁可下載查看

下載本文檔

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

文檔簡介

1、Scrum敏捷開發(fā)管理辦法 V1.0敏捷開發(fā)概念簡單的說,敏捷開發(fā)是一種以人為核心、迭代、循序漸進、小步快走的開發(fā)方法。在敏捷開發(fā)中,軟件項目的構(gòu)建被切分成多個子項目,各個子項目的成果都經(jīng)過測試,具備集成和可運行的特征。換言之,就是把一個大項目分為多個相互聯(lián)系,但也可獨立運行的小項目,并分別完成,在此過程中軟件一直處于可使用狀態(tài)。敏捷開發(fā)特征開發(fā)方法要稱之為敏捷,需要具備4個基本特征:增量的、協(xié)作的、直接的、適應(yīng)性強的。增量”是指小版本、頻繁發(fā)布。“協(xié)作”是指客戶和開發(fā)人員之間緊密溝通,經(jīng)常工作在一起。“直接”是指方法本身是容易學(xué)習(xí)和修改的。“適應(yīng)”是指能把剛剛發(fā)生的改變考慮進來。三、敏捷開發(fā)

2、宣言個體和交互勝過過程和工具可以工作的軟件勝過面面俱到的文檔客戶合作勝過合同談判響應(yīng)變化勝過遵循計劃雖然右項也很有價值,但是我們認為左項具有更大的價值四、敏捷宣言遵循的原則我們遵循以下原則:我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。即使到了開發(fā)的后期, 也歡迎改變需求。 敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。經(jīng)常性的交付可以工作的軟件,交付的間隔可以從幾星期到幾個月,交付間隔越短越好。在整個項目開發(fā)期間,業(yè)務(wù)人員和開發(fā)者必須天天都在一起工作。圍繞被激勵起來的個體來構(gòu)建項目。給他們所需的環(huán)境和支持,并且信任他們能夠 完成工作。在團隊部,最具有效果并且富有效率的傳遞信息的方

3、法,就是面對面的交談。可以工作的軟件是首要的進度度量標(biāo)準(zhǔn)。敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)人員和用戶應(yīng)該保持長期的、恒定 的開發(fā)速度。不斷的關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。簡單一一盡可能減少工作量的藝術(shù)至關(guān)重要。最好的架構(gòu)、需求和設(shè)計出自于自組織的團隊。每隔一定時間,團隊都要總結(jié)如何才能更有效的工作,然后相應(yīng)地調(diào)整自己的行為。五、Scrum的定義Scrum是一個輕量級的軟件開發(fā)方法。Scrum是一個敏捷開發(fā)框架,是一個增量的、迭代的開發(fā)過程。在這個框架中,整個開 發(fā)周期包括若干個小的迭代周期,每個迭代周期稱為一個Sprint,每個Sprint的建議長度是2到4周。在Scrum

4、中,使用產(chǎn)品BackLog來管理產(chǎn)品或者是項目的需求,產(chǎn)品backLog是一個按照商業(yè)價值排序的需求列表,列表條目的體現(xiàn)形式通常為Story。Scrum開發(fā)團隊從產(chǎn)品BackLog中挑選最有價值的需求進行開發(fā)。Sprint中挑選的需求經(jīng)過 Sprint計劃會議上的分析,討論和估算得到一個sprint的任務(wù)列表,我們稱為 Spring backLog。在每個迭代結(jié)束時,Scrum團隊將交付潛在的可交付 的產(chǎn)品增量。六、Scrum框架術(shù)語類型術(shù)語解釋3個角色PO( Product Owner )產(chǎn)品負責(zé)人,類似產(chǎn)品經(jīng)理崗位SM( Scrum Master)Scrum活動管理者或教練,類似項目經(jīng)理

5、崗位Scrum Team (團隊)Scrum團隊3個工件產(chǎn)品 backlog(Product Backlog )產(chǎn)品特性列表,類似需求列表,產(chǎn)品特性 計劃會議后的輸出Sprint Backlog迭代任務(wù)列表,Sprint計劃會議后的輸出燃盡圖(Burn-down Chart )燃盡圖,進度跟蹤的圖表工具5個活動產(chǎn)品Backlog梳理會議(ProductBacklogRefinement)產(chǎn)品特性計劃會,類似產(chǎn)品圍規(guī)劃活動Sprint計劃會議(Sprint Planning Meeti ng)Spri nt計劃會議,類似項目需求澄清、任 務(wù)分解活動每日站會 (Daily ScrumMeeting

6、)每日簡會,類似日工作匯報活動Sprint評審會議(Sprint Review Meet ing)Sprint評審會,類似軟件集成活動Spri nt回顧會議( SprintRetrospectiveMeeting)Sprint回顧會,類似項目回顧及反思總結(jié) 活動5個價值1. 承諾-愿意對目標(biāo)做出承諾2. 專注-把你的心思和能力都用到你承諾的工作上去3. 開放-Scrum把項目中的一切開放給每個人看4. 尊重-每個人都有他獨特的背景和經(jīng)驗5. 勇氣-有勇氣做出承諾,履行承諾,接受別人的尊重Spri nt沖刺,指某一次迭代開發(fā)階段用戶故事(User Story )用戶故事,從系統(tǒng)各種用戶的各自使用

7、場 景角度來描述的功能要求,類似需求規(guī)格 說明任務(wù)看板任務(wù)墻,任務(wù)跟蹤的白板工具障礙列表障礙列表,風(fēng)險記錄跟蹤的工具七、SCRUM理論基礎(chǔ)Scrum以經(jīng)驗性過程控制理論(經(jīng)驗主義)做為理論基礎(chǔ)的過程。經(jīng)驗主義主知識源于經(jīng)驗,以及基于已知的東西做決定。Scrum采用迭代、增量的方法來優(yōu)化可預(yù)見性并控制風(fēng) 險。Scrum的三大支柱支撐起每個經(jīng)驗性過程控制的實現(xiàn):透明性、檢驗和適應(yīng)。Scrum的 三大支柱如下:第一:透明性( Transparency )透明度是指, 在軟件開發(fā)過程的各個環(huán)節(jié)保持高度的可見性, 影響交付成果的各個方面 對于參與交付的所有人、 管理生產(chǎn)結(jié)果的人保持透明。 管理生產(chǎn)成果的

8、人不僅要能夠看到過 程的這些方面,而且必須理解他們看到的容。也就是說,當(dāng)某個人在檢驗一個過程,并確信 某一個任務(wù)已經(jīng)完成時,這個完成必須等同于他們對完成的定義。第二:檢驗( Inspection )開發(fā)過程中的各方面必須做到足夠頻繁地檢驗,確保能夠及時發(fā)現(xiàn)過程中的重大偏差。 在確定檢驗頻率時, 需要考慮到檢驗會引起所有過程發(fā)生變化。 當(dāng)規(guī)定的檢驗頻率超出了過 程檢驗所能容許的程度,那么就會出現(xiàn)問題。幸運的是,軟件開發(fā)并不會出現(xiàn)這種情況。另 一個因素就是檢驗工作成果人員的技能水平和積極性。第三:適應(yīng)( Adaptation )如果檢驗人員檢驗的時候發(fā)現(xiàn)過程中的一個或多個方面不滿足驗收標(biāo)準(zhǔn), 并且

9、最終產(chǎn)品 是不合格的, 那么便需要對過程或是材料進行調(diào)整。 調(diào)整工作必須盡快實施, 以減少進一步 的偏差。Scrum 過三個活動進行檢驗和適應(yīng):每日例會檢驗Sprint 目標(biāo)的進展,做出調(diào)整,從而優(yōu)化次日的工作價值; Sprint 評審和計劃會議檢驗發(fā)布目標(biāo)的進展,做出調(diào)整,從而優(yōu) 化下一個 Sprint 的工作價值; Sprint 回顧會議是用來回顧已經(jīng)完成的 Sprint ,并且確定做 出什么樣的改善可以使接下來的 Sprint 更加高效、更加令人滿意,并且工作更快樂。八、Scrum 開發(fā)模型引用自火星人敏捷開發(fā)手冊產(chǎn)品咖洌義 HS*九、Scrum的角色及職責(zé)先來說一個故事:一只雞對一頭豬

10、說:“我們合伙開家飯店吧! ”豬想了想,說:“好啊!那我們給這個飯 店起個什么名字呢?”雞說: “就叫【雞蛋和火腿】好了! ”豬回答道:“那還是算了吧,你 要做的只是下幾只雞蛋,而我卻把命都搭上了!”因此,我們把與開發(fā)相關(guān)的干系人分為兩類,“豬”類人員和“雞”類人員。Scrum中,以下幾個角色都是“豬”類人員,他們把所有的時間和精力都投入到產(chǎn)品的開發(fā)中,并對產(chǎn) 品完全負責(zé):1、產(chǎn)品負責(zé)人產(chǎn)品負責(zé)人(Product Owner )的職責(zé)如下:?為產(chǎn)品的ROI負責(zé)。?確定產(chǎn)品的功能。?決定發(fā)布的日期和發(fā)布容。?根據(jù)市場價值確定功能優(yōu)先級。?每個Sprint ,根據(jù)需要調(diào)整功能和優(yōu)先級(每個Spri

11、nt開始前調(diào)整)。?接受或拒絕接受開發(fā)團隊的工作成果。Product Owner 參與 Scrum planning 。2、ScrumMaster作為Team Leader和Product own er緊密地工作在一起,他可以及時地為團隊成員提供幫助。他必須 :? 保證團隊資源完全可被利用并且全部是高產(chǎn)出的。? 保證各個角色及職責(zé)的良好協(xié)作。? 解決團隊開發(fā)中的障礙。? 做為團隊和外部的接口,屏蔽外界對團隊成員的干擾。? 保證開發(fā)過程按計劃進行,組織 Daily Scrum, Sprint Review and SprintPlanning meetings 。3、團隊負責(zé)產(chǎn)品的開發(fā)? 一般情

12、況人數(shù)在 5-9 個左右? 團隊要跨職能(包括開發(fā)人員、測試人員、用戶界面設(shè)計師等)? 團隊成員需要全職。 (有些情況例外,比如數(shù)據(jù)庫管理員)? 在項目向?qū)袡?quán)利做任何事情已確保達到 Sprint 的目標(biāo)。? 高度的自組織能力。? 向 Product Owner 演示產(chǎn)品功能。? 團隊成員構(gòu)成在 sprint 不允許變化。? 團隊整體向產(chǎn)品開發(fā)負責(zé)。十、 Scrum 工件1、產(chǎn)品 Backlog有優(yōu)先級的故事列表,并估算故事點2、Sprint Backlog當(dāng)前 Sprint 要完成的任務(wù)列表,并估算工時? 團隊成員自己挑選任務(wù),而不是指派任務(wù)? 對每一個任務(wù),每天要更新剩余的工作量估算?

13、每個團隊成員都可以修改 Sprint backlog ,增加、刪除或者修改任務(wù)3、發(fā)布燃盡圖直觀反應(yīng)當(dāng)前發(fā)布剩余的工作量,以 Sprint 周期數(shù)和故事點數(shù)為單位。4、Sprint燃盡圖Sprint燃盡圖直觀的反映了Sprint過程中,剩余的工作量情況, Y軸表示剩余的工作,X軸表示Sprint的時間。隨著時間的消耗工作量逐漸減少,在開始的時候,由于估算上的誤差或者遺漏工作量有可能呈上升態(tài)勢。1.|h總工咋量:IzO已圭匪:120 剽余:D14C6020工作日(天)剩 余 工 作Sprint過程1、Sprint計劃會議?團隊從產(chǎn)品backlog中挑選他們承諾完成的條目。(做什么)?創(chuàng)建 Spr

14、int Backlog(怎么做)? 標(biāo)識具體的任務(wù)并為任務(wù)做估算? 由團隊協(xié)作完成,而不是 Scrum Master?考慮了高層設(shè)計2、Scrum每日站會團隊每天進行15分鐘的檢驗和適應(yīng)的會議稱為Scrum每日站會。每日站會上,每個團隊成員需要匯報以下三個問題:?昨天你完成了什么? 今天你將完成什么? 完成今天的工作有什么障礙或需要協(xié)助匯報的對象是團隊,不是任何一位領(lǐng)導(dǎo)(PO,SM,團隊負責(zé)人)。匯報的重點在于第 3 個問題,即提出問題,進而解決。每日站會不是進度匯報會議,這個會議是為將產(chǎn)品 backlog 條目轉(zhuǎn)化成為增量的人 (團隊)召開的。團隊承諾實現(xiàn) Sprint 目標(biāo)和完成產(chǎn)品 Ba

15、cklog 條目。每日站會是檢 驗朝向 Sprint 目標(biāo)的進程, 如果有必要進行后續(xù)會議對 Sprint 中的下一步工作進行調(diào) 整,目的在在于增加團隊實現(xiàn)目標(biāo)的可能性。這是Scrum經(jīng)驗過程中的重要檢驗和適應(yīng)的會議。3、Sprint 評審會議Sprint 評審會議用來演示在這個 Sprint 中開發(fā)的產(chǎn)品功能給 Product Owner.Produc Owner 會組織這階段的會議并且邀請相關(guān)的干系人參加。? 團隊展示 Sprint 中完成的功能? 一般是通過現(xiàn)場演示的方式展現(xiàn)功能和架構(gòu)? 不要太正式? 不需要 PPT? 一般控制在半個小時? 團隊成員都要參加? 可以邀請所有人參加4、Sp

16、rint 回顧會議Sprint 回顧會議上, 全體成員討論有哪些好的做法, 哪些不好的做法, 好的做 法要繼續(xù)發(fā)揚,共同確定一項需改進的點在下個迭代進行改進。? 團隊的定期自我檢視,發(fā)現(xiàn)什么是好的,什么是不好的,持續(xù)改進? 一般控制在 2 個小時? 每個 Sprint 都要做? 全體參加? Scrum Master? 產(chǎn)品負責(zé)人? 團隊? 可能的客戶或其它干系人十二、 Scrum 開發(fā)流程A. 我們首先需要確定一個 Product Backlog (按優(yōu)先順序排列的一個產(chǎn)品需求列 表),這個是由 Product Owner 負責(zé)的。 確定優(yōu)先級從 4 個方面考慮: 1、獲得這些功 能可帶來的經(jīng)

17、濟價值; 2、開發(fā)(可能還包含支持)新功能所需的成本;3、開發(fā)新功能所產(chǎn)生的學(xué)習(xí)和知識的量及重要性;4、開發(fā)這些功能所減少的風(fēng)險。B. Scrum Team 根據(jù) Product Backlog 列表,做工作量的預(yù)估和安排。C. 有了 Product Backlog 列表,我們需要通過 Sprint Planning Meeting( Sprint 計劃會議) 來從中挑選出一批 Story 作為本次迭代完成的目標(biāo),這個目標(biāo)的時間周期 是 14 個星期,然后把這個 Story 進行細化,形成一個 Sprint Backlog 。D. Sprint Backlog 是由 Scrum Team 去完

18、成的,每個成員根據(jù) Sprint Backlog 再細化成更小的任務(wù)(細到每個任務(wù)的工作量在 2 天能完成)。E. 在Scrum Team完成計劃會議上選出的 Sprint Backlog過程中,需要進行 Daily Scrum Meeting (每日站立會議), 每次會議控制在 15 分鐘左右,每個人都必須發(fā)言, 并且要向所有成員當(dāng)面匯報你昨天完成了什么,并且向所有成員承諾你今天要完成什 么,同時提出可能會遇到的障礙和風(fēng)險, 每個人回答完成后,要走到黑板前更新自己的 Sprint burn down ( Sprint 燃盡圖)。F. 做到每日集成,也就是每天都要有一個可以成功編譯、并且可以演

19、示的版本;很多人可能還沒有用過自動化的每日集成,其實TFS就有這個功能,它可以支持每次有成員進行簽入操作的時候,在服務(wù)器上自動獲取最新版本,然后在服務(wù)器中編譯, 如果通過則馬上再執(zhí)行單元測試代碼,如果也全部通過,則將該版本發(fā)布,這時一次正式的簽入操作才保存到TFS中,中間有任何失敗,都會用通知項目管理人員。G. 當(dāng) Sprint Backlog 里的 Story 被完成,也就表示一次 Sprint 完成,這時,我 們要進行 Srpint Review Meeting (演示會議),也稱為評審會議,產(chǎn)品負責(zé)人和客 戶都要參加(最好本公司老板也參加),每一個 Scrum Team 的成員都要向他們演示自 己完成的軟件產(chǎn)品(這個會議非常重要,一定不能取消)。H. 最后

溫馨提示

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

評論

0/150

提交評論