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

1. 贊 助 單 位：協 辦 單 位：
主 辦 單 位：AgileCommunity.tw
Towards scrum of scrums
Observation & Retrospective
遊戲橘子 行動雲端創新處
軟體架構師 杜秉穎

2. 關於我
• 臺北科技大學資訊工程所博士
– 法定專長：視覺化程式語言
– 軟體工程
• 國小玩了Doom後就想寫遊戲
• 經歷
– 叡揚資訊 資深軟體分析師
– 遊戲橘子 資深軟體工程師 -> 軟體架構師
AgileCommunity.tw
2

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

4. 團隊類型
AgileCommunity.tw
新創團隊
接各式各
樣的外包
幫公司
開發產品
以上皆是
或皆不是
4
?

5. 團隊規模
AgileCommunity.tw
m < 5 5 < m <10
10 < m < 50 m > 50
5
?

6. 開發方法或流程
AgileCommunity.tw
Waterfall
Doing
Agile
Being
Agile
自以為
Agile
6
?

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

11. 如何分組
AgileCommunity.tw
11

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

16. Sprint的進行
AgileCommunity.tw
16

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

19. 分組後進行的情況
AgileCommunity.tw
19

20. 分組後第一次refinement差點看日出
AgileCommunity.tw
20

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 森川亮

37. SUMMARY
AgileCommunity.tw
37

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