Scrum and XP的實戰經驗 - 2. 我們如何紀錄產品的Backlog (2)
Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
故事中其他的欄位
有時候我們會使用其他欄位, 方便讓產品負責人來判斷優先順序
# 軌道 (Track): 對這故事的簡單分類, 像是: "後端系統", 或是 "最佳化". 產品負責人可能容易過濾出, 屬於"最佳化"種類的故事出來, 然後把他們的須先順序設定比較低
# 元件(Components): 通常會利用excel中的checkboxes來實現. 例如: "database, server, client". 這裡整個團隊或是產品負責人, 可以標示哪個技術元件可以用來實作這個故事. 當你有多個scrum團隊時, 這是非常有用的一個技巧. 像是, 後端系統的團隊, 客戶端系統的團隊, 可以很方便讓每個團隊知道, 他們需要實作哪些故事.
# 請求者(Requesters): 產品負責人可以記錄, 起初是哪個客戶, 或是關係厲害人提出這項需求, 以方便之後回報目前處理的進度
# 錯誤案例追蹤代碼(Bug tracking ID): 如果你有錯誤案例追蹤系統, 像是我們用Jira一樣, 方便讓你追蹤故事和錯誤案例之間的關連
如何讓我們的產品backlog保留在商業應用層次
如果產品負責人有技術的背景, 那他可以添加一個故事: "把Event表格增加index". 為什麼他需要這個呢? 真正背後可能的原因, 是希望在後端系統中, 能加快搜尋事件表單的反應速度.
但也有可能完全並不是那回事, 表單變慢的瓶頸不見得是index. 所以產品負責人還是只關注在商業的需求上面, 而開發團隊才是解決這些技術問題的合適人選.
當我看到一些技術導向的故事出現, 我一般都會問產品負責人, 一些"但是為什麼呢?"的問題, 直到我們真正了解潛在的目地為止. 然後才用真正的目的, 來改寫這個故事.(加快後端系統中, 搜尋事件表單的反應速度), 原先技術導向的敘述只會放在註解中以供參考 ("對event表格增加index可能會解決這個問題")
留言列表
