Product Backlog
在專案一開始時，需要有一份要處理的工作項目。在傳統專案中，我們會使用需求規格書，或是者是使用個案。可是在Scrum的軟體開發中，我們使用的是Product backlog這個東西。你會問說這又是什麼新的名詞呢？讓我們來看看大家怎麼定義它：
A. Wiki上的定義
- 對於整個專案來說，它是一個較高層次(high-level)的文件。
- 包含了所有想要功能的描述，或者是wish-list等等。
- 是根據商業價值來排定優先順序
- 它列出了“什麼”東西要被建構
- 它是一份公開並且是任何人可以來編輯修改的文件，每個項目有對應的大約商業價值，以及所需的開發代價
來源：http://en.wikipedia.org/wiki/Scrum_(development)
B. Scrum Alliance上的定義
- 它是系統的需求
- 可以視為是由一堆排好優先順序的項目所組成
- 包含了客戶功能性和非功能性的需求
- Product backlog內容的來源會有很多個
- 產品負責人(product owner)需負責排定product backlog內項目的優先順序
來源：http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1125
C. Mike Cohn下的定義
- 是產品中所有想要的功能的主要列表
- 每當從客戶或是產品中學習到新的經驗，便可以新增或是修改Product backlog的內容。
- 在Scrum的backlog只是簡單地列出我們想要做的事情
所以根據以上的定義，我們可以得知Product backlog有以下的特性：
- 較高優先順序的項目會放在前面
- 較高優先順序的項目通常比較小、比較詳盡、比較特殊化
- 較低優先順序的項目通常比較大、比較不清楚、比較一般化
- Backlog的項目可以隨時修改優先順序
- Backlog的項目可以隨時被移除
留言列表
