Mopcon 2021 Scrum 是新的死亡行軍嗎?

1. Scrum 是新的死亡行軍嗎?
DavidKo
1

2. 我是誰?
Odd-e Agile Coach
敏捷三叔公 David Ko
繁中版譯者 部落客
台灣敏捷社群組織者 敏捷/DevOps研討會
組織者 2

3. • 願景
 致力於用更好的方式做產品
 也幫助客戶用更好的方式做產品
• 服務
 開發與交付
 諮詢與輔導
 培訓與認證
3

4. 大綱
何謂死亡行軍
大家如何處理死亡行軍
真 敏捷怎麼看待此事
建議的處理方法
4

5. 緣起: 這段對話有沒有很熟悉
我們這週只拿了 13 點 story
你們怎麼拿這麼少? 這樣不行啦
上次你們 bug 這麼多,
我都沒說什麼, 幫一下忙
嗯, 好吧, 那再多拿一些好了
記得 bug 要排進去修復喔
下午部門會議要來喔
部門改善計畫記得做
Scrum
Master
Scrum
Master
Scrum
Master
部門
主管
團隊
團隊
5

6. 事情做不完, 迭代沒有停的時候
Scrum 讓你好忙好忙, 忙到心裡發毛
6

7. 從專案開始，
即一路掙扎, 往失敗前進
我們把這種狀況稱之為死亡行軍
7

8. 你們團隊中了幾個?
Bug 常常增加
迭代目標常
沒做到
士氣下降,
成員常流失
互相指責
變嚴重
忽略好的做法因
為需要時間
很難找到樂於助
人和協作的人
定期加班, 且越
來越長
8

9. 大綱
何謂死亡行軍
大家如何處理死亡行軍
真 敏捷怎麼看待此事
建議的處理方法
9

10. 聽過 Crunch Mode 嗎?
Tiger Team 聽過嗎?
War Room 總有吧?
天下武學 殊途同歸
10

11. 趕死線模式 - Crunch Mode
• 是指一段時間, 這段時間是用來連續長時間加班
Crunch mode
• 免費早餐, 晚餐, 宵夜
• 有人會幫你跑腿做雜事
• 有額外的員工加入幫忙
• 提供住宿
有些公司會提供福利
• 但是時間一長後, 生產力增長其實不明顯
• 甚至會降低工作效率
在短時間內, 這種做法可以增加生產力
11

12. 韓國遊戲業稱超時工作為趕死線模式
每週工作 51.25 小時
12

13. 為什麼大家喜歡加班
不用花腦筋
想解決方法
很容易
可以套用
一開始
生產力會增加
13

14. 加班會帶來的問題
待處理的工作量
品質
加班
技術債
-
-
+
-
-
+
事情多就
犧牲品質
事情多長加班
加班越多
就隨便做
14

15. 大綱
何謂死亡行軍
大家如何處理死亡行軍
真 敏捷怎麼看待此事
建議的處理方法
15

16. Cargo Cult
16

17. Kent Beck 在 Extreme
Programming Explained
一書中提到：
”一週工作不要超過
40 小時”
並且
“從不連續兩週加班”
17

18. 加班, 其實是專案面臨嚴重問題的徵兆
會連續加班兩週
代表專案有了即使超時工作
也無濟於事的問題
18

19. Ron Jeffries
認為這不是”每週 40
小時”的問題
而是期待 穩定的步調
(Sustainable Pace)
Ron Jeffries
19

20. 敏捷宣言中的原則
Agile processes promote sustainable
development. The sponsors, developers,
and users should be able to maintain a
constant pace indefinitely
敏捷程序提倡可持續的開發。
贊助者、開發者及使用者應當能不斷地維持
穩定的步調。
20

21. Kanban 中如何落實可持續步調
清單 下一步 進行中 檢視 做完
3 2
限制同時最多進行的事情數目
完成舊工作, 再拿新工作
A
B
C
F E
D
G
J I
H
K
21

22. Scrum 中如何落實持續步調
Product
Backlog
Sprint
Backlog
Product Owner
Sprint
1- 4 周
Team
Scrum
Master
Sprint
Planning
Sprint
Review
Sprint
Retrospective
Daily
Scrum
Sprint
Refinement
Potentially
Shippable product
迭代規劃會議時, 團隊決定做多少
22

23. 大綱
何謂死亡行軍
大家如何處理死亡行軍
真 敏捷怎麼看待此事
建議的處理方法
23

24. 讓我們從不從角度來處理
PO
SM
團隊
24

25. PO 可以怎麼做
說不
假設驅動
開發
排好優先
順序
實例化
需求
25

26. 說不
通常加功能不會賣更多
只會讓時程和系統大亂
26

27. 假設驅動開發
https://www.alexandercowan.com/hypothesis-driven-development-practitioners-guide/
想法 設計 開發 部署
測試
客戶
假設
問題
假設
市場
假設
我們相信
在查詢網頁中, 增加旅館影片大小
將會造成 (商業影響)
增加客戶訂房的機率
當以下事情發生就代表成功 (如何衡量)
當空房出現後 48 小時內, 預訂率比以前
增加 5%
27

28. 排好優先順序
目
標
角色
1
角色
2
影響
1
影響
3
影響
2
交付
1
交付
2
交付
3
影響地圖
活動 1
活動 2
活動 3
活動 5
活動 4
史詩 1
史詩 7
史詩 4
史詩 3
史詩 2
史詩 6
史詩 5
故事地圖 階段 1 階段 2
故事
1-1
故事
3-2
故事
2-1
故事
1-2
故事
3-1
故事
2-2
故事
4-1
Product
Backlog
高
中
低
洋蔥式
漸進排序
28

29. 實例化需求 – 減少大家對需求的落差 – 做對的產品
故事清單
越
上
面
要
越
清
楚
用戶故事：作為用戶，
我希望能夠註冊該服
務，以便我可以開始
在線購物
用戶必須填寫所有
必填欄位, 才能提交
註冊。
來自同一個 IP 的提
交, 只能在 30 分鐘
內提交 3 次
用戶必須填寫
David,
dd@gmail,com,
0922333444
才能提交註冊。
用戶 在
192.168.2.3 (12:43,
12:50, 12:55, 12:58)
時提交, 系統不會允
許
故事
規則
範例
範例
故事
測試
說明
變成
驗證
29

30. 讓我們從不從角度來處理
PO
SM
團隊
30

31. 團隊體溫計 (1) - Spotify Team Health Check
支持 團隊合作
受害者 或 參
與者
任務
程式碼健康
狀況
交付價值 學習 交付速度
容易發佈 有趣
解釋這 10
個領域
綠：有趣, 很棒, 很行
黃：普通, 還行
紅：無聊, 很差, 不行
針對每個領域
大家投票
解讀投票結果
31

32. 團隊體溫計 (2)
● Happiness Index
○ 問題
■ 你在公司快樂嗎
■ 你的工作快樂嗎
■ 你對客戶滿意嗎
○ 答案級別: 5 級
○ 特色
■ 快速
■ 長期追蹤趨勢
32

33. 團隊體溫計 (3)
● 講幹話講瘋話的頻率
● 臉上的笑容
● 比正常時期晚到的次數
33

34. 建立鬆弛機制
● 規劃休息時間
○ 番茄鐘每小時休息 10 分鐘
● 團隊建設 (Team Building) + 下午茶
34

35. 讓我們從不從角度來處理
PO
SM
團隊
35

36. 專注
• 重要的事先做
• 設定和落實 Sprint
goal, daily goal
• 不要打開任何會分心
的軟體
千里之行, 始於足下
36

37. 找出瓶頸和浪費
• 紀錄工作時間
• 大多問題是
• 會議太多
• 寫程式太少
• 問題知道太晚
30
15
25
15
10
5
時間比例
Coding Scrum 會議 公司會議
其他會議 維護 雜事
平均開發時間 > 4 小時 (贏 60%)
中階主管開會時間約佔 35%
中階主管開會次數每天約 12 次
37

38. 為工作設時間盒
• 番茄鐘工作法
• 工作/開會項目設定
時間盒
• 專屬的開發時間
寫程式 寫程式 開會
38

39. 問題知道太晚
• 搭檔編程
• 撰寫自動化測試
• 持續整合/部署
搭檔編程
• 檢視代碼
• 交流想法
撰寫自動化測試
• 及早檢查
• 頻繁檢查
持續整合/部署
• 整合確認
• 環境確認
39

40. 總結
敏捷提倡可持續的開發
如何改善死亡行軍
PO
SM
團隊
• 說不
• 假設驅動開發
• 排好優先順序
• 實例化需求
• 收集團隊溫度
• 鬆弛機制
• 專注
• 找出瓶頸和浪費
• 為工作設時間盒
• 問題知道太晚
40

41. Q & A
41