[SCRUM] Scrum 是什麼（8）：Sprint Demo Meeting－Foxbrush

From: http://teddy-chen-tw.blogspot.tw/2012/01/scrum-7sprint-demo-meeting.html

==============================================

那今天就來談一下 Sprint Demo Meeting 好了。這個會議有兩種可能的開法：

正常版本

團隊中有專職的 Product Owner。
在 Sprint Demo Meeting 時 Product Owner 、Scrum Master、Developers 都必需要參加。
其他閒雜人等如果想過來看戲也是可以，但是「理論上」這些圍觀的鄉民們是不能發言的。
會議可由 Scrum Master 或是協調一位團隊成員主持。
會議前一天 Scrum Master 要先 email 一份 Sprint demo (review) agenda 給與會人員，範例如下（或參考「Scrum 是什麼（3）：三種補充文件」）：

會議前一天負責 demo 的人要花點時間準備要 demo 的內容（不要為了 demo 花太多時間，最多最好不要超過 1-2 小時），千萬不要沒準備就跑來 demo 然後當場才發現要 demo 的功能都不能動。
會議開始時，Scrum Master 說明一下這個 sprint 的目標，然後依據會議議程逐一請相關人等 demo。例如：

Scrum Master：「大家好，歡迎參加 E-Com 團隊第 5 個 sprint 的 demo。我們已經完成了這個 sprint 的目標 xxxx，現在開始 sprint demo 會議。第一個 story 是 yyy，我們先請 David 示範一下這個功能要如何使用」。
David：...（開始 demo 這個功能）（在 demo 過程中，如果與會者有問題可以隨時發問）。
David：（demo 結束）
Scrum Master：各位關於這個功能還有沒有其他問題？如果沒有的話我們謝謝 David，接下來請 Tim demo 這個功能的測試結果。
Tim：....

Scrum Master 要控制一下每一個 demo 項目所花的時間，並且要避免過於冗長的討論。
Product Owner 如果對於功能不滿意，或是有修正意見，可以當場反應給 Developers 了解。至於後續要如何修改的細節，則不需要在會議中討論。
如果經費許可團隊可以準備一些零食給與會者享用，可以把 sprint demo 當成是一個小小的「驗收與慶功場合」...當然如果團隊要是連一個 story 都沒有完成那就另當別論了...XD。

異常版本

團隊中有沒有專職的 Product Owner（由其他團隊成員兼任），或是團隊在開發一個新產品，Product Owner 也正在摸索需求（翻成白話文就是 Product Owner 也還搞不太清楚狀況...Orz）。

會參加 sprint demo 會議的人（包含圍觀鄉民）大多是比較偏技術的開發人員。
其他內容與前述正常版本都很像，但是在異常版本中，sprint demo 的項目可能還會包含「施工的 tasks」。也就是說，正常版本的 demo 比較像是「black-box demo」，與會人員只關心每一個做完的 story 要如何使用以及是否真的做完，不去管 Developers 倒底是如何做完這些 stories。而異常版本的 demo 比較像是「black-box + white-box demo」，除了包含正常版本的 demo 內容以外，團隊也可能會利用機會 demo 技術性的 tasks，例如「database schema design」、「新的 DAO 」、「某某 bug 如何解決」等。

***

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