Scrum的基本概念其實(shí)并不復(fù)雜，但是想做好并不容易，大家都知道product backlog的重要性，但是我們?nèi)绾沃贫ê驼宫F(xiàn)它，如何評定優(yōu)先級(jí)，如何進(jìn)行初始評估？下面我將介紹和product backlog相關(guān)的一些問題。

在Scrum之 流程和術(shù)語介紹了流程，這里主要介紹第一個(gè)最重要的工件 Product Backlog。它是Scrum的核心，也是一切的起源。它是由Product Owner負(fù)責(zé)制定的一個(gè)按照重要性的級(jí)別排序了的故事列表。?

• 什么是Prodcut Backlog
  

backlog英文意思為“積壓的工作”。?product backlog是一個(gè)具有優(yōu)先級(jí)的需求列表， 并對每個(gè)需求進(jìn)行了粗略的估算。在Scrum中表示可以預(yù)知的所有任務(wù)，包括未細(xì)化的產(chǎn)品功能要求、Bugs、缺陷、用戶提出的改進(jìn)、具競爭力的功能及技術(shù)升級(jí)等，按優(yōu)先級(jí)定義出來，這些任務(wù)可能不是完整的，甚至可能隨時(shí)會(huì)更改或添加。Prodcut Backlog永遠(yuǎn)處于不完整狀態(tài)，它隨著產(chǎn)品及其使用環(huán)境的變化而變化，它是動(dòng)態(tài)的，管理層不斷對之做出改變，確定產(chǎn)品需求，保證產(chǎn)品適用性、實(shí)用性和競爭性。

1. 在列表上層的故事首先被團(tuán)隊(duì)完成
2. Product Backlog不是制定一次就完了的，它是動(dòng)態(tài)的，需要持續(xù)的被修訂，可能會(huì)出現(xiàn)故事的增加、刪除和修改、合并或者拆分
3. 任何一個(gè)Backlog的目標(biāo)都是：它應(yīng)該足夠短、級(jí)別足夠高，無特殊情況不需要修改。如果Backlog改變了，那么我認(rèn)為你應(yīng)該假設(shè)你的?Backlog錯(cuò)了，而不是需求變更了。變更需求通常意味著Backlog太長或者太詳細(xì)，比如把復(fù)雜算法和邏輯也寫入了backlog中了，要不就是寫 的太含糊不清了，需要花費(fèi)太多的時(shí)間猜測它究竟講的是什么。

這里有一個(gè)別人做的，大家可以參考一下?product sprint示例

Make the Product Backlog DEEP

• Prodcut Backlog有什么用?

產(chǎn)品backlog根據(jù)用戶價(jià)值羅列所有即將在產(chǎn)品中開發(fā)的功能，通過簡潔的展示需要實(shí)現(xiàn)的功能，我們可以對項(xiàng)目進(jìn)行規(guī)模上的估算，確定發(fā)布計(jì)劃和迭代計(jì)劃。產(chǎn)品backlog可以幫助我們對將要做的事情有個(gè)整體的認(rèn)識(shí)，以及可以知道我們現(xiàn)在的狀態(tài)。如果沒有backlog，我們將不知道現(xiàn)在和將來產(chǎn)品做成什么樣子，由于對產(chǎn)品目標(biāo)的不明確，當(dāng)然也不知道什么時(shí)候可以發(fā)布產(chǎn)品，或者發(fā)布的產(chǎn)品能給客戶帶來什么價(jià)值。

• 誰提供product backlog的需求

產(chǎn)品負(fù)責(zé)人與客戶最近，他最清楚產(chǎn)品應(yīng)該做什么樣子，所以product backlog應(yīng)該由Product Owner來制定。里面的需求由產(chǎn)品負(fù)責(zé)人或者客戶制定，有時(shí)候Team里的需求分析人員可以和產(chǎn)品負(fù)責(zé)人或客戶一起定義需求。制定后，由Scrum master和Team協(xié)助產(chǎn)品負(fù)責(zé)人修訂并進(jìn)行初始評估，里面的需求在sprint計(jì)劃會(huì)議將進(jìn)行更進(jìn)一步的討論。

• 什么時(shí)候會(huì)修改product backlog

如果一個(gè)列表太長或者內(nèi)容陳舊，product backlog的浪費(fèi)遠(yuǎn)大于價(jià)值本身，所以我們必須不斷的維護(hù)產(chǎn)品backlog。產(chǎn)品backlog由產(chǎn)品負(fù)責(zé)人提供，與Team進(jìn)行規(guī)模估算時(shí)，可能會(huì)拆分合并或者添加刪除故事，初始估計(jì)也由Team進(jìn)行評估提供估計(jì)值。產(chǎn)品所有者通常會(huì)向開發(fā)小組提出自己確定的優(yōu)先級(jí)順序，而小組也可能會(huì)請產(chǎn)品所有者根據(jù)他們對主題的評估對這個(gè)順序作出少量調(diào)整。

• 怎么寫故事

一般按照輕量級(jí)的故事來進(jìn)行描述需求。用戶故事是最基本的設(shè)計(jì)單元，它是從系統(tǒng)用戶或者客戶的角度出發(fā)對功能的一段簡要描述。用戶故事的形式很自由，沒有什么強(qiáng)制性的語法。但是，按照大致符合這樣一個(gè)形式來考慮 用戶故事是比較有益的：“作為【用戶的類型】，我希望可以【先這樣做，然后那樣做，就應(yīng)該得到…的結(jié)果】以便【業(yè)務(wù)價(jià)值】。”以這樣的模作為例子，可以得到一個(gè)用戶故事說：“作為購書者，我希望可以根據(jù)ISBN來找到一本書，以便能更快的找到正確的書。”在做用戶故事時(shí)，需要注意每個(gè)用戶故事用的是用戶的語言，它只描述一個(gè)功能（feature），而且每個(gè)用戶故事的開發(fā)周期不要太長（1－5天）

我們不需要一開始對所有的故事都進(jìn)行詳細(xì)的描述，但計(jì)劃放在下一個(gè)sprint中的故事應(yīng)該比較清楚。可以按照硝煙一書中的表格來寫backlog的故事：

• ID為一個(gè)唯一標(biāo)識(shí)，確定后最好固定不變，在其他工作或者文檔中想引用故事就使用這個(gè)ID來引用
• Name2到10個(gè)字，通過簡單的描述來說明故事，如果要很多字才能表達(dá)這個(gè)故事，那很有可能這個(gè)故事太大，或者不清楚
• 重要性?這個(gè)優(yōu)先級(jí)決定了sprint選擇的故事，優(yōu)先級(jí)越高的越早實(shí)現(xiàn)
• 初始估算?這個(gè)由Team來根據(jù)故事描述內(nèi)容來估算，產(chǎn)品負(fù)責(zé)人講解完故事后，Team對不清楚的進(jìn)行詢問，大概了解后進(jìn)行粗略估算。從估算的角度出發(fā)，故事不應(yīng)該太短，但也不能太過于詳細(xì)，不需要把具體的規(guī)則和算法寫進(jìn)去。
• How do demo?從用戶視角，從操作層面進(jìn)行講解這個(gè)故事如何通過軟件來演示，也可以作為一個(gè)簡單的測試用例了。重要性高的backlog條目都要填寫”如何演示“。
• Notes相關(guān)信息、解釋說明和對其他資料的引用等，一般都非常簡短。

有時(shí)我還會(huì)增加一個(gè)分類列來標(biāo)識(shí)出故事的主題，通過主題來從更大視角來查看需求主要內(nèi)容，后期也可以根據(jù)主題的優(yōu)先級(jí)來初始確定故事的優(yōu)先級(jí)。

INVEST in Good Stories, and SMART Tasks

如何溝通故事

• 
  

總結(jié)

以上是生活随笔為你收集整理的Scrum 之 product Backlog的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。