文档介绍了大规模敏捷开发中的挑战和解决方案，例如团队间的相依性管理和需求釐清。强调了通过特性团队和持续集成等方法来提高团队之间的协作和灵活性。还提到了一些具体的实践和工具，以优化产品开发过程和减少无效工作。

1. 1

2. 我是誰?
2008 在大型組織玩敏捷
Agiletour 台北組織者
敏捷社群創始人
谷歌設計衝刺推廣者
敏捷三叔公
David Ko
davidko@odd-e.com

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

4. 大家交流一下
• 你的角色: RD, QA, PM/PO, 其他
• 有用 Scrum 開發的
• 有多個團隊一起開發產品
• 有多個團隊一起用 LeSS 開發產品
4

5. 大規模軟體開發常見問題
• 1. 不知道對方在做什麼, 會重複開發元件
• 2. 最後整合才發現有問題
• 3. 彼此互相無法支援
• 4. 先做自己會的而不是最有價值
• 5. 團隊人數一直在增加
• 6. 小功能要做很久才出來, 因為跟很多人
有關
5

6. 大規模軟體開發常見問題
6

7. 大綱
緣起
團隊的設計
如何處理相依性的設計
7

8. 2004 年 Nokia 想導入敏捷開發
8

9. 9

10. Scrum 的本質
10
團隊成員如何以更好的方式協同做事

11. 一開始的挑戰
11
只有 1.5 個 coach
支援 10 個團隊 Nokia 都是多個團隊
完成產品

12. 12
我們如何開始進行
多團隊的 Scrum?

13. 師法前人經驗 (非理論)
13
回顧 Excel 1.0
的開發作法
回顧 VC++ 1.0
的開發作法
Daily Build Feature Team

14. Ericson – 對手的作法
XP and large distributed software projects
14
Source: Extreme programming examined: XP and large distributed software projects
避免進行太大的代碼合併

15. Ericson – 對手的作法
XP and large distributed software projects
15
Source: Extreme programming examined: XP and large distributed software projects
專注於客戶要的價值, 而非技術

16. 學習到的戲法
16
Feature Team
Daily Build

17. 大綱
緣起
團隊的設計
如何處理相依性的設計
17

18. LeSS 最有影響的組織結構
18
https://less.works/less/structure/feature-teams

19. Component
Team
的缺點
• 循序開發
• 限制學習
• 不見得都
很忙
• 延遲交付
19

20. Feature Team 的設計思維
20
彼此協作 須了解
較多事情
成長思維

21. 世事總是有不完美
21
Feature
Team A
Feature
Team B
Feature
Team C
Component
Team D
Product
Backlog
ü 太專業
ü 很少用的
ü 沒空學
ü 太多元

22. 世事總是有不完美
22
Feature
Team A
Feature
Team B
Feature
Team C
Component
Team D
Product
Backlog
(1) 去 Feature Team A 一
起開發出來
(2) 各個 Feature Team
派人來開發
(3) 去 Feature Team C 指
導他們開發出來

23. 單一 PB, 單一 PO
23
Team
Product
Owner
Scrum 時代 LeSS 時代
統一優先順序, 避免多頭馬車
Team Product Owner
Team Product Owner
Team Product Owner

24. 但是 Product Owner 不是操人
24
Team
Product
Owner
LeSS 時代
BA
分擔
工作
決定最
後順序
直接面對客戶
學習領域知識

25. 大綱
緣起
團隊的設計
如何處理相依性的設計
25

26. 處理開發相依性的起源
26
Daily Build Continuous
Integration
• 重心在程式碼
• 多人的開發程式碼會相互影響
• 利用 持續整合早點發現被影響

27. 團隊之間有相依性
在大規模敏捷要如
何解決?
27

28. 團隊之間本來就會
有相依性度狀況
這不是要解決的事
要看相依性的種類
28 https://www.youtube.com/watch?v=cxmLO0U6gQ0&t=812s

29. 29
同步的
相依 非同步的
相依
不同團隊
在同一時間
會有相依關係
不同團隊
在不同時間
會有相依關係

30. 30
迭代 1 迭代 2
故事 A
(C1, C2)
故事 B
(C2, C3)
Team A
故事 C
(C4)
Team B
故事 D
(C2)
Team A 和 Team B 同時要討論怎麼用 C2

31. 31
如果團隊們 同時
專注在同一部分的代碼
團隊間 預期 會彼此干擾
但這樣的相依是好的
鼓勵不同團隊間:
擴大學習/系統思考/提早整合

32. 32
迭代 1 迭代 2
故事 A
(C1)
故事 B
(C2, C3)
Team A
故事 C
(C4)
Team B
故事 D
(C2)
Team A 之後會改到 C2,
但是目前沒空和 Team
B 討論
Team B 現在會改到 C2,
但是 Team A 沒空和他
們討論

33. 33
迭代 1 迭代 2
故事 A
(C1)
故事 B
(C2, C3)
故事 C
(C3)
故事 D
(C2)
Team A
Team B
Team B 在忙別的,
沒空處理 Team A
對 C2 的修改
Team A 需要 Team
B 調整 C2 的用法

34. 34
團隊們 不同時間
相依在同一部分的代碼
導致團隊會受到 不預期 的干擾
這樣的相依才是問題:
延遲整合/局部優化

35. 35
想想剛剛的相依狀況
如果把團隊換成個人
是否在一個團隊內也發生
以前你無解, 現在也是無解

36. 利用擴大學習來解決
36
Product
Backlog 數目
團隊工作的
範圍
對團隊靈活
性的要求
團隊靈活性
的差距
團隊靈活性
團隊承受的
壓力
團隊
擴大學習
+
+
+
+
+
+
-
-
B2
團隊擴大學習
提高靈活性
B1
團隊靈活性
限制全局優化價值
https://github.com/yilv/LargeScaleProductDevelopmentOrganization/blob/master/Chapter4/WorkDesignChoices.md
• 團隊相依狀況
• 不懂別人在做什麼
• 沒有相關技能
• 時程很趕
• 品質不佳
• ….

37. LeSS 如何處理
37
需求釐清
• 子需求領
域
• 多團隊
PBR
• 撰寫不熟
的需求
迭代規劃
• 同地點的
會議
• 聯合設計
工作坊
• 漸進式領
需求
開發
• 搭擋編成
• 持續整合
• 程式碼共
有
迭代檢視
• 展示不熟
的需求
• 展示市集

38. 利用子需求領域來漸進式學習
38
https://less.works/less/less-huge/area-product-backlog

39. 39
(1) 有關連的需求
大家一起來進行
需求梳理
(2) 每個需求團隊
都派代表參加
(3) 或是利用世界
咖啡館方式討論
https://www.infoq.com/presentations/less-workshop-backlog-refinement/

40. 對不熟故事撰寫驗收條件
40
用戶故事 1 (A|B|C)
用戶故事 2 (A|D|E)
用戶故事 3 (B|D|E)
用戶故事 4 (A|D|F)
Team C (A|B|D)
Team B (A|D|F)
Team A (A|B|C)

41. LeSS 如何處理
41
需求釐清
• 子需求領
域
• 多團隊
PBR
• 撰寫不熟
的需求
迭代規劃
• 同地點的
會議
• 聯合設計
工作坊
• 漸進式領
需求
開發
• 搭擋編成
• 持續整合
• 程式碼共
有
迭代檢視
• 展示不熟
的需求
• 展示市集

42. 42
https://less.works/less/framework/sprint-planning-one
大家盡量選擇
有相關連的需求
利用 聯合設計
工作坊
來同步和學習
利用同一地點
可即時同步
相關連的資訊

43. 漸進式領需求
43
用戶故事 1 (A|B|C)
用戶故事 2 (A|D|E)
黃色團隊
(A|B|C)
綠色團隊
(C|D|E)
藍色團隊
(A|B|E|F)
綠色團隊和藍色團隊
為了接用戶故事 2,
需要學習新技能

44. LeSS 如何處理
44
需求釐清
• 子需求領
域
• 多團隊
PBR
• 撰寫不熟
的需求
迭代規劃
• 同地點的
會議
• 聯合設計
工作坊
• 漸進式領
需求
開發
• 搭擋編成
• 持續整合
• 程式碼共
有
迭代檢視
• 展示不熟
的需求
• 展示市集

45. 開發三板斧
45
持續整合 (每 30 分鐘要 push)
搭擋編程 程式碼共有

46. LeSS 如何處理
46
需求釐清
• 子需求領
域
• 多團隊
PBR
• 撰寫不熟
的需求
迭代規劃
• 同地點的
會議
• 聯合設計
工作坊
• 漸進式領
需求
開發
• 搭擋編成
• 持續整合
• 程式碼共
有
迭代檢視
• 展示不熟
的需求
• 展示市集

47. 展示不熟的用戶故事
47
用戶故事 1 (A|B|C)
用戶故事 2 (A|D|E)
用戶故事 3 (B|D|E)
用戶故事 4 (A|D|F)
Team C
(A|B|D)
Team B
(A|D|F)
Team A
(A|B|C)
Team A
(A|B|C)
Team C
(A|B|D)
Team B
(A|D|F)

48. 展示市集
48
https://less.works/less/framework/introduction

49. 總結 – LeSS 的設計
站在 巨人的肩膀 上
最大化 團隊之間的相依性
善用 擴大學習, 讓略懂略懂 > 0
49

50. 後續參考文章
50

51. Q & A