項(xiàng)目管理01_如何實(shí)施scrumppt課件

1、如何實(shí)施scrum青島易軟天創(chuàng)網(wǎng)絡(luò)科技 2021/4/14原作彭優(yōu) 2021/04/26精簡(jiǎn)總目錄scrum流程scrum中常見問題工程經(jīng)理相關(guān)研發(fā)團(tuán)隊(duì)相關(guān)測(cè)試人員相關(guān)會(huì)議相關(guān)2scrum流程scrum的根本流程圖scrum的根本流程概略實(shí)施scrum的兩個(gè)階段傳統(tǒng)團(tuán)隊(duì)轉(zhuǎn)向矯捷團(tuán)隊(duì)開好幾個(gè)會(huì)議逐漸找到適宜團(tuán)隊(duì)的開發(fā)實(shí)際3scrum的根本流程圖4scrum的根本流程概略5如上圖所示，根本流程如下：產(chǎn)品擔(dān)任人擔(dān)任整理user story，構(gòu)成左側(cè)的product backlog。發(fā)布方案會(huì)議：product owner擔(dān)任講解user story，對(duì)其進(jìn)展估算和排序，發(fā)布方案會(huì)議的產(chǎn)出就是制定出這

2、一期迭代要完成的story列表，sprint backlog。迭代方案會(huì)議：工程團(tuán)隊(duì)對(duì)每一個(gè)story進(jìn)展義務(wù)分解，分解的規(guī)范是完成該story的一切義務(wù)，最終每個(gè)義務(wù)都有明確的擔(dān)任人，并完成工時(shí)的初估計(jì)。每日例會(huì)：每天scrum master召集站立會(huì)議，團(tuán)隊(duì)成員回答昨天做了什么今天方案做什么，有什么問題。演示會(huì)議：迭代終了之后，召開演示會(huì)議，相關(guān)人員都受邀參與，團(tuán)隊(duì)擔(dān)任向大家展現(xiàn)本次迭代獲得的成果。期間大家的反響記錄下來，由po整理，構(gòu)成新的story?；叵霑?huì)議：工程團(tuán)隊(duì)對(duì)本期迭代進(jìn)展總結(jié)，發(fā)現(xiàn)缺乏，制定改良方案，下一次迭代繼續(xù)改良，已到達(dá)繼續(xù)改良的效果。實(shí)施scrum的兩個(gè)階段第一階段：

3、嚴(yán)厲按照scrum的流程進(jìn)展。 scrum曾經(jīng)是最簡(jiǎn)流程，不宜再進(jìn)展刪減。學(xué)習(xí)一樣?xùn)|西很重要的就是初心，把原有的東西放下。 組織構(gòu)造層面的支持非常重要。第二階段：根據(jù)團(tuán)隊(duì)實(shí)踐情況進(jìn)展調(diào)整。找到團(tuán)隊(duì)最正確的迭代周期。找到團(tuán)隊(duì)最正確的開發(fā)實(shí)際。建立產(chǎn)品的發(fā)布節(jié)拍。6傳統(tǒng)團(tuán)隊(duì)轉(zhuǎn)向矯捷團(tuán)隊(duì)瀑布開發(fā)轉(zhuǎn)向迭代開發(fā)。固定的迭代周期，迭代周期內(nèi)不能隨意改動(dòng)需求。工程經(jīng)理轉(zhuǎn)向scrum master 簡(jiǎn)稱SM放權(quán)產(chǎn)品經(jīng)理轉(zhuǎn)向 product owner簡(jiǎn)稱PO工程成員轉(zhuǎn)向 team member需求改用 user story 跟蹤義務(wù)分解改為團(tuán)隊(duì)來做。義務(wù)指派改為自在領(lǐng)取。甘特圖改用燃盡圖。獨(dú)立考核改為團(tuán)隊(duì)的共

4、進(jìn)退。7開好幾個(gè)會(huì)議方案會(huì)議第一部分：做好優(yōu)先級(jí)的排序，思索投入產(chǎn)出。方案會(huì)議的第二部分：團(tuán)隊(duì)分解，自主領(lǐng)取。每日的站立會(huì)議：控制時(shí)間，重在溝通，非匯報(bào)會(huì)議。不處理問題。演示會(huì)議：展現(xiàn)成果，得到反響。提高團(tuán)隊(duì)成就感。 回想會(huì)議：逐漸改良實(shí)際。8逐漸找到適宜團(tuán)隊(duì)的開發(fā)實(shí)際結(jié)對(duì)編程代碼規(guī)范源代碼管理代碼review每日提交交叉測(cè)試重構(gòu)分享會(huì)議簡(jiǎn)單設(shè)計(jì)自動(dòng)化測(cè)試框架9scrum中常見問題如何寫用戶故事？如何決議用戶故事的優(yōu)先級(jí)？向迭代中添加需求，SM應(yīng)該怎樣做？10如何寫用戶故事？角色，做的事情，價(jià)值或者緣由。定義完成的規(guī)范。User Story應(yīng)遵照INVEST規(guī)那么：Independent 獨(dú)立

5、性，防止與其他Story的依賴性。Negotiable 可談判性，Scrum中的story不是瀑布開場(chǎng)某事中的Contract, Stories不用太過詳細(xì)，開發(fā)人員可以給出適當(dāng)?shù)慕ㄗh。Valuable 有價(jià)值性， Story需求表達(dá)出對(duì)于用戶的價(jià)值 Estimable 可估計(jì)性，Story應(yīng)可以估計(jì)出Task的開發(fā)時(shí)間。 Sized Right 合理的尺寸， Stories應(yīng)該盡量小，并且使得團(tuán)隊(duì)盡量在1個(gè)sprint(2 weeks)中完成。 Testable 可測(cè)試性， User Story應(yīng)該是可以測(cè)試的，最好有界面可以測(cè)試和自動(dòng)化測(cè)試。每個(gè)義務(wù)都應(yīng)有Junit Test.11如何規(guī)定

6、用戶故事的優(yōu)先級(jí)？根據(jù)需求的價(jià)值和投入來估算ROI，投入產(chǎn)出比。有的需求價(jià)值很高，但開發(fā)團(tuán)隊(duì)實(shí)現(xiàn)起來非常難，也是不行的。12向迭代中添加需求，SM應(yīng)該怎樣做？某天，大老板說，我們要做個(gè)什么東東。產(chǎn)品經(jīng)理就找工程經(jīng)理(scrum master)說，“老板說了，要做個(gè)什么事情，工程經(jīng)理就把需求加上去了。或者產(chǎn)品經(jīng)理直接找到研發(fā)人員，偷偷摸摸的加上某功能。向迭代中添加需求是scrum殺手，scrum master應(yīng)英勇的說“不， 請(qǐng)等待n周！研發(fā)人員：沒有在禪道義務(wù)列表中的不做！scrum master：沒有放入禪道sprint backlog的不做！13工程經(jīng)理相關(guān)角色的轉(zhuǎn)變考核的轉(zhuǎn)變后續(xù)的開展1

7、4角色的轉(zhuǎn)變從原來的管理者轉(zhuǎn)變?yōu)樾Яφ咝膽B(tài)的調(diào)整，從事必躬親改為放權(quán)放手讓團(tuán)隊(duì)去做，允許團(tuán)隊(duì)犯錯(cuò)15考核的轉(zhuǎn)變矯捷開發(fā)團(tuán)隊(duì)更是一個(gè)整體。共進(jìn)共退，榮譽(yù)與共團(tuán)隊(duì)的集體考核團(tuán)隊(duì)內(nèi)部本人進(jìn)展考核16后續(xù)的開展scrum master 做到最勝利的地方就是，這個(gè)團(tuán)隊(duì)不再需求他了。那么一定有工程經(jīng)理犯嘀咕了，那我怎樣辦啊。能夠的方向：scum master trainer：培育更多的scrum master帶其他的團(tuán)隊(duì)專向架構(gòu)師轉(zhuǎn)向產(chǎn)品轉(zhuǎn)向開發(fā)團(tuán)隊(duì)17研發(fā)團(tuán)隊(duì)相關(guān)團(tuán)隊(duì)人數(shù)要適當(dāng)包含多種才干和角色將指派義務(wù)改為自在領(lǐng)取每次迭代改良一點(diǎn)構(gòu)成自我組織的團(tuán)隊(duì)將鍍金行為轉(zhuǎn)換為迭代需求文檔是必要的記得更新義務(wù)形狀1

8、8團(tuán)隊(duì)人數(shù)要適當(dāng)有的團(tuán)隊(duì)人數(shù)太多，每天早上開站立會(huì)議都要很長時(shí)間。團(tuán)隊(duì)人數(shù)太少，無法完成大的功能突破。建議5-9人。scrum master和product owner不是team成員19包含多種才干和角色比如后臺(tái)和前臺(tái)比如測(cè)試比如DBA完本錢期迭代所需求的一切技藝20將指派義務(wù)改為自在領(lǐng)取傳統(tǒng)工程管理中，都是工程經(jīng)理分解義務(wù)，然后指派到人。如今改為團(tuán)隊(duì)自主分解，自在領(lǐng)取。一定要選擇本人感興趣的。21每次迭代改良一點(diǎn)在每次迭代后，找到可以改良的地方繼續(xù)改良找到適宜團(tuán)隊(duì)最正確的開發(fā)實(shí)際22要構(gòu)成自我組織的團(tuán)隊(duì)要構(gòu)成自我組織的團(tuán)隊(duì)。工程經(jīng)理的放權(quán)。開發(fā)團(tuán)隊(duì)成員自主認(rèn)識(shí)的崛起。23將鍍金行為轉(zhuǎn)換為迭

9、代需求某位開發(fā)人員很開心的說，我又添加了一個(gè)功能。這個(gè)功能能夠會(huì)酷，但它不在我們的方案范圍內(nèi)。功能能夠會(huì)帶來很多意想不到的問題，甚至后果很嚴(yán)重。有想法可以提技術(shù)類的需求，排到迭代中。24文檔是必要的矯捷并不是不需求文檔各種各樣的設(shè)計(jì)文檔，比如數(shù)據(jù)庫設(shè)計(jì)文檔，api接口文檔。安裝部署文檔。25記得更新義務(wù)形狀燃盡圖開場(chǎng)橫著走啦。每天該當(dāng)重新估計(jì)本人所擔(dān)任義務(wù)的估計(jì)剩余時(shí)間。26測(cè)試人員相關(guān)bug管理及時(shí)關(guān)注task及bug的進(jìn)度積極并仔細(xì)地參與會(huì)議測(cè)試用例需經(jīng)產(chǎn)品經(jīng)理和開發(fā)人員復(fù)查27bug管理一切bug，不論bug的嚴(yán)重程度和bug的緊急程度，都要在禪道上有表達(dá)。確認(rèn)是bug的，封鎖該bug時(shí)

10、，處理方案不是“已處理的，都必需備注封鎖緣由。其中“不予處理和“延期處置的必需經(jīng)產(chǎn)品經(jīng)理確認(rèn)后方可封鎖。每天下班前在對(duì)應(yīng)的工程群里發(fā)出一切未修正的bug列表，并對(duì)應(yīng)開發(fā)。線下測(cè)試時(shí)新版本發(fā)布后，先驗(yàn)證禪道上已處理的bug，再繼續(xù)接下來的測(cè)試任務(wù)。28及時(shí)關(guān)注task及bug的進(jìn)度最小可測(cè)試單元完成開發(fā)后，及時(shí)測(cè)試bug修復(fù)后，及時(shí)部署到測(cè)試環(huán)境并回歸29積極并仔細(xì)地參與會(huì)議務(wù)必參與以下會(huì)議需求討論會(huì)每日站會(huì)參會(huì)前一定要預(yù)備充分，如在需求討論會(huì)之前，熟習(xí)需求文檔、原型圖和流程圖。30測(cè)試用例需經(jīng)產(chǎn)品經(jīng)理和開發(fā)人員復(fù)查測(cè)試用例完成后，需告知產(chǎn)品經(jīng)理和開發(fā)人員產(chǎn)品經(jīng)理和開發(fā)人員可以從不同的角度對(duì)測(cè)試用例進(jìn)展完善。31會(huì)議相關(guān)方案會(huì)議不宜太長站立會(huì)議不宜太長演示會(huì)議的必要性回想會(huì)議的必要性32方案會(huì)議不宜太長33產(chǎn)品方案會(huì)議和迭代方案會(huì)議嚴(yán)厲控制在一天內(nèi)終了。scrum master需求主要掌控會(huì)議進(jìn)程。在召開產(chǎn)品方案會(huì)議之前，scrum master和產(chǎn)品擔(dān)任人可以事先做一些預(yù)備。站立會(huì)議不宜太長站立會(huì)議最好控制在15分鐘內(nèi)。站立會(huì)議主要的目的在于溝通，團(tuán)隊(duì)成員之間彼此更新信息，及時(shí)