産品待辦清單的幾個最佳實踐産品待辦清單是什麼産品待辦清單裡有什麼？如何維護産品待辦清單？單清單的産品待辦清單有什麼困難？樹形的産品待辦清單更具表現力長期運維的産品待辦清單不再隻包括待辦事項

産品待辦清單對應的英文是project backlog，也有翻譯為“産品待辦事項清單”，是指為開發完善産品而待辦的事項清單。

在scrum guide中，産品待辦清單是一個排序的清單，包含所有産品需要的東西，也是産品需求變動的唯一來源。産品負責人負責産品待辦事項清單的内容、可用性和優先級。産品待辦事項清單永遠是不完全的，最初的版本隻列出最初始的和衆所周知的需求。産品待辦事項清單根據産品和開發環境的變化而演進。待辦事項清單是動态的，它經常發生變化以識别使産品合理、有競争力和有用所必需的東西。隻要産品存在，産品待辦事項清單就存在。

産品待辦事項清單列出了所有的特性、功能、需求、改進方法和修複等對未來釋出産品進行的改變。産品待辦事項清單條目包含描述、次序和估算的特征。

産品待辦清單的另外一個翻譯産品待辦事項清單顯示産品待辦清單裡應當包含待辦事項。待辦事項包括所有的特性、功能、需求、改進方法和修複等對未來釋出産品進行的改變。常見的待辦事項是以使用者故事形式來表達的。

在scrum guide中，産品待辦清單通常以價值、風險、優先級和必須性排序。排在頂部的産品待辦清單條目需要立即進行開發。排序越高，産品待辦清單條目越緊急，就越需要仔細斟酌，并且對其價值的意見越一緻。排序越高的産品待辦清單條目比排序低的更清晰、更具體。根據更清晰的内容和更詳盡的資訊就能做出更準确的估算。優先級越低，細節資訊越少。開發團隊在接下來的sprint 中将要進行開發的産品待辦事項清單條目是細粒度的，已經被分解過，是以，任何一個條目在 sprint 的時間盒内都可以被“完成”。開發團隊在一個 sprint 中可以“完成”的産品待辦清單條目被認為是“準備好的”或者“可執行的”，能在 sprint 計劃會議中被選擇。随着産品的使用、價值的擷取以及市場的回報，産品待辦清單變成了更大、更詳盡的清單。因為需求永遠不會停止改變，是以産品待辦清單是個不斷更新的工件。業務需求、市場形勢和技術的變化都會引起産品待辦清單的變化。

若幹個 scrum 團隊常常會一起開發某個産品。但描述下一步産品開發工作的産品待辦清單隻能有一個。那麼這就需要使用對産品待辦清單條目進行分組的屬性。“産品代表事項清單優化（英文原文是grooming）”是增添細節、估算和排序條目的舉動。這是一個持續不斷的過程，産品負責人和開發團隊協作讨論産品代表事項清單條目的細節。在産品待辦事項清單優化的時候，條目會被評審和修改。然而，産品負責人可以随時更新産品待辦事項清單條目或酌情決定。

從以上文字可以推斷，scrum guide所說的産品待辦清單是一張清單，通過不斷維護，排在頂部的待辦事項得到了分析，并拆分到足夠小的粒度，以便在一個sprint中進行開發。這樣做法有如下的兩大弊端：

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

這樣，原始的資訊和關聯關系都得到了維護。

另外一種方式是有關聯關系的多清單，形式如下

第一級清單（比如原始需求，史詩故事）

第二級清單（比如使用者故事，需求用例等）

第三級清單（比如界面細節）

epic1

userstory1

userstory2

userstory3

對應于userstory1的細節

對應于userstory2的細節

對應于userstory3的細節

epic2

userstory4

userstory5

userstory6

...

......

部落格中表格修改不易，一般的，在靈活開發環境下，不使用第三級清單。

顯然的，關聯關系的多清單也可以轉換成樹形結構。現在不少工具可以幫助展現不同的形态以友善各人的習慣

對于已經完成的待辦事項如何處理？ 常見有兩種做法：

1，從産品待辦清單中移除，但是不能真的扔掉，為了産品的長期運維，将其轉移組織到反映産品最新需求的文檔中，常見用wiki作為載體。 

2，保留在産品待辦清單中，進行狀态和版本管理。

第2種做法無須進行轉移，利用條目化管理工具（比如vsts，jira，redmine，polarion，mantis，sharepoint等等）能友善的管理好狀态和版本。

當某已經完成事項需要修改增強更新時，隻需檢索到原條目，然後進行修改，然後将其釋出目标版本設為最新的版本。較之第1種方法，無需搬移，而第1種方法的話，遇到修改增強更新時，先從文檔中檢索到最新情況，然後根據最新情況撰寫待辦事項進入到産品待辦清單，做完之後，從産品待辦清單中再搬移回文檔。

随着工具的發展，第2種做法漸漸成為多數的選擇，在這種情況下，産品待辦清單的字面意思就不再恰當，也許改名為産品需求清單更為合适，或者說産品待辦清單是産品需求清單的一部分，對産品需求清單設立一個過濾器，查詢未完成的待辦事項就得到了“産品待辦清單”。

參考資料 

1，scrum guide 中文版  https://www.scrum.org/scrum-guide  

[本頁面的文字允許在和下修改和再使用。]