把故事拆解成更小的故事
故事不應該太小或是太大(以評估的角度來看)。如果你有一堆0.5故事點數的故事，你可能會是微觀管理的受害者。另一方面，若是你有 40 故事點數的故事，則代表你有高度風險會只做完一部分的故事而已。那對你公司是沒有價值的，並增加管理上的負擔。進一步來說。如果你們所評估的速度是 70，可是有兩個高優先順序的故事是 40，那這個規劃就非常困難。你可能有兩種選擇：承諾不足，意味你只選擇一個；或過度承諾，意味你選擇都做。
我發現多數大的故事可以拆解成小的故事。只要確認小的故事依然能有商業價值即可
我們一般都確保故事在2-8人天內可以做完，我們的速度通常大約是在40-60之間，所以我們大約在每個Sprint中可以完成10個故事左右。有時候少到5個，有時候多到15個左右。不過這些數量都是用索引卡來管理可以負荷的
一個 sprint 中做5 到 15 個故事，是一個有用的準則。小於 5 個通常表示故事太大了。而多餘 15 個，則表示團隊拉太多故事，會無法完成每件事情。（或是故事太小，造成微觀管理）
把故事拆解成任務
等一下，故事和任務的區別是什麼？ 這是一個非常好的問題。
這個區別很簡單。故事是可以交付的東西，是產品負責人所關心的。任務不是可以交付的項目，並且產品負責人也不在乎。
這裡是把一個故事拆解成更小的故事的例子：
這裡是把一個故事拆解成任務的例子：
這裡我們看到一些有趣的事情：
• 新的Scrum團隊通常不願意花時間，事先把一堆故事拆解成任務。有些人覺得這像是waterfall的方法。
• 對於了解非常清楚的故事，事前拆解或是之後拆解都是一樣容易的。
• 這樣的拆解，通常會找出一些額外的工作，讓原先估算的時間變長，但可以讓Sprint計畫更接近真實。
• 這種事先的拆解，可以讓每日的Scrum會議有顯著的效率 (可參考第八章 我們怎樣進行每日會議)。
• 即使這樣的拆解不夠準確，開始進行後也許馬上就要被修正，但是以上所提到的好處還是可以獲得的。
所以，我們試圖將Sprint規劃會議的時間拉到夠長，以確保有時間進行任務的拆解。如果時間不夠了，我們可能就不做了 (請看後面的 "最後的底限在哪裡")。
任務拆解是一個很好的機會，去找出之間的相依性 – 像是”我們需要存取生產線上的日誌” 或 “我們需要 HR Jim 的幫助” – 並且來找出對付這些相依性的方法。也許是打個電話給 Jim，看看他是否能在這個 sprint 中保留時間給我們。越早發現這些相依性，越有可能避免讓它搞砸你的 sprint。
注意 - 我們在實踐TDD(Test Driven Development)，也就是對於每個故事，第一件任務就是"撰寫一個失敗的測試"，而最後一個任務是"重構" (= 改進程式的可讀性和移除重複的地方)。
定義每日會議的時間和地點
Sprint規劃會議有一個經常被遺忘的產出，就是"事先規劃好的每日會議時間和地點"。第一次每日會議是非常重要的開始，每個成員會決定要怎麼開始工作。沒有這樣，你的sprint將會有一個不好的開始。
我比較喜歡早上開會，但是，我必須承認，我們並沒有嘗試過在中午或是下午，進行過每日會議。
現在我有中午或下午的每日會議，運行的還不錯。就讓團隊來決定吧。如果不確定，就做實驗吧。雖然大部份的團隊比較喜歡早上。
在下午開每日會的缺點是： 當你早上開始工作，你必須試圖去回想，你昨天告訴別人你今天要做什麼。
在上午開每日會的缺點是： 當你早上開始工作，你必須試圖去回想，你昨天做了什麼，這樣才能告訴別人。
我的看法是，第一個缺點比較糟，因為重要的事是要知道你今天要做什麼，而不是你已經做了什麼。
我們預設的作法是選擇一個大家都不會有意見的最早時間。通常是9：00，9：30或是10：00。最重要事情是，這是每個人都能接受的時間。
哪裡是最後的底限
好的，現在時間已經用完了。照理說，所有事情要在Sprint規劃會議中完成，如果我們時間不夠，那麼我們應該要把哪些事情砍掉呢？
嗯，我會使用以下規則，來決定要做事情的優先順序：
順序 1： Sprint的目標和展示的時間。這是你開始一個Sprint最基本該有的東西。團隊需要有個目標，和一個結束的日期，然後他們就可以根據產品backlog正確運作。是的，有點扯。你應該考慮規劃一下明天再開一次Sprint規劃會議。但是如果你真的需要馬上開始Sprint，或許這樣就可以。不過，老實說，我從來沒有試過在這麼少資訊下開始Sprint的。
順序2： 列出哪些故事是團隊接受要在這個Sprint中處理的。
順序3： 填寫Sprint中每個故事的估算值
順序4： 填寫Sprint中每個故事的"如何展示" 。
順序5： 速度和資源計算，當作你Sprint計畫中的實現檢查(reality check)。包括團隊成員的清單，以及他們的承諾。(否則你就無法計算速度)。
保持簡單，以及在較高層次，最多花五分鐘來做。詢問：”從人員配置的角度來看，這次的 sprint 和上次的 sprint，主要不同的地方在哪?” 如果沒有， 就使用昨日氣象。如果有，就根據現狀加以調整。
順序6： 描述每日會議的時間和地點。它將會花點時間去決定，如果你時間不夠用，Scrum master可以先決定，在會議後以mail通知所有人。
順序7： 把故事拆解成任務。這個拆解也可以在每日會議上去做，不過它會有點影響到Sprint進行的流程。
全站熱搜
留言列表
