2015年1月8日 星期四

[讀書心得] 告別瀑布擁抱 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 再說,如此開發人員有個節奏,而不是永遠做不完的死亡行軍。

0 則回應:

Related Posts Plugin for WordPress, Blogger...