在SCRUM方法中明確要求了3個文檔：
      1 product backlog

2 sprint backlog

3 burn-down chart

Product backlog 中列舉了本項目應(yīng)該實現(xiàn)的需求，需求采用了用戶故事的方式進行描述，用戶故事是一句簡短的采用用戶熟悉的術(shù)語表達的需求，是用戶講給開發(fā)人員的故事，不是開發(fā)人員講給用戶的故事。既然是故事，就要有人講，誰講呢，是product owner來講，每次講時可能就有細節(jié)的不同，就要有變化，但是萬變不離其宗，所以故事本身是有一定的彈性的。故事可以有標(biāo)準(zhǔn)的格式，我稱之為三段論式故事，哪三段呢？

1 用戶角色

2 需要的功能

3 目的

比如，有這樣一個故事：

作為一個家庭主婦，我需要一個30平米的餐廳，以便于我可以招待10位朋友來用餐。

用戶角色是家庭主婦，30平米的餐廳是功能需求，招待10位朋友用餐是為什么需要這個功能。千萬不要小看這個三段論式的故事，需要仔細琢磨每一段的作用。用戶角色表明了是誰使用這個功能，如果一個功能沒有明確的使用者，是否可以刪除呢？如果一個用戶角色不重要，是否這個需求的優(yōu)先級比較低呢？目的說明了為什么需要這個功能，這個功能解決了什么問題，如果一個功能沒有明確的目的，那是否可以刪除呢？如果目的不太關(guān)鍵，這個需求是否可以優(yōu)先級比較低呢？

優(yōu)先級？沒錯，我多次提到了優(yōu)先級，需求一定要分優(yōu)先級！誰來劃分需求的優(yōu)先級？Product owner！如何劃分優(yōu)先級？根據(jù)商業(yè)價值！根據(jù)對客戶、對最終用戶的商業(yè)價值來劃分優(yōu)先級。如何區(qū)分商業(yè)價值的大小呢？比如提問如果不實現(xiàn)此需求，如果晚實現(xiàn)此需求客戶是否會不滿意，是哪類人不滿？不滿意到什么程度？也有的專家提出了更專業(yè)的方法，其實沒必要，如果product owner真的稱職的話，相信他，可以憑經(jīng)驗劃分出優(yōu)先級。

是否僅僅描述了這樣一句話就充分了呢？其實還有第四段，即用戶故事的驗收標(biāo)準(zhǔn)，或者叫用戶故事的測試要點，這也是由product owner來完成的，product owner可以先完成前三段，在和team member的溝通過程中，逐步豐富完善驗收標(biāo)準(zhǔn)。對于前面我們提到的那個故事，如果你實現(xiàn)了這樣一個餐廳，比如是一個2米寬，15米長的餐廳，那位家庭主婦會如何想？哈哈，如果她心理健康的話，估計她立馬讓你跳樓！如果她心理不健康的話，她會跳樓的。當(dāng)然在敏捷的方法中不會出現(xiàn)這種現(xiàn)象，在你開發(fā)的過程中，product owner會和你隨時溝通交流的，在溝通中product owner還傳達了這樣的信息：

1我希望這個餐廳是5米*6米；

2我希望這個餐廳光線明亮；

3我希望這個餐廳靠近廚房；

4 ......

這就是驗收標(biāo)準(zhǔn)！也可以換一種角度，從如何驗收的角度的來描述：

1 我會量量這個房間是否是5米*6米的；

2 我會測測如果在這個房間里白天打撲克，不開燈的話，能否看到撲克的花色和點數(shù)；

3 我會測測從廚房到餐廳需要走幾步；

4 ......

如果一個故事提不出來驗收標(biāo)準(zhǔn)怎么辦呢？不實現(xiàn)它，晚實現(xiàn)它，直到明確了驗收標(biāo)準(zhǔn)。

到目前為止我們實際講了在product backlog中包含了5段：

Product backlog = 需求 + 優(yōu)先級

= 用戶故事 + 優(yōu)先級 + 驗收標(biāo)準(zhǔn)

= 用戶角色 + 功能 + 目的 + 優(yōu)先級 + 驗收標(biāo)準(zhǔn)

有的專家把驗收標(biāo)準(zhǔn)單列出來，我認為驗收標(biāo)準(zhǔn)是需求的一部分，只不過換了一種描述方式而已，所以還是作為product backlog的一部分吧。

前面我一直在提“功能”二字，沒有提非功能的需求，如果有非功能的需求怎么辦？兩種處理辦法，一是如果能明確到某個故事，就描述在故事的驗收標(biāo)準(zhǔn)中，二是寫一個“技術(shù)故事”，單列出來，提醒開發(fā)人員注意這些故事，這個故事未必是product owner提出的。

對于用戶故事我們希望能達到如下的理想：

1）獨立性。盡可能避免故事之間存在依賴關(guān)系，故事間存在依賴關(guān)系會造成劃分優(yōu)先級的困難，在安排開發(fā)順序時需要考慮故事之間的依賴關(guān)系。

2）可協(xié)商性。故事是可協(xié)商的，故事是有彈性的，故事是需要講的，不是必須實現(xiàn)的書面合同或者需求。

3）對用戶或者客戶有價值。確保每個故事對客戶或用戶有價值的最好方式是讓用戶編寫故事。

4）可預(yù)測性。開發(fā)者應(yīng)該能夠預(yù)測（至少大致猜測）故事的規(guī)模，以及編碼實現(xiàn)所需要的時間。

5）短小精悍。一般一個故事在一個迭代周期內(nèi)一定是可以實現(xiàn)的，而我們提倡短周期迭代。

6）測試性。所編寫的故事必須是可測試的，能夠定義出驗收標(biāo)準(zhǔn)。

注意，這是理想！

Product backlog在項目進展過程中是會發(fā)生變化的，只有product owner有權(quán)來修改此文檔。你可以用EXCEL文件來描述它，也可以采用一些敏捷項目管理的工具來幫助你維護，或者使用一些缺陷的跟蹤工具如JIRA之類的，最直觀的最樸素的辦法是采用不干貼紙，直接貼在辦公室的白板上，讓大家都能隨時看到！