Jeff Sutherland 提到 Scrum 基本的想法：(1) 經常檢查你的方向是否正確, 你做的東西是否是客戶要的? (2) 是否有任何方法, 可以改進目前作法, 讓你更快更好. 由此可以知道, Scrum 中最重要的部分之一是在於, 利用 Scrum Review 會議展現每次迭代的增量, 讓客戶看看這是不是他要的, 然後根據回饋來及時調整.
在 2017 Scrum Guide 中, Sprint Review 會議的重點如下：
參與者包含 Scrum團隊和產品負責人邀請的主要利害關係人；
● 產品負責人解釋哪些產品待辦事項已經「完成」，與哪些尚未「完成」；
● 開發團隊討論在短衝中進行順利的事項，遇到那些問題與及這些問題如何被解決；
● 開發團隊展示已「完成」的工作並回答關於增量的問題；
● 產品負責人討論目前的產品待辦清單的現況，他/她（視情況而定）根據到目前為止的進度來預測可能的的交付日期；
● 整個團體協同合作來決定下一步要做什麼，所以短衝檢視會議提供了有價值的資訊給接下來的短衝規劃會議當作輸入
在 2020 Scrum Guide 中, 就寫得比較簡短, 描述如下：
在這個事件中，Scrum Team 與利害關係人（stakeholders）回顧在 Sprint 中完成的成果，以及環境發生了什麼變化，基於這些資訊，與會者對接下來要做什麼進行協同合作，也可調整 Product Backlog，藉此來掌握新的機會。Sprint Review 是一個工作會議，Scrum Team 應避免將其限於投影片展示。
由上面可以知道, 在 2020 Scrum Guide 比較偏向描述要做什麼, 不多談怎麼做的細節. 它把怎麼做給團隊去發揮. 但是我們可以知道 Sprint Review 會議主要在處理這些事情
(1) 規劃的執行狀態分享
(2) 和與會者以互動方式展示已完成的需求
(3) 根據與會者回饋調整 Product Backlog
一開始要說明這次迭代中, Sprint Goal 是什麼, 預計要做什麼需求, 目前已經完成哪些需求. Goal 和要做的需求還是要跟與會者對齊. 確認大家是否一致, 看看大家是否有溝通上的落差.
接著就是展示已完成的需求. 要提醒大家的, 我們只展示已完成的需求, 對於未完成的需求不需要展示, 避免與會者或是利害關係人誤會, 以為這些東西已經好了差不多, 這些未完成的需求可能還需要相當多的時間才做得完. 另一件要注意的事, 展示不該只是用投影片來說明, 這樣只是單向溝通, 效果不會很好, 大家很容易聽過就忘, 印象不會很深刻. 最好能夠以雙向來進行. 互動式的作法, 我們在後面會跟大家介紹.
最後, Sprint Review 還有個重點是要根據回饋來調整 Product Backlog, 也就是要有些行動方案出現. 很多時候大家只在意 demo, 在展示完後與會者給了很多意見, 當下很興奮很高興, 可是後續卻沒有任何行動, 這樣只做了一半事情. 因此, 需要記得馬上調整 Product Backlog, 把合適的回饋加進去, 跟大家同步這樣的改變, 讓團隊和利害關係人都知道.
常見的互動式展示需求的方式, 有以下幾種：
(1) 市集 (review-bazaar)
圖片來源: https://less.works/img/framework/sprint-review-bazaar-sketch.png
市集這個想法是 LeSS 中一個很特別的點子. 建議把 sprint review 變成展覽會一樣來舉行. 每個攤位會展示一個或是多個完成的需求. 團隊成員和相關的利害關係人, 可以自行前往有興趣的攤位去看看.
進行的流程如下
(2) 交換展示
當你要展示某些完成的需求時, 一般來說都是讓開發這個需求的人去展示, 或者是要測試這個需求的人去展示. 這邊我們可以用不一樣的作法, 讓不是開發這個需求的人去展示. 這樣的作法有幾個好處:
a. 互相學習
LeSS 認為 Sprint Review 不該只是展示功能和調整 product backlog 而已. 更重要的這是一次學習的機會, 讓你可以看看不同人所做的需求是什麼, 學習如何安裝環境, 思考要準備什麼展示資料, 以及用戶會如何使用這個需求. 另外, 這個需求和你知道的部分有什麼關聯, 哪些地方會影響到.
b. 換位思考
如果是讓原先開發或是測試這個需求的人來展示, 因為他們都是一直在接觸這個需求, 雖然是比別人知道的更多, 但是想法上可能會固定在某個範疇中. 藉由另外一批人來展示, 原先那批人可以看到別人是怎麼想這個需求的, 藉由不同的觀點, 可以觸發你更多想法.
當然這樣做的缺點, 你會需要較多的準備時間. 那些另一批人需要時間去準備和瞭解, 可能會詢問原先接觸的人很多問題. 對於這樣的投資你可以想想是否可行或是值得的.
(3) Bug Bash
什麼是Bug Bash, 在wiki中的解釋是這樣的 (http://en.wikipedia.org/wiki/Bug_bash)
Bug bash is where all the developers, testers, program managers, usability researchers, designers, documentation folks, and even sometimes marketing people, put aside their regular day-to-day duties and pound on the product to get as many eyes on the product as possible.
就是每個人放下手邊的工作,這段時間進行測試, 找出具有潛在性的bug, 例如UI 那裡不好用,需要重新設計! 或是哪些error handling不盡理想. 找到越多越好,寧可錯殺, 也不要放掉一個! 每個人需要浴血奮戰, 絞盡腦汁在有限的時間找出bug.
要鼓勵各部門, 不同角色, 或是不同領域交叉搜索,因為新的思路和角度通常有助於發現更多的Bug
儘管這是一個測試活動，但參與者並不僅限於測試人員。專案經理，開發人員甚至於高層管理人員都應參加，如同全民動員。目的是要集思廣益. 不一定針對全部的功能, 可以針對某一部份,某個主題(某各特別的或是重要的功能, 效能, 安全性、使用者界面可用性、國際化和本地化等) 或是某個人做的功能去做測試.
如果必要的時候, 需要加一些獎勵, 來鼓勵來找到最多bug或是最有價值bug的人.中間還可以供應點心, 讓大家能全新全意致力於找bugs
在 Sprint Review 中, 可以用這樣的模式, 讓所有與會者花個 30 分鐘, 大家一起來測試這個迭代所完成的需求, 這中間可以準備些飲料, 並且利用競賽和獎品, 讓大家對新功能可以實際使用一段時間, 並且在競賽和獎品的的催化下, 促使大家可以更深入的探索, 不會光只是很表面的試試而已.
以下是常見的流程：
a. 活動目的介紹
說明這次活動的重點. 不一定要廁所有已完成的功能, 可以針對最重要的需求. 或者是某種類型的問題深入探索.
b. 說明如何記錄
Bug Bash 中如何記錄找到的問題是個關鍵, 如何讓參與者容易記, 願意記, 是這個活動成功的關鍵之一.
c. 獎勵介紹
為了增加大家的動機, 適當的獎勵是需要的.
d. 進行測試
e. 統計成果
f. 公佈成績和總結
時間足夠的話, 可以邀請參與者分享一下, 這個過程中找到比較精彩難忘的 bug.
(4) Mob Testing
什麼是 Mob Testing呢? 它是一種軟體測試設計技術, 由一組測試人員一起來測試某個軟體. 在這種形式的測試中, 有兩個主要角色：
a. 司機
在測試過程中，通常由一個人操作電腦, 這個人被稱為“司機(driver)”. 其他的人設計測試個案, 並觀察測試結果.
b. 領航員
導航員 (pilot)提出建議, 告訴 driver 要測什麼, 然後觀察測試過程並提供反饋.
一段時間後，driver的角色轉換到另一個人身上, 讓每個人都有機會擔任這個角色.
暴民測試的目標是利用不同的觀點和交流來提高軟件的品質. 每個人都有自己的專長, 作為一個團隊一起工作, 可以讓大家更快地發現和解決問題.
暴徒測試很重要有幾個原因，包括：
a. 更快地識別問題
通過在一起協作測試的過程中, 結合不同測試人員的知識、技能和經驗,可以更快地識別和解決問題。
b. 改善團隊成員之間的溝通
促進團隊成員之間的溝通和協作,防止任何錯誤傳達或誤解.
c. 提高效率
可以提高測試效率. 因為識別和解決問題所需的時間更少.
d. 更好團隊建設
這個測試活動促進團隊合作，可以加強團隊成員之間的關係.
從以上這些方法中, 你可以知道 LeSS 的精神都不是希望一個單向溝通, 你說我聽, 沒有互動的作法. 他會希望藉由雙向的交流, 讓問題或是意見可以被充分的討論, 讓大家的聲音可以被聽見, 這樣大家才會更想去貢獻自己的想法, 讓團隊朝著更好的方向成長.
iThome鐵人賽
看影片追技術
