iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 17
0
Software Development

團隊導入Scrum會遇到的30個問題系列 第 17

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

[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 自省會議來回顧一下團隊的體驗和想法,決定我們下一步要往哪個方向做。


上一篇
[Day 15] 我們的item做完了嗎?
下一篇
[Day 17] Sprint Retrospective 已經沒什麼好說的了
系列文
團隊導入Scrum會遇到的30個問題30

尚未有邦友留言

立即登入留言