如何實施scrum及常見問題,青島易軟天創(chuàng)網絡科技有限公司 2012/4/14,2,實施scrum幾個階段,第一階段：嚴格按照scrum的流程進行。 scrum已經是最簡流程，不宜再進行刪減。 學習一樣東西很重要的就是初心，把原有的東西放下。 組織結構層面的支持非常重要。 第二階段：根據團隊實際情況進行調整。 找到團隊最佳的迭代周期。 找到團隊最佳的開發(fā)實踐。 建立產品的發(fā)布節(jié)奏。,3,傳統(tǒng)團隊轉向敏捷團隊,瀑布開發(fā)轉向迭代開發(fā)。 固定的迭代周期，迭代周期內不能隨意改變需求。 項目經理轉向scrum master 放權 產品經理轉向 product owner 項目成員轉向 team member 需求改用 user story 跟蹤 任務分解改為團隊來做。 任務指派改為自由領取。 甘特圖改用燃盡圖。 獨立考核改為團隊的共進退。,4,開好幾個會議,計劃會議第一部分：做好優(yōu)先級的排序，考慮投入產出。 計劃會議的第二部分：團隊分解，自主領取。 每日的站立會議：控制時間，重在溝通，非匯報會議。不解決問題。 演示會議：展示成果，得到反饋。提高團隊成就感。 總結會議：逐步改進實踐。,5,逐步找到適合團隊的開發(fā)實踐,結對編程 代碼規(guī)范 源代碼管理 代碼review 每日提交 交叉測試 重構 分享會議 簡單設計 自動化測試 框架,6,產品常見問題,如何寫用戶故事？ 是否還需要原型圖？ 是否還需要詳細設計？ 如何決定用戶故事的優(yōu)先級？ 向迭代中添加需求 沒有發(fā)布計劃 沒有定義需求完成的標準 不參與研發(fā)過程。,7,如何寫用戶故事,角色，做的事情，價值或者原因。 定義完成的標準。 User Story應遵循INVEST規(guī)則： Independent 獨立性，避免與其他Story的依賴性。 Negotiable 可談判性，Scrum中的story不是瀑布開始某事中的Contract, Stories不必太過詳細，開發(fā)人員可以給出適當的建議。 有價值性， Story需要體現出對于用戶的價值 Estimable 可估計性，Story應可以估計出Task的開發(fā)時間。 Sized Right 合理的尺寸， Stories應該盡量小，并且使得團隊盡量在1個sprint(2 weeks)中完成。 Testable 可測試性， User Story應該是可以測試的，最好有界面可以測試和自動化測試。每個任務都應有Junit Test.,8,是否還需要原型圖？,scrum里面并沒有規(guī)定要寫原型圖。 原型圖比較直觀，可以作為user story的補充。,9,是否還需要詳細設計？,不需要。 應當將之前寫的需求的詳細設計，或者產品規(guī)格說明書拆解，拆分成一個個的user story. 原因： 無法排序 無法單獨跟蹤 限制了研發(fā)團隊的發(fā)揮,10,如何規(guī)定用戶故事的優(yōu)先級？,根據需求的價值和投入來估算ROI，投入產出比。 有的需求價值很高，但開發(fā)團隊實現起來非常難，也是不行的。,11,scrum殺手：向迭代中添加需求,某天，大老板說，我們要做個什么東東。 產品經理就找項目經理(scrum master)，說，老板說了，要做個什么事情。項目經理就把需求加上去了。 或者產品經理直接找到研發(fā)人員，偷偷摸摸的加上功能。 scrum master應勇敢的說, no, 請等待n周。,12,沒有定義user story完成的標準,也就是最重要的幾個用例，要定義這個需求完成的標準是什么。 比如一個用戶登錄功能，其完成的標準： 輸入正常的用戶名和密碼，應當能夠登錄系統(tǒng)。 輸入錯誤的用戶名和密碼，應當提示登錄錯誤。,13,不參與研發(fā)過程,不參與研發(fā)過程，和開發(fā)團隊有對立情況。 應當及時和開發(fā)團隊進行溝通和交流，隨時發(fā)現問題，隨時解決。 可以考慮完成某一個功能之后，就立馬驗證。,14,項目經理相關,從管理者轉為服務者 關于考核 后續(xù)如何發(fā)展？,15,從管理者轉為服務者,從原來的管理者轉變?yōu)榉照?心態(tài)的調整 從事必躬親改為放權 放手讓團隊去做，允許團隊犯錯,16,如何考核員工？,敏捷開發(fā)團隊更是一個整體。 共進共退，榮譽與共 團隊的集體考核 團隊內部自己進行考核,17,后續(xù)發(fā)展方向,scrum master 做到最成功的地方就是這個團隊不再需要你了。 那么肯定有項目經理犯嘀咕了，那我怎么辦啊。 可能的方向： scum master trainer：培養(yǎng)更多的scrum master 帶其他的團隊 專向架構師 轉向產品 轉向開發(fā)團隊,18,開發(fā)團隊相關,團隊人數要適當 包含多種能力和角色 指派任務改為自由領取任務 每期項目改進一點 自我組織的團隊 鍍金行為 文檔 忘記更新燃盡圖,19,團隊人數要適當,有的團隊人數太多，每天早上開站立會議都要很長時間。 團隊人數太少，無法完成大的功能突破。 5-9人。 scrum master和product owner不是team成員,20,包含多種能力和角色,比如后臺和前臺 比如測試 比如DBA 完成本期迭代所需要的所有技能,21,將指派任務改為自由領取,傳統(tǒng)項目管理中，都是項目經理分解任務，然后指派到人。 現在改為團隊自主分解服務，自由領取任務。 一定要選擇自己感興趣的。:),22,每次迭代改進一點,每次迭代都要改進一些 持續(xù)改進 找到適合團隊最佳的開發(fā)實踐,23,要形成自我組織的團隊,要形成自我組織的團隊。 項目經理的放權。 開發(fā)團隊成員自主意識的崛起。,24,鍍金行為,某位開發(fā)人員很開心的說，我又增加了一個功能。 這個功能可能會酷，但它不在我們的計劃范圍內。:) 功能可能會帶來很多意想不到的問題，甚至后果很嚴重。 有想法可以提技術類的需求，排到迭代中。,25,關于文檔,敏捷并不是不需要文檔 各種各樣的設計文檔，比如數據庫設計文檔，api接口文檔。 安裝部署文檔。,26,忘記更新燃盡圖,燃盡圖開始橫著走啦。 每天應當重新估計自己所負責的任務的預計剩余時間。,27,會議相關,會議太長，一天之內無法完成 站立會議時間太長 站立會議不相關的人員發(fā)言 不召開演示會議 沒有回顧會議 回顧會議沒有產生行動計劃,28,計劃會議太長,產品計劃會議和迭代計劃會議嚴格控制在一天內結束。 scrum master需要主要掌控會議進程。 在召開產品計劃會議之前，scrum master和產品負責人可以事先做一些準備。,29,站立會議變成了問題解決會議,站立會議主要的目的在于溝通，團隊成員之間彼此更新信息，及時發(fā)現風險。 不是問題的解決會議。有關問題會后相關人員加以解決。,30,站立會議不相干的人員發(fā)言,豬和雞的故事