產品待辦列表是什么

產品待辦列表對應的英文是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??
[本頁面的文字允許在知識共享 署名-相同方式共享 3.0協議和GNU自由文檔許可證下修改和再使用。]

總結

以上是生活随笔為你收集整理的产品待办列表的几个最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。