Scrum and XP from the Trenches - How we do Scrum
Henrik Kniberg
http://www.crisp.se/ScrumAndXpFromTheTrenches.html
把故事拆解成更小的故事
故事不應該太小或是太大(以評估的角度來看). 如果你有一堆0.5故事點數的故事, 你可能會是微觀管理的受害者. 另一方面, 若是你有40 故事點數的故事, 則代表你有高度風險會只做完一部分的故事而已. 那對你公司是沒有價值的, 並增加管理上的負擔. 進一步來說. 如果你們所評估的速度是70, 可是有兩個高優先順序的故事是40, 那這個規劃就非常困難. 你可能有兩種選擇: 承諾不足(under-committing),意味你只選擇一個;或過度承諾(over-committing), 意味你選擇都做.
我發現多數大的故事可以拆解成小的故事. 只要確認小的故事依然能有商業價值即可
我們一般都確保故事在2-8人天內可以做完, 我們的速度通常大約是在40-60之間, 所以我們大約在每個sprint中可以完成10個故事左右. 有時候少到5個, 有時候多到15個左右. 不過這些數量都是用索引卡來管理可以負荷的
把故事拆解成任務
等一下, 故事和任務的區別是什麼? 這是一個非常好的問題
這個區別很簡單. 故事是可以交付的東西, 是產品負責人所關心的. 任務不是可以交付的項目, 並且產品負責人也不在乎.
這裡是把一個故事拆解成更小的故事的例子
這裡是把一個故事拆解成任務的例子
這裡我們看到一些有趣的事情:
# 新的scrum團隊通常不願意花時間, 事先把一堆故事拆解成任務. 有些人覺得這像是waterfall的方法
# 對於了解非常清楚的故事, 事前拆解或是之拆解都是一樣容易的
# 這樣的拆解, 通常會找出一些額外的工作, 讓原先估算的時間變長, 但可以讓sprint計畫更接近真實.
# 這種事先的拆解, 可以讓每日的scrum會議有顯著的效率 (可參考第八章 我們怎樣進行每日會議)
# 即使這樣的拆解不夠準確, 開始進行後也許馬上就要被修正, 但是之前拆解後的好處還是有用的
所以, 我們試圖將sprint規劃會議的時間拉到夠長, 以確保有時間進行任務的拆解. 如果時間不夠了, 我們可能就不做了 (請看後面的 "最後的底限在哪裡")
注意 - 我們在實踐TDD(Test Driven Development), 也就是對於每個故事, 第一件任務就是"撰寫一個失敗的測試", 而最後一個任務是"重構" (= 改進程式的可讀性和移除重複的地方)
定義每日會議的時間和地點
Sprint規劃會議有一個經常被遺忘的產出, 就是"事先規劃好的每日會議時間和地點". 沒有這一點
第一次每日會議是非常重要的開始, 每個成員會決定要怎麼開始工作. 沒有這樣, 你的sprint將會有一個不好的開始
我比較喜歡早上開會, 但是, 我必須承認, 我們並沒有嘗試過在中午或是下午, 進行過每日會議.
在下午開每日會的缺點是: 當你早上開始工作, 你必須試圖去回想, 你昨天告訴別人你今天要做什麼
在上午開每日會的缺點是: 當你早上開始工作, 你必須試圖去回想, 你昨天做了什麼, 這樣才能告訴別人.
我的看法是, 第一個缺點比較糟, 因為重要的事是要知道你今天要做什麼, 而不是你已經做了什麼
我們預設的作法是選擇一個大家都不會有意見的最早時間. 通常是9:00, 9:30或是10:00. 最重要事情是, 這是每個人都能接受的時間.
留言列表
