Scrum敏捷開發(fā)模式.ppt

1、Scrum敏捷開發(fā)模式,在研發(fā)團隊的應用,鄭成龍 2015年8月,目錄,培訓目的 我們的背景 Scrum敏捷開發(fā)方法簡介 Scrum敏捷開發(fā)整體解決策略 溝通不及時之困推到“角色墻”組建多角色分層敏捷團隊 需求不穩(wěn)定之困分階段細化需求，并行研發(fā) 計劃執(zhí)行差之困分階段制定并跟蹤開發(fā)計劃 產品引用滿足度不高之困分階段提前驗證產品滿足度 研發(fā)人員業(yè)務能力參差不齊之困通過機制保證持續(xù)提升人員業(yè)務能力和研發(fā)效率 效果與價值,培訓目的,1.提高軟件開發(fā)效率縮短產品上市時間 2.提升客戶滿意度和快速響應市場變化,1.強調開發(fā)團隊與業(yè)務專家緊密協(xié)作，面對面溝通 2.頻繁交付新的軟件版本 3.緊湊的自我組織型團

2、隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，注重軟件開發(fā)中“人”的作用。,需求分析師/經理 開發(fā)經理 開發(fā)/測試工程師和經理 部門經理、主設計 架構師/產品經理 原型客戶,后面重點講解,我們的背景,敏捷應用關鍵策略,問 題,效 果,Scrum敏捷開發(fā)方法簡介,Scrum是一個輕量級的軟件開發(fā)方法，它通過一個或多個跨職能的小型團隊分多個迭代持續(xù)增量的交付軟件產品。通過迭代和快速用戶反饋來管理不確定性和擁抱變化。 在Scrum中，使用產品Backlog管理產品或項目需求。 Sprint計劃會分析、討論和估算得到一個Sprint的任務列表。 每個迭代結束時，Scrum團隊將交付潛在的可交付的

3、產品增量。,溝通不及時之困推到“角色墻”組建多角色分層敏捷團隊,在產品研發(fā)過程中，僅僅依靠文檔進行知識傳遞是遠遠不夠的，往往一個產品 的研發(fā)效率與這個團隊的溝通氛圍有直接關系。為了解決溝通不及時，在組建Scrum敏捷團隊時，推到“角色墻”，組建多角色分層敏捷團隊，使不同角色之間溝通無障礙，并通過日常7會議確保有效溝通。 組建敏捷團隊：,推到“角色墻”組建多角色分層敏捷團隊,研發(fā)部門的Scrum團隊由3層Scrum團隊構成：Scrum開發(fā)團隊、業(yè)務級Scrum團隊、部門級Scrum團隊。 Scrum開發(fā)團隊：根據(jù)人員規(guī)模和產品模塊的耦合度，分成多個Scrum開發(fā)團隊，每個團隊由6-8人組成，包括

4、需求分析師、開發(fā)經理、開發(fā)工程師、測試工程師，團隊的ScrumMaster由開發(fā)經理擔當；,推到“角色墻”組建多角色分層敏捷團隊,業(yè)務級Scrum團隊：虛擬團隊，分別由不同Scrum開發(fā)團隊相同角色構成，包括“需求Scrum團隊”、“開發(fā)經理Scrum團隊”、“測試Scrum團隊”，各自團隊的Scrum Master分別由需求經理、主設計、測試經理擔當； 部門級Scrum團隊：虛擬團隊，由各業(yè)務級Scrum團隊的Scrum Master構成，Scrum Master由部門經理或主設計擔當； 以NC資金開發(fā)部的組織結構圖為例：,推到“角色墻”組建多角色分層敏捷團隊,團隊各角色職責如下：,推到“角

5、色墻”組建多角色分層敏捷團隊,日常7個會議確保有效溝通,需求不穩(wěn)定之困分階段細化需求，并行研發(fā),根據(jù)Scrum敏捷研發(fā)思想，通過分階段細化研發(fā)范圍，確定每個迭代的需求Backlog，并行研發(fā)，減少需求變化對后續(xù)開發(fā)活動的影響。并且，通過定期召開“需求會議”和“下一次迭代內容溝通”，穩(wěn)步推進需求逐步細化，為后續(xù)開發(fā)工作提前做準備。 編寫迭代詳細需求 根據(jù)產品概要需求，編寫迭代詳細需求文檔，并形成SprintBacklog,確定迭代的工作范圍，每個backlog的編寫遵循以下格式的關鍵要素： As a,I want to so i can . 通過四步驟完成： 1.找出角色（role）； 2.明確

6、不同角色能夠做什么（goal）； 3.確定怎樣做會給該角色帶來的好處（business value）； 4.明確其衡量標準（Acceptance Test）。,分階段細化需求，并行研發(fā),Backlog示例如下：,分階段細化需求，并行研發(fā),兩層級溝通會逐漸細化明確研發(fā)范圍 需求會議： 每個迭代中期召開； 各Scrum開發(fā)團隊需求分析師討論下一迭代Sprint目標； 確定下一迭代Backlog優(yōu)先級； 討論需要跨團隊協(xié)調問題，指定責任人； 全員發(fā)布會議內容; 會議以需求Scrum團隊為單位。 下一迭代內容溝通會： 每個迭代中期召開； 需求分析師向Scrum開發(fā)團隊說明下一迭代工作目標和范圍； 開發(fā)

7、經理和測試工程師粗略估計工作量，最終確定下一迭代Backlog; 全員發(fā)布會議內容; 會議以開發(fā)Scrum團隊為單位。 (會議的具體說明，詳見附件),計劃執(zhí)行差之困分階段制定并跟蹤開發(fā)計劃,在研發(fā)過程中，由于時常受到一些計劃之外工作的干擾，譬如突發(fā)的項目支持問題、需求變更，往往導致制定的計劃執(zhí)行性差。結合Scrum敏捷研發(fā)思想，采用分階段執(zhí)行并跟蹤計劃，來確保計劃的可執(zhí)行性。包括估算迭代工作量、明確迭代頻度，和從計劃制定、發(fā)布到跟蹤的日常4個會議，隨時發(fā)現(xiàn)進度風險。 估算迭代工作量 Scrum敏捷應用的工作量估算，主要通過估算總工期、計算平均生存力，最終完成總工作量的估算。 總工作量=開發(fā)時間

8、+需求討論及設計交流時間 開發(fā)時間=總工期/平均生存力/開發(fā)人數(shù) 需求討論及設計交流時間=開發(fā)時間*30% 1.估算總工期 根據(jù)Product Backlog條目，逐條進行估算。,分階段制定并跟蹤開發(fā)計劃,2.計算平均生產力 根據(jù)每位開發(fā)工程師的工作能力和工作經驗估算生產力，計算平均生產力。,分階段制定并跟蹤開發(fā)計劃,3.估算總工作量 總工作量估算以開發(fā)時間為主。 明確迭代頻度 通常每個Sprint周期的長度由本版本產品的全部Backlog的總工期和開發(fā)團隊的研發(fā)效率來決定的，同時也要考慮產品的特點和團隊成員的開發(fā)節(jié)奏。 通常會選擇2-4周作為一個Sprint迭代周期，長短的優(yōu)缺點： 短的Sp

9、rint周期，意味著短的反饋周期，更頻繁的交付和用戶反饋，在錯誤的方向上花的時間更少，學習和改進速度更快。通常適用于需求變化頻繁的產品。 長的Sprint周期，意味著團隊有更多時間充分準備和解決問題，達成Sprint目標 ，同時不必被批發(fā)的Sprint計劃會和演示打斷開發(fā)節(jié)奏，通常適用于需求穩(wěn)定的產品。 特殊說明： 1.一旦確定Sprint周期，不要輕易調整，影響團隊開發(fā)節(jié)奏，影響研發(fā)效率。 2.在一個部門組織內，存在多個Scrum團隊時，盡量保持所有團隊步調一致。,分階段制定并跟蹤開發(fā)計劃,從計劃制定、發(fā)布到追蹤日常4個會議確保計劃可執(zhí)行 為了確保研發(fā)計劃的有效執(zhí)行，通過日常的4個會議，從計

10、劃制定、發(fā)布到追蹤，保證計劃的可執(zhí)行性。 迭代計劃會 作為迭代啟動會議，迭代開始時召開； 確定本迭代目標和本迭代Backlog; 評估工作量，完成Backlog細化開發(fā)任務、及任務的分配； 全員發(fā)布會議內容; 會議以開發(fā)Scrum團隊為單位。 每日立會 每天早上召開； 每個成員匯報昨天的開發(fā)進度和今天的開發(fā)計劃、及遇到的障礙； 會議以開發(fā)Scrum團隊為單位。,分階段制定并跟蹤開發(fā)計劃,開發(fā)經理會議 每個迭代中期召開； 各Scrum開發(fā)團隊的開發(fā)經理匯報各自團隊進度（尤其是接口協(xié)作任務進度）; 確定下一迭代接口協(xié)作任務的開發(fā)順序和完成時間； 說明各自團隊遇到的障礙和問題，分享各自團隊好的工作方

11、法和成果； 全員發(fā)布會議內容; 會議以開發(fā)經理Scrum團隊為單位。 進度評估會 每月召開一次； 需求開發(fā)、測試分別匯報研發(fā)進度； 說明各自業(yè)務團隊遇到的障礙和問題，安排負責人協(xié)調解決； 全員發(fā)布會議內容; 會議以部門級Scrum團隊為單位。,產品引用滿足度不高之困分階段提前驗證產品滿足度,根據(jù)Scrum敏捷開發(fā)思想，在每一個迭代最后召開“迭代演示會議”，研發(fā)團隊想架構師/產品經理或原型客戶演示本次迭代的成果，把產品的應用驗證提前到每個迭代，為偏差留出修正空間。同時通過日常研發(fā)過程分析，發(fā)現(xiàn)其中可能存在的風險，及時調整。 “迭代演示會議”提前驗證滿意度 迭代演示會議： 作為迭代成果驗收會議，迭

12、代完成時召開； 由測試工程師演示本迭代成果（產品功能）; 架構師/產品經理或原型客戶對迭代成果發(fā)表改進意見； 演示中的問題記入下一迭代工作內容； 全員發(fā)布迭代演示結果； 會議以Scrum開發(fā)團隊為單位.,附引進原型客戶的四個階段： 概要分析階段 找出原型客戶，即業(yè)務需求清晰、業(yè)務應用熟悉，具有行業(yè)普遍性或領先性。 需求調研階段 確認是否可以參與產品的研發(fā)過程，告知參與方式和頻度，確定具體客戶代表。 產品開發(fā)階段 參與迭代演示會議，提出迭代成果評審意見。 用戶驗證階段 參與用戶驗證，驗證產品功能。,日常研發(fā)過程分析 1.燃盡圖看Sprint內任務完成情況是否出現(xiàn)偏差 曲線明顯偏向上方時，存在任務

13、延期風險，明顯偏向下方時，任務進度提前，需要增加Backlog。,2.進度曲線圖看各迭代進度是否可控 每個迭代的完成標準是測試用例提交率100%，并通過迭代演示。 每個迭代的測試用例提交率在90%上下時，說明進度可控，延期率清晰可度量。 在進度穩(wěn)定可控的情況下，各迭代內測試用例個數(shù)逐漸增多，生存率穩(wěn)步提升。,3.缺陷積壓曲線圖看團隊工作負荷與產品質量 每個迭代缺陷積壓量相對平穩(wěn)，團隊工作負荷穩(wěn)定 采用優(yōu)先解決影響主流程缺陷的策略，新功能開發(fā)完成后（sprint7）,缺陷積壓以簡單控制性錯誤為主，迅速收斂，產品質量無重大風險。,研發(fā)人員業(yè)務能力參差不齊之困通過機制保證持續(xù)提升人員業(yè)務能力和研發(fā)效

14、率,“全員講師全員培訓”機制 研發(fā)團隊業(yè)務能力的提升一直困擾著各個研發(fā)機構，也制約著研發(fā)效率的提升。在Scrum敏捷應用過程中，每個人發(fā)揮各自擅長領域，人人都是講師人人都參加培訓，做到全員培訓營造學習型組織。 “迭代回顧會議”持續(xù)提升研發(fā)效率 會議關鍵點： 迭代完成時召開； 總結迭代開發(fā)過程中好的工作方式和可能的改進點； 團隊成員以頭腦風暴、輪流發(fā)言、自愿發(fā)言方式； 全員發(fā)布會議內容； 以Scrum開發(fā)團隊為單位。,“敏捷研發(fā)績效考核”機制 涵蓋Scrum敏捷團隊全部角色，同時兼顧在研產品研發(fā)和發(fā)版產品的項目支持，兼顧研產品的缺陷修復和發(fā)版后的產品質量，兼顧任務完成率和完成質量，以及推動重新的激勵機制。 績效考核結構圖：,效果與價值,NC5.7版本對于資金管理產品而言，是一個極具挑戰(zhàn)的版本，需要在不足6個月內完成4個全新的產品模塊開發(fā)，完成10個模塊的大幅度升級改造，在功能上達到超越競爭對手的目標，確立商場競爭優(yōu)勢，為后續(xù)的NC6.0開發(fā)奠定基礎。 采取Scrum敏捷開發(fā)方法后，工作質量和工作效率得到明顯提升：,效果與價值,同時也取得良好效果： 促進需求、開發(fā)、測試之