1、a,1,a,2,Scrum 敏捷,a,3,目錄, Scrum概覽, Scrum中的角色和關(guān)鍵原則, Scrum流程：策劃、執(zhí)行跟蹤、回顧, 幾個應(yīng)用主題（發(fā)布周期、度量、大團隊）, We Need Scrum?,a,4, 產(chǎn)品投放市場的時間太慢 項目失敗的比例高的離譜 投資回報低，經(jīng)常失敗 對變化與變更的響應(yīng)，難度大且成本高 客戶體驗及客戶為導(dǎo)向很差 軟件質(zhì)量不過關(guān) 生產(chǎn)力需要大幅提高 員工士氣，動力及責(zé)任感很低 需要普遍的微觀管理 人員流失率特別高 .,許多企業(yè)面臨的問題與挑戰(zhàn),a,5,越來越多的企業(yè)使用Scrum解決這些問題,Google IBM Nokia Siemens Philips

2、 Accenture Sun UbisoB Bleum SAP, Microsoft Infosys Oracle Wipro Motorola Yahoo! Schneider Agilent Irdeto Double Click, Autodesk Tencent Plenware Trendmicro Moodys StarCite,a,6,哪些類型的項目已經(jīng)在使用Scrum,大型企業(yè)級軟件項目 商業(yè)軟件產(chǎn)品 消費者軟件項目/大型網(wǎng)站 美國FDA批準(zhǔn)的應(yīng)用于X射線和MRI的軟件 高可靠性系統(tǒng)（99.9999以上） 財務(wù)支付系統(tǒng) 智能家居項目 戰(zhàn)斗機項目,大型數(shù)據(jù)庫應(yīng)用 嵌入式電信系統(tǒng)

3、手機項目 CMMI5級的組織 多地點同步開發(fā) 支撐和維護項目 非軟件項目 ,a,7,Scrum在Yahoo！的應(yīng)用(引Scrum中文網(wǎng)),Yahoo! 在全球有超過200個團隊（超過兩千人）使用Scrum, ,面向用戶的項目 關(guān)鍵的基礎(chǔ)設(shè)施項目 分布式項目 全新產(chǎn)品開發(fā) 維護型項目,這份調(diào)查的數(shù)據(jù)是在Yahoo!采納Scrum后18個月時采集, ,反映80個團隊的情況 采用匿名方式 得到84%的調(diào)查響應(yīng)率,a,8,與傳統(tǒng)方法的對比：團隊生產(chǎn)力,a,9,與傳統(tǒng)方法的對比：士氣,a,10,與傳統(tǒng)方法的對比：責(zé)任感與主人翁意識,a,11,與傳統(tǒng)方法的對比：協(xié)調(diào)與合作,a,12,與傳統(tǒng)方法的對比：交付

4、質(zhì)量,a,13,有多少人愿意繼續(xù)使用Scrum,a,14,下一章節(jié),a,15,目錄, Scrum概覽, Scrum中的角色和關(guān)鍵原則, Scrum流程：策劃、執(zhí)行跟蹤、回顧, 幾個應(yīng)用主題（發(fā)布周期、度量、大團隊）, We Need Scrum?,a,16,敏捷價值觀之敏捷宣言（認同）,過程和工具 完備的文檔 合同談判 遵循計劃,重于 重于 重于 重于,個體與交互 可用的軟件 客戶協(xié)作 響應(yīng)變化,a,17,什么是Scrum？（ 一個輕量級的軟件開發(fā)方法 ）,Scrum是一個敏捷開發(fā)框架，是一個增量的、迭代的開發(fā)過程。 1. Scrum中項目整個開發(fā)周期包括若干個小的跌代周期，每個小的的跌代周期

5、稱為一個Sprint，每個 Sprint的建議長度2到4周。 2. 使用產(chǎn)品Backlog來管理產(chǎn)品或項目的需求，產(chǎn)品backlog是一個按照商業(yè)價值排序的需求列表，列表 條目的體現(xiàn)形式通常為用戶故事（UserStory）。 3. 團隊從產(chǎn)品Backlog中挑選最有商業(yè)價值的需求，需求經(jīng)過Sprint計劃會議上的分析、討論和估算得到 一個Sprint的任務(wù)列表，我們稱它為Sprint backlog 。 4.在每個迭代結(jié)束時，Scrum團隊將交付潛在可交付的產(chǎn)品增量。,a,18,Scrum框架流程,a,19,Scrum框架組成,3,三個角色 產(chǎn)品負責(zé)人 Scrum Master 團隊,Spri

6、nt計劃會議 每日站會 Sprint評審會議 Sprint 回顧會議,四個儀式,3,三個產(chǎn)物 產(chǎn)品Backlog Sprint Backlog 個角色 燃盡圖,a,20,Scrum使用的幾個原則, 不同類型/背景的項目需要不同的管理方法, 以項目成果為導(dǎo)向而不是過程導(dǎo)向, 衡量項目成功與否，要看重項目成果的商業(yè)價,值和ROI（投資回報），而非僅超支、延期、遵循計劃, 20/80法則，最大可能滿足涉眾核心需要, 及時讓涉眾參與，并及早展現(xiàn)項目進展和成,果，及時調(diào)整，確保交付商業(yè)價值最大化,a,21,Scrum特點, 適于在不確定性高的環(huán)境中開發(fā)復(fù)雜產(chǎn)品； 簡潔但有效；, 易于學(xué)習(xí)和掌握；, 能夠

7、在開發(fā)進程中不斷檢查，并作出相應(yīng)調(diào)整；, 項目信息對所有干系人高度透明；, 便于快速發(fā)現(xiàn)問題，促使團隊和組織持續(xù)改,進；,a,22,Scrum中的角色, Scrum Master, 項目經(jīng)理 ？教練 ？QA？, Product Owner, 產(chǎn)品經(jīng)理？, Team,a,23,團隊構(gòu)成, 7人，+ or - 2, 偏小一些會更合適, 應(yīng)100%投入到迭代中 最好坐在一起, 角色交叉, 包含增量開發(fā)產(chǎn)品所需的所有技能, 開發(fā)、測試、UI設(shè)計、技術(shù)文檔編寫 團隊基于技能而不是“崗位”來認領(lǐng)工作,a,24,團隊管理模式, 自我管理和自我組織, 團隊決定要完成的工作量，相互協(xié)作進行任務(wù)管理,和執(zhí)行，以實

8、現(xiàn)承諾的目標(biāo), 只有團隊失敗而沒有個人失敗的原則,a,25,Scrum軟件項目分析，優(yōu)點。, ,你有5個月時間可用； 你要交付5個特性； 每個月，你有100人日可用 每個特性需要20人日設(shè)計、40人日開發(fā)、20 人日測試、20人日返工（解決bug、優(yōu)化）,商業(yè)價值 40單位 24單位 20單位 12單位 4單位 100單位,特性 F1 F2 F3 F4 F5 總計,a,26,傳統(tǒng)模式 根據(jù)第一頁給出的信息，計算每個階段的時間 長度（考慮實際團隊情況，不完整），在下圖 中標(biāo)識出階段劃分。,M1,M2,M3,M4,M5,a,27,Scrum模式 根據(jù)第一頁給出的信息，計劃一下你的開發(fā)進 度（團隊拆

9、分，細節(jié)把握，提高質(zhì)量）,M1,M2,M3,M4,M5,a,28,下一章節(jié),a,29,目錄, Scrum概覽, Scrum中的角色和關(guān)鍵原則, Scrum流程：站會、策劃和回顧, 幾個應(yīng)用主題（發(fā)布周期、度量、大團隊）, We Need Scrum?,a,30,Scrum Master, SM幫助團隊學(xué)習(xí)和應(yīng)用Scrum來實現(xiàn)商業(yè)價值, SM盡其所能幫助團隊獲得成功, 服務(wù)團隊 保護團隊, 引導(dǎo)大家有效應(yīng)用Scrum, SM不是團隊的“老板”, 不負責(zé)為團隊分配任務(wù) 不會幫團隊做決定, 不對團隊及時完成工作負責(zé),a,31,Scrum Master做什么事情？, 服務(wù)團隊, 幫助團隊排除障礙和問

10、題（“絆腳石”）, 促進協(xié)作，包括團隊內(nèi)、團隊和Product Owner間, 保護團隊, 保護團隊，使之免收外界干擾或威脅, 教導(dǎo)團隊, 幫助團隊和PO改進工作的有效性, 幫助團隊和PO 面對并解決困難和問題, 引導(dǎo)Scrum的有效應(yīng)用, 把Scrum教給團隊、PO和整個公司 確保所有標(biāo)準(zhǔn)Scrum實踐得到遵循,a,32,Scrum Master的選擇 高效SM的特征, ,對團隊的成功有高度的責(zé)任心 良好的人緣、良好的溝通技能 敏感、好的聆聽者 積極、樂于助人 技術(shù)專家，會更有幫助但非必要, 專職SM會有最好的成果 如果不能專職，必須有一位成員擔(dān)當(dāng)這個角色（相應(yīng) 降低他的原工作負擔(dān)） 避免讓

11、團隊行政管理者做 做SM 因為大家會指望原管理者來作規(guī)劃，也就很難做到自 我管理,a,33,Product Owner, 負責(zé)最大化項目ROI（投資回報）, 實現(xiàn)手段：, 多方收集意見，充分了解機會和風(fēng)險；, 確定清晰、一致的愿景及目標(biāo)，明確為實現(xiàn)最大,商業(yè)價值所需做的事情；, 制訂一個需求表，按照優(yōu)先級列出特性和功能； 積極參加迭代計劃和迭代回顧會議，在迭代中為,團隊提供支持；, 基于日常觀察和學(xué)習(xí)，持續(xù)精煉和優(yōu)化PB；, 對PB優(yōu)先級有最終決策權(quán),a,34,Scrum給團隊管理者帶來哪些變化, 第1步：列出管理者過去負責(zé)的事項列表,（盡可能列全）, 第2步：勾掉列表中：, 與Scrum沖突

12、的；, 在Scrum中不必要的；, 對實現(xiàn)團隊自我管理有不良影響的；,a,35,管理者2.0, 第3步：幫助管理者按照以上步驟，梳理一,份新的工作說明；, 第4步：與管理者的上級和HR溝通，爭取,理解和支持；,a,36,迭代中不允許變更, 禁止變更交付件和交付日期, 一旦團隊作出承諾，就不允許變更交付件 如果發(fā)生重大變化，PO可以中止當(dāng)次迭代, 在迭代中會出現(xiàn)“分解”和“澄清”，但是不允許添加,新工作，或者對現(xiàn)有工作進行“實質(zhì)變更”, “變更”vs“澄清”, 如果存在爭議，那么將其認定為變更，放到PB,中，下一次迭代再考慮。, 在我們實際應(yīng)用中，將較低級別的需求剔除掉。,a,37,變更的影響

13、在迭代期間，如果PO增加只需要少量工作的工 作項，或替換部分工作項，會有什么影響？,當(dāng)前迭代,今后的迭代,團隊交 PO滿 付承諾 意度 項的能 力,團隊 對交 付件 的承 諾,PO不 提變 更的 自律,PO寫 PB的 規(guī)則,團隊對 團隊遵 其它團 要交付 循其它 隊遵循 承諾內(nèi) Scrum Scrum 容的關(guān) 規(guī)則的 規(guī)則的 注度 自律性 自律性,a,38,PO用戶故事, 用戶故事是寫PB的好方法之一；, 用戶故事是簡短、明確的功能說明，按照,用戶價值和用戶需要編寫。,a,39,迭代計劃會議, 團隊確定在迭代結(jié)束時，能完成多少PB 對于2周迭代的項目，會議一般花3-4小時, 分兩部分（同一天內(nèi)

14、，連續(xù)）, 第一部分 （PO召開需求評審會） ：團隊評審PO想要的東西， 然后與PO確認“完成”的定義, 第二部分(團隊拆分需求，打撲克牌)：團隊決定承諾完成多少， 以及如何實現(xiàn)承諾。,a,40,迭代策劃第一部分, PO介紹PB中最優(yōu)先PB項的細節(jié), 團隊提出問題、建議，就疑問進行確認 協(xié)商對PB需要做的修改, 團隊驅(qū)動項增加到PB中 大粒度項拆分, 任何其它提煉和優(yōu)化, 團隊和PO評審標(biāo)準(zhǔn)的“完成定義”，就所有,修訂達成一致,a,41,“完成”定義,在迭代結(jié)束時，要“完成”的功能，,必須完成以下步驟：,1 開發(fā)規(guī)格說明書,2 開發(fā)規(guī)格說明書評審 3 開發(fā)完成 4 代碼review,5 單元測

15、試完成 6 測試用例完成 7 測試用例評審 8 測試執(zhí)行報告 9 已提交至測試集成 , 缺陷標(biāo)準(zhǔn)： 不允許P1 P2缺陷，P3缺陷小于3個,a,42,達到“完成”不太好的方式,a,43,達到“完成”更好的方式,a,44,迭代策劃第二部分, 團隊開始將PB項分解為工作任務(wù)，并且估計需要,的時間, 對照團隊可用資源，團隊承諾本迭代完成量，確,保工作量適當(dāng), 所有團隊成員都參與會議和討論，無論經(jīng)驗多少,及能力高低,a,45,計劃紙牌,a,46,燃盡圖,a,47,每日Scrum會議, 會議目的：, 保持團隊內(nèi)部協(xié)調(diào)順暢，相互之間進展明晰 每天暴露困難和障礙，非團隊監(jiān)管, 如何開展：, 在Task白板處

16、，每個工作日舉行，團隊所有成員參加 （開會時間到，不等待其他成員，小組自定義懲罰措施。） 圍成一個圈，面向圓心（而非SM） 行政管理者最好回避, 每個人匯報3件事（也可以做一些調(diào)整） 會議中不允許討論（如果確實必要，簡潔一點）,a,48,每日Scrum會議, Master任務(wù)：, 記錄并現(xiàn)場解答跟蹤問題。 更新燃盡圖。, 團隊個人(每個人1-3分鐘陳述，講給團隊), 昨天完成的Task。 今天將認領(lǐng)的Task。 需要協(xié)助解決的問題。,a,49,白板,a,50,迭代回顧（回顧會議）, 迭代回顧的目的：產(chǎn)品檢查和適應(yīng), 參與者：團隊、PO、SM、各職能組leader、其,他涉眾；, 參考方式：,

17、演示產(chǎn)品，驗證迭代期內(nèi)的承諾完成內(nèi)容。相關(guān)人員一起討,論產(chǎn)品與“完成標(biāo)準(zhǔn)”的偏差。, 團隊向PO提出產(chǎn)品相關(guān)議題，或迭代中碰到的問題（例如：,在后續(xù)迭代中需要解決的技術(shù)問題）, PO向團隊提出產(chǎn)品相關(guān)議題，或迭代中碰到的問題（例如：,市場變化、用戶新需求等）,a,51,迭代總結(jié)(總結(jié)報告上傳至WIKI,統(tǒng)一管理) 迭代總結(jié)的目的：團隊工作方式檢查和自適應(yīng) 參考方式： 每次迭代回顧后召開，1-2小時 團隊、SM參加 管理者和PO應(yīng)參加，但只部分時間參與，團隊需要內(nèi)部交 談時間 通常會邀請一位中立人員來擔(dān)當(dāng)會議協(xié)調(diào)人 討論四個主題, ,哪些做得好 那些需要改善（不太好的） 需要在以后嘗試的事情（今

18、后迭代中改善） 要上報的問題（向管理者）,a,52,迭代總結(jié)記錄,a,53,下一章節(jié),a,54,目錄, Scrum概覽, Scrum中的角色和關(guān)鍵原則, Scrum流程：策劃、執(zhí)行跟蹤、回顧, 幾個應(yīng)用主題（發(fā)布周期、度量、大團隊）, We Need Scrum?,a,55,Scrum 中的發(fā)布周期,a,56,Scrum發(fā)布周期, 兩種常見方法：, 多次迭代發(fā)布：, 每次迭代發(fā)布：,a,57,頂層設(shè)計和架構(gòu)調(diào) 研，開發(fā)環(huán)境安裝,多次迭代發(fā)布方法之一 發(fā)布前SPRINT,最終穩(wěn)定和發(fā)布 準(zhǔn)備,a,58,多次迭代發(fā)布方法之一,在項目接近結(jié)束 時，縮短迭代,期，以更快地檢 查/適應(yīng),a,59,簡介：,Scrum和度量,a,60,Scrum和度量, Scrum不會阻止你跟蹤或測量你所實施的開發(fā)過,程；, 不過，你必須當(dāng)心測量的可能不良后果, 比如：個人燃燒圖, 測量的記錄和匯報可能需要花費資源, 如果確實需要消耗團隊資源，應(yīng)該讓這些消耗在任務(wù),時間估計時明確出來，或作為一個PB或SB項,a,61,常用度量, 進度差異對比, 用實際速度比較估計速度；, 工作量差異對比, 任務(wù)匯總成本（跟蹤本身的工作量，及可能引發(fā)的問,題和數(shù)據(jù)作弊）；, 實際消耗時間 vs 預(yù)計消耗時間；, 掙得值（已實現(xiàn)商業(yè)價值）, 商業(yè)價值燃燒圖,a,62,簡介： ：Scrum自適應(yīng),-如何應(yīng)