[讀書心得] 告別瀑布擁抱 Scrum

原本想自己畫一張圖來說明，不過網路上已經看到很棒又很宅的說明圖，就直接引用了。

先說明一下角色：

• 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 就做調整。

個人感覺最大優點有幾個：

• 理論上每個 Sprint 完，都應該有個可以動的東西（雖然功能可能不足）讓客戶看到並反饋，再根據客戶反饋來修正或修改需求，而不用等到第一次正式交付才發現我做的不是你要的。
• 開發成員眼前的目標就是這個 Sprint 的工作，而 PM 要保證這個 Sprint 內都不會有變動也沒人會去打擾開發成員。有變動沒關係，下個 Sprint 再說，如此開發人員有個節奏，而不是永遠做不完的死亡行軍。