![[ 小黑宅 ]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjmj8WPlai5Sm3WwgojjMZ6gskRvSKGQJoJLSBz9-7VBEBuc_zkmYiGRwSMmvUr9UYsit7rvEXLajK7U4NoPeoLCwOc8UdlUzkj6wx-m19KR_TAoVPMaPk_bvUSQxyQ-HltWbOjm2gEbk5I/s1600-r/logo.png){kind=logo}
原本想自己畫一張圖來說明，不過網路上已經看到很棒又很宅的說明圖，就直接引用了。
先說明一下角色：
- Product Owner：就是 PM，客戶需求與開發團隊的橋樑，確認做出來的東西是不是客戶想要的。
- Scrum Master：熟悉 scrum 的人，了解 scrume 流程要做些什麼，有哪些 scrume 工具（ex：看板，燃盡圖...etc）可以用。
- Team：就是實際在開發的開發成員啦。
接下來就直接看圖說故事了。
圖片來源：http://www.scrumprimer.org/en/anime
整個流程可以分成三大塊：
- Sprint 計畫會議（上圖左）
- 類似 kick-off 會議，Product Owner 將客戶需求說明給大家聽，由開發成員把需求轉化成工作清單。
- 決定第一個 Spirit 的工作清單。
- 會議時間不超過一天。
- 每個 Sprint（上圖中）
- 一個 Sprint 為一週 ~ 一個月。
- 每個 Sprint 的目標就是完成該 Sprint 的工作清單。
- 每日立會
- 昨日完成哪些工作。
- 今日預計要完成哪些工作。
- 讓別人知道遇到那些困難，會後就可以討論。
- 每日立會時間不超過15分鐘。
- Product Owner 要保證不變動目前在開發的需求，所有變動都等到這個 Sprint 完再說。
- 每個 Sprint 結束後（上圖右）
- 檢視會議
- 檢視目前的專案狀況。
- 完成的工作。
- 沒完成的工作。
- 新增加的需求。
- 決定下個 Sprint 的工作清單。
- 決定是否要繼續執行專案。
- 回顧會議
- 針對開發流程做討論。
- 預估 SKD 是否準確，為什麼？
- 哪些流程工具需要改進。
- 兩個會議時間加起來不超過一天。
個人感覺最大優點有幾個：
- 理論上每個 Sprint 完，都應該有個可以動的東西（雖然功能可能不足）讓客戶看到並反饋，再根據客戶反饋來修正或修改需求，而不用等到第一次正式交付才發現我做的不是你要的。
- 開發成員眼前的目標就是這個 Sprint 的工作，而 PM 要保證這個 Sprint 內都不會有變動也沒人會去打擾開發成員。有變動沒關係，下個 Sprint 再說，如此開發人員有個節奏，而不是永遠做不完的死亡行軍。
Open Source Initiative
