[Day 16] 不要在Sprint Review只做測試啦

問題:
有人期待，Sprint Review就是一個測試大會阿，我們就是透過Sprint Review找到Bug來修。
可是這樣做Sprint Review的時間就會變得很長，也感覺少了一點效率。

我們可以如何有效運用Sprint Reivew的時間?

問題分析:

• 大家覺得測試和"檢視後調整" 有什麼不一樣?
• 測試這個過程還可以在什麼時候做? 誰來做?

SamHuang的看法:
實際上，Sprint Review的重點是用來拿feedback的，不只是拿來測試有沒有符合一開始的需求。
如果只是測試做出來的東西有沒有符合一開始規劃的期待，那我們就把這個會叫 "Sprint Testing" 就ok囉。
Review, 是透過feedback來發現我們之前沒想到、沒規劃到、或不知道的東西。
Feedback有可能來自試用後的新想法，或是發布的功能/產品在市場上的反應。

對策:

1. 再加開一個會，這樣我們就有 "Sprint Testing", 還有 "Sprint Reivew"
2. 停下來，回頭檢查一下團隊的DoD (Definition of Done)，有沒有一條關於功能面測試的東西? 如果沒有，請加上。
3. 實驗看看，所有item測試完之後再進Review, 和都不測試進Review再測試有什麼不同，得到的資訊有什麼不一樣。

選擇對策:
2.3.

執行:
2. 從Definition of Done的演變，也能看出一個scrum team能力的提升。
可能從手動測試，Code Review，自動化測試，到分享item資訊給需要的人來提升產品和服務的品質。
如果團隊能在完成item的時候也一併完成功能面的測試，那跟PO review的時間就可以花在決定下一步或是產生新的想法。
3. 試試看就知道囉，測試完可以透過Retrospective 自省會議來回顧一下團隊的體驗和想法，決定我們下一步要往哪個方向做。