towards scrum of scrums

贊 助 單 位：協 辦 單 位：主 辦 單 位： AgileCommunity.tw

Towards scrum of scrumsObservation & Retrospective

遊戲橘子 行動雲端創新處軟體架構師 杜秉穎

AgileCommunity.tw

2

關於我• 臺北科技大學資訊工程所博士

– 法定專長：視覺化程式語言– 軟體工程

• 國小玩了 Doom 後就想寫遊戲• 經歷

– 叡揚資訊 資深軟體分析師– 遊戲橘子 資深軟體工程師 -> 軟體架構師

AgileCommunity.tw

3

Outline• 背景與觀察到的問題• 如何分組• 分組後進行的情況• Summary

AgileCommunity.tw

4

團隊類型

新創團隊 接各式各樣的外包幫公司開發產品 以上皆是或皆不是

?

AgileCommunity.tw

5

團隊規模

m < 5 5 < m <10

10 < m < 50 m > 50?

AgileCommunity.tw

6

開發方法或流程

Waterfall DoingAgile

BeingAgile

自以為Agile

?

AgileCommunity.tw

7

關於 Project GATE 團隊• 行動裝置上的應用程式專案

– 跨平台、使用雲服務、提供社群平台服務、導入應用程式遊戲化 (gamification)– 一個預計自集團內部切分出的新創團隊 (?)– 專案執行面及技術選擇上有相當的自主權 (?)

2015 11/28 – 11/29華山 1914 文化創意產業園區

AgileCommunity.tw

8

持續成長的團隊成員

May, 13

July Oct Dec Jan, 14

Apr May Jun Sep Feb, 15

Apr June Agu Oct5 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

Others Developer

AgileCommunity.tw

9

Project GATE

團隊好像很 Agile 啊 ~

Unit testing with high coverageAutomatic acceptance testingContinuous integrationAutomatic deploymentScrumContinuous improvementEating your own dog food

AgileCommunity.tw

10

還是隱隱約約感到什麼不對勁• 會議很長、沒效率、難達成共識

– 激烈地討論 PO 提出的設計– 這設計我本來就不喜歡…– 挑好做的設計

• 對 sprint failed 好像沒感覺又好像很害怕

AgileCommunity.tw

11

如何分組

AgileCommunity.tw

12

PO 的定位• 為了讓成員對產品更有認同感與責任感

– PO 不再提設計– PO -> Problem owner

• 只定義問題• 由團隊提供設計

AgileCommunity.tw

13

分組• 在 Sprint 4.7 的自省會議結束後，由 PO提出分組的進行

– 讓團隊討論是以 component teams 或feature teams 的方式分組

– 先隨機分組– 讓團隊自行決定是否互換– 討論怎麼進行 refinement meeting– Dice game

AgileCommunity.tw

14

三個 scrum teams• 1 Product backlog• 3 scrum boards OP * 5

Art * 2Server * 2Planner * 1

HW * 6Art *1iOS * 1

Server * 1QE * 1

Android * 2

BXM * 6Art * 1iOS *2

Server * 1QE * 1

Android * 1

AgileCommunity.tw

15

Sprint 週期的改變Mon Tue Wed Thu Fri

Planning RefinementPlanning Refinement

Tuning ReviewPolish Tuning Retrospecti

ve

Week 1

Week 2

Mon Tue Wed Thu FriPlanning RefinementPlanning Refinement

Polish

Week 1

Week 2

Tuning ReviewTuning Retrospecti

veWeek 3

AgileCommunity.tw

16

Sprint 的進行

AgileCommunity.tw

17

自省會議的方式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 Masterissues

and suggestio

ns

announcement

AgileCommunity.tw

18

Refinement meeting Version 1

• PO 的期望– 1 feature team refine 1 story (feature)

• Team 的決定– 2 feature teams refine 2 stories

together

AgileCommunity.tw

19

分組後進行的情況

AgileCommunity.tw

20

分組後第一次 refinement 差點看日出

AgileCommunity.tw

21

Sprint 4.8 自省與觀察• 分組太過草率，時機不對

– 沒有自主權，設計無法單一 feature team 做決定– 資源不均

• Cross functional team?• Refinement meeting 時間根本沒縮短

– 需求不清楚 ?– 一次開完 ?– 效率不佳 ?

AgileCommunity.tw

22

跨組支援OP * 5

Art * 2Server * 2Planner * 1

HW * 6Art *1iOS * 1

Server * 1QE * 1

Android * 2

BXM * 6Art * 1iOS *2

Server * 1QE * 1

Android * 1

AgileCommunity.tw

23

Sprint 4.9 自省與觀察• Retrospective meeting 原本大家可以一起討論出一個結果，但現在討論完還要進

scrum of scrums 討論，而且還不一定有結果• 跨 team 的溝通不良• 跨組支援

– 該怎麼 plan ？

AgileCommunity.tw

24

Refinement meeting Version 2

PO 說明待refine 的stories

Feature team 領取

story

2 個 feature teams 一起對

stories 進行初步的切割(PO 要在場 )

2 個 feature teams 各自對領取的 story 完成細部設計

(PO 要在場 )

PO 確認feature

team 的設計符合需求2 個 feature

teams 各自發表細部設計(PO/OP 要在場 )

設計細節公告

AgileCommunity.tw

25

Sprint 4.10 自省與觀察 (1/2)

• 兩個 feature teams 對於 refinement meeting 流程的認知完全不同– 兩個 feature teams 都開了會前會– 但提出的設計和 story 切割的細膩度完全不同

AgileCommunity.tw

26

Sprint 4.10 自省與觀察 (2/2)

• Story (verification) failed 怎麼辦？– PO 的說法

• Story描述上有但沒實作• 部分細節 ( 動畫 /UI細節 ) 在 iOS 和 Android 不一致• Story描述上沒有，但有 ( 很明顯的 )Bug

– Team 的說法• Planning 時要 plan得更細• 估時可能要保守一點• 盡早和 PO驗證

AgileCommunity.tw

27

Refinement meeting Version 3

PO 說明待refine 的stories

PO 選擇初步的設計

feature teams 說明初步設計(PO 要在場 )

feature teams各自完成細部設計(PO 要在場 )

PO 確認feature

team 的設計符合需求feature teams各自發表細部設計(PO/OP 要在場 )

設計細節公告

會前會

AgileCommunity.tw

28

Sprint 5.1 自省的回饋• 開發中的設計調整 (UI/UX) 該如何同步？

– feature teams <-> PO <-> OP• 人力資源嚴重不均

– 原本承諾要支援 B ，但 A 組自己都做不完了，結果 AB 兩組都沒做完，引起誤會–說好的 Android dojo呢？

AgileCommunity.tw

29

Sprint 5.2 自省與觀察• Android dojo 好棒棒

– 一個 user story 在 dojo中完成• Refinement meeting 還是很長很累 Orz

– PO 的角色到底是什麼？對設計打槍？• 中斷

– 在 sprint中加新 stories– 新 stories 的時數要 plan嗎？

AgileCommunity.tw

30

Sprint 5.3 自省與觀察• 漫長的建置時間

– 大概需要 30 分鐘建置出可布署的程式• 不含程式碼，要建置超過 16k 個資源檔• iOS/Android/Server

– 分類建置布署• Polish 的重點到底是體驗還是驗證 stories

– QE希望大家幫忙驗證 stories

AgileCommunity.tw

31

Sprint 5.4 自省與觀察• 為了產品好，還是要 polish

–手動測試的時間點？– iOS 開發比較快，但不代表 iOS 一定是對的，需求還是來自 story 本身的敘述

• 建議改採用 branch-based 的方式開發–企畫用的資源原始檔 (Excel) 怎麼辦？– Build pipeline 的調整

• 不屬於 feature team 的 stories 不應放在feature team 的 scrum board中

AgileCommunity.tw

32

Sprint 5.5 自省與觀察• Planning meeting 的時間是否能再縮短？

– Task 一定會切，但若時間不夠，就不估時間– Scrum board 只秀 story burn down

• 這 2 個 sprints 太趕，未能充足的Refinement ， Story 有許多未釐清的細節，如何認定 Story 完成 (ready to plan)需要一個規則

AgileCommunity.tw

33

Sprint 5.6 自省與觀察• 自發地 pair programming 學習 iOS• Android 很容易 crash

– 該 refactor 就做–增加容錯機制

• Story 應再切小一點• 單一 Story ， story point 原則上不超過 5點，每個

sprint 大約能完成 20點• 跨組支援到底該怎麼 plan ？

AgileCommunity.tw

34

核心的問題 (1/3)

• Doing agile ≠ Being agile怕sprint failed 抗拒變更

估時保守記錄所有細節會議討論到很細

整體會議時間拉長

開發時間縮短 Responding to change over

following a plan?

Working software over comprehensive documentation?

AgileCommunity.tw

35

核心的問題 (2/3)

Individuals and interactions over processes and tools?

• Synchronization ≠ Communication分組好像在搞分裂

資訊決策難同步用流程讓資訊同步Follow流程

非規範的溝通無增

AgileCommunity.tw

36

核心的問題 (3/3)

• Boss = Customer (?)需求時常變更

PO無法掌握需求不易凝聚共識頻繁修改程式

產品延期上架

打擊團隊士氣

Customer collaboration over contract negotiation不必提高「士氣」，沒有幹勁的人稱不上專業

LINE 前任 CEO 森川亮

AgileCommunity.tw

37

SUMMARY

AgileCommunity.tw

38

分組能做什麼• 減少大鍋飯的心態

–暴露出問題– 自省的議題較過去辛辣 (敢說、願意說 )

• 讓團隊意識到 cross functional 的重要性• 有競爭意識

– 在意自己團隊的設計是否被採用– 在意自己團隊的 burndown chart

AgileCommunity.tw

39

分組不能做什麼• 建立對需求的共識• 加速會議的進行• 自發地讓自己變 cross functional• 讓團隊更 Agile (?)

AgileCommunity.tw

40

未來• 雖然分組沒能真正解決當初的問題，但也不用悲觀，在 scrum 的框架中，團隊還是能以自己的步調調整跟改進• 整個團隊都須對 Agile 有更進一步的了解

– PO 頻繁地協調客戶 (Boss) 與團隊有一致的目標– Scrum team 用高品質的產品贏得信任– Scrum master 讓團隊能更 agile