Introduction SCRUM

1. SCRUM
V0.1
Author: 呂宗螢

2. Outline
• Introduction
• History
• Software Engineering
• Waterfall Model
• Agile
• SCRUM Role
• SCRUM Activity
• SCRUM Process
• SCRUM Artifact
• Spiral Model vs Agile Model
• Conclusion

3. Introduction
• Software engineering.
• A kind of Agile.
• Scrum is an iterative and incremental agile software
development framework for managing product
development.
• Management and Control Process.

4. History
• 1986 年，竹內弘高和野中郁次郎闡述了一種新的整體性的方法
，該方法能 提高商業新產品開發的速度和靈活性夠
• 1991 年， DeGrace 和 Stahl 在《 Wicked Problems,
Righteous Solutions 》一書中將這種方法稱為 Scrum ，在竹內
弘高和 野中郁次郎的文章中提到的橄欖球術語。
• 1990 年代初，肯 · 施瓦伯在其公司使用了一種方法 Advanced
Development Methods( 先進開發方法 ) ，這種方法後來發展為
Scrum 。同時，傑夫 · 薩瑟蘭在 Easel 公司開發了一種類似的
方法，並首次稱之為 Scrum 。
• 1995 年，在奧斯汀舉辦的 OOPSLA '95 上，薩瑟蘭和施瓦伯
聯合發表了論文首次提出了 Scrum 概念。施瓦伯和薩瑟蘭在接
下的幾年裡合作，將上述的文章，他們的經驗，以及業界的最佳
實踐融合起來，形成我們現在所知的 Scrum 。
• 2001 年，施瓦伯與麥克 · 比竇 (Mike Beedle) 合著了《敏捷軟
體開發 - 使用 Scrum 過程》一書，介紹了 Scrum 方法。

6. Software Engineering
Goal

7. Software Engineering
• Validation
• Are we building the right system?
• Verification
• Are we building the system right?

8. Performance
Value
Quality
Do the right things
Do the things right
Do the right things &
Do the things right
GG!

9. Waterfall model
If failed!?

10. Agile Software Development
• 是一種應對快速變化的需求的一種軟體開發能力
• Iterative, incremental and evolutionary
• Efficient and face-to-face communication
• Very short feedback loop and adaptation cycle
• Quality focus
• Specific tools and techniques, such as continuous integration,
automated unit testing 、 pair programming 、 test-driven
development 、 design patterns 、 domain-driven design 、 code
refactoring and other techniques are often used to improve quality and
enhance project agility.

11. The Agile Manifesto
• Individuals and interactions over Processes and tools
• Working software over Comprehensive documentation
• Customer collaboration over Contract negotiation
• Responding to change over Following a plan

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

13. SCRUM Process

14. SCRUM Core Role
• Product Owner (PO or Product Manager, PM)
• Scrum Master (SM)
• Developer

15. Product Owner (PO)

16. Product Owner (PO)
• 利益相關者和客戶代表人
• 定義產品的需求
• Story 的形式把產品需求寫出來
• 決定施工順序
• 要負責回答問題與釐清需求
• 擔當產品成敗責任

17. Story
• Scenario
• EX ：我是個學生，我可以看到老師上傳的上課教材
• Story Point
• 用來估算 Story 大小
• 相對的
• EX ：一天 8 小時為 1 story point or 一天 5 小時為 1 story point
• 或直接使用時數來做

18. Scrum Master (SM)

19. Scrum Master (SM)
• 依循 Scrum 的精神來運作軟體開發流程
• 排除任何阻礙開發活動的事件

20. Developer

21. Developer
• 負責實作
• 3-9 individuals
• Cross-functional team
• analyse, design, develop, test, technical communication,
document, etc.
• EX ：設計 UI 的人也能 寫點程式，寫程式的人也能 操作資料庫夠 夠
或是做 UI 端的程式設計等等。

22. Ancillary Role
• Stakeholder
• Customer 、 Vendor
• Manager
• Boss

23. Activity
• Spring Start
• Sprint planning meeting
• Spring Running
• Sprint
• Daily Scrum
• Spring End
• Sprint review meeting (demo)
• Sprint retrospective meeting

24. Sprint Planning Meeting
• Sprint 開始前會議
• PO 、 SM 與 Developer 參與
• 限制 8 小時
• 定義 Sprint 目標
1.解說 story 要做什麼
2.挑選這個 Sprint 所要開發的 Stories
3.將每一個 stories 細分為若干個 task ，並且估算完成每一
個 task 所需的時間 (hr)
4.產生 Spring Backlog

25. Sprint
• 實作
• 2-4 週 ( 可自定 )

26. Daily Scrum
• Developer
• 每日站立會議
• 約 15 分鐘
• 報告進度
1. 昨天做了那些事 ?
2. 今天準備做了那些事 ?
3. 遇到任何問題 ? (Any impediments/stumbling blocks)
• 目的了解進度及解決會阻礙進度的問題

27. 大部分人想像的工作進度

28. 學生症候群 (Student Syndrome)

29. Sprint Review Meeting
• Sprint 結束時會議
• PO 、 SM 、 Developer( 可邀請輔助角色 )
• 限制 4 小時
• Demo 此 sprint 所完成的 story
• PO ( 客戶 ) 確認這些 story
• 是否符合需求 ?
• 是否還需要改進 ?
• 激發新想法
• 目的改善產品符合需求 (Validation: Are we building the
right system?)

30. Sprint Retrospective Meeting
• Sprint 結束時會議
• SM 與 Developer (PO 亦可 )
• 限制 3 小時
• 檢討與改善『軟體開發流程』
• 好的 ? 不好的 ? 沒做到的 ?
• 如何改善 ?
• 目的改善流程及增進 Coding 品質 (Verification: Are we
building the system right?)

31. SCRUM Process
Daily Scrum
Sprint Planning Meeting
Sprint review meeting (demo)
Sprint retrospective meeting

32. Artifact
• Product backlog
• 產品的完整需求規格
• Sprint backlog
• 一個 sprint 準備施工的 stories
• Burndown chart
• Sprint summary report
• 完成多少個 story points
• 列出好的以及有待改善的項目，以及改善計畫。
• Working software
• 可以動的系統

33. Burndown Chart
EX: 5 個人 * 一天工作 8 小時 * 共 5 個工作天 = 200 小
時

34. Spiral Model vs Agile Model

35. Spiral Model vs Agile Model
Prototype 1 Prototype 2
Sprint 1
Sprint 2
Sprint 3
Product
Sprint
planning
meeting
Running &
Daily meeting
review meeting (demo)
retrospective meeting

36. Conclusion
• 應對快速變化的需求，不斷的調整
• 重視 Customer 、 PM 、 RD 溝通
• 成員及流程都需要自我調整及進化
• 時間管理
• 沒有銀彈

37. Reference
• http://en.wikipedia.org/wiki/Scrum_(software_developmen
t)
• http://en.wikipedia.org/wiki/Agile_software_development
• http://teddy-chen-tw.blogspot.tw/
• 敏捷開發法的逆襲
• http://www.easterbrook.ca/steve/2010/11/the-difference-
between-verification-and-validation/
• http://www.agilemanifesto.org/principles.html
• http://en.wikipedia.org/wiki/No_Silver_Bullet
• 專案管理與創意的冰與火之爭