敏捷誤區！Sprint評審的誤區 | 真不是演示會 demo show

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