This slide explains scrum and agile essential and also how to use kanban to expose your team's problem.

1. 1

2. 2

3. • 產品負責人
• 為產品的成敗負責
• 收集、分析產品資訊
PO
• Scrum傳道者
• 引導團隊敏捷化
Scrum Master Team
• 團隊
• 跨職能
• 功能團隊
3

4. Planning
Refine
4

5. How? When?
Role?
Purpose?
5

6. Review Retrospective
What’s different?
6

7. 勇氣
專注
承諾
尊重
公開
7

8. Scrum的本質就是敏捷精神的一個Framework！
8

9. 9

10. 10

11. 11

12. 12

13. 13

14. 14

15. 15

16. Command and Control Self-Organizing
16

17. 17

18. 18
Facilitator

19. 19
Scrum的Input和Output是什麼？

20. 20
Potentially Shippable Product
Sprint backlog

21. 21
探索(Discover)
了解什麼才是對的
產品要去建構
交付(Deliver)
如何正確地去建構產品

22. 22
在Scrum中,怎麼整理產品需求?

23. 23

24. 2424

25. 25
Kano模型
團隊反饋 利害關係人意見
市場變化
如何排序Product Backlog Item?

26. 26
對專案執行做規劃
讓團隊與你一起規劃

27. 27
對專案執行做規劃
長期的產品
願景指南
策略邊界和
目標
針對高階功
能設定粗略
的時程 決定有那些
功能要在這
次發佈
定義完成準
則
規劃如何在
一個衝刺內
交付那些功
能的項目
依照衝刺計
劃進行每日
工作
Product Vision
Product Roadmap
Release Plan
Sprint Plan
Daily Commitment

28. 28
衝刺2衝刺1 衝刺3 衝刺N
開始日 結束日
固定時間長度
時間盒(Time-Box)
讓團隊更加地聚焦在目標上

29. 29
在什麼時候處理和討論Backlog?

30. 30

31. 31
Planning會議有下列活動:
1.展示重要的PBI
2.澄清重要的PBI相關的問題
3.團隊協作梳理新的PBI
4.團隊按照順序嘗試選擇PBI

32. 32
運用工具和方法論
要不斷更新和整理產品需求
該怎麼管理Product Backlog?

33. 33
人物誌(Persona)
使用者旅程地圖(user journey map)
心理地圖(Empathy map)

34. 34
發佈計劃

35. 35
構思想法
了解客戶
述說故事
探索細節
• 產品初步想法
• 影響地圖
• 客戶訪談
• 人物誌/用戶旅程地圖
• 使用者故事地圖
• 最小發行部份
• 協同設計工作坊
• 實例化需求

36. 36
商業目標
角色
角色
功能
功能
功能
功能
功能假設影響假設
確實存在的角色<->影響
關係
功能對影響
解決程度

37. 37
商業目標
角色
角色
功能
功能
功能
功能

38. 38
和團隊成員談你的構想
和團隊成員一起討論假設
Impact map怎麼用?

39. 39
Activity Time
User Activities
User tasks
User stories
Priorities
Walking skeleton

40. 40
Theme
Epic
User story

41. 41

42. 42
User stories User story mapping
USM幫助團隊成員瞭解整個全局！

43. 43
Before
After

44. 44
Impact mapping和User story mapping有什麼關係?

45. 4545
那來的?
從假設找出最小可行產品
快速取得市場反饋,再修正假設

46. 4646
商業目標
角色
角色
功能
功能
功能
功能
從假設找出最小可行產品
依重要性: Goal -> Role -> Impact 過濾User story

47. 47

48. 48
在什麼時候使用Impact map和user story mapping？

49. 49

50. 50
Refine會議可以做什麼?
拆解Product Backlog + 估算工作

51. 51
Refine會議有下列活動:
1.重新調整”完成的定義”
2.計算團隊下個Sprint可用時間
3.團隊一起討論可能實現的方案
4.團隊協作創建任務並估計
5.根據任務時間以及速率向PO作出
最終承諾

52. 52
?

53. 53
Independent Encourage loosly coupled design. Helps continuous integration
Negotiable A promis to talk rather than stick to a specification
Valuable Everyone get into client’s shoes. Ask why, why and why
Estimatable You can manage what your measure
Small Small enough to plan for short production releases
Testable Done means tested and ready to deploy

55. 55
Operations As __ user
I want to Create
Delete
Update
REad
Different Inputs
As __ user
I want to select …
I want to write a ….
Simple To Complex
As __ user
I want to find …
By keyword
by date
Work Flow
As __ user
I want to send email
I want to save data

56. 56
Round 0
小 大
Round 1
小 大
Round 1~N
Round N+1
Round N+2

57. 57
拆
解
聚
合

58. 58
Round 1
Round 3
Story Point: 3 Story Point: 2Story Point: 5
Round 2
Story Point: 3

59. 59
Sprint 1 Sprint 2 Sprint 3 Sprint N
如果團隊沒有反饋
我都不會知道
每次衝刺過後,都會
產生需要維護的週
期性工作,這些很容
易被漏估了!
維護型工作
1 2 3
5
10
15
4
團隊速率: 13 per sprint
Sprint: 10個工作日

60. 60
1 2
3 4
1 2
3 4
5
5
Feeding Buffer
Project Buffer
面對重要的工作,總
是要有備無患
採用關鍵鏈,而不是
盲目對每個工作加
上緩衝的設定

61. 61
3
5
2
1
3
Sprint 1
3
5
1
3
1
Sprint 2
3
3
2
3
1
Sprint 3
Done: 14 Done: 13 Done: 13
1 2 3
5
10
15
依照產品規劃
這些功能大概
多久能做好?
估算完之後大概
有32個故事點,
預估 30天可以
完成
團隊速率: 13 per sprint
Sprint: 10個工作日

62. 62
本次衝刺同樣是
兩週(10個工作天)
我們決定在本次衝
刺完成這些工作項
目;若時間允許,會再
多完成一個
1 2 3
5
10
15
團隊速率: 13 per sprint
Sprint: 10個工作日
Sprint
1 3
2
2
1
3
1
3
2
4

63. 63
你還沒說Acceptance Criteria
?

64. 64
User story
Acceptance Criteria 允收準則就是：
完成User Story的條
件,可以使用
Given/When/Then
格式

65. 65
User story
Acceptance Criteria
如果Given/When/Then格式
無法被團隊接受,可以考
律使用條列式

66. 66
Wish-list
As a customer, I want to be able to have wish-lists so
that I can come back to buy products later
As a customer, I want to be able to
save a product in my wish-list so that
I can view it again later
As a customer, I want to be able to
view my wish-list so that I can buy
items from it
Put ‘Add to wish-list’
button on each
product page
Create new
do to store
wish-list items
Create page to
display user’s
wish-list
Add ‘View wish-list’
link to homepage
Theme
Epic
Stories
Tasks

67. 67
Wish-list
As a customer, I want to be able to have wish-lists so
that I can come back to buy products later
As a customer, I want to be able to
save a product in my wish-list so that
I can view it again later
As a customer, I want to be able to
view my wish-list so that I can buy
items from it
Put ‘Add to wish-list’
button on each
product page
Create new
do to store
wish-list items
Create page to
display user’s
wish-list
Add ‘View wish-list’
link to homepage
Theme
Epic
Stories
Tasks
Task Task Task Task
Sub-TaskSub-TaskSub-Task
Sub-TaskSub-TaskSub-TaskSub-Task
Story Story Story
Epic

68. 68
如何進行Daily Scrum?

69. 69
每天固定時間點、時間
週期、同一個地點 舉行
Daily Scrum

70. 70
每位成員講三件事:
1.昨天做了什麼
2.今天想做什麼
3.有遇到什麼阻礙

71. 71
Daily Scrum有五
項需要注要的指南
！
1)Do Not direct 2)Huddle/Collaborate 3)Scrum Lead starts
4)Always have it 5)Encourage break outs

72. 72
從Scrum Task Board來
觀察團隊隱藏的問
題,並且在Daily Scrum
討論改善
User story Task
Definition of Done
• 通過允收測試
• 通過單元測試
• 可發佈

73. 73
使用圖表更能更清楚
看到團隊問題
可以從燃盡圖中看到
專案總進度與剩餘工
作量的關係
燃起圖可以激勵士氣

74. 74
人終究不是機器人,
在衝次過後,需要的
是休息和放鬆!

75. 75
Sprint結束之後要做什麼呢？

76. 76

77. 77
團隊在Review會議
中展示本次衝刺結果
並且收集利害關係人
的反饋

78. 78
Function 1
某個功能是否完成,並
且寫下個人觀點,以及
還可以改進的項目

79. 79
這次終於可以
結束了吧?
還有回顧會
議呦!

80. 80

81. 81
Safety Discover Analyze Plan Close
每個人的參與
度有多高?
概觀 - 繼續
- 調整
- 停止
- 我們的方向
是什麼
- 我們有怎樣
的過去
- 如何紀錄和
追蹤
- 如何執行
5-10% 30-50% 20-30% 15-20% 10%

82. 82
藉由發散、收斂的方式
引導團隊找出關鍵的
議題
常見的方法為:
Lean Coffee

83. 83
團隊運用因果關係圖,
剖析本次衝刺大家最
關注的議題
當討論的過程中,發現
迴圈,記得要特別標註
起來,因為這代表團隊
要改善的根因找到了

84. 84
這次終於可以
結束了吧?
等等!光是這樣
就能運行了嗎?

85. 85
僅僅是瞭解Scrum還是會
有專案失敗的狀況發生?
原因是什麼呢?
將為您分曉!

86. 86
產品代辦清單中,記得不要
把任務(Task)放到裡面,並
且PO要懂得每一個項目的
商業價值
！

87. 87
PO一定要貼近利害關係人
並且時時關注市場變化,最
重要的是: 取得團隊的反饋
要善用溝通工
具取得反饋

88. 88
PO與團隊說明產品的願景
並且與團隊一起訂定:發佈
計劃 & 衝刺計劃
產品不是PO的
事,是團隊的事
瞭解產品願景才
能走在同一個方向

89. 89
團隊是為了衝刺的目標努
力,而不是為了工作項目努
力瞭解目標才能夠正
確的反饋給PO
每個衝次都有它
的目標

90. 90
Scrum只是框架,每個會議
該怎麼展開與套用什麼溝
通工具,可以由團隊自行決
定
IM和USM讓我
能夠把概念傳遞給
團隊
只用文件或口說,真
的無法了解產品

91. 91
User Story重點不在格式,而
是它的規範,遵守INVEST
才是最重要的事!
PO最好不要親自寫
User story,以避免
知識的詛咒!
由團隊寫才能深刻
理解需求

92. 92
團隊的速率是一個指標,團隊
可以藉由這個指標察覺團隊
狀態的變化
由速率作為依據對PO做出承
諾,並且在回顧會議中觀察速
率的變化

93. 93
Daily Scrum不是對Scrum
Master報告,是要同步團隊的
現況
埋頭工作的同時,也要瞭解專
案目前的狀態

94. 94
Review會議除了可以建立客
戶的信心之外,還可以得到真
正的客戶反饋
PO可以先暖場,但是
真正的舞台是給團隊
成員的!
盡可能展現這一回
合衝刺的成果!

95. 95
回顧會議引導團隊發現團隊
中的問題,並提出改進計劃,
並且在下一次的回顧會議中
追蹤並審視改進計劃的效益
是否符合預期我們不找女巫找問
題!

96. 96
我不做協調的工作,
我觀察且引導團隊
我沒有Boss,別把我
當小妹使喚呦!
我們18般武藝樣樣
精通,沒有誰只專職
做某個工作,我們瞭
解產品,並且熱愛工
作!
身為PO,我觀察市
場,並且貼近客戶,雖
是如此,但我絕不是
技術麻瓜!

97. 97
要不要考慮導入
看板方法呢?
Scrum能夠幫助團
隊在對的方向奔馳
但是每次遇到突發
的任務,總是苦惱!

98. 98
看板方法來自豐田汽車的管
理方法;利用一些簡單的原則
就能快速、有效率的製造出
一台客製化極高的汽車

99. 99
1.Visualize
Work-In-
Progress
2.Limit
Work-In-
Progress
3.Reduce
Multi-tasking
or Task
swiching
4.Improved
Focus
5.Improvement
in Cycle time
6.Feedback
frequency
increases
7.Quality
improves
8.Team
maturity
improves
Recipe to
improve
capability
看板方法來自豐田汽車的管
理方法;利用一些簡單的原則
就能快速、有效率的製造出
一台客製化極高的汽車

100. 100
這是一個看板的完整範例;
但是看板實際上是一直不斷
在演化的,沒有所謂的最終
版本
User
story 1
Stories in
Progress
Pri DevelopmentBacklog Ready for
UAT
Acceptance test To be
Deployed
System Test
In progress Done In progress Done
User
story 7
User
story 4
User
story 5
User
story 6
User
story 2
User
story 3
Emergency fixes
In progress Done
Legend
Task Team
Member
Critical
Bug
Bug
3 5 3 33

101. 101
Backlog Working on Verify Deployed
首先將工作流程轉換成為
看板中每一個欄位,其順序
由左到右
順序

102. 102
針對緊急狀況設制一個專屬
的泳道,並且採用不同的流
程
Backlog Working on Verify Deployed
Emergency 特殊流程
泳道

103. 103
卡片的設計可以依照團隊和
專案而定,這裡僅是提供一個
例子,唯一的設計指南就是-
表達力
2017-06-23
As a ….
I want to….
So that ….
Lisa
預計完成的日期完成的子任務數
User story的負責人
(負責不一定就是全由他做)
Start: 2017-06-01
End: 2017-06-22
開始日期,結束日期
User story描述

104. 104
Backlog Working on Verify Deployed
Emergency
104
為了能夠更清楚表達,甚至
可以考慮使用不同顏色的卡
片來凸顯不同的工作
這樣就能夠知道,目
前有多少緊急工作

105. 105
Backlog Working on Verify Deployed
Emergency
105105
卡片的顏色比例,也可以讓團
隊瞭解專案的現況,並且可以
作為資源分配的依據
如果金色卡片太多,可能
要多拉一點灰色卡片
Normal Bug Enhancement
Emergency

106. 106
Backlog Working on Verify Deployed
Emergency
In progress Done
Pull
當看板運行一段時間後,會發
現某些階段是整個系統的瓶
頸,採用拉式系統是應對的好
方法
針對可能的瓶頸資源,需
要重新設計看板

107. 107107
每個系統都擁有瓶頸,而處理
瓶頸有五個步驟:
1.找出瓶頸
2.確保瓶頸總是滿載
3.調整瓶頸區接鄰區域的工
法
4.增加資源到瓶頸區
5.若第4步打破了瓶頸,就再
回到步驟1
1
Identify the
constraint
2
Exploit the
constraint
3
Subordinate
everything else to
the constraint
4
Elevate the
constraint
5
Go back
To step #1

108. 108108
Backlog Working on Deployed
Emergency
In progress Done
如果想要刻意凸顯某個工作
階段的瓶頸需要在關鍵時刻
讓團隊關注、可以獨立出一
個欄位,並且加上在製品限制
看板的布局都是為了讓
團隊收到訊號
VerifyBuffer
額外多一個欄位

109. 109
Backlog Working on Deployed
Emergency
3
Verify
2
Buffer
3
2017-06-23
As a ….
I want to….
So that ….
Lisa
Start: 2017-06-01
End: 2017-06-22 109109109
看板兩大度量指標就是: 前導
時間(Lead Time),和吞吐量(
Throughput)
前導時間= 完工日期 – 收單日期
吞吐量 = 單位時間的完工數量

110. 110
Backlog Working on DeployedVerifyBuffer
前導時間
工期 前導時間是從接受工作直到
完成工作的總耗費時間
工作進行的過程中,可能會遇
到暫停、延遲等狀況
前導時間常常會和工期
兩者混淆,團隊要訂好DoD
Definition of Done
• 通過允收測試
• 通過單元測試
• 可發佈

111. 111
Backlog Working on Verify Deployed
Emergency
在制品限制可以讓流程的瓶
頸被快速找到,並且隨著在制
品數字的變化,團隊的生產力
也會隨著變化
3
在制品的限制可以從大
慢慢變小,但不能等於1
Cycle Time =
Work in Progress
Throughput
(Little’s Law)
Buffer
3 2

112. 112
Backlog Working on Deployed
5
Verify
5
Buffer
3
在製品上限會直接影響到前
導時間的長短;當在製品過大
前導時間就會變長;若是太小
則發生阻塞時,就會有人力的
浪費
Backlog Working on Deployed
1
Verify
1
Buffer
1
好無聊!
瓶
頸
間
反
覆
切
換
反
覆
切
換
沒人理
等很久
動不了
做完了,動不了

113. 113
高WIP讓成品製造時間變
得更長,也會讓團隊在發現
缺陷(Defect)時,反應變慢
低WIP讓製造時間變短,也
避免了過度的浪費,當發現
缺陷時,也能夠快速反應
每個階段在完成一定的批
量之後才交由下一個階段
每個階段在完成自己階段
的工作之後,交由下一個階
段
Batch Producing
One-Piece Flow

114. 114
團隊在製品上限計算:
Step1. 一個團隊成員估算其工作能力為2
2 * 5 = 10
Step2. 提升壓力,可以先從少一個人算起
2*4 = 8
團隊在製品上限的計算非
常簡單,並且可以為了凸顯
團隊是否有瓶頸而逐步降
低在製品上限(不得降到1)
千萬不要一開始就加太多
壓力給團隊!

115. 115
Backlog Working on Deployed
Emergency
3
Verify
2
Buffer
3
2017-06-23
As a ….
I want to….
So that ….
Lisa
Start: 2017-06-01
End: 2017-06-22
115115
整個看板其實背地裡藏了很
多個訊號;團隊可以追蹤這些
訊號,並且從訊號來驗證改善
的成果

116. 116
Backlog Working on Deployed
Emergency
3
Verify
2
Buffer
3
衝刺2衝刺1 衝刺3 衝刺N
開始日 結束日
固定時間長度
讓Scrum的時間盒概念與
看板結合;將時間盒作為看
板的一個訊號,當訊號出現
之後,所有團隊成員可以進
行團隊狀態的審視;訊號: 計
畫、衝刺、檢示、回顧會
議

117. 117
Backlog Working on Verify Deployed
Backlog
User Story
Task
Bug
User Story
us2
us3
Task Buffer
us1
結構 發散成Task/Bug,收斂成User story
為了要符合Scrum對於需
求的結構規格,看板可以進
行發散-聚合的動作;讓使用
者故事中的任務和缺陷在
工作流中流動,並在完成之
後,聚合成為一個使用者故
事

118. 118
依照團隊流程以及DoD來
更新看板的布局(Layout)
Verify System Test Acceptance
Test
為了讓測試流程能夠明確
讓團隊瞭解,將原本的單一
欄位拆成兩個
Definition of Done
• 通過系統測試
• 通過允收測試
• 可發佈

119. 119
通過TOC後,針對有瓶頸的
工作階段進行優化和調整
限縮進入瓶頸階段的工作
量,並且設定在製品數量上
限
System Test
對於瓶頸附近的工作階段,
也都需要進行微調整,最好
的方式就是在製品限制!
Acceptance
Test
瓶頸間!
Buffer
3 3 3

120. 120
結合前面的成果,最後可以
繪製出這個版本的看板
User
story 1
Stories in
Progress
Development
Backlog Ready for
UAT
Acceptance test To be
Deployed
System Test
User
story 4
User
story 5
User
story 2
User
story 3
5 3 2

121. 121
任務和缺陷工作單的優先
權無法凸顯,並且有時緊急
修復的工作也沒辦法呈現
User
story 1
Stories in
Progress Development
Backlog Ready for
UAT
Acceptance test To be
Deployed
System Test
User
story 4
User
story 5
User
story 2
User
story 3
5 3 3
121
使用第一個版本試著運行
一段時間後,會發現到有諸
多窒礙難行之處,可以在
Daily Scrum中進行討論並
改善
3

122. 122
User
story 4
User
story 7
User
story 5
User
story 6
User
story 1
Stories in
Progress
Pri DevelopmentBacklog Ready for
UAT
Acceptance test To be
Deployed
System Test
User
story 2
User
story 3
Emergency fixes
3 5 3 33
122122
使用第一個版本試著運行
一段時間後,會發現到有諸
多窒礙難行之處,可以在
Daily Scrum中進行討論並
改善

123. 123
使用第一個版本試著運行
一段時間後,會發現到有諸
多窒礙難行之處,可以在
Daily Scrum中進行討論並
改善
我們也想要從看板獲得專
案資訊,但是不知道該怎麼
解讀這個看版
我們需要在看板
上加上一些Tips!

124. 124
User
story 1
Stories in
Progress
Pri DevelopmentBacklog Ready for
UAT
Acceptance test To be
Deployed
System Test
User
story 2
User
story 3
Emergency fixes
3 5 3 33
Legend
Task Critical
Bug
Bug
User
story 4
User
story 7
User
story 5
User
story 6
適當地在看板上加上說明
區域,可以幫助團隊以及所
有利害關係人們可以更方
便地解讀這個看板

125. 125
配合拉式(Pull)系統,我們
打算再把開發和緊急修復
欄位切割!
125
當QA資源不足,除了加
上Buffer欄位,其實可以對
開發欄位再改進!
In progress
In progress
Done
Done

126. 126
In progress
In progress
Done
Done
將頭像貼紙貼在卡片上,並
且限制每張貼紙的張數,就
能夠追蹤人力資源!
除了工作之外,人力其實也
可以是追蹤的項目!
Team
Member

127. 127127
在Scrum中很多的活動都
能利用看板追蹤團隊狀態

128. 128
永遠都不要忘掉
敏捷與精實