Scrum 是什麼（8）：Sprint Review Meeting

January 19 09:40~10:42

前情題要：

• 〈Scrum 是什麼（1）：雙重回饋機制〉
• 〈Scrum 是什麼（2）：Scrum 的內涵〉
• 〈Scrum 是什麼（3）：三種補充文件〉
• 〈Scrum 是什麼（4）：Product Backlog〉
• 〈Scrum 是什麼（5）：初探 Sprint Planning Meeting〉
• 〈Scrum 是什麼（6）：Sprint Planning Meeting 眉角〉
• 〈Scrum 是什麼（7）：Daily Scrum〉

也不知道是那根筋不對勁沒事訂定什麼「2012 年每天寫一篇部落格文章」的目標，現在想一想真的是頭殼壞去。前幾天赫然發現，農曆新年快到了耶，還是要寫（當初「許願」的時候怎麼沒把這點考慮進去啊...Orz）。到底能不能撐過第一個月都還不知道，算了，撐一天算一天，反正最近瘦了2-3公斤，還有一點食言而肥的本錢...XD。

剛剛想了老半天也擠不出什麼新東西出來，那今天就來談一下 Sprint Review Meeting 好了。這個會議有兩種可能的開法：

正常版本

• 團隊中有專職的 Product Owner。
• 在 Sprint Review Meeting 時 Product Owner 、Scrum Master、Developers 都必需要參加，最好也邀請stakeholder 一起參與並提供意見。
• 會議可由 Product Owner、Scrum Master 或是協調一位團隊成員主持。
• 會議前一天 Scrum Master 要先 email 一份 Sprint review agenda 給與會人員，範例如下（或參考「Scrum 是什麼（3）：三種補充文件」）：

• 會議前一天負責示範的人要花點時間準備（不要為了review花太多時間，最多最好不要超過 1-2 小時），千萬不要沒準備然後當場才發現要展示的功能都不能動。
• 會議開始時，主持人（Product Owner、Scrum Master或是Team都可以） 說明一下這個 sprint 的目標，然後依據會議議程逐一請相關人等展示功能。例如：
  • 主持人：「大家好，歡迎參加 E-Com 團隊第 5 個 sprint 的 review。我們已經完成了這個 sprint 的目標 xxxx，現在開始 sprint review會議。第一個 story 是 yyy，我們先請 David 示範一下這個功能要如何使用」。
  • David：...（開始展示這個功能）（在展示過程中，如果與會者有問題可以隨時發問）。
  • David：（展示結束）
  • Scrum Master：各位關於這個功能還有沒有其他問題？如果沒有的話我們謝謝 David，接下來請 Tim 展示這個功能的測試結果。
  • Tim：....
• 主持人要幫忙注意每一個展示項目所花的時間，並且要避免與功能無直接相關且過於冗長的討論。
• Product Owner 或是 stakeholder 如果對於功能不滿意，或是有修正意見，可以當場反應給 Developers 了解。至於後續要如何修改的細節，則不需要在會議中討論。
• 如果經費許可團隊可以準備一些零食給與會者享用，可以把 sprint review當成是一個小小的「驗證與慶功場合」...當然如果團隊要是連一個 story 都沒有完成那就另當別論了...XD。

異常版本

 

• 團隊中有沒有專職的 Product Owner（由其他團隊成員兼任），或是團隊在開發一個新產品，Product Owner 也正在摸索需求（翻成白話文就是 Product Owner 也還搞不太清楚狀況...Orz）。
• 會參加 sprint review會議的人（包含圍觀鄉民）大多是比較偏技術的開發人員。
• 其他內容與前述正常版本都很像，但是在異常版本中，sprint review的項目可能還會包含「施工的 tasks」。也就是說，正常版本的review比較像是「black-box review」，與會人員只關心每一個做完的 story 要如何使用以及是否真的做完，不去管 Developers 倒底是如何做完這些 stories。而異常版本的review比較像是「black-box  + white-box review」，除了包含正常版本的review內容以外，團隊也可能會利用機會review技術性的 tasks，例如「database schema design」、「新的 DAO 」、「某某 bug 如何解決」等。

 

***

為什麼會有兩種不同的 sprint review 進行方式？照道理講應該是只有第一種正常版本，只要review功能如何使用以及讓 Product Owner 「驗收」這些功能這樣就可以了。但是實務上有些團隊所面對的問題（專案）在某些階段技術細節相當程度會決定專案的成敗 ，或是團隊想利用「大家都在」的機會「快速」同步一下一些技術性的核心議題（與會者可能大多是技術背景的人）。在這種情況下，在 sprint review 時如果有需要的話也順便談一點「內幕消息（技術性議題）」應該是可以接受的。

***

下一集：〈Scrum 是什麼（9）：Retrospective Meeting〉

***

 

友藏內心獨白：又在逆練九陰真經了。