如何實施scrum青島易軟天創網絡科技有限公司2012/4/14（原作）彭優2017/04/26（精簡）總目錄scrum流程scrum中常見問題項目經理相關研發團隊相關測試人員相關會議相關2scrum流程scrum的基本流程圖scrum的基本流程詳情實施scrum的兩個階段傳統團隊轉向敏捷團隊開好幾個會議逐步找到適合團隊的開發實踐3scrum的基本流程圖4scrum的基本流程詳情如上圖所示，基本流程如下：產品負責人負責整理userstory，形成左側的productbacklog。發布計劃會議：productowner負責講解userstory，對其進行估算和排序，發布計劃會議的產出就是制定出這一期迭代要完成的story列表，sprintbacklog。迭代計劃會議：項目團隊對每一個story進行任務分解，分解的標準是完成該story的所有任務，最終每個任務都有明確的負責人，并完成工時的初估計。每日例會：每天scrummaster召集站立會議，團隊成員回答昨天做了什么今天計劃做什么，有什么問題。演示會議：迭代結束之后，召開演示會議，相關人員都受邀參加，團隊負責向大家展示本次迭代取得的成果。期間大家的反饋記錄下來，由po整理，形成新的story?；仡檿h：項目團隊對本期迭代進行總結，發現不足，制定改進計劃，下一次迭代繼續改進，已達到持續改進的效果。5實施scrum的兩個階段第一階段：嚴格按照scrum的流程進行。scrum已經是最簡流程，不宜再進行刪減。學習一樣東西很重要的就是初心，把原有的東西放下。組織結構層面的支持非常重要。第二階段：根據團隊實際情況進行調整。找到團隊最佳的迭代周期。找到團隊最佳的開發實踐。建立產品的發布節奏。6傳統團隊轉向敏捷團隊瀑布開發轉向迭代開發。固定的迭代周期，迭代周期內不能隨意改變需求。項目經理轉向scrummaster（簡稱SM）放權產品經理轉向productowner（簡稱PO）項目成員轉向teammember需求改用userstory跟蹤任務分解改為團隊來做。任務指派改為自由領取。甘特圖改用燃盡圖。獨立考核改為團隊的共進退。7開好幾個會議計劃會議第一部分：做好優先級的排序，考慮投入產出。計劃會議的第二部分：團隊分解，自主領取。每日的站立會議：控制時間，重在溝通，非匯報會議。不解決問題。演示會議：展示成果，得到反饋。提高團隊成就感?；仡檿h：逐步改進實踐。8逐步找到適合團隊的開發實踐結對編程代碼規范源代碼管理代碼review每日提交交叉測試重構分享會議簡單設計自動化測試框架9scrum中常見問題如何寫用戶故事？如何決定用戶故事的優先級？向迭代中添加需求，SM應該怎么做？10如何寫用戶故事？角色，做的事情，價值或者原因。定義完成的標準。UserStory應遵循INVEST規則：Independent獨立性，避免與其他Story的依賴性。Negotiable可談判性，Scrum中的story不是瀑布開始某事中的Contract,Stories不必太過詳細，開發人員可以給出適當的建議。Valuable有價值性，Story需要體現出對于用戶的價值Estimable可估計性，Story應可以估計出Task的開發時間。SizedRight合理的尺寸，Stories應該盡量小，并且使得團隊盡量在1個sprint(2weeks)中完成。Testable可測試性，UserStory應該是可以測試的，最好有界面可以測試和自動化測試。每個任務都應有JunitTest.11如何規定用戶故事的優先級？根據需求的價值和投入來估算ROI，投入產出比。有的需求價值很高，但開發團隊實現起來非常難，也是不行的。12向迭代中添加需求，SM應該怎么做？某天，大老板說，我們要做個什么東東。產品經理就找項目經理(scrummaster)說，“老板說了，要做個什么事情”，項目經理就把需求加上去了。或者產品經理直接找到研發人員，偷偷摸摸的加上某功能。向迭代中添加需求是scrum殺手，scrummaster應勇敢的說“不，請等待n周！”研發人員：沒有在（禪道）任務列表中的不做！??！scrummaster：沒有放入（禪道）sprintbacklog的不做！??！13項目經理相關角色的轉變考核的轉變后續的發展14角色的轉變從原來的管理者轉變為服務者心態的調整，從事必躬親改為放權放手讓團隊去做，允許團隊犯錯15考核的轉變敏捷開發團隊更是一個整體。共進共退，榮譽與共團隊的集體考核團隊內部自己進行考核16后續的發展scrummaster做到最成功的地方就是，這個團隊不再需要你了。那么肯定有項目經理犯嘀咕了，那我怎么辦啊?？赡艿姆较颍簊cummastertrainer：培養更多的scrummaster帶其他的團隊專向架構師轉向產品轉向開發團隊17研發團隊相關團隊人數要適當包含多種能力和角色將指派任務改為自由領取每次迭代改進一點形成自我組織的團隊將鍍金行為轉換為迭代需求文檔是必要的記得更新任務狀態18團隊人數要適當有的團隊人數太多，每天早上開站立會議都要很長時間。團隊人數太少，無法完成大的功能突破。建議5-9人。scrummaster和productowner不是team成員19包含多種能力和角色比如后臺和前臺比如測試比如DBA完成本期迭代所需要的所有技能20將指派任務改為自由領取傳統項目管理中，都是項目經理分解任務，然后指派到人?，F在改為團隊自主分解，自由領取。一定要選擇自己感興趣的。21每次迭代改進一點在每次迭代后，找到可以改進的地方持續改進找到適合團隊最佳的開發實踐22要形成自我組織的團隊要形成自我組織的團隊。項目經理的放權。開發團隊成員自主意識的崛起。23將鍍金行為轉換為迭代需求某位開發人員很開心的說，我又增加了一個功能。這個功能可能會酷，但它不在我們的計劃范圍內。功能可能會帶來很多意想不到的問題，甚至后果很嚴重。有想法可以提技術類的需求，排到迭代中。24文檔是必要的敏捷并不是不需要文檔各種各樣的設計文檔，比如數據庫設計文檔，api接口文檔。安裝部署文檔。25記得更新任務狀態燃盡圖開始橫著走啦。每天應當重新估計自己所負責任務的預計剩余時間。26測試人員相關bug管理及時關注task及bug的進度積極并認真地參與會議測試用例需經產品經理和開發人員復查27bug管理所有bug，不論bug的嚴重程度和bug的緊急程度，都要在禪道上有體現。確認是bug的，關閉該bug時，解決方案不是“已解決”的，都必須備注關閉原因。其中“不予解決”和“延期處理”的必須經產品經理確認后方可關閉。每天下班前在對應的項目群里發出所有未修正的bug列表，并@對應開發。線下測試時新版本發布后，先驗證禪道上已解決的bug，再繼續接下來的測試工作。28及時關注task及bug的進度最小可測試單元完成開發后，及時測試bug修復后，及時部署到測試環境并回歸29積極并認真地參與會議務必參與以下會議需求討論會每日站會參會前一定要準備充分，如在需求討論會之前，熟悉需求文檔、原型圖和流程圖。30測試用例需經產品經理和開發人員復查測試用例完成后，需告知產品經理和開發人員產品經理和開發人員可以從不同的角度對測試用例進行完善。31會議相關計劃會議不宜太長站立會議不宜太長演示會議的必要性回顧會議的必要性32計劃會議不宜太長產品計劃會議和迭代計劃會議嚴格控制在一天內結束。scrummaster需要主要掌控會議進程。在召開產品計劃會議之前，scrummaster和產品負責人可以事先做一些準備。33站立會議不宜太長站立會議最好控制在15分鐘內。站立會議主要的目的在于溝通，團隊成員之間彼此更新信息，及時發現風險。不是問題的解決會議。問題應該在會后討論，并由相關人員加以解決。34演示會議的必要性演示會議是非常好的展示團隊風采和提升團隊士氣，增加成就感的方式。也是非常好的展示產品和獲得反饋的機會。也是對外證明，我們的游戲規則是遵守的，你可以信賴我們。35回顧會議的必要性回顧會議是為了持續改進。會議要形成計劃，產生行動。36謝謝結束37演講完畢，謝謝觀看！內容總結如何實施scrum。青島易軟天創網絡科技有限公司2012/4/14（原作）。彭優2017/04/26（精簡）。產品負責人負責整理userstory，形成左側的productbacklog。每日例會：每天scrummaster召集站立會議，團隊成員回答昨天做了什么今天計劃做什么，有什么問題。學習一樣東西很重要的就是初心，把原有的東西放下。瀑布開發轉向迭代開發。固定的迭代周期，迭代周期內不能隨意改