Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Towards scrum of scrums

1,380 views

Published on

Project GATE一開始是由不到十人的小型Scrum團隊開發,成員隨著時間成長,額外的負擔開始慢慢浮現,開會次數越來越多,但似乎很難取得共識,因此開會時間越來越長,資訊的同步變得困難,更擔憂的是團隊成員對產品的認同感慢慢降低。但系統上線在即,上線營運後,各式問題和新feature應該會如雪花般進來,不夠agile的話如何應付?經過一番討論,PO決定讓scrum team在上線前進行細胞分裂,希望回到scrum框架中建議的7加減2人,並重新定位PO,不再是提供solution讓scrum team實作的角色,而是透過讓不同團隊對PO的問題(想法)提供solution的方式,來加強團隊對產品的認同感。理想是好的,但分裂或是改變總是會帶來些痛苦的經歷,整個team又是如何克服過程中的問題呢?分裂是否有成功呢?將在分享中揭曉。

Published in: Software
  • Be the first to comment

Towards scrum of scrums

  1. 1. 贊 助 單 位:協 辦 單 位: 主 辦 單 位:AgileCommunity.tw Towards scrum of scrums Observation & Retrospective 遊戲橘子 行動雲端創新處 軟體架構師 杜秉穎
  2. 2. 關於我 • 臺北科技大學資訊工程所博士 – 法定專長:視覺化程式語言 – 軟體工程 • 國小玩了Doom後就想寫遊戲 • 經歷 – 叡揚資訊 資深軟體分析師 – 遊戲橘子 資深軟體工程師 -> 軟體架構師 AgileCommunity.tw 2
  3. 3. Outline • 背景與觀察到的問題 • 如何分組 • 分組後進行的情況 • Summary AgileCommunity.tw 3
  4. 4. 團隊類型 AgileCommunity.tw 新創團隊 接各式各 樣的外包 幫公司 開發產品 以上皆是 或皆不是 4 ?
  5. 5. 團隊規模 AgileCommunity.tw m < 5 5 < m <10 10 < m < 50 m > 50 5 ?
  6. 6. 開發方法或流程 AgileCommunity.tw Waterfall Doing Agile Being Agile 自以為 Agile 6 ?
  7. 7. 關於Project GATE團隊 • 行動裝置上的應用程式專案 – 跨平台、使用雲服務、提供社群平台服務、導 入應用程式遊戲化(gamification) – 一個預計自集團內部切分出的新創團隊(?) – 專案執行面及技術選擇上有相當的自主權(?) AgileCommunity.tw 2015 11/28 – 11/29 華山1914文化創意產業園區 7
  8. 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. 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. 10. 還是隱隱約約感到什麼不對勁 • 會議很長、沒效率、難達成共識 – 激烈地討論PO提出的設計 – 這設計我本來就不喜歡… – 挑好做的設計 • 對sprint failed好像沒感覺又好像很害怕 AgileCommunity.tw 10
  11. 11. 如何分組 AgileCommunity.tw 11
  12. 12. PO的定位 • 為了讓成員對產品更有認同感與責任感 – PO不再提設計 – PO -> Problem owner • 只定義問題 • 由團隊提供設計 AgileCommunity.tw 12
  13. 13. 分組 • 在Sprint 4.7的自省會議結束後,由PO提出 分組的進行 – 讓團隊討論是以component teams或feature teams的方式分組 – 先隨機分組 – 讓團隊自行決定是否互換 – 討論怎麼進行refinement meeting – Dice game AgileCommunity.tw 13
  14. 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. 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
  16. 16. Sprint的進行 AgileCommunity.tw 16
  17. 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. 18. Refinement meeting Version 1 • PO的期望 – 1 feature team refine 1 story (feature) • Team的決定 – 2 feature teams refine 2 stories together AgileCommunity.tw 18
  19. 19. 分組後進行的情況 AgileCommunity.tw 19
  20. 20. 分組後第一次refinement差點看日出 AgileCommunity.tw 20
  21. 21. Sprint 4.8 自省與觀察 • 分組太過草率,時機不對 – 沒有自主權,設計無法單一feature team做決 定 – 資源不均 • Cross functional team? • Refinement meeting時間根本沒縮短 – 需求不清楚? – 一次開完? – 效率不佳? AgileCommunity.tw 21
  22. 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. 23. Sprint 4.9 自省與觀察 • Retrospective meeting原本大家可以一起討 論出一個結果,但現在討論完還要進scrum of scrums討論,而且還不一定有結果 • 跨team的溝通不良 • 跨組支援 – 該怎麼plan? AgileCommunity.tw 23
  24. 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. 25. Sprint 4.10 自省與觀察 (1/2) • 兩個feature teams對於refinement meeting 流程的認知完全不同 – 兩個feature teams都開了會前會 – 但提出的設計和story切割的細膩度完全不同 AgileCommunity.tw 25
  26. 26. Sprint 4.10 自省與觀察 (2/2) • Story (verification) failed怎麼辦? – PO的說法 • Story描述上有但沒實作 • 部分細節(動畫/UI細節)在iOS和Android不一致 • Story描述上沒有,但有(很明顯的)Bug – Team的說法 • Planning時要plan得更細 • 估時可能要保守一點 • 盡早和PO驗證 AgileCommunity.tw 26
  27. 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. 28. Sprint 5.1 自省的回饋 • 開發中的設計調整(UI/UX)該如何同步? – feature teams <-> PO <-> OP • 人力資源嚴重不均 – 原本承諾要支援B,但A組自己都做不完了,結 果AB兩組都沒做完,引起誤會 – 說好的Android dojo呢? AgileCommunity.tw 28
  29. 29. Sprint 5.2 自省與觀察 • Android dojo好棒棒 – 一個user story在dojo中完成 • Refinement meeting還是很長很累Orz – PO的角色到底是什麼?對設計打槍? • 中斷 – 在sprint中加新stories – 新stories的時數要plan嗎? AgileCommunity.tw 29
  30. 30. Sprint 5.3 自省與觀察 • 漫長的建置時間 – 大概需要30分鐘建置出可布署的程式 • 不含程式碼,要建置超過16k個資源檔 • iOS/Android/Server – 分類建置布署 • Polish的重點到底是體驗還是驗證stories – QE希望大家幫忙驗證stories AgileCommunity.tw 30
  31. 31. Sprint 5.4 自省與觀察 • 為了產品好,還是要polish – 手動測試的時間點? – iOS開發比較快,但不代表iOS一定是對的,需 求還是來自story本身的敘述 • 建議改採用branch-based的方式開發 – 企畫用的資源原始檔(Excel)怎麼辦? – Build pipeline的調整 • 不屬於feature team的stories不應放在 feature team的scrum board中 AgileCommunity.tw 31
  32. 32. Sprint 5.5 自省與觀察 • Planning meeting的時間是否能再縮短? – Task一定會切,但若時間不夠,就不估時間 – Scrum board只秀story burn down • 這2個sprints太趕,未能充足的Refinement, Story有許多未釐清的細節,如何認定Story 完成(ready to plan)需要一個規則 AgileCommunity.tw 32
  33. 33. Sprint 5.6 自省與觀察 • 自發地pair programming學習iOS • Android很容易crash – 該refactor就做 – 增加容錯機制 • Story應再切小一點 • 單一Story,story point原則上不超過5點,每個sprint大 約能完成20點 • 跨組支援到底該怎麼plan? AgileCommunity.tw 33
  34. 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. 35. 核心的問題 (2/3) AgileCommunity.tw Individuals and interactions over processes and tools? • Synchronization ≠ Communication 分組好像 在搞分裂 資訊決策 難同步 用流程讓 資訊同步 Follow 流程 非規範的 溝通無增 35
  36. 36. 核心的問題 (3/3) • Boss = Customer (?) AgileCommunity.tw 需求時常 變更 PO無法 掌握需求 不易凝聚 共識 頻繁修改 程式 產品延期 上架 打擊團隊 士氣 Customer collaboration over contract negotiation 36 不必提高「士氣」,沒有幹勁 的人稱不上專業 LINE 前任 CEO 森川亮
  37. 37. SUMMARY AgileCommunity.tw 37
  38. 38. 分組能做什麼 • 減少大鍋飯的心態 – 暴露出問題 – 自省的議題較過去辛辣 (敢說、願意說) • 讓團隊意識到cross functional的重要性 • 有競爭意識 – 在意自己團隊的設計是否被採用 – 在意自己團隊的burndown chart AgileCommunity.tw 38
  39. 39. 分組不能做什麼 • 建立對需求的共識 • 加速會議的進行 • 自發地讓自己變cross functional • 讓團隊更Agile (?) AgileCommunity.tw 39
  40. 40. 未來 • 雖然分組沒能真正解決當初的問題,但也 不用悲觀,在scrum的框架中,團隊還是能 以自己的步調調整跟改進 • 整個團隊都須對Agile有更進一步的了解 – PO 頻繁地協調客戶(Boss)與團隊有一致的目 標 – Scrum team 用高品質的產品贏得信任 – Scrum master 讓團隊能更agile AgileCommunity.tw 40

×