怎樣破解迭代評審會七宗罪,開一場高效會議

語言: CN / TW / HK

共創嘉賓| 潮海專案教練

撰文編輯| LigaAI

全文約 4,300 字,閱讀約需 12 分鐘


迭代評審會(Sprint Review)基於真實的使用者使用場景,展示當前整個產品增量,通過獲取貼合用戶使用習慣的反饋和建議,最終輸出產品待辦列表的優化調整。迭代評審會應重點關注使用者需求的解決情況,而不是查詢缺陷(當然,影響核心流程的重大缺陷一定要記錄在冊)。

  • 展示結果:開發團隊檢視當前迭代的最初計劃,展示每個需求/故事的工作結果及變化;
  • 評審反饋:產品負責人進行確認,收集反饋,並記錄進一步的改進設想為新需求/故事;
  • 調整方案:產品負責人及關鍵干係人介紹有關後續迭代的新資訊/設想,為接下來的迭代計劃會議提供有價值的輸入資訊。

基於清晰的會議目的和討論重點,如何更好地完成迭代評審會?高效的迭代評審會又有哪些不為人知的事半功倍小技巧?

本期敏捷實踐,LigaAI聯合潮海專案教練團隊的資深敏捷教練,一一為你解答。

一、 每個迭代結束都要進行評審嗎?

作為Scrum五大事件之一,迭代評審會通常在產品增量完成後、正式釋出前舉行,但在實踐經驗中,並非每個迭代完成都必須要進行評審。依據時間頻率的不同,迭代評審會分為高頻評審和低頻評審。

  • 高頻評審適用於產品增量複雜的情況。通過將產品增量拆分成若干個關鍵需求,並在每個關鍵需求完成後,邀請重要干係人蔘與檢驗,以分散一次性評審的會議壓力。
  • 低頻評審適合產品增量對干係人的感知價值不大(比如長流程的端到端需求)或干係人時間緊張等情況。通過多個增量的合併評審,減少頻繁會議對工作的佔用和干擾。

此外,以迭代週期/固定週期作為舉行迭代評審會的標誌並非最優解。迭代週期是團隊內部的開發管理單位,在可感知價值增量層面或有不穩定性。

更好的做法是基於里程碑/史詩的完成情況,以增量結果為指標,按需開展迭代評審會。 研發里程碑一般分為「內部里程碑」和「外部里程碑」兩種。

  • 內部里程碑常指專案關鍵決策點,如需求階段完成、設計階段完成,主要用於評估專案內部風險,一般不涉及使用者反饋,無需迭代評審;
  • 外部里程碑是涉及對外發布的重大功能/模組的完成,需要在產品釋出前邀請關鍵干係人蔘加迭代評審會,並貢獻真實的使用反饋。

二、 干係人一定要參與會議嗎?

在《每日站會能不能取消?》一文中,我們曾提到「非必要情況下,Scrum Master可以不參加每日站會」。那麼,迭代評審會是否也可以不需要關鍵干係人的參與呢?

答案是——不可以。

迭代評審會的核心目標是收集使用者反饋,所以關鍵干係人的參與極其重要。 但在實際中,不可避免地,干係人可能因各種原因無法參加會議,可以採用以下幾種方式解決:

第一,由干係人授權的決策代表代替干係人蔘加會議。決策代表需要具備對產品增量貢獻反饋的能力,並且要能夠提出「通過與否」的關鍵性意見。

第二,如果幹系人無法分出大塊時間參與評審,那Scrum團隊可以採用高頻小模組的方式完成反饋,遵循「價值原則」——先展示最急需反饋的功能。

第三,將干係人的會議預約列入待辦。避免臨期預約的衝突和缺席隱患,產品負責人可以在迭代規劃期,就提前鎖定關鍵干係人的會議時間,或將迭代評審會以定期形式常態化(比如安排在每雙週的固定時段),確保干係人可成功出席。

貢獻反饋的干係人必須參加,而執行反饋的技術人員也同樣不能缺席。 開發團隊應在現場直面使用者,聆聽最真實的使用者聲音,才能更好地理解業務、理解需求。

理想情況下,開發團隊應全員參與迭代評審會,同干係人一起協作討論,在認同中建立工作價值感;

如果團隊規模較大,也可以輪流派代表或者安排技術骨幹參與會議,負責本次產品增量的開發人員必須出席會議,以減少一手反饋的傳遞偏差。

三、迭代評審會的多種開啟方式

01 合而為一

踐行Scrum的過程中,敏捷四會(即計劃會、每日站會、評審會和回顧會)不必是完全獨立的。

例如,對於每週一迭代的短週期敏捷團隊,可以考慮將評審會和計劃會合為一次會議,以減輕會議負擔。會議中,應先評審、後計劃:關鍵干係人在評審結束後先行離場,Scrum團隊繼續進行新一期迭代的計劃會議。

迭代回顧會則不建議與其它會議合併,因為這是敏捷團隊覆盤和經驗總結的寶貴機會;但可以考慮將多個迭代的回顧會合並一次舉行。

02 一分為二

對於產品增量價值低、客戶感知影響不大、或有高質量要求,需先進行內部評審的迭代而言,可以採用「一分為二」的低頻評審形式,將迭代評審會分為「Scrum團隊的內部會議」和「與干係人協作的外部會議」兩次進行。

  • Scrum團隊的內部評審側重於完整的功能展示,重點審查關鍵功能能否跑通、是否存有Bug尚未修復/發現等;
  • 有關鍵干係人蔘與的外部評審以收集使用者真實反饋為主,重點驗證產品增量是否滿足客戶需求、是否達成真正的產品價值。

03 直面客戶是最好的形式

遠端辦公和異地協作盛行的今天,共享式的文件/表格/問卷協作免去許多會議,但是迭代評審會以獲取使用者真實反饋為核心,面對面溝通卻是不可省去的重要儀式——直面客戶、觀察使用者的使用和體驗是獲取有效反饋的主要途徑。

對於重要且急需使用者反饋的功能,Scrum團隊應主動安排產品負責人和功能相關的技術骨幹前往干係人公司,進行一對一展示和溝通

面對無法克服的時差或時空問題,也可以採用線上視訊會議的形式,但是建議要開啟攝像頭和麥克風,並使用共享螢幕,讓Scrum團隊「看到」干係人的使用反饋。

四、迭代評審會的四個黃金搭檔

高效的迭代評審會一般包含功能演示、體驗試用、討論反饋和待辦優化四個環節。

01 功能展示

述清會議內容與目的後,開發成員結合迭代計劃與產品增量,向產品負責人和關鍵干係人展示已經完成的產品價值。

看似簡單的功能展示,也存在一些共性的改進空間——《深入核心的敏捷開發》提出「展示會七宗罪」以描述功能展示過程中的七大問題,並針對性地提出了高效展示會的七個技巧。

七宗罪之一:準備工作沒做好,空耗會議時間

正確做法:主講人在正式展示前,應該做好充分的準備工作——預演演示步驟,準備測試資料,提前部署演示環境等等,避免手忙腳亂和空轉浪費,提高會議效率。


七宗罪之二:沒有說明鋪墊,雲裡霧裡不知所以

正確做法:在開始演示之前,主講人應當簡要地介紹會議目標和所要展示的功能,並說明功能給使用者帶來的價值。清晰的上下文能讓產品負責人和干係人更快地進入狀態。


七宗罪之三:逐條過驗收標準,缺失業務完整性

正確做法:不要逐個演示使用者故事/驗收標準。主講人應以功能為單位,將完整的產品/功能/模組串起來展示;最好定義出單獨的業務場景,使用業務語言讓業務成員更有代入感。


七宗罪之四:相同/類似的功能,演示所有路徑

正確做法:只演示最關鍵的路徑。遇到多個路徑實現相同或相似功能時,選擇其中一條最複雜/重要的路徑詳細演示,其他路徑指出不同的地方,點到為止,無需覆蓋全部路徑。


七宗罪之五:過多提及跟演示功能無關的內容

正確做法:專注於最有價值/重要的功能演示,不要讓小反饋/未完成的模組耽誤會議時間;儘量不提及技術難題或技術方案等業務人員不感興趣的內容。


七宗罪之六:認為展示僅僅是BA或QA的事情

正確做法:不讓某個角色獨佔功能展示,人人都應該參與進來;可以採用人員輪換的方式進行展示,這樣可以提升成員的業務意識,更熟悉整個系統功能。


七宗罪之末:不熟悉的新人負責展示,重點模糊

正確做法:新人展示前應充分了解業務和系統,確保能夠應對和解答業務的挑戰和疑問;也可以讓新人在結對程式設計、Story Kickoff等多做主導,具備一定的系統和業務意識後再向干係人展示。

02 體驗試用

開發成員完成功能演示後,更重要的是要讓關鍵干係人親自體驗和試用系統功能/Demo。使用者親自下場試用和檢驗,是獲取反饋中必不可少的一環。

產品負責人也可以邀請真實的使用者參加評審會,讓其在開發的指導下體驗演示的功能和系統。需要注意,此時開發團隊應該為干係人和使用者留出足夠的自主探索空間,引導他們重現最真實的使用習慣和場景,避免成為「產品推銷員」。

03 討論反饋

產品負責人要收集關鍵干係人(和使用者)的反饋,及時記錄最新的改進與設想為新的需求。在體驗試用環節,Scrum團隊可以通過以下幾種方式,觀察使用者體驗,洞悉真實反饋。

  • 注重整體的展示,避免成為驗收測試

讓干係人和使用者體驗功能並非授權全自主探索——開發成員需要提供必要的場景描述,還原功能使用場景,讓使用者更有代入感;但,切忌進行步驟指導,過多的干預反而不利於觀察真實反饋。

另外,不要逐一演示使用者故事。開發成員應儘可能引導使用者對整個產品/功能模組進行試用,並關注基於產品整體的功能完整性和銜接流暢性,觀察和分析可能存在的優化空間。

  • 細心觀察使用者表現,敏感捕捉使用障礙

在使用者體驗功能時,Scrum團隊應該留心觀察他們自然表達和流露的語言、表情、操作和使用習慣等,要具備捕捉異常的敏感度

比如使用者是否在使用期間出現困惑表情、在無反應的地方反覆點選等等。通過深入挖掘使用者行為背後的原因,瞭解最真實的行為反饋。

  • 使用開放性問題,引導使用者自主表達

與干係人和使用者協作、溝通和討論時,避免使用「是不是」、「有沒有」等封閉性問題;多用開放性問題,一步步引導使用者表達出最真實的想法

發現使用者頻繁點選某個按鈕,或瀏覽選項的時間過長時,可以通過丟擲「你希望這個按鈕提供什麼功能/選項(但沒有滿足)嗎?」等問題,鼓勵使用者主動說出對系統功能的期待,為後續的迭代貢獻有價值的意見和改進空間。

04 待辦優化

在評審會的最後,產品負責人及關鍵干係人介紹有關後續迭代的新資訊或新設想,結合當前產品或市場環境的變化,討論即將釋出的版本的產品功能,為接下來的迭代計劃會議提供有價值的輸入資訊。

通常在會後,產品負責人會結合迭代評審會的結果,對產品待辦列表和需求優先順序進行重新評審和整理——這也是衡量會議成功的關鍵。

為了更準確地完成待辦列表調整,開發團隊應對未完成的工作保持開放和透明,以便產品負責人能制定更全面的決策;

產品負責人可以結合不同決策依據,應用優先順序排序的三個模型和四張畫布,更高效地完成調整。

更多閱讀請點選:

不同決策應參考什麼指標進行優先順序優化?

做優先順序排序時使用最多的三個模型

譯文 | 四張畫布教你判斷「產品開發優先順序」

# Liga總結

迭代評審會的核心目標是為了獲取真實的使用者反饋,為後續的迭代和研發工作貢獻有價值的意見。

高效的迭代評審會要抓住功能展示、體驗試用、討論反饋和待辦優化四個關鍵環節。Scrum團隊以專業、高效的姿態,向干係人和使用者呈現研發成果;通過引導和觀察,洞悉真實場景下的使用反饋,更好地服務後續迭代。

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