持續交付時代，還有必要進行 Sprint Review 麼？

持續交付時代，企業經過自動化構建部署，快速頻繁地發佈軟件。不少團隊爲了儘早獲取用戶和干係人的反饋來適應變化，採用一次性的特性評審來取代迭代評審會（Sprint Review）。那麼持續交付時代，是否還要堅持 Sprint Review？Sprint Review 的價值在哪裏？本期「項目管理100問」來聊一聊 Sprint Review。

Sprint Review 是什麼？

在「ONES 小課堂：讓我聊一聊 Scrum」中說到，Scrum 將整個開發過程分爲屢次 Sprint，經過屢次 Sprint 來改善正在構建的特性，逐步完善產品。

Sprint 須要通過 Planning - Implementation - Review - Retrospective 4個階段流轉，在 Sprint 結束時進行 Review，來檢視所交付的產品增量並按需調整產品待辦事項列表。

Scrum 迭代流程圖

Sprint Review 的價值

Sprint Review 的目的是爲本次迭代交付的產品得到反饋，響應業務需求，確保達到應用效果，避免開發對用戶沒有價值的功能。Sprint Review 將參與該過程的全部人員聯繫在一塊兒，集中展現多個特性功能，幫助利益相關者全方位思考，從總體上優化和改進產品。

對於團隊來講，總體優化和改進是很難的，經過儀式感的會議機制持續地學習和討論，讓團隊成員清楚地知道每次交付的是一個可用的軟件版本，而不是單純的產品功能。Sprint Review 讓持續交付文化融入團隊，保證研發的節奏和質量。

Scrum 過程當中每一個要素都是以一種微妙的方式相互做用，隨意裁剪模塊會破壞敏捷的節奏。Sprint Review 做爲敏捷中重要的一環，必不可少。那麼，如何高效地完成 Sprint Review 並充分得到反饋？

Sprint Review 成功要點

1. 在會議準備階段，PO 須要根據迭代規劃週期和類型肯定演示計劃和演示日期，在 ONES Wiki 中與團隊成員同步演示環境及數據，提升會議效率；

ONES Wiki 共享文檔，沉澱團隊知識

2. 肯定會議主持人，把控會議流程及會議走向，避免將會議變成簡單的演示會議。

Sprint Review 不是 Sprint Demo，Sprint Demo 是單向溝通，而 Spirnt Review 是雙向溝通。它不只是展現本次迭代的成果，還要求項目組內部成員（包括PO、SM、開發測試等）和項目組外部利益相關者（包括客戶、最終用戶等）相互提問反饋，檢查新功能是否知足客戶需求；

3. 建議由 PO 進行操做，講解當前完成功能及遺留問題或風險，全部參會人員根據體驗及演示提出反饋或建議，按照優先級錄入 Sprint 或 Product backlog;

ONES Project 創建需求池

4. Sprint Review 結束後，如未達上線標準，PO 須要引導團隊成員根據演示反饋造成問題的「行動計劃」並執行，直至下一次演示經過方可上線；

5. Sprint Review 不是惟一得到反饋的方式，團隊應該儘早獲取用戶和干係人的反饋。ONES Desk 支持快速收集、跟蹤、管理和解決客戶的建議反饋，幫助團隊改善產品功能、解決用戶需求，不斷從事件中學習和沉澱。

ONES Desk 幫助企業快速響應客戶反饋

持續交付時代，ONES爲中大型團隊提供優秀的敏捷研發實踐，打造研發過程當中多角色間的高效協做環境，幫助中大型企業快速可靠地迭代版本，持續交付價值。