Scrum旨在作爲用於複雜產品交付的簡單但足夠的框架。 Scrum並非萬能的解決方案，靈丹妙藥或完整的方法論。相反，Scrum提供了最小的邊界，團隊可以在這些邊界內使用經驗方法自組織解決複雜的問題。這種簡單是其最大的優勢，同時也是圍繞Scrum的許多誤解和誤區的來源。
誤區：Sprint評論是一個演示
又到了衝刺評審的時候了。開發團隊正在其中一間會議室中進行演示。當Jim將筆記本電腦連接到投影儀時，Susan緊張地重新整理了團隊完成當前Sprint的工作記錄。 "我要展示新的購物車嗎？"她問高級開發人員約翰，聲音有些不確定。約翰點了點頭，然後停頓了一下，加入購物車"。然後，我將顯示新的訂單審覈頁面"。隨着時鐘調到11點，利益相關者開始進到會議室，笨拙地在巨大的桌子周圍找到位置。產品負責人馬麗到達，並在桌頭的一種更舒適的椅子上坐下。她轉向開發團隊併發出Sprint評審開始的信號； "散會"。四十分鐘後，開發團隊評審了已完成項目的清單，並展示了所有值得展示的內容。隨着演示的結束，觀衆向開發團隊致以熱烈的掌聲。當利益相關者離開會議室時，開發團隊鬆了一口氣。 "嗯，這是一次很棒的Sprint評審！"馬麗總結道。
在這篇文章中，我們解決了一個誤區，即"Sprint評審"主要是一個將增量"演示"給利益相關者的機會。
如果您意識到以下的跡象，則適合您：
- 利益相關者很容易與開發團隊區分開，都佔據了自己的房間；
- Sprint評審是採用Powerpoint演示文稿，其中包含(據說)軟件的屏幕截圖；
- 在場的利益相關者均未實際使用或打算使用該產品；
- 利益相關者幾乎沒有任何投入(或者沒有邀請他們參加)；
- 在Sprint評審期間，用於點擊產品的鍵盤和鼠標實際上從未交到利益相關者、用戶的手中，但在開發團隊中卻無可挑剔。
- 演示結束後會鼓掌。更糟糕的是，開發團隊被噓出了房間。
- 開發團隊普遍有緊張感；
- Sprint團隊和利益相關者實際上將Sprint評審稱爲"演示"；
通過將Sprint評審主要作爲演示來對待，失去了進行檢查和調整的重要機會的目的。太多的Scrum團隊將Sprint評審作爲展示進度，提供"產品更新"，向利益相關者出售所構建產品或談論他們所做的事情的時刻。
"太多的Scrum團隊將Sprint評審作爲展示進度，提供'產品更新'，向利益相關者出售產品或談論他們正在做的事情的時刻。"
Sprint評審的目的
《Scrum指南》的描述作爲"在Sprint結束舉行以檢查增量和調整產品待辦事項列表的事件"的Sprint評審。"。這強調在Sprint評審期間，" Scrum團隊和利益相關者就Sprint所做的事情進行協作。基於此以及在Sprint期間對產品待辦事項列表所做的任何更改，與會人員將就可爲實現價值最大化而進行的下一步工作進行協作。"
"在Sprint評審期間，Scrum團隊與其利益相關者之間的合作至關重要"
換句話說，在Sprint評審期間，Scrum團隊與其利益相關者之間的合作至關重要。在Scrum中，我們瞭解到產品開發是一項複雜的活動。在進行工作時，我們要解決的問題和最佳解決方案都會從我們在開發過程中所學到的知識中浮現出來。 Sprint評審是Scrum中的關鍵機遇，它可以通過讓已完成的工作中產生見解並在其基礎上爲後續步驟提供意見來使其成爲可能。
Sprint評審旨在使產品的狀態(增量)和產品待辦事項透明。然後，Scrum團隊和利益相關者對這兩者進行檢查，並分享從該檢查中學到的知識。連同當前的市場狀況，組織變更，預算和時間表，他們共同決定下一步。 Sprint評審的輸出包括根據所學知識對產品待辦事項進行的調整。從某種意義上說，Sprint評論旨在回答以下問題："根據我們學到的Sprint的知識，下一步是什麼？"這爲Sprint計劃提供了寶貴的意見。
好的Sprint評審具有以下特徵：
- 利益相關者和開發團隊的成員與局外人是無法區分的；
- 積極邀請參與者提供反饋、建議和想法；
- 產品待辦事項在Sprint評審中佔有重要位置，並隨着新見解的出現而積極調整；
- Sprint評審不是將開發團隊向產品負責人介紹增量，而是整個Scrum團隊(包括產品所有者)與利益相關者分享增量；
- 產品負責人討論產品待辦事項，並根據進度傳達可能的完成日期；
小提示
- 在開始之前，請重申Sprint評審的目的。請確保人們瞭解此次活動是關於收集反饋並共同解決複雜問題，而不是"銷售產品"或"接受已完成的工作"；
- 要求開發團隊成員與利益相關者"結對"並一起檢查增量。不要讓開發人員在平板電腦，筆記本電腦或臺式機上演示增量，而是將鍵盤/設備交給利益相關者，讓他們在開發人員的指導下進行實驗；
- 避免使用Powerpoint或屏幕截圖檢查增量狀態。實際操作軟件是驗證開發人員、用戶和其他利益相關者的假設和解釋的最佳方法。
- 確保所有開發人員都參加Sprint評審。 Sprint評審是一個理想的機會，可以在Sprint期間收集有關開發人員改進/規模化/更新的產品反饋。最好的情況是，Sprint評審是與真正參與Scrum團隊進度並渴望看到和討論結果的利益相關者一起進行的一次活動。
- 使用有效的格式，不要坐在桌子旁看着屏幕。使用引導技巧讓所有參與者積極參與。
- Sprint評審應該是一個"反饋方"，而不是開發團隊在其他人都昏昏欲睡時瀏覽"完成的工作"清單。
- 邀請真實用戶參加Sprint評審。這些是(將)實際使用產品的人員，最有能力確定產品是否"效果良好"。不過，請儘量避免將Sprint評審轉變爲"用戶接受測試"；
- 更改格式。根據上下文更改Sprint評審的格式。有時，最好設置不同的"市場攤位"，在這些攤位中，開發人員會設置爲突出產品的特定方面。有時，集中演示並隨後進行便利的討論最爲有效。 Scrum團隊應不斷尋找從利益相關者那裏收集反饋的最佳方法；
- 在閉幕式中，請參與者根據進展如何做(進一步)提高Sprint評審的價值；
- 通過電子郵件，新聞通訊或個人邀請各種方式來邀請參加者，說明參加者爲何如此重要的原因；
- 對未完成的工作要公開透明。並非所有的Scrum培訓師都同意，共享未完成的工作是一個好主意。因爲這可能會產生錯誤的期望。但是我們認爲，檢查未完成的工作可以產生寶貴的見解。它可以告訴我們一些有關障礙，瓶頸或其他問題的信息。在Sprint評審期間着重於確定這些問題，但將其解決方案留給Sprint回顧；
結束
在這篇博客文章中，我們打破了"Sprint評審"是關於將增量增量演示給利益相關者的誤區。儘管演示當然可以成爲Sprint評審的一部分，但它無法捕獲Sprint評審的真正含義：Scrum團隊和利益相關者之間的合作，以檢查迄今爲止的增量和進度，並確定最有價值的下一步。
討論區
-
你的Sprint評審是如何進行的？
-
有邀請利益干係人嗎？
-
您如何看待這個誤區？
-
您是否認識到Sprint評論不僅僅是一個演示？
-
您學到了什麼？
歡迎留言討論。
本文首發於 Bob Jiang的博客 ，轉載請聯繫 Bob Jiang