Product Backlog：終極任務清單

健康的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敏捷博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。