本文件介绍了敏捷转型的工具和流程，包括建立危机意识、组建领导团队和沟通愿景等关键步骤。它强调了变革管理的重要性，并提出精实改变画布和实践社群等指导方法。通过实例和策略，提供了敏捷转型成功的建议和实施方案。

1. 啟動敏捷轉型的工具箱
Odd-e Agile Coach
David Ko 1

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

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

4. 市調
• 你們公司尚未導入敏捷的, 請打 +0
• 你們公司正在敏捷轉型的, 請打 +1
• 你們公司已經實施敏捷多年的, 請打 +3
4

5. 服藥須知
5
針對 中大型 組織
並且 公司層級 的推廣小組
不是 控制與命令型 的組織

6. 聽到要推敏捷轉型
6

7. 很多郎中都會推薦我
7

8. https://davestuartjr.com/silver-bullets/
是的沒有銀製武器
但是我們有劍
8

9. 敏捷啟動工具箱
敏捷轉型流程
精實改變畫布
Improvement kata
實踐社群 (Community of Practices)
9

10. 10
導入任何新東西
都是在進行 變革管理

11. 11
約翰科特
變革之父
• 哈佛最年輕終身教授
• 領導人的變革法則, 在 2011被時
代雜誌選為史上最具影響力的
商管書籍之一
• 哈佛商業評論的文章: 加速
(Accelerate!), 得到 2012 年麥肯錫獎

12. 約翰科特的領導變革
建立
危機意識
成立
領導團隊
提出願景
溝通願景
授權
員工參與
創造
近程戰果
鞏固戰果
並持續
深植
企業文化
12

13. 如何建立危機感
13
喚醒領導的
變革意識
導入知識
讓管理層產
生危機感
• 競爭對手間
的較勁
• 世界趨勢
• 教育訓練
• 外來和尚
• 走出同溫層
• 高層的壓力
• 部門之間比較
• 市場資訊

14. 轉型領導團隊 v.s. 實踐社群
實踐社群
實踐社群
轉型領導團隊
• 營造文化
• 支持變革
• 對專業熱情
• 落實某些實踐
14

15. 趨勢科技的 DevOps 轉型之旅
2015 年
消費端產品團隊
開始負責 Ops
任務
2019 年
CEO 發起
DevOps 運動
2019 年
60 位跨部門
高管加入轉
型小組
https://www.ithome.com.tw/news/142647
2019 年
確定轉型
思維和策略
2019 年
評量現狀
2019 年
喚醒 DevOps
認知和察覺
2020 年
動手實踐
DevOps
15

16. 轉型策略
16

17. 遊戲化推廣活動
17

18. 有話題性的研討會
• 兩天多軌的研討會
• 超過 50 成功案例
• 借鏡微軟, AWS
• 與 唐鳳 的對話
18

19. ITHome 報導
19

20. 你覺得那個步驟最重要
1. 建立
危機意識
2. 成立
領導團隊
3. 提出願景
4. 溝通願景
5. 授權
員工參與
6. 創造
近程戰果
7. 鞏固戰果
並持續
8. 深植
企業文化
20

21. 敏捷啟動工具箱
敏捷轉型流程
精實改變畫布
Improvement kata
實踐社群 (Community of Practices)
21

22. 在規劃時要注意的事情
計畫太多是
浪費
需要考慮
多點面向
期待可以
一目了然
容易和其他
人溝通
要能
容易調整
22

23. 精實改變畫布 (Lean Change Canvas)
改變的影響者
願景
策略目標
行動
所要求的投資 利益
溝通
成功的條件
急需改變的事
23

24. 精實改變畫布
24
改變的影響者
願景
策略目標
所要求的投資 利益
急需改變的
3個最
重要原因
誰會被這個
轉型或是改變
所影響
行動
溝通
成功的條件
預期的收益
當改變後,
組織可以達到
的美好境界
要達成願景
所需要策略.
要衡量的
關鍵指標
用什麼方式
和團隊溝通
你所要的改變
指導團隊
進行改變
的戰術
為了改變所需要投入的資源
急需改變的事
1
4
5
7 6
8
5
2
3

25. 範例: 建立可持續交付的高士氣團隊
25
改變的影響者
願景
策略目標
行動
所要求的投資 利益
溝通
成功的條件
需求不
確定
加班
太多
交付
太慢
團隊
成員
客戶
建立可持續
交付的高士
氣的團隊
客戶
信任
主管
放心
員工
高興
教育
訓練
迭代
開發
每月固
定交付
率>80%
回顧
會議
10%
還債時
間
SP &
PBR
技術讀
書會
實施
CI
實施
Scrum
急需改變的事
1 on 1
持續
整合
Bug 數
減少
10%
讀書會
投資

26. 這樣可行嗎?
26

27. 你需要思考以下事情
確保改變的範
圍最小 藉由實驗確保改
變是可行的
27

28. 縮小改變範圍的做法
• 縮小某些項目的範圍
• 目標或行動不要花超過一個月
• 同時進行的工作不要太多
28
改變的影響者
願景
策略目標
所要求的投資 利益
急需改變的
3個最
重要原因
誰會被這個
轉型或是改變
所影響
行動
溝通
成功的條件
預期的收益
當改變後,
組織可以達到
的美好境界
要達成願景
所需要策略.
要衡量的
關鍵指標
用什麼方式
和團隊溝通
你所要的改變
指導團隊
進行改變
的戰術
為了改變所需要投入的資源
急需改變的事
1
4
5
7 6
8
5
2
3

29. 縮小範圍 – 針對目標和行動 (1)
改變的影響者
願景
策略目標
行動
所要求的投資 利益
溝通
成功的條件
需求不
確定
加班
太多
交付
太慢
團隊
成員
客戶
建立可持續
交付的高士
氣的團隊
客戶
信任
主管
放心
員工
高興
教育
訓練
迭代
開發
每月固
定交付
率>80%
回顧
會議
10%
還債時
間
SP &
PBR
教育
訓練
實施
CI
實施
Scrum
急需改變的事
29
1 on 1
持續
整合
Bug 數
減少
10%
讀書會
投資

30. 縮小範圍 – 針對目標和行動 (2)
改變的影響者
願景
策略目標
行動
所要求的投資 利益
溝通
成功的條件
需求不
確定
加班
太多
交付
太慢
團隊
成員
客戶
建立可持續
交付的高士
氣的團隊
客戶
信任
主管
放心
員工
高興
教育
訓練
察覺
問題
每月固
定交付
率>80%
回顧
會議
10%
還債時
間
SP &
PBR
教育
訓練
讀書會
內部經
驗分享
急需改變的事
30
1 on 1
Bug 數
減少
10%
讀書會
投資
學習
知識

31. 敏捷啟動工具箱
敏捷轉型流程
精實改變畫布
Improvement kata
實踐社群 (Community of Practices)
31

32. Improvement Kata
32
Mike Rother

33. 願景方向 (Direction)
33
 找出北極星
目標，不一定總是要達到，
目標是用來幫助你瞄準方向

34. 現在的狀態 (Current Condition)
34
 了解自己
 排除偏見

35. 下個目標狀態 (Next Target Condition)
35
 要超越現狀
 具有未知性

36. 實驗 (Experiments)
36
 快速實驗
 根據資料學習

37. 案例: 加班很嚴重
37
花很多時間在加班
紀錄
工時
分析
瓶頸
核心
工時
讓加班狀況不常見
目標: 瞭藉現狀
活動: 紀錄工時
指標
每類活動的時間
每類活動的比例
目標: 分析瓶頸
活動: 分析那些超標
指標
開發 每天 3-4 小時
Scrum 會議約 13%
每天會議次數
目標: 專注開發時間
活動: 每天下午2-5點專心開發
指標
每人每週開發時數
是否 > 15 小時

38. 案例: 實施持續整合 (Continuous Integration)
38
大多數不懂也不會
培訓
動手
競賽
試點
團隊
每次功能完成都會執行
目標: 知識傳遞
活動: 訓練課程
指標
參加人數
考過 70 分比例
目標: 知道如何用工具
活動: 3 小時的工具設定工坊
指標
團隊參加過幾個工具
團隊實際裝到產品環境幾個
目標: 試點團隊
活動: 每個部門找出試點團隊
指標
各部門參與團隊數
CI 執行次數
CI 成功比例
CI 執行時間

39. 敏捷啟動工具箱
敏捷轉型流程
精實改變畫布
Improvement kata
實踐社群 (Community of Practices)
39

40. 實踐社群 (Community of Practices)
• 將某一特定主題感興趣的人聯繫在一起的網路
• 成立的目的
– 知識技能的共享
– 有助轉型的效率
– 情感的交流
40

41. Google Testing Grouplet
• 20% 時間的專案, 自發性來做, 員工主導
• 目的
– 推動 開發人員 測試
• 座右銘
– Debugging sucks. Testing rocks
• 沒有預算, 沒有權力, 創業精神
41

42. 42

43. 告知 Inform
• Noogler = new + Googler, Google 新人
• 介紹可用的工具, 並儘早向新員工灌輸思想
Noogler Training
Tech Talks
Free Books
• 要動手練習的 tutorials
• 可按上面的練習, 學會一些新的技能或流程
Codelabs
43

44. Testing on the Toilet (TofT)
在 2006 年頭腦風暴會議中產生
人們會收集書, 但通常不會看
想出這招來教大家學好測試
• 在 30 個谷歌辦公室的數百個廁所
• 涵蓋不同編程語言和應用領域
• 由來自世界各地的志願者撰寫
• 也會對外發行給公司外的人
每週會出現
44

45. 有知識就夠了嗎?
從哪邊開始 舊系統
怎麼辦
45

46. Test Certified
Bharat Mediratta 和 Nick Lesiecki 的心血結晶
由下向上發起, 沒有權力, 完全是自動自發
團隊可以自己掌控要做多少
團隊可以知道要往哪個方向努力
Testing Grouplet 可以知道個團隊落實多少
46

47. Google 測試認證等級
Level 1 做好
準備
Level 2 增加
涵蓋率
Level 3 測試
新增代碼
Level 4 測試
遺留代碼
Level 5 更好
整體涵蓋率
(1) 使用涵蓋
工具, 持續集
成
(2) 測試有分
級: 小型, 中型,
大型
(3) 建立
smoke test
(4) 標記出
nondeterminis
tic tests (不確
定測試)
(1) 代碼提交前
要進行 smoke
test
(2) 整體增量測
試涵蓋率要大
於 50%
(3) 小型測試的
增量測試涵蓋
率要大於 10%
(4) 每個功能至
少要有一個整
合測試案例
(5) 如果測試有
失敗不能發布
(1) 所有重要的
代碼變更都要
經過測試
(2) 小型測試的
增量測試涵蓋
率要大於 50%
(3) 新增的重要
功能都要有整
合測試
(1) 任何代碼提
交前要自動進
行 smoke test
(<30 min)
(2) 整體的測試
涵蓋率至少
40%
(3) 小型測試的
測試涵蓋率不
該小於 25%
(4) 所有重要的
功能都應該被
整合測試驗證
到
(5) 沒有不確定
測試
(1) 每個 bug 都
要增加一個相
對應的測試個
案
(2) 積極使用可
用的代碼分析
工具
(3) 整體測試涵
蓋率不該小於
60%
(4) 小型測試的
增量測試涵蓋
率不該小於
40%
47

48. Test Mercenaries (測試傭兵)
• 由 SWE 所組成, 扮演內部諮詢的角色
• 從 2006 年末到 2009 年初
Google 內部的一個開發團隊
幫助團隊改進測試實踐和代碼質量
• 確保 2009 年底所有團隊都能達到 level 3
幫助團隊落實測試認證
48

49. Test Mercenaries (測試傭兵)
49
評估 坐在一起
每次進駐
至少兩名傭兵
找能見度高的專案
先開始
剛開始先幫忙
code review, 以建
立信任
至少合作三個月
每次參與後會進行
回顧會議
測試傭兵內部會互
相交流案例, 手法,
和工具

50. Fixits
團隊/公司 級別的一天的活動
有助於推最新的技術
• 專注處理某一類的問題
• 處理重要但不緊急的任務
• 撰寫測試, 修復壞掉的測試, 測試認證升級
活動內會做什麼
50

51. 曾經幾個重要的 fixit
• 提供工具來幫忙解決我沒時間測試的問題
2008 (I don’t have time to test)
• Build tools 導入分散式編譯和執行的基礎建設
2009 (Revolution Fixit)
• 導入 Test Automation Platform, TAP (CI 系統)
2010 (TAP Fixit)
51

52. 你覺得哪招比較有用
52

53. 今日重點
• 利用 變革管理流程 指導敏捷轉型
• 根據 精實轉型畫布 來 啟動轉型計畫
• Improvement kata 來進行 PDCA 實驗
• 讓 實踐社群 穩固你的 重要技術底氣
53

54. Q & A
54