健康的Product Backlog就像一個健康的人那樣：整潔有序、組織合理、公開透明。
一個按照優先順序順序排好的敏捷Backlog不僅能夠簡化發版和迭代計劃，還能夠對團隊計劃去做的所有工作進行細緻規劃——包括客戶根本不會關注的內部工作。尤其是當利益相關者和其他團隊對團隊提出額外的工作需求時，Backlog能夠幫助他們設定期望指標，同時還能夠使工程時間具備價值，產出實際可交付的成果。
什麼是Product Backlog？
Product Backlog是開發團隊根據路線圖及需求制定的按優先順序排列的列表。其中，最重要的專案顯示在Product Backlog的頂部，確保團隊知道這就是要先交付的成果。因此，開發團隊不是按照Product Owner規定的節奏開展工作，Product Owner也不會是開發團隊完成工作的驅動者。相反，開發團隊根據Product Backlog中的順序推進工作，通過看板的持續改善或scrum的迭代來完成這些專案。
專家提示：將所有工作內容儲存在同一個任務跟蹤器中——不要使用多個系統來管理bug、需求和研發工作項。如果是要求開發團隊完成的工作，就請將其儲存在單個列表中。
以兩個“R”為出發點
團隊的路線圖和需求為Product Backlog奠定了基礎。路線圖計劃可以拆分為幾個史詩（epic），每個史詩（epic）都包含幾個需求和使用者故事。 讓我們來看看一個名為Teams in Space的虛構產品的路線圖。
由於Teams in Space網站是路線圖中的第一個任務，我們希望將這一任務分解為下面三個不同的開發史詩（epic）（這裡以綠色、藍色和藍綠色顯示）和每個史詩（epic）中各自不同的使用者故事。
然後，Product Owner將每個使用者故事的需求，整合到開發團隊的單個列表中。Product Owner可以先提供單個完整的史詩（epic）（左圖）。或者，如果預訂折扣航班的測試對這個系統來說更為重要時，就需要來自幾個史詩的使用者故事（右圖）。 下面是兩個例子：
哪些因素可能會影響Product Owner的優先順序排序？
- 客戶優先權
- 緊急反饋
- 相對實施難度
- 工作項之間的關聯關係（如：如果先做完A，B會更容易）
雖然確定Product Backlog的優先順序順序是Product Owner的任務，但絕對不應該在封閉的情況下完成。實際上Product Owner會通過收集來自客戶、設計人員和開發團隊的意見和反饋，來優化每個人的工作量和所需交付的產品。
確保 Backlog處於健康狀態
Product Backlog一旦建立，非常重要的一點就是要通過定期維護來確保它能夠與開發專案的整體節奏保持一致。Product Owner在每次迭代規劃會議前，都應該評審backlog，以確保優先順序順序正確無誤，且上一次迭代的反饋已經被整合到本次迭代中。敏捷圈通常將Product Backlog的定期審查稱為“Backlog修飾”。
如果Product Backlog的規模變大，Product Owner就需要按照短期和長期專案，將backlog進行分組。貼標籤前，短期專案需要完善細節。這需要與設計和研發一起協作制定完整的使用者故事、估算開發時間。較長期的專案不需要特別清晰具體，但最好能讓開發團隊做一個粗略的估計來判斷專案的優先順序。這裡的關鍵詞是“粗略”——也就是說團隊完全理解並開始著手做長期專案後，所有的估算都有可能發生改變。
Backlog作為連線Product Owner和開發團隊之間的橋樑。如果是由於客戶反饋、精煉估算和新需求出現等原因，Product Owner可以隨時重新變更backlog的優先順序。但是，一旦進入開發階段，儘量將更改的機率降到最低，因為這樣會打亂開發團隊的節奏並影響工作的聚焦點、流程和士氣。
專家提示：一旦backlog超出了團隊的長期能力，可以嘗試關閉團隊幾乎無法達成的任務。在團隊的任務跟蹤器中，用特別的表述來給這些任務做標記，如“超出範圍”等，以便用於稍後研究。
需要注意的非常規現象:
- Product Owner在專案一開始就對backlog進行了優先順序排序，並且在開發人員和利益相關者提供反饋意見時也沒有對其進行調整。
- 開發團隊將backlog中的事項限制為面向客戶的專案。
- Backlog儲存在本地，不經常共享，導致感興趣的各方無法獲取更新後的內容。
Product Backlog如何讓團隊保持敏捷？
經驗豐富的Product Owner會嚴格修改其專案的Product Backlog，使其成為可靠且可共享的工作大綱。
Backlog鼓勵能夠讓專案變得更健康的討論和決策——因為並不是每項任務都可以排在第一位。
利益相關者可以質疑既定優先順序，這是一個很好的做法。圍繞優先事項進行討論能夠確保每個人的優先事項保持一致。這些討論可以促進團隊優先順序一致性的文化，確保專案中的每個成員都有優先順序一致的思維。
Product Backlog同時也是迭代規劃的基礎。所有工作項都應包含在backlog中：使用者故事、bug、設計變更、技術債、使用者提出的需求、回顧中的操作項等。這樣做可以確保每個迭代的每個人的工作項都包含在整個討論中。然後，在完全知曉需要完成的所有事項的情況下，團隊成員可以在迭代開始前與Product Owner一起權衡此次迭代的工作項。
專家提示：Product Owner決定了backlog中工作項的優先順序，而開發團隊則通過backlog來決定團隊開發速度。而對於希望將工作“推”給團隊的新Product Owner而言，這可能是一種難以平衡的關係。
文章來源：Worktile敏捷部落格
歡迎訪問交流更多關於技術及協作的問題。
文章轉載請註明出處。