Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
訂定sprint的長度
- 5月 17 週日 200917:20
Scrum and XP的實戰經驗 Ch4 (2)
Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
訂定sprint的長度
- 5月 16 週六 200907:18
Scrum and XP的實戰經驗 Ch4 (1)
Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
4. 我們如何產生sprint計畫
Sprint規劃是非常重要的會議, 應該算是Scrum中最重要活動(當然啦, 這是我個人的意見). 執行不好的sprint規劃會議, 將會毀掉整個spint.
- 5月 13 週三 200909:17
Scrum and XP的實戰經驗 Ch3
3. 我們如何準備Sprint的規劃
Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
- 5月 11 週一 200909:48
Scrum and XP的實戰經驗 Ch2 (2)
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可能會解決這個問題")
- 5月 11 週一 200909:31
Scrum and XP的實戰經驗 Ch2 (1)
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): 其他相關的資訊, 解釋, 參考資料等等, 一般來說都很簡短
