十三、產(chǎn)品Backlog
對需求的概要描述會在項目早期收集，但在那個時候它們只是最粗略的描述，然后在項目進行過程中逐步完善
產(chǎn)品Backlog包括所有待添加功能的列表，它由產(chǎn)品負(fù)責(zé)人維護，并根據(jù)優(yōu)先級按順序保存，它具有很高的動態(tài)性，其中的事項會被增加或減少，同時在每個Sprint中，這些事項會因為對產(chǎn)品、用戶和團隊等有更多的了解而重新排列優(yōu)先級
從文檔到討論的轉(zhuǎn)變
書面文檔會讓你暫停做出判斷
有了書面文檔，我們就不能像談話時那樣反復(fù)聲明要表達的意思
書面文檔不利于團隊責(zé)任制
1、切勿良莠不分
可工作的軟件勝過全面的文檔
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?——敏捷宣言
在交付產(chǎn)品時，伴隨它的是產(chǎn)出的代碼和自動化的測試用例
文檔應(yīng)用于捕捉交談記錄使其不被忘記
2、在產(chǎn)品Backlog中使用用戶故事
用戶故事通常遵循一個簡單的模板：作為一個《用戶類型》，我想《某個目標(biāo)》，以便于《一些原因》
用戶故事可作為開發(fā)與PO的承諾：開發(fā)答應(yīng)PO在他們開發(fā)該用戶故事前將與PO討論，而PO答應(yīng)團隊，當(dāng)團隊準(zhǔn)備討論時它保證將有時間參與
持續(xù)地提煉需求
不管我們在項目的開始階段工作多長時間或多么努力來確認(rèn)所有需要的功能，我們都不能成功，因為總有一些只有在系統(tǒng)成型后用戶或開發(fā)人員才會想到的東西
1、涌現(xiàn)的需求
不能提前確認(rèn)的功能被稱作涌現(xiàn)的需求
Scrum團隊承認(rèn)，不管團隊成員如何小心謹(jǐn)慎地做計劃，需求都會涌現(xiàn)，同時涌現(xiàn)的需求會被看作是計劃太早進行或包含太多細(xì)節(jié)導(dǎo)致的結(jié)果，而不會將它們當(dāng)作計劃的某種失敗
我們最好根據(jù)功能要被實現(xiàn)的時間，采用不同精確程度的方式來規(guī)定功能需求，而不是一開始就為了它的完整性而苦苦掙扎
2、產(chǎn)品Backlog冰山
1）梳理產(chǎn)品Backlog
團隊需要去梳理或照顧它的產(chǎn)品Backlog，應(yīng)花每個Sprint的10%精力梳理，以便為下一個Sprint作準(zhǔn)備
大功能被分成小的功能，并且細(xì)節(jié)會在小的功能加入Backlog后添加
如果團隊認(rèn)為比較靠下的事項會對它們上面的事項有影響，那么他們應(yīng)花精力來理解它
3、為什么要持續(xù)地提煉需求？
1）事情會發(fā)生變化——優(yōu)先級與重要程度會反復(fù)變化
2）不需要——即將開發(fā)的條目要給予足夠的可見性，以便讓團隊看得更遠(yuǎn)，從而避免大部分問題
3）時間有限——幾乎所有的項目都有時間限制，同等對待所有的需求是一種浪費
4、對用戶故事的持續(xù)提煉
大型用戶故事需要可以被拆分成小用戶故事，從而確保在每個Sprint中實現(xiàn)
大故事被拆分后，需要立即廢棄
一些大需求因為太多，所以它們要被拆分成稍小的大需求
通過加入滿意條件來持續(xù)提煉可幫助團隊，讓他們知道PO對該功能的期望
學(xué)會在沒有詳細(xì)說明書的情況下開始
在寫一份文檔前，問問自己是否愿意一直更新該文檔
1、通過事例說明
通過討論和事例的組合來解釋這種詳細(xì)的需求，可以增加產(chǎn)品負(fù)責(zé)人要求的東西正是開發(fā)人員正在創(chuàng)建的系統(tǒng)的可能性
事例最理想的狀態(tài)是轉(zhuǎn)化為自動化測試
2、跨職能的團隊能降低對文檔的需求
從某個文檔受益的人應(yīng)該是那個寫文檔的人，開發(fā)編寫給測試的說明書，應(yīng)由測試?yán)^續(xù)維護更新
創(chuàng)建DEEP的產(chǎn)品Backlog
Backlog的幾個關(guān)鍵屬性
D詳略得當(dāng)——當(dāng)前Sprint的用戶故事，充分詳細(xì)；不著急開發(fā)的要簡略
E做過估算的——靠前的規(guī)劃精確，靠后的估算大略
E涌現(xiàn)的——隨著時間的推移、了解的深入，用戶故事會增加、移除與重排
P排列優(yōu)先級的——價值由高到低，始終根據(jù)優(yōu)先級開發(fā)
不要忘記討論
產(chǎn)品Backlog不在于寫，而在于經(jīng)常討論
