如何編寫產品backlog
產品 backlog 是 Scrum 的核心,也是一切的起源。從根本上說,它
就是一個需求、或故事、或特性等組成的列表,按照重要性的級別
進行了排序。它裏面包含的是客戶想要的東西,並用客戶的術語加
以描述。
backlog一般包含這幾個字段
- ID-----統一標識符,一個自增長數字
- Name ----- 簡短的描述性故事名
- Importance-----重要性
- Inisital estimate ---- 團隊初步估算工程量(包括story point ,一般大致相當於一個“理想的人天----man day”)
- How to demo -----它大略描述了這個故事應
該如何在 sprint 演示上進行示範,本質就是一個簡單的測
試規範。“先這樣做,然後那樣做,就應該得到……的結
果 ”。
o 如果你在使用 TDD(測試驅動開發),那麼這段
描述就可以作爲驗收測試的僞碼錶示。 - Notes — 相關信息、解釋說明和對其它資料的引
用等等。一般都非常簡短。
額外的故事字段
有時爲了便於產品負責人判斷優先級別,我們也會在產品 backlog
中使用一些其它字段。
ƒ Track(類別)——當前故事的大致分類,例如“後臺系統”
或“優化”。這樣產品負責人就可以很容易選出所有的“優
化”條目,把它們的級別都設得比較低。類似的操作執行
起來都很方便。
ƒ Components(組件)——通常在 Excel 文檔中用“複選框”
實現,例如“數據庫,服務器,客戶端”。團隊或者產品
負責人可以在這裏進行標識,以明確哪些技術組件在這個
故事的實現中會被包含進來。這種做法在多個 Scrum 團隊
協作的時候很有用——比如一個後臺系統團隊和一個客戶
端團隊——他們很容易知道自己應當對哪些故事負責。
ƒ Requestor(請求者)——產品負責人可能需要記錄是哪個
客戶或相關干係人最先提出了這項需求,在後續開發過程
中向他提供反饋。
ƒ Bug tracking ID(Bug 跟蹤 ID)——如果你有個 bug 跟蹤
系統,就像我們用的 Jira 一樣,那麼瞭解一下故事與 bug
之間的直接聯繫就會對你很有幫助。