Towards scrum of scrums
?Download as PPTX, PDF?
18 likes?1,881 views
Project GATE一開始是由不到十人的小型Scrum團隊開發，成員隨著時間成長，額外的負擔開始慢慢浮現，開會次數越來越多，但似乎很難取得共識，因此開會時間越來越長，資訊的同步變得困難，更擔憂的是團隊成員對產品的認同感慢慢降低。但系統上線在即，上線營運後，各式問題和新feature應該會如雪花般進來，不夠agile的話如何應付？經過一番討論，PO決定讓scrum team在上線前進行細胞分裂，希望回到scrum框架中建議的7加減2人，並重新定位PO，不再是提供solution讓scrum team實作的角色，而是透過讓不同團隊對PO的問題(想法)提供solution的方式，來加強團隊對產品的認同感。理想是好的，但分裂或是改變總是會帶來些痛苦的經歷，整個team又是如何克服過程中的問題呢？分裂是否有成功呢？將在分享中揭曉。
Towards scrum of scrums
- 1. 贊 助 單 位：協 辦 單 位： 主 辦 單 位：AgileCommunity.tw Towards scrum of scrums Observation & Retrospective 遊戲橘子 行動雲端創新處 軟體架構師 杜秉穎
- 2. 關於我 ? 臺北科技大學資訊工程所博士 – 法定專長：視覺化程式語言 – 軟體工程 ? 國小玩了Doom後就想寫遊戲 ? 經歷 – 叡揚資訊 資深軟體分析師 – 遊戲橘子 資深軟體工程師 -> 軟體架構師 AgileCommunity.tw 2
- 3. Outline ? 背景與觀察到的問題 ? 如何分組 ? 分組後進行的情況 ? Summary AgileCommunity.tw 3
- 5. 團隊規模 AgileCommunity.tw m < 5 5 < m <10 10 < m < 50 m > 50 5 ?
- 7. 關於Project GATE團隊 ? 行動裝置上的應用程式專案 – 跨平台、使用雲服務、提供社群平台服務、導 入應用程式遊戲化(gamification) – 一個預計自集團內部切分出的新創團隊(?) – 專案執行面及技術選擇上有相當的自主權(?) AgileCommunity.tw 2015 11/28 – 11/29 華山1914文化創意產業園區 7
- 8. 持續成長的團隊成員 AgileCommunity.tw 5 5 5 5 5 5 5 5 5 5 4 5 5 5 8 11 12 10 12 13 14 16 19 18 17 15 16 17 May, 13 July Oct Dec Jan, 14 Apr May Jun Sep Feb, 15 Apr June Agu Oct Others Developer 8
- 9. Project GATE 團隊好像很Agile啊~ AgileCommunity.tw Unit testing with high coverage Automatic acceptance testing Continuous integration Automatic deployment Scrum Continuous improvement Eating your own dog food 9 ? ? ? ? ? ? ?
- 10. 還是隱隱約約感到什麼不對勁 ? 會議很長、沒效率、難達成共識 – 激烈地討論PO提出的設計 – 這設計我本來就不喜歡… – 挑好做的設計 ? 對sprint failed好像沒感覺又好像很害怕 AgileCommunity.tw 10
- 12. PO的定位 ? 為了讓成員對產品更有認同感與責任感 – PO不再提設計 – PO -> Problem owner ? 只定義問題 ? 由團隊提供設計 AgileCommunity.tw 12
- 13. 分組 ? 在Sprint 4.7的自省會議結束後，由PO提出 分組的進行 – 讓團隊討論是以component teams或feature teams的方式分組 – 先隨機分組 – 讓團隊自行決定是否互換 – 討論怎麼進行refinement meeting – Dice game AgileCommunity.tw 13
- 14. 三個scrum teams ? 1 Product backlog ? 3 scrum boards AgileCommunity.tw OP * 5 Art * 2 Server * 2 Planner * 1 HW * 6 Art *1 iOS * 1 Server * 1 QE * 1 Android * 2 BXM * 6 Art * 1 iOS *2 Server * 1 QE * 1 Android * 1 14
- 15. Sprint週期的改變 AgileCommunity.tw Mon Tue Wed Thu Fri Planning Refinement Planning Refinement Tuning Review Polish Tuning Retrospectiv e Week 1 Week 2 Mon Tue Wed Thu Fri Planning Refinement Planning Refinement Polish Week 1 Week 2 Tuning Review Tuning Retrospectiv e Week 3 15
- 17. 自省會議的方式 AgileCommunity.tw OP team retrospective meeting feature team 1 retrospective meeting feature team 1 retrospective meeting Product Owner Scrum Master Product Owner Product OwnerScrum Master Scrum of scrums meeting Product OwnerProduct OwnerProduct Owner Scrum MasterScrum Master issues and suggestion s announcement 17
- 18. Refinement meeting Version 1 ? PO的期望 – 1 feature team refine 1 story (feature) ? Team的決定 – 2 feature teams refine 2 stories together AgileCommunity.tw 18
- 21. Sprint 4.8 自省與觀察 ? 分組太過草率，時機不對 – 沒有自主權，設計無法單一feature team做決 定 – 資源不均 ? Cross functional team? ? Refinement meeting時間根本沒縮短 – 需求不清楚? – 一次開完? – 效率不佳? AgileCommunity.tw 21
- 22. 跨組支援 AgileCommunity.tw 22 OP * 5 Art * 2 Server * 2 Planner * 1 HW * 6 Art *1 iOS * 1 Server * 1 QE * 1 Android * 2 BXM * 6 Art * 1 iOS *2 Server * 1 QE * 1 Android * 1
- 23. Sprint 4.9 自省與觀察 ? Retrospective meeting原本大家可以一起討 論出一個結果，但現在討論完還要進scrum of scrums討論，而且還不一定有結果 ? 跨team的溝通不良 ? 跨組支援 – 該怎麼plan？ AgileCommunity.tw 23
- 24. Refinement meeting Version 2 AgileCommunity.tw PO說明待 refine的 stories Feature team 領取story 2個feature teams 一起對stories進行 初步的切割 (PO要在場) 2個feature teams 各自對領取的story 完成細部設計 (PO要在場) PO確認feature team的設計符 合需求 2個feature teams 各自發表細部設計 (PO/OP要在場) 設計細節公告 24
- 25. Sprint 4.10 自省與觀察 (1/2) ? 兩個feature teams對於refinement meeting 流程的認知完全不同 – 兩個feature teams都開了會前會 – 但提出的設計和story切割的細膩度完全不同 AgileCommunity.tw 25
- 26. Sprint 4.10 自省與觀察 (2/2) ? Story (verification) failed怎麼辦？ – PO的說法 ? Story描述上有但沒實作 ? 部分細節(動畫/UI細節)在iOS和Android不一致 ? Story描述上沒有，但有(很明顯的)Bug – Team的說法 ? Planning時要plan得更細 ? 估時可能要保守一點 ? 盡早和PO驗證 AgileCommunity.tw 26
- 27. Refinement meeting Version 3 AgileCommunity.tw PO說明待 refine的 stories PO選擇初 步的設計 feature teams 說明初步設計 (PO要在場) feature teams各 自完成細部設計 (PO要在場) PO確認feature team的設計符 合需求 feature teams各 自發表細部設計 (PO/OP要在場) 設計細節公告 會前會 27
- 28. Sprint 5.1 自省的回饋 ? 開發中的設計調整(UI/UX)該如何同步？ – feature teams <-> PO <-> OP ? 人力資源嚴重不均 – 原本承諾要支援B，但A組自己都做不完了，結 果AB兩組都沒做完，引起誤會 – 說好的Android dojo呢？ AgileCommunity.tw 28
- 29. Sprint 5.2 自省與觀察 ? Android dojo好棒棒 – 一個user story在dojo中完成 ? Refinement meeting還是很長很累Orz – PO的角色到底是什麼？對設計打槍？ ? 中斷 – 在sprint中加新stories – 新stories的時數要plan嗎？ AgileCommunity.tw 29
- 30. Sprint 5.3 自省與觀察 ? 漫長的建置時間 – 大概需要30分鐘建置出可布署的程式 ? 不含程式碼，要建置超過16k個資源檔 ? iOS/Android/Server – 分類建置布署 ? Polish的重點到底是體驗還是驗證stories – QE希望大家幫忙驗證stories AgileCommunity.tw 30
- 31. Sprint 5.4 自省與觀察 ? 為了產品好，還是要polish – 手動測試的時間點？ – iOS開發比較快，但不代表iOS一定是對的，需 求還是來自story本身的敘述 ? 建議改採用branch-based的方式開發 – 企畫用的資源原始檔(Excel)怎麼辦？ – Build pipeline的調整 ? 不屬於feature team的stories不應放在 feature team的scrum board中 AgileCommunity.tw 31
- 32. Sprint 5.5 自省與觀察 ? Planning meeting的時間是否能再縮短？ – Task一定會切，但若時間不夠，就不估時間 – Scrum board只秀story burn down ? 這2個sprints太趕，未能充足的Refinement， Story有許多未釐清的細節，如何認定Story 完成(ready to plan)需要一個規則 AgileCommunity.tw 32
- 33. Sprint 5.6 自省與觀察 ? 自發地pair programming學習iOS ? Android很容易crash – 該refactor就做 – 增加容錯機制 ? Story應再切小一點 ? 單一Story，story point原則上不超過5點，每個sprint大 約能完成20點 ? 跨組支援到底該怎麼plan？ AgileCommunity.tw 33
- 34. 核心的問題 (1/3) ? Doing agile ≠ Being agile AgileCommunity.tw 怕sprint failed 抗拒變更 估時保守 記錄所有 細節 會議討論 到很細 整體會議 時間拉長 開發時間 縮短 Responding to change over following a plan? Working software over comprehensive documentation? 34
- 35. 核心的問題 (2/3) AgileCommunity.tw Individuals and interactions over processes and tools? ? Synchronization ≠ Communication 分組好像 在搞分裂 資訊決策 難同步 用流程讓 資訊同步 Follow 流程 非規範的 溝通無增 35
- 36. 核心的問題 (3/3) ? Boss = Customer (?) AgileCommunity.tw 需求時常 變更 PO無法 掌握需求 不易凝聚 共識 頻繁修改 程式 產品延期 上架 打擊團隊 士氣 Customer collaboration over contract negotiation 36 不必提高「士氣」，沒有幹勁 的人稱不上專業 LINE 前任 CEO 森川亮
- 38. 分組能做什麼 ? 減少大鍋飯的心態 – 暴露出問題 – 自省的議題較過去辛辣 (敢說、願意說) ? 讓團隊意識到cross functional的重要性 ? 有競爭意識 – 在意自己團隊的設計是否被採用 – 在意自己團隊的burndown chart AgileCommunity.tw 38
- 39. 分組不能做什麼 ? 建立對需求的共識 ? 加速會議的進行 ? 自發地讓自己變cross functional ? 讓團隊更Agile (?) AgileCommunity.tw 39
- 40. 未來 ? 雖然分組沒能真正解決當初的問題，但也 不用悲觀，在scrum的框架中，團隊還是能 以自己的步調調整跟改進 ? 整個團隊都須對Agile有更進一步的了解 – PO 頻繁地協調客戶(Boss)與團隊有一致的目 標 – Scrum team 用高品質的產品贏得信任 – Scrum master 讓團隊能更agile AgileCommunity.tw 40