敏捷開發與Scrum

1. 敏捷開發與Scrum
By 黃升煌

2. 軟體開發現況

3. 一句話惹火工程師
• 這改一下就好啦
• 這應該很簡單吧
• 幫我加十個功能，明天就要，拜託
• 你就大概弄一個，讓我參考看看
• …
3http://buzzorange.com/2015/01/22/10-things-to-teach-you-how-annoyed-engineer/
◢▆▅▄▃崩╰(〒皿〒)╯潰▃▄▅▇◣

4. 傳統瀑布式開發方法
4

5. 傳統瀑布式開發方法
• 一次談好需求
 說好了就不可以改變喔(ﾟ∀ﾟ)
• 一次做好設計
 設計時需求變更，請重新設計(|||ﾟдﾟ)
• 一次寫好程式
 寫程式時時需求變更，請重新設計後再改寫程式(#`皿´)
• 一次完成測試
 三個月後才測試三個月前寫的程式有bug，程式早就不好改了(／‵Д′)／~ ╧╧
 測試時才想到新的需求，請回到步驟一…
5◢▆▅▄▃崩╰(〒皿〒)╯潰▃▄▅▇◣

6. 6

7. 軟體開發的現實
• 軟體是軟的，當然應該要更容易改變
• 凍結需求是不可能的
• 因為需求永遠都有可能變動，所以甘特圖、時程預估永遠都不準確
• User永遠不知道他們要的是什麼(總是要看到東西才有感覺嘛)
• 瀑布式開發流程不是不好，但應該用在需求變動不大的專案(但軟體專案沒有固定
需求這回事)
7

8. 8

9. 敏捷開發

10. 什麼是敏捷？
• 敏捷可以讓開發軟體速度更快
• 敏捷可以讓大家都不用加班
• 敏捷可以不用花時間跟客戶溝通就寫出讓客戶滿意的產品
• 敏捷可以不用再花時間寫一堆的文件了
• …
10

11. 敏捷宣言
• 藉著親自並協助他人進行軟體開發，我們正致力於發掘更優良的軟體開發方法。
透過這樣的努力，我們已建立以下價值觀:
• 個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商
回應變化 重於 遵循計劃
• 也就是說，雖然右側項目有其價值，但我們更重視左側項目。
11http://agilemanifesto.org/iso/zhcht/

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

13. 到底什麼是敏捷？
• 敏捷是一種心態
• 從心態開始保持敏捷
• 重視人與人的溝通互動
• 重視真正可用的軟體
• 重視合作
• 擁抱變更
13

14. Scrum

15. 什麼是Scrum
• 傳統瀑布式：預測型流程
• Scrum：經驗型流程
• 敏捷是心態、Scrum是心法
• 沒有100%正確的方法
• 活的、有彈性的開發流程
15

16. Scrum精神
• 歡迎變更
• 迭代式開發
• 各司其職
• 持續改善
16

17. 迭代式開發
17

18. 各司其職
• Scrum角色
 產品負責人(Product Owner)：定義產品需求，負責產品成敗。對需求優先順序有最高決
定權。
 Scrum Master：協助並確保團隊以Scrum精神進行工作，並排除任何阻礙開發工作的障
礙，確保團隊工作效能。
 Team Member：負責專案開發工作，團隊成員應為跨職能團隊。團隊包含所有能完成專
案需要能力的人才。
 Stakeholder：其他與專案相關但沒有直接參與專案的人。
18

19. Scrum流程
• 將需求拆解成若干個product backlogs
• 規劃每個sprint要完成的backlog item，及backlog item的切確需求、story point
• 在每個sprint中，每日進行daily scrum
• Sprint結束後，交付每階段可用的產品及demo meeting
• Sprint結束後，進行retrospective meeting，檢討流程需要改善的部分
19

20. 20

21. 21

22. 持續改善
• Daily scrum meeting：每日簡短會議，明白團隊遇到的問題以及阻礙。
• Retrospective meeting：每個sprint結束後進行檢討，並討論下個sprint該如何
調整。
22

23. Scrum預估時程─燃盡圖
23

24. Scrum預估時程─累積流量圖
24

25. Scrum流程優點
• 除了基本的流程以外，不死板決定方法，100個scrum團隊會有100種特色
• 藉由短時間的sprint循環，持續交付可用產品
• 藉由每次retrospective meeting，改善團隊開發遇到的問題
• 開發過程將變的更具有可預測性
25

26. Demo
使用TFS2015

27. Q&A