在軟體開發時, 常常要做的事情太多不知道哪個要先做, 導致團隊無法真的集中火力, 在對的事情上出力.
此外, 就算事情不算太多, 但是因為要做什麼不是很清楚, 導致當初估算不準, 或是想錯需求, 或者是程式的部分比想像中的難搞. 可以我們常常要拖到最後才發現這些事情.
那在 Scrum 中, 有什麼作法可以幫助我們專注, 早點看到問題, 然後早點處理呢? 以下就是最常使用的五大壓箱寶:
(1) Sprint Goal
在 Sprint Planning 會議時, Product Owner(PO) 會和團隊討論出. 這個迭代要達成的目標, 也就是 Sprint Goal. 讓所有人都要了解, 哪些 story 是這次迭代要交付的, 他們的優先順序為何, 對客戶會有什麼影響和價值. 這些是一開始的時候, PO 要跟團隊同步這樣的資訊
(2) AC
在 Sprint Planning 或是 Product Backlog Refinment(PBR) 會議時, 對於要做的 story 的驗收標準, 團隊需要和 PO 一起確認, 一起討論這需求要做成什麼樣, 讓大家一開始對需求內容不要差太遠. 我們會在這兩個會議中對齊一次.
但隨著迭代的進行, 如果開發人員發現有任何問題, 可以再來更新 AC 的內容, 並且即時跟 PO討論, 這些修改或是有疑問的地方, 是否需求就是這樣的. 讓需求的確認可以及時.
(3) Daily Scrum
每天會召開 Daily Scrum, 大家交換彼此遭遇的問題, 需要什麼幫忙, 目前進度如何. 讓所有人對團隊狀況是高度掌握的. 有問題也可以第一時間就開始思考如何處理.
(4) Daily Goal
Daily Scrum 結束前, 大家也可以說說今天要完成什麼, 規劃的部分是否和 sprint goal 是對齊的. 明天 Daily Scrum 時也可以來看一下, 前一天定的目標是否完成. 這招大家比較少見過, 通常是在時程很緊, 不確定很高時, 利用這樣的 goal 來確保大家是做最重要的事.
(5) Demo
每當有一個 story 完成時, 我們就可以先進行 story 的 demo. 找相關的 stakeholder 展示完成的結果, 並且說明是否滿足 DoD 和 AC. 讓雙方的回饋可以第一時間都拿到. 不需要等 Sprint Review 會議才展示, 一方面讓回饋可以更早, 另一方面讓討論時間更充裕.
你看, Scrum 是一個很精心設計的框架. 這中間有多種回饋機制, 讓你不斷地在對齊, 好讓你可以快速反應.
發表迴響