l

2012年1月19日 星期四

Scrum 是什麼(8):Sprint Review Meeting

January 19 09:40~10:42

螢幕截圖 2015-06-11 21.33.34

前情題要:


也不知道是那根筋不對勁沒事訂定什麼「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 時如果有需要的話也順便談一點「內幕消息(技術性議題)」應該是可以接受的。

***

***
 
友藏內心獨白:又在逆練九陰真經了

3 則留言:

  1. 請教每個sprint/story額外產生的一些內部技術文件、新的整合測試程式,是適合在平日daily meeting就讓團隊成員有充分掌握嗎?還是在每個sprint結束時,有適合的場合可以發表?

    回覆刪除
    回覆
    1. 您提到的技術文件應該是團隊內部的事,在平常開發的時候就可以交流(例如透過pair programming)。如果需要全部團隊都知道,可以安排開會的task,或是把技術交流的時間附屬在某個task上面,也可以利用sprint結束之後的時間。

      刪除