2023-05-12|閱讀時間 ‧ 約 7 分鐘

Backlog Refinement 帶領你把願景兌現成價值

本文已取得 Scrum Inc. 官方授權翻譯,原文為:Backlog Refinement Takes You from Vision to Value https://www.scruminc.com/backlog-refinement-vision-value/ (全文視情況刪減或調整,以幫助閱讀)
*本文「refine」譯為「精煉」、「7 Product Dimensions」譯為「七項產品特點」、「Structured Conversation」譯為「結構化會談」,以及「Enabling specification」譯為「能用之規格」;本文的「Story」均指「User Story」。

更快的交付價值

Backlog Refinement 能為開發而準備好你所需的 Backlog 。投資此事,能幫助你更快的交付價值、倍增你的生產力,以及建立強大的協作 —即 高績效團隊的支柱。我們發現 Product Owner 在 Backlog Refinement上,需要更進一步的訓練。 透過極度專注在價值,以及進行運用七項產品特點(7 Product Dimensions)的結構化對會談(Structured Conversation),你會大幅提升把願景兌現成價值的能力。
Refinement 是關於「持續準備好(Readying)」
精煉 Product Backlog 是以某種方式為 Sprint Planning 準備好 Backlog Item ,這種方式包含分析和切分 Story。 一個健康的 Backlog ,是由 Product Owner 持續精煉的,以提供給團隊詳細說明、作為估點、評估價值與排序 Backlog Item 用。這項持續精煉的工作,能快速和增量交付(incremental delivery)產品價值,同時也是最佳化開發團隊生產力的關鍵。根據 Jakobsen 和 Sutherland 的研究指出,為了進行 Sprint Planning ,而已先及時被適當精煉的 Product Backlog Item,能倍增團隊的生產力。(請見參考書目1)
然而,團隊卻苦於有效率(時間)且有效果(成效)的做出這項重要的工作(指 Refinement)。當他們浪費時間在對於整體產品價值不重要的 Backlog Item 上,或因為東西太大或模糊,而導致無法執行或展示時,他們會猶豫且難再進行下去。
從價值開始,及從價值結束
當一個成功產品與它的願景和目標保持一致時,它就能產生價值。當產品提供合理報酬,以換取時間、金錢、商品或服務時,它便會產生價值。
Refinement 假定 Product Owner 和開發團隊合作,基於價值,而替 Backlog 排序。Refinement 需要做出艱難的決策,這項決策是基於平衡「不同利害關係人的價值觀點」與「根據持續變化的市場條件和客戶需求而隨著時間改變的價值」而作出。
基於價值而建立的 Backlog Refinement 之決策,需要 Product Owner 和團隊間的協作。建立信任,則應該揭露影響整體開發生命週期的「無法避免之取捨」的「複雜性」。比如:有些 Sprint 也許需要團隊承擔短期技術債,以便在高度競爭市場上,保有與其他產品一致,而所需交付的功能。其他 Sprint 可能需要團隊推延所需做的功能,到比較後面的 Sprint ,以便關注在減少違規(regulatory noncompliance)的風險。
每個產品和其關聯的 Backlog Item 都有七項產品特點,這包含功能需求(使用者、行動、數據和控制特點)與非功能需求(介面、環境和品質屬性特點)。(請見參考書目2)
這七項產品特點提供正在開發中的產品,一份統一、完整與全面詳盡的理解。Backlog Item 的全貌,強調沒有任何一項特點本身是足夠的 — 即這全部七項都是必須存在的。透過探索這些特點,每個人對於 Backlog Item 的了解,應該都能從改善後的(結構化)會談而獲益。

結構化會談,幫助你做出有價值的拆分

在 Backlog Item 被精煉的同時,團隊需要一種機制來鼓勵其探索、評估和進行確認。這種持續且有系統的方法,被稱為結構化會談。
結構化會談的概念,源自於一個對團體協作和創新有用的工具。它鼓勵以更有效的方法來探索、評估和確認選項。
一開始,團隊由七項產品特點來為 Backlog Item 探索選項。接著,團隊評估高價值選項的子集(subset),再將他們組成有價值的集合體。直到每個人藉由確認每個 Story 如何被展示和驗證,以確認他們有共同的理解後,這會談才會結束。
精煉並運用結構化會談和七項產品特點,來揭露相依性,並使團隊著重在可行動與有價值的 Story 上,而這些 Story 是足夠小的,以致於能被評估,且在一個 Sprint 中被完成。能用之規格,通常是這些會談的副產品,而且其補充了更多複雜的 Story。(請見參考書目3)
能用之規格包含 wireframes(介面特點)、資訊模式圖(數據特點)、決策表(控制特點),或相似的視覺分析模型。舉例來說,團隊應該以對遵循規則最有用的、產品支援的參考資訊和不具備產業知識(domain knowledge)的團隊成員,來確定建立的能用之規格的優先順序。
參考書目:
1. Jakobsen, C.R. and Jeff Sutherland, J. “Scrum and CMMI — Going from Good to Great: Are you Ready-Ready to be Done-Done?” Agile Conference, IEEE Conference Publications (2009): 333–337.
2. Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting. 2012.
3. Sutherland, Jeff. “Enabling Specification: The Key to Building Agile Systems.” Scruminc (blog). June 2, 2012.
分享至
成為作者繼續創作的動力吧!
© 2024 vocus All rights reserved.