1. Why SCRUM
(敏捷式專案管理)
尚玉瑋
ywshang@itri.org.tw 1

2. 先做名詞解釋
2

3. 敏捷(Agile)是一種框架(可以解釋成
一種概念)，在這個概念下，由不同
的專案管理大師發展出不同門派。目
前常見的有Scrum、XP、Lean…。
在溝通上我們會用Scrum或敏捷
(Agile)來稱呼，其實指的都是同一個
東西。
3

4. START
4

5. 這是一個真實故事
5

6. 自從2010拿到PMP
6

7. Requirements
Waterfall
Model
Analysis
& Design
Development
Testing
& Validation
PMP說： Deployment
我們要時時刻刻修正管理計畫 & Maintenance
7

8. 事實上
8

9. 自從寫完需求分析
跟功能報價後
文件更新頻率越來越低
9

10. 不是偷懶
10

11. 而是每增加一個需求
User往往不太看更新後
的文件
客戶會覺得口頭上的討論就已經是確認需求
更新後的需求文件對客戶的價值，往往不高
11

12. 更何況同時兼任
PM、SA、SD 、PG
12

13. 學習
敏捷式專案管理後
13

14. 看到一些
解決問題的方法
14

15. 稍微解釋
SCRUM
15

16. 本投影片只會粗略介紹敏捷式專案管理
必須深入學習，才能了解更細節的部分
(本投影片較適合想對SCRUM有點概念的人)
16

17. 它是基於Iteration Model的管理模式
假設一個為期3個月的專案，以每14天為一個基期(Sprint)，總共
區分成12期，把全部功能分散在12期內完成，每一期的結束必須
跟使用者進行Demo&Review，確保功能正確產出。
(Waterfall的做法是當功能完成到一定的進度才會跟User Demo)
17

18. 好處是
使用者不必等很久就能看到系統功能
若是有問題，系統方可以提早修正。
傳統上，客戶必須在測試期才能做意見回饋
18

19. 在Demo&Review之後
接著召開Sprint Meeting，讓User決
定本期(Sprint)要開發那些功能。
(這些功能就是下次Demo&Review的內容)
讓客戶檢視專案執行概況，例如，增加了多
少需求，還需要多少時間系統才能完成。 19

20. 就這樣重覆到
專案結束
20

21. SCRUM
怎麼解決問題
21

22. 需求管理
使用者不斷增加、變更需求
22

23. 在敏捷的世界裡，客戶必須把需求寫
在便利貼上，假設有10個需求就寫
10張，然後在Demo&Review裡驗證
功能是否符合該需求。
23

24. 好處是
需求不會遺漏，不會要求客戶
Review整份需求文件，只需專注在
未完成的便利貼上。
24

25. 時程管理
25

26. 每個寫在便利貼上的需求，系統方會
對這個需求進行複雜度評估，然後給
予一個數字。假設本(期)Sprint能處
理的複雜度總量為100，客戶可以任
意挑選不同需求的便利貼，只要複雜
度總量不超過100即可。
26

27. 好處是
需求予以量化後，假設客戶提出20
個新需求，系統方可以很容易估算出
需要增加多少時間進行開發。此外，
需求的執行先後順序是由客戶排定，
而非系統方(讓客戶挑選重要的先做)
27

28. 用簡單的方式就能做好需求、時程管理
28

29. 上圖，有些不符合Scrum
的做法，參考就好
29

30. 專案管理不是SOP ，可以
用局部導入的方式，轉變
成你自己的方法(流程)。
30

31. 團隊改善
31

32. 在敏捷的世界裡，有兩個時間點可以
作團隊改善，第一個叫Daily Scrum
，第二個是在每期(Sprint)結束後招
開的改善(Retrospective)會議
團隊改善其實是落在整個敏捷流程裡
32

33. Daily Scrum也叫Daily Standup
Meeting(每天大家站著開會)，此時
每個人需要回答3個問題
1.昨天做了什麼
2.今天要做什麼
3.有沒有遭遇困難
33

34. 1.昨天做了什麼
2.今天要做什麼
可以讓團隊成員跟PM了解進度，有
沒有人打混，一看就很明顯…
身為一個PM，你是怎麼關心組員的進度?
34

35. 3.有沒有遭遇困難
藉由將問題拋出，讓團隊可以去想
辦法解決，而不是孤軍奮戰。
35

36. Retrospective 會議
目地在改善工作流程，檢討每期
(Sprint)的執行狀況，好的地方就保
留，不好的地方就改善。
傳統的管理手法，沒有讓成員發聲的管道
36

37. 另一個常見的問題
37

38. 我們公司有
CMMI
ISO9000
ISO2000
…..
現在還多一個Scrum?
38

39. Scrum與CMMI對照表
http://ebookbrowse.com/cmmi-iso-vs-agile-dev-doc-d191228954
39

40. 某種程度上
符合公司規範流程
40

41. 好處是
41

42. 減少
Paper Work
42

43. 專注
產品(功能)開發
43

44. Scrum文件基本上只有便利貼
(這是把便利貼做成投影片的版本)
44

45. 回頭看一下
SCRUM流程圖
45

46. 還記得Daily Stand-Up Meeting嗎，每天都要不斷召開
每一期(Sprint)的執行時間長度，長度是固定的
每期(Sprint)的做完
都有東西產出
每一期要做的便條紙需求，集合起來就叫Sprint Backlog
還記得便條紙嗎，全部集合起來，專有名詞就叫Product Backlog 46

47. Demo&Review之後
討論下個Sprint的產出 Retrospective Meeting，
改善工作流程
Sprint Meeting，決定要產出哪些功能
Demo&Review Meeting，
獲得意見回饋

48. 關於敏捷
還有很多沒講
48

49. 1.需求怎麼編寫、如何切割
2.複雜度如何估算
3.如何計算團隊執行速率
(團隊能處理的複雜度總量)
4.Sprint Meeting的意義
….
49

50. 敏捷式管理的概念很簡單
但執行上會有相當的難度
至於細節…嗯…再說吧
The End 50