項目管理01_如何實施scrumppt課件

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

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

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

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

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

6、用戶故事的優(yōu)先級？根據(jù)需求的價值和投入來估算ROI，投入產(chǎn)出比。有的需求價值很高，但開發(fā)團隊實現(xiàn)起來非常難，也是不行的。12向迭代中添加需求，SM應(yīng)該怎樣做？某天，大老板說，我們要做個什么東東。產(chǎn)品經(jīng)理就找工程經(jīng)理(scrum master)說，“老板說了，要做個什么事情，工程經(jīng)理就把需求加上去了。或者產(chǎn)品經(jīng)理直接找到研發(fā)人員，偷偷摸摸的加上某功能。向迭代中添加需求是scrum殺手，scrum master應(yī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)放手讓團隊去做，允許團隊犯錯15考核的轉(zhuǎn)變矯捷開發(fā)團隊更是一個整體。共進共退，榮譽與共團隊的集體考核團隊內(nèi)部本人進展考核16后續(xù)的開展scrum master 做到最勝利的地方就是，這個團隊不再需求他了。那么一定有工程經(jīng)理犯嘀咕了，那我怎樣辦啊。能夠的方向：scum master trainer：培育更多的scrum master帶其他的團隊專向架構(gòu)師轉(zhuǎn)向產(chǎn)品轉(zhuǎn)向開發(fā)團隊17研發(fā)團隊相關(guān)團隊人數(shù)要適當包含多種才干和角色將指派義務(wù)改為自在領(lǐng)取每次迭代改良一點構(gòu)成自我組織的團隊將鍍金行為轉(zhuǎn)換為迭代需求文檔是必要的記得更新義務(wù)形狀1

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

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

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