Scrum and XP的實戰經驗 - 2. 我們如何紀錄產品的Backlog
Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
2. 我們如何紀錄產品的Backlog
產品的Backlog是整個Scrum中的核心, 也是所有東西的起源. 基本上來說, 它是由需求, 故事或是功能等, 所組成的一個依重要性排列的列表. 它裡面是用客戶的術語, 來描述客戶所想要的東西, 我們稱這些叫做故事(Stories), 有時候也叫做Backlog項目.
我們的故事包含以下欄位
# 編號 (ID): 一個唯一的識別號碼, 號碼會自動增加, 若是我們之後改變故事名稱, 它可以避免我們找不到.
# 名稱(Name): 由簡潔, 有敘述性的句子來表示故事. 例如: "查看交易的歷史紀錄". 它必須要夠清楚, 才能讓程式設計師和產品負責人, 大致了解我們講的東西是什麼, 並且也可清楚區分他和其它故事的差別. 正常來說大約是由2~10字所組成.
# 重要性 (Importance): 產品負責人要評估故事的重要性, 例如: 10 或是 150, 數字越高代表越重要.
* 我企圖避免使用"優先順序(Priority)"這個說法, 通常1代表最高優先順序, 可是如果後來有其高更重要的事情, 那他的優先順序應該要是什麼? 要給0 或是 -1?
# 初始估算 (Initial estimate): 只團隊最初對他的估算, 認為與其它故事相比, 完成這個故事所需要付出的代價為何. 最小單位是用故事點數(Story point)來表示, 通常會用多少人天(man-day)來約略估算
* 可問大家: "如果有適當的人員來開發這個故事(不會太多也不會太少, 通常是兩位), 並且把他們關到一間房間, 有很多食物, 然後沒有打攪. 那需要幾天才能交出一個完整, 可以展示, 並且已經經過驗證的, 可以交付的實作結果呢?". 如果答案是"把三個人關在一起, 大約需要4天", 則故事點數的初估值就是12.
* 重要的是這裡並不是絕對值(也就是2 個故事點數就是代表要花兩天), 而是一個相對值. (也就是說, 2個故事點數所要花的時間, 會是4個故事點數的一半)
# 如何展示 (How to demo): 大略描述這個故事, 在sprint的展示會議上要如何被展示. 它基本上是一個簡單的測試規格書. "先做這個, 再做那個, 然後這個功能就完成"
* 如果你有實作測試先行的開發方式(TDD), 那麼這段說明就可以變成你驗收測試(acceptance test)程式的虛擬碼(pseudo code)
# 註解 (Notes): 其他相關的資訊, 解釋, 參考資料等等, 一般來說都很簡短
我們嘗試過很多欄位, 但是最後發現, 上面這六個欄位是我們一直採用下去
通常我們會把它存放在共享的Excel中 (這樣可以多個使用者同時去編輯它). 依官方說法, 產品負責人擁有和負責這份文件, 但是我們並不想讓其他人不能接觸他, 因為很多時候, 測試開發人員需要查詢這份文件, 以釐清一些事情, 或是改變原先的估算
同理, 我們並沒有把它放在版本控制工具的資料庫中; 相反的, 我們把他放到共用的檔案夾中. 這樣是最簡單方法, 可以避免在同時編輯下, 造成lock或是merge的問題.
但是, 大部分其他欄位, 我們都有還是有保留在版本控制工具的資料庫中
留言列表
