產品待辦列表

產品待辦列表對應的英文是product backlog，也有翻譯為“產品待辦事項列表”，是指為開發完善產品而待辦的事項列表。

基本介紹

• 中文名：產品待辦列表
• 外文名：product backlog

簡介

在Scrum Guide中，產品待辦列表是一個排序的列表，包含所有產品需要的東西，也是產品需求變動的來源。產品負責人負責產品待辦事項列表的內容、可用性和優先權。產品待辦事項列表永遠是不完全的，最初的版本只列出最初始的和眾所周知的需求。產品待辦事項列表根據產品和開發環境的變化而演進。待辦事項列表是動態的，它經常發生變化以識別使產品合理、有競爭力和有用所必需的東西。只要產品存在，產品待辦事項列表就存在。

產品待辦列表的內容

產品待辦列表的另外一個翻譯為產品待辦事項列表，它顯示產品待辦列表里應當包含待辦事項。待辦事項包括所有的特性、功能、需求、改進方法和修復等對未來發布產品進行的改變。產品待辦事項列表條目包含描述、次序和估算的特徵。常見的待辦事項是以用戶故事形式來表達的，也有將原始需求、客戶需求、需求用例等作為待辦事項存放到產品待辦列表。

產品待辦列表的維護

在Scrum Guide中，產品待辦列表通常以價值、風險、優先權和必須性排序。排在頂部的產品待辦列表條目需要立即進行開發。排序越高，產品待辦列表條目越緊急，就越需要仔細斟酌，並且對其價值的意見越一致。排序越高的產品待辦列表條目比排序低的更清晰、更具體。根據更清晰的內容和更詳盡的信息就能做出更準確的估算。優先權越低，細節信息越少。開發團隊在接下來的Sprint中將要進行開發的產品待辦事項列表條目是細粒度的，已經被分解過，因此，任何一個條目在 Sprint 的時間盒內都可以被“完成”。開發團隊在一個 Sprint 中可以“完成”的產品待辦列表條目被認為是“準備好的”或者“可執行的”，能在 Sprint 計畫會議中被選擇。隨著產品的使用、價值的獲取以及市場的反饋，產品待辦列表變成了更大、更詳盡的列表。因為需求永遠不會停止改變，所以產品待辦列表是個不斷更新的工件。業務需求、市場形勢和技術的變化都會引起產品待辦列表的變化。

若干個 Scrum 團隊常常會一起開發某個產品。但描述下一步產品開發工作的產品待辦列表只能有一個。那么這就需要使用對產品待辦列表條目進行分組的屬性。“產品待辦列表最佳化（2013年前英文原文是grooming, Scrum Guide2013版改為refinement）”是增添細節、估算和排序條目的舉動。這是一個持續不斷的過程，產品負責人和開發團隊協作討論產品代表事項列表條目的細節。在產品待辦事項列表最佳化的時候，條目會被評審和修改。然而，產品負責人可以隨時更新產品待辦事項列表條目或酌情決定。

單列表的產品待辦列表存在的問題

從以上文字可以推斷，Scrum Guide所說的產品待辦列表是一個列表，通過不斷維護，排在頂部的待辦事項得到了分析，並拆分到足夠小的粒度，以便在一個疊代衝刺中進行開發。這樣做法有如下的兩大不利之處：

1. 早先的一個待辦事項可能分解成多個待辦事項，其關聯信息難以維護
   
2. 早先收集的信息在最佳化和細化過程中可能在多次傳遞後失真
   

樹形的產品待辦列表更具表現力，人們為了克服單列表的不足，採用了樹形的產品待辦列表，常見形態如下：

• 原始需求或者史詩故事A
  

1. 用戶故事或者用例A1
   
2. 用戶故事或者用例A2
   

• 原始需求或者史詩故事B
  

1. 用戶故事或者用例B1
   
2. 用戶故事或者用例B1
   
3. 更細的用戶故事B11
   
4. 更細的用戶故事B12
   

這樣，原始的信息和關聯關係都得到了維護。

另外一種方式是有關聯關係的雙列表，第一級列表是原始需求或者是史詩故事，或者是概要需求；第二級列表是用戶故事，或者需求用例,第二級列表中的條目必須對應到第一級中的條目。顯然的，帶有關聯對應關係的雙列表也可以轉換成樹形結構。當前不少工具可以幫助展現不同的形態以方便各人的習慣。

長期運維的產品待辦列表

對於業主方而言，往往需要長期的運維某產品，那么，在長期運維中，對於已經完成的待辦事項如何處理？ 常見有如下做法：

1. 從產品待辦列表中移除，但是不能真的扔掉，為了產品的長期運維，將其轉移組織到反映產品最新需求的文檔中，常見用wiki作為載體
   
2. 保留在產品待辦列表中，以備查詢，不再修改
   
3. 保留在產品待辦列表中，進行狀態和版本管理
   

第1種做法遇到原功能修改增強升級時，需要先從需求文檔中檢索到最新情況，然後根據最新情況撰寫待辦事項進入到產品待辦列表；當此待辦事項做完之後，再從產品待辦列表中再搬移更新回到需求文檔。

第2種做法遇到原功能修改增強升級時，可查詢到原來如何，新建待辦事項來處理，跟蹤新的待辦事項。

第3種做法無須進行轉移，利用條目化管理工具能方便的管理其狀態、版本以及關聯關係。 當已經完成的事項需要修改增強升級時，只需檢索到原條目，然後進行修改，將其發布目標版本設為最新目標的版本。較之第1種方法，無需搬移，而隨著工具的發展，第2種做法漸漸成為多數的選擇，在這種情況下，產品待辦列表的字面意思就不再恰當，也許改名為產品需求列表更為合適，或者說產品待辦列表是產品需求列表的一部分，對產品需求列表設立一個過濾器，查詢未完成的待辦事項就得到了“產品待辦列表”。