產品待辦列表

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

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

產品待辦列表里有什麼？

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

如何維護產品待辦列表？

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

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

單列表的產品待辦列表有什麼困難？

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

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

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

     1原始需求或者史诗故事A
                   1.1用户故事或者用例A1
                   1.2用户故事或者用例A2
     2原始需求或者史诗故事B
                   2.1用户故事或者用例B1
                   2.2用户故事或者用例B1
                       2.2.1 更细的用户故事B11
                       2.2.2 更细的用户故事B12

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

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

長期運維的產品待辦列表

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

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

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

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

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

外部連結

• 產品待辦事項梳理 - 捷伴行Agile （頁面存檔備份，存於網際網路檔案館）