Scrum敏捷開發管理辦法20150921_第1頁
Scrum敏捷開發管理辦法20150921_第2頁
Scrum敏捷開發管理辦法20150921_第3頁
已閱讀5頁,還剩5頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、Scrum敏捷開發管理辦法 V1.0敏捷開發概念簡單的說,敏捷開發是一種以人為核心、迭代、循序漸進、小步快走的開發方法。在敏捷開發中,軟件項目的構建被切分成多個子項目,各個子項目的成果都經過測試,具備集成和可運行的特征。換言之,就是把一個大項目分為多個相互聯系,但也可獨立運行的小項目,并分別完成,在此過程中軟件一直處于可使用狀態。敏捷開發特征開發方法要稱之為敏捷,需要具備4個基本特征:增量的、協作的、直接的、適應性強的。增量”是指小版本、頻繁發布?!皡f作”是指客戶和開發人員之間緊密溝通,經常工作在一起?!爸苯印笔侵阜椒ū旧硎侨菀讓W習和修改的?!斑m應”是指能把剛剛發生的改變考慮進來。三、敏捷開發

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

溫馨提示

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

評論

0/150

提交評論