Sprint Review 到底是迭代評審會,還是功能演示會?

語言: CN / TW / HK

迭代結束前,敏捷團隊通過Sprint Review,向關鍵干係人展示其工作結果和目標完成進度,檢查已交付的價值增量,並結合反饋確定或調整未來的產品規劃和待辦列表。

依據敏捷聯盟的描述,Sprint Review的與會人包括Scrum團隊(產品負責人、Scrum Master和研發團隊),以及產品負責人邀請的關鍵干係人;會議的一般流程如下:

  • Scrum團隊說明產品待辦列表中哪些專案已經/尚未完成
  • 開發人員討論在迭代期間達成的進展、遇到的問題以及其解決方案
  • 開發人員展示已經完成的工作,並回答關於價值增量的問題。
  • 產品負責人討論現有的產品待辦列表,並根據目前的專案進展預測可能的目標和交付日期(如果需要的話)。
  • 敏捷團隊合作討論下一步怎麼做,Sprint Review要為後續的迭代提供有價值的意見。
  • 審查產品或市場環境的變化,分析可能對下一步要做的最有價值的事情產生的影響。
  • 討論即將釋出的版本的產品功能,審查時間表、預算、潛在功能以及市場變化。

不同語境下,Sprint Review多被譯為「迭代評審會」或「功能演示會」。但眾多實踐經驗卻強調:

You should never call the Sprint Review the Sprint Demo.

Sprint Review是不是Demo/功能演示會?解答這個問題,要先回答會議的「討論物件」和「會議目標」分別是什麼。

01 不侷限於迭代成果,重點展示整個產品增量

若從字面涵義理解Sprint Review,或許有朋友會認為它是關於迭代成果的會議,即討論當前迭代已交付的價值。但Sprint Review的一般流程指出,與會人應該圍繞「價值增量」展開討論

開發人員展示其已經完成的工作,並回答關於價值增量的問題。

Scrum Guide中定義「增量 Increment」為「所有先前增量的累加」,且實踐經驗表明,增量會在Sprint Review會議呈現。

每個增量都是所有先前增量的累加,並經過全面驗證以確保所有增量可協同工作……增量的總和會在Sprint Review中呈現,以支援經驗主義。

因此,除了同步迭代期間工作和障礙外,更重要的,Sprint Review要展示整個產品增量,以供檢視,而不僅是關注最新的迭代所實現的價值

技術側成員向業務側呈現基於整個產品目標的已完成工作,業務側成員結合產品目標和外部變化,對研發成果進行驗收。

Sprint Review能夠實現「產研-業務-使用者」多終端的進度同步和目標對齊。若只停留在迭代增量的展示或報告上,恐怕就會降級成圍繞「完成了什麼 > 沒完成什麼 > 為什麼沒完成」的工作彙報。

也因此,許多實踐經驗都證明,完整的產品功能展示/Demo演示是更理想的Sprint Review形式

相比逐一展示使用者故事,或者僅使用含功能截圖的PPT彙報,Demo演示能夠更加直觀、全面且集中地呈現業務目標的完成進度,也更便於產品負責人和關鍵干係人評估研發成果,更快地完成目標的調整和待辦優化。

02 不止於Demo演示,協作與反饋更為關鍵

雖說功能/Demo演示是更理想的形式,但這並不意味著,順利完成功能演示就大功告成。Sprint Review的最終目的不是演示,而是對產品待辦列表做出調整。

敏捷開發的核心是快速響應和擁抱「變化」——所有外部的、業務的、基於時間/預算/組織的變化。敏捷開發通過短週期的價值交付,和及時地獲取源自業務的反饋,持續地明確、修正和調整前進目標,以減小變化帶來的影響。

是以,Scrum團隊呈現圍繞目標和業務交付的研發成果(即產品價值增量),只是完成資訊透明和進度同步的第一步;

更重要的下一步是,與關鍵干係人協作,獲得基於迭代和增量的反饋,為後續的迭代工作提供寶貴意見,再次明確目標,並分析下一迭代所需交付的「最有價值的事情」的變化。

所謂「協作」就是要打破技術和業務、Scrum團隊和干係人之間的「隱形牆」,將所有人揉成一團,在統一的會議目標基礎之上,展開互動和討論。

比如,與其讓開發團隊演示產品功能,不如讓干係人在開發的指導下完成使用者路徑,以真正的使用者視角檢查研發成果,貢獻反饋。

換句話說,讓Scrum團隊與主要干係人組織協作,完成對產品待辦列表的檢查和調整是會議的關鍵。脫離反饋和待辦調整的單方面的功能演示,只是換了外衣的「工作彙報」罷了。正如《深入核心的敏捷開發》所說的:

如何評價迭代評審會的效果?唯一的評價標準是,會後有沒有對Product Backlog做出調整。

03 給予正向反饋,尊重並認可團隊的貢獻

Scrum團隊與主要干係人破冰協作,為當前的產品增量提供反饋意見,並確定後續的迭代目標。但在許多敏捷實踐中,貢獻反饋的環節很容易變形成「質量檢驗」和「缺陷問責」。

與會人將Sprint Review視作「成果彙報」或者「階段驗收」,業務端會天然地形成「查漏補缺」和「撥亂反正」的自覺,而技術端則會因免於指責而陷入「粉飾太平」之中。

長此以往,技術和業務、Scrum團隊和干係人之間的關係會越發緊張,陣營堡壘也逐漸堅厚,最後Sprint Review成為人人抗拒的儀式。

因此,Sprint Review不是為了貢獻一個集中問責的機會,而是為了及時的反饋和更好的提升——這也是敏捷開發所追求的——持續地學習、反饋、提升和再實踐。

換言之,Sprint Review希望輸出正向反饋業務端對技術端為實現目標所作出的貢獻和成果表示認可與尊重技術端對業務端傳遞的反饋和改進建議持以開放心態;至於那些尚未完成/仍需優化的部分正是下一階段或後續的努力方向。

Sprint Review不是針鋒相對的修羅場,而是結合溝通、協作和反饋的最佳實踐。

  • 產品負責人和干係人通過功能演示掌握最新的產品增量和目標進度,作出最及時的修正和調整,確定正確的業務方向;
  • Scrum Master和開發團隊在展示和討論中,同步成果、統一目標、定位和評估目標貢獻度,在真實的反饋中贏得工作成就感。

正確的Sprint Review能讓每一位與會人在結束會議時都認為「我們正朝著正確的方向前進」。

# Liga總結

Sprint Review是「以終為始」的優化過程——圍繞完整的產品/模組形態,檢視當前的進度,評估需要修正的階段目標並制定下一步的成長計劃。

因此,Sprint Review應該圍繞產品的價值增量展開,而不是隻關注最新的迭代交付了哪些價值;同時,會議結束要有反饋輸出,對產品待辦列表做出恰當的調整

Demo演示是比較理想的會議形式,但不要只停留在演示;反饋不為問責,而是為了提升和優化,成就更好的敏捷協作。

瞭解更多敏捷開發、專案管理、行業動態等訊息,關注我們 LigaAI@oschina 或點選LigaAI - 新一代智慧研發協作平臺,線上申請體驗我們的產品。