這是《落葉》文集里第?94?片落葉，希望你能喜歡，不為別的，只為這份堅持。
The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product. When applying Scrum, it's not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers.?
為什么先引用 Product Backlog 的原文解釋呢？因為很多名詞的釋義在被翻譯成中文之后，要么比較晦澀，要么就有偏差，通過原文能更精準(zhǔn)地理解這個 Scrum 里重要的工件之一。
今天我這個老兵來理論結(jié)合實踐的說說 PB 在 Scrum 里到底有什么用，后續(xù)會結(jié)合更深入的學(xué)習(xí)實踐繼續(xù)改進(jìn)更新。
1、PB 指的就是 Scrum 流程里的產(chǎn)品清單，Product Owner 和團(tuán)隊會基于這個清單得出 Sprint Backlog 和 Sprint Plan，所以你可以把 PB 理解成一個產(chǎn)品需求池和規(guī)劃路線，PO 對它負(fù)責(zé)，創(chuàng)建和維護(hù)的權(quán)限都只有 PO 才有，它也是持續(xù)增長的一個清單；
2、PB 通常包含有幾項內(nèi)容：Features，Bugs，Technical word，Knowledge acquisition，下面會分開描述；
3、Bugs：缺陷，通常來自于用戶反饋和之前 Sprint 遺留下來的已知問題，這類任務(wù)需求比較清晰單一，責(zé)任人也相對明確；
4、Technical work：技術(shù)類工作，通常來自于開發(fā)團(tuán)隊內(nèi)部，例如代碼優(yōu)化、模塊代碼重構(gòu)、自動化腳本更新和性能優(yōu)化等，這類任務(wù)需求比較清晰單一，責(zé)任人也相對明確；
5、Knowledge acquisition：知識獲取，通常來自于產(chǎn)品交接，新項目所需的知識學(xué)習(xí)、技術(shù)預(yù)研等等，根據(jù)不同階段的 Sprint，這類需求的優(yōu)先級會有不同；
6、Features：功能或特性的需求，一般會用簡短的文字進(jìn)行描述，通常有固定的語法格式，在 Scrum 里稱之為 User Story，顧名思義就是從用戶的角度來描述用戶渴望得到的功能。下面我們來重點說下 User Story，你可以簡單地理解 PB 就是由多個 User Story 組成的集合；
7、User Story 的標(biāo)準(zhǔn)格式：As a Role, I want to Do，so that some Reasons. 作為“某種角色”，我想要“做什么”，所以“需要什么”；
8、什么是優(yōu)秀的 User Story？一個好的用戶故事應(yīng)該包括以下三個要素和六大特性：
三個要素：角色、活動、商業(yè)價值，角色和活動要描述清晰，商業(yè)價值的作用在于讓團(tuán)隊能夠很清楚這個 User Story 的價值，同時也能很好地理解真實的用戶場景；
六大特性：獨立性、可協(xié)商性、有價值、可估算性、短小、可測試性
9、產(chǎn)品負(fù)責(zé)人在編寫 User Story 的時候，需要定義好驗收標(biāo)準(zhǔn)，也就是 Scrum 里常聽到的 DoD （Definition of Done），因為 PO 在做 Sprint 驗收的時候，需要一個清晰且唯一的標(biāo)準(zhǔn)，否則會導(dǎo)致 PO 和開發(fā)團(tuán)隊在驗收問題上的扯皮。
比如：
Sprint 驗收的 DoD：代碼完成、單元測試完成、功能測試完成、幫助文檔完成。
項目發(fā)布的 DoD：性能測試完成、安全測試完成、災(zāi)難恢復(fù)測試完成
10、User Story 和 User Story 之間盡可能地減少依賴關(guān)系，同時對于 User Story 常用故事點（Story Point）去評估大小，這里的故事點只是一個相對值，并不是絕對值。通常都是選定一個合適規(guī)模的 User Story 作為 1 SP，再將其他用戶故事跟它比較，估算出相應(yīng)的 SP 值。
作者簡介：14 年測試 + 11 年項目管理 + 11 年團(tuán)隊管理 = 一個測試?yán)媳?/p>
