Product Backlog源自于Scrum方法，是指產(chǎn)品待辦事項(xiàng)的集合，其中事務(wù)有優(yōu)先級判斷，先處理優(yōu)先級高的事項(xiàng)。那么，如何制定Product Backlog呢？
Product backlog是一個(gè)敏捷團(tuán)隊(duì)管理開發(fā)過程的核心，所有的活動和交付物都圍繞Product backlog來進(jìn)行。在制定Product backlog的過程中會遇到很多問題，接下來，我們將結(jié)合Worktile敏捷開發(fā)實(shí)例，帶大家一起學(xué)習(xí)如何制定Product backlog 。
一、Product backlog和用戶故事
Product backlog是Scrum的核心，也是一切的起源。它是由Product Owner負(fù)責(zé)制定的一個(gè)按照重要性的級別排序的用戶故事列表。
規(guī)模較小的用戶故事可以直接加入Product backlog；規(guī)模較大的用戶故事要先拆分，再加入Product backlog進(jìn)行迭代。
用戶故事是一句簡短的、采用用戶熟悉的術(shù)語表達(dá)的需求，是Product owner講給開發(fā)人員的故事，含有一定業(yè)務(wù)價(jià)值的端到端交付。
用戶故事是描述對用戶有價(jià)值的功能，一個(gè)好的用戶故事應(yīng)該包括角色、功能和商業(yè)價(jià)值三個(gè)要素。
- 角色：到底是誰要使用這個(gè)功能，這個(gè)功能是為誰而設(shè)計(jì)的？
- 功能：這個(gè)功能是怎樣的，要達(dá)到什么程度？
- 商業(yè)價(jià)值：為什么要這個(gè)功能，這個(gè)功能最后能帶來什么有益的商業(yè)價(jià)值，對用戶來說有什么意義？
一般我們在描述一個(gè)用戶故事的時(shí)候會按照以下格式：
作為一個(gè)<角色>, 我想要<功能>, 以便于<商業(yè)價(jià)值>。
比如：作為一個(gè)“項(xiàng)目經(jīng)理”，我想要“有快捷方法把所有項(xiàng)目生成甘特圖”，以便于“項(xiàng)目管理和查看所有項(xiàng)目進(jìn)度。”
需要注意的是用戶故事不能夠使用技術(shù)語言來描述，要使用用戶可以理解的業(yè)務(wù)語言來描述。在Worktile中，我們用一個(gè)任務(wù)類型為“敏捷需求”的任務(wù)代表一個(gè)用戶需求。
二、如何編寫Product backlog或用戶故事
Product backlog一般由Product owner編寫，再確定優(yōu)先級，最后在Sprint plan meeting上和開發(fā)團(tuán)隊(duì)確認(rèn)。但有時(shí)研發(fā)團(tuán)隊(duì)也會寫，比如：作為研發(fā)人員，我需要寫一個(gè)操作緩存的模塊，這就是研發(fā)initial的backlog。
用戶故事看似簡單，但是其實(shí)是很難寫。比如：作為會議管理員，可以查看所有用戶的提問，以便了解哪些用戶發(fā)表的評論?？瓷先ミ@種價(jià)值描述不錯(cuò)，但是如果系統(tǒng)只是為了查看的話，會議管理員為什么要查看？如果評論很多，他如何查看？
所以用戶故事的價(jià)值描述其實(shí)是給需求分析做了一些價(jià)值挖掘的要求，團(tuán)隊(duì)要去挖掘角色做這一動作的價(jià)值，并為角色挖掘出必要且合理的理由。
用戶故事具備以下六個(gè)特征：
1. 獨(dú)立性（Independent）：要盡量避免故事間的相互依賴。在對故事排列優(yōu)先級時(shí)，或者使用故事做計(jì)劃時(shí)，故事間的相互依賴會導(dǎo)致工作量估算變得更加困難。通?？梢酝ㄟ^兩種方法來減少依賴性：
- 將相互依賴的故事合并成一個(gè)大的、獨(dú)立的故事；
- 用一個(gè)不同的方式去分割故事。
2. 可討論性（Negotiable）：故事卡是功能的簡短描述，細(xì)節(jié)將在客戶團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)的討論中產(chǎn)生。故事卡的作用是提醒開發(fā)人員和客戶進(jìn)行關(guān)于需求的對話，它并不是具體的需求本事。一個(gè)用戶故事卡帶有了太多的細(xì)節(jié)，實(shí)際上限制了和用戶的溝通。
3. 對用戶或客戶有價(jià)值的（Valuable）：用戶故事應(yīng)該很清晰地體現(xiàn)對用戶或客戶的價(jià)值，最好的做法是讓客戶編寫故事。一旦一個(gè)客戶意識到這是一個(gè)用戶故事并不是一個(gè)合同，而且可以進(jìn)行協(xié)商的時(shí)候，他們將非常樂意寫下故事。
4. 可估算的（Estimable）：開發(fā)團(tuán)隊(duì)需要去估計(jì)一個(gè)用戶故事以便確定優(yōu)先級，工作量，安排計(jì)劃。但是讓開發(fā)者難以估計(jì)故事的問題來自：
①開發(fā)人員缺少領(lǐng)域知識；
②開發(fā)人員缺少技術(shù)知識；
③故事太大了。
5. 小的（Small）： 一個(gè)好的故事在工作量上要盡量小，最好不要超過10個(gè)理想人/天的工作量,至少要確保的是在一個(gè)迭代或Sprint中能夠完成。用戶故事越大，在安排計(jì)劃，工作量估算等方面的風(fēng)險(xiǎn)就會越大。
6. 可測試的（Testable）：故事必須是可測試的。成功通過測試可以證明開發(fā)人員正確地實(shí)現(xiàn)了故事。如果一個(gè)用戶故事不能夠測試，那么你就無法知道它什么時(shí)候可以完成。一個(gè)不可測試的用戶故事例子：用戶必須覺得軟件很好用。
在很多項(xiàng)目中，Product owner只是從一個(gè)角度編寫Product backlog，這樣往往容易忽略很多需求。所以在編寫用戶故事前要識別用戶角色和虛擬人物(Personal)，從不同角度編寫Product backlog 。
以下是招聘網(wǎng)站可能出現(xiàn)的用戶角色列表：
三、如何確定Sprint backlog的優(yōu)先級
編寫完P(guān)roduct backlog后，Product Owner需要對需求進(jìn)行優(yōu)先級的評定，根據(jù)優(yōu)先級從高到低依次作為Sprintbacklog。評定標(biāo)準(zhǔn)由Product Owner定。
對于一些無法估算時(shí)間成本的backlog，需要細(xì)化到一個(gè)能估算的backlog為止。
例如，此次的backlog是A功能，但要做A功能的時(shí)間無法估算，拆分A功能發(fā)現(xiàn)要做A需要先做B功能，可要做B功能的時(shí)間也無法估算，再拆分B功能發(fā)現(xiàn)要先做C功能，而C功能可以估算。這時(shí)的Backlog優(yōu)先級就是C→B→A。
需要注意的是，Sprintbacklog在項(xiàng)目進(jìn)展過程中是會發(fā)生變化的，只有Product owner有權(quán)來修改優(yōu)先級。
四、Worktile是如何管理Product backlog的
Worktile支持自定義任務(wù)類型，這表示客戶可以根據(jù)自己的需求，靈活配置任務(wù)的狀態(tài)／屬性信息，以及任務(wù)的工作流以及關(guān)聯(lián)關(guān)系等。Worktile中用一系列的標(biāo)簽來區(qū)分用戶故事的信息，需求來源對應(yīng)角色，任務(wù)名稱對應(yīng)功能，還可以自定義規(guī)模、優(yōu)先級等。
Worktile對Product backlog的管理，是按照以下幾個(gè)步驟進(jìn)行的：
- 通過收集社區(qū)、幫助中心、后臺的客戶反饋，由客戶成功整理出自客戶／產(chǎn)品／售后等渠道的用戶故事，由產(chǎn)品負(fù)責(zé)人細(xì)化為需求；
- 在Worktile中建立項(xiàng)目和需求任務(wù)；
- Pruduct owner整理需求池；
- 安排研發(fā)優(yōu)先級；
- 在Sprint plan meeting上Scrum團(tuán)隊(duì)溝通，給開發(fā)團(tuán)隊(duì)分配任務(wù)。
當(dāng)開發(fā)團(tuán)隊(duì)完成了Product backlog并不是就真正的結(jié)束了，還需要驗(yàn)收，或者叫用戶故事的測試要點(diǎn)，驗(yàn)收標(biāo)準(zhǔn)由Product owner自己決定或是在Sprint Review Meeting和開發(fā)團(tuán)隊(duì)一起決定，每個(gè)團(tuán)隊(duì)的驗(yàn)收標(biāo)準(zhǔn)都不一樣，有些團(tuán)隊(duì)以需求完成作為驗(yàn)收標(biāo)準(zhǔn)，有些團(tuán)隊(duì)以需求通過測試為驗(yàn)收標(biāo)準(zhǔn)，但總體的驗(yàn)收標(biāo)準(zhǔn)遵循DoD（Definition of Done）原則。
綜上，一個(gè)完整的Product backlog = 用戶故事+ 優(yōu)先級 + 驗(yàn)收標(biāo)準(zhǔn)。
愛盈利-運(yùn)營小咖秀(www.jza6.com) 始終堅(jiān)持研究分享移動互聯(lián)網(wǎng)App運(yùn)營推廣經(jīng)驗(yàn)、策略、全案、渠道等純干貨知識內(nèi)容；是廣大App運(yùn)營從業(yè)者的知識啟蒙、成長指導(dǎo)、進(jìn)階學(xué)習(xí)的集聚平臺；
想了解更多移動互聯(lián)網(wǎng)干貨知識，請關(guān)注微信公眾號運(yùn)營小咖秀（ID: yunyingshow）
