文档概述了敏捷开发和Scrum框架的基本原则与实践。强调了通过迭代和协作方式提升软件开发效率，并详细介绍了Scrum团队的角色、工作流程及会议形式。文中还探讨了与传统项目管理方法的比较及常见问题的解决方案。

1. Scrum深入淺出
2015.03.25 @ Hiiir Inc. 7F 東方藍
Taien Wang<taien_wang@hiiir.com>
時間軸科技股份有限公司

2. 大綱
• 敏捷開發
• Scrum
2

3. 敏捷開發(Agile Development)
• 一種以人為核心、迭代、循序漸進的開發方法
• 起源
– 幾個軟體專家在美國猶他州聚會起草了敏捷宣言文件
• 具體
– 在敏捷開發中，軟體項目的構建被切分成多個子項目，各個子項目的成果都經
過測試，具備集成和可運行的特征
– 換言之，就是把一個大項目分為多個相互聯繫，但也可獨立運行的小項目，並
分別完成，在此過程中軟體一直處於可使用狀態
3

4. 敏捷開發宣言文件 – 價值觀
• 我們一直在實踐中探索更好的軟體開發方法，身體力行的同時也幫助他人
• 由此我們建立了以下價值觀
– 個體和互動高於流程和工具
– 工作的軟體高於詳細的文件
– 客戶合作高於合約談判
– 響應變化高於遵循計畫
4

5. 敏捷開發宣言文件 – 原則
一. 我們最優先的任務，是透過及早並持績地交付有價值的軟體來滿足客戶需求
二. 竭誠歡迎改變需求，甚至已處開發後期亦然。敏捷流程掌控變更，以維護客戶的競爭優勢
三. 經常交付可用的軟體，頻率可以從數週到數個月，以較短時間間隔為佳。
四. 業務人員與開發者，必須在專案全程中天天一起工作
五. 以積極的個人來建構專案，給予他們所需的環境與支援，並信任他們可以完成工作
六. 面對面的溝通是傳遞資訊給開發團隊及團隊成員之間，效率最高且效果最佳的方法
七. 可用的軟體是最主要的進度量測方法
八. 敏捷程序提倡可持續的開發。贊助者、開發者及使用者應當能不斷地維持穩定的步調
九. 持續追求優越的技術與優良的設計，以強化敏捷性
十. 以簡潔文本，它是極力減少不必要工作的藝術
十一. 最佳的架構、需求與設計皆來自能自我的組織團隊
十二. 團隊定期自省如何更有效率，並據之適當地調整與修正自己的行為
5

6. 敏捷流派
• XP Extreme Programming(極限編程)
• Scrum
• Kanban
• Lean Software Development(精益軟體開發)
• Feature Driven Development, FDD(特性驅動開發)
• Dynamic Systems Development Method, DSDM(動態系統開發方法)
• Crystal Clear Method(水晶方法)
• Adaptive Software Development, ASD(自適應軟體開發)
• Agile Unified Process, AUP
• Agile Modeling, AM(敏捷建模)
6

7. 價值驅動 vs 計畫驅動
7

8. 設計師內心的告白
8

9. 價值流: 傳統 VS Scrum
• 傳統
• Scrum
9

10. 管理框架: 傳統 VS Scrum
• 傳統專案管理過程
• Scrum專案管理框架
10

11. 敏捷與非敏捷: 流程控制
11

12. Iterative, Incremental Development
反覆, 漸進式開發
12

13. 敏捷和Scrum為什麼在軟體開發管理中有效
• 系統風險降低機制
• 更精益的軟體開發生命週期
• 更具適應性的項目管理過程
• 基於人類積極性和成就感的項目管理和開發過程框架
13

14. 問題
• 敏捷開發與持續性整合(Continuous Integration)的關係?
– 掌握開發節奏
• 每次軟體發布都要是能被正確執行的
• 越老越大的產品測試越久
– 依靠QA只能一直加人, 時間還不一定追的到
– QA 越多, RD 就越懶去驗證自己寫的程式
14

15. 起源
• 1986, The New Product Development Game, Harvard Business Review, Hirotaka
Takeuchi/Ikujiro Nonaka
– 專案團隊由較小規模的跨職能團隊組成, 為了一個共同的目標協同工作
• Object Oriented Analysis and Design(OOAD), Jeff Sutherland
• Object Oriented Programming, Systems, Languages, and Application(OOPSLA),
Ken Schwaber
• 1995, Scrum and the Perfect Storm, Jeff Sutherland/Ken Schwaber, Object
Management Group(OMG)
15

16. Scrum角色與責任
16
• 利害關係人(Stakeholder)
– 擁有產品的願景與想法
• Scrum團隊
– 產品擁有者(Product Owner, PO)
• 需求管理與驗收產品
– Scrum大師(Scrum Master, SM)
• 確保Scrum流程順暢執行
– 開發團隊(Dev Team, Team)
• 做出產品

17. 運作流程
17

18. Scrum 團隊
• 實際執行專案的團隊
– 自我管理
– 跨功能
– 持續交付產品
18
角色 責任
Product Owner What? 做對
Team How? How much? 做好

19. 產品積壓工作
需求討論會議 衝刺討論會議(Sprint Planning)
活動 撰寫 User Story Part I:
• Why? What?
• 解釋與釐清Story內容
• 決定Sprint Goal(Definition of Done,
DoD)
Part II:
• How?
• 切割Story與估計Task時間
時間 1~2天 4周衝刺一次: 8小時(分兩次)
2周衝刺一次: 4小時
人員 產品負責人/需求單位 產品負責人/團隊
產出 User Story(角色-目的-做什麼-重要性)
Product Backlog(產品積壓)
User Story(+確定重要性與估算時間)
DoD: Task, Story, Sprint, Release
每天例會的地方
19

20. User Story - 撰寫
• 角色-目的-做什麼
• 技巧
– end-to-end
– 不要有相依性
• 合併
• 切割
20

21. User Story - 故事卡
• PO - 重要性(Important)
• Team - 價值(Value)
• Team - 估算(Estimate)
21

22. Sprint可完成Story數
• 團隊速度(Velocity)
– 總工作時數 = 成員總工作天數*每天工作時數
• 團隊承諾(Commitment)
– 直覺
22

23. 點數估算的方法
• 計畫紙牌
– 費式數列(Fibonacci)
– 越大越不準
• 估算都是相對的
23

24. User Story 切任務與對應
24
User Story
相對點數
User Story
相對點數
Task
工時
Task
工時
Task
工時
Task
工時
Task
工時
Task
工時
Task
工時
User Story
相對點數
Task
工時
時間順序
優
先
順
序

25. Product Backlog 到 Sprint Backlog
• 產品負責人管理產品的工具
25
優
先
順
序

26. 產品積壓工作 – 常見問題(1/2)
• 需求討論會議/衝刺討論會議開不完?
– 就給他拖?
• 衝刺討論會議估算點數沒有共識?
– 就給給他沒共識?
• 品質與時間怎麼辦?
– User Story 以業務為主
• 溝通後隱含在 User Story 裡
– User Story 可含非業務
• 四種常見的Story: User, Quality, Technical, Bug Fix
26

27. 產品積壓工作 – 常見問題(2/2)
• 估不準怎麼辦?
– 從估算中學習勝過學習去估算
• PO不滿意某些User Story放不進去Sprint?
– Option 1: 重新設定優先權
– Option 2: 縮小範圍
– Option 3: 拆分故事
27

28. 每日Scrum會議(Daily Scrum) – 介紹
• 一種站立會議(standing up meeting)
• 不超過15分鐘為原則
• 搭配Sprint Backlog, Sprint Goal, 便利貼, 任務板(Task Board), 燃盡圖(Burndown Chart)
• 報告內容
– 昨天做了什麼
– 是否遇到困難
– 今天預計要做什麼
• 目的
– 保持工作進度透明, 提早排除與因應風險
28

29. 環境布置
• 讓團隊坐一起(互相聽到, 互相看到, 隔離)
• 讓產品負責人無路可走
• 讓經理與教練無路可走
29

30. 每日Scrum – 常見問題
• 看Scrum Master報告
• 不聽其他人報告
• 隱惡揚善
• 團隊同仁找不到事情做?
30

31. 衝刺審查(Sprint Review)
• 團隊實際演示給利害關係人看
– 可動的東西比不可動的東西好
– 交付的價值大於完成的工作
31

32. 衝刺回顧(Sprint Retrospective)
• 好(Good)
• 可以更好(Cloud have done better)
• 改善(Improvements)
• 正向力量
– 團隊輪流感謝Sprint幫助自己的一個成員
– 輪一圈後再重新開始(沒有想感謝的就跳過), 直到所有人都沒有要感謝的
32

33. Sprints 修整時刻
• 最糟
• 好一些
• 更好
• 最好?
33

34. Agile Tool
• Redmine + (Scrum Plugin / Agile)
• Visual Studio Online
• Trello
• Jira
• VersionOne
• ScrumWorks
• XPlanner
34

35. 參考資料
• 搞笑談軟工, Teddy
• User Story Mapping, Jen-Chieh Ko, 2012
• Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth S.
Rubin, 2012
• Scrum In Action, Andrew Pham, 2011
• Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore
Product Development with Large-Scale Scrum, Craig Larman, 2010
• Scrum and XP from the Trenches, Henrik Kniberg, 2007
35