專案需求一直變動要如何開始第一個Sprint之做就對了

May 5 22:01~23:20

Teddy以前有位導入Scrum的客戶，由於接受導入輔導的團隊手邊同時還有案子要進行，因此許多活動的安排必須要配合專案的時程。在上完了「Scrum敏捷方法實作班」課程之後，又遇到客戶要準備出貨，因此導入顧問服務又往後延了一陣子。

在導入的過程中，由於客戶的專案時程變化的很快，因此Teddy原本計劃的導入時程也需要跟著調整。有一天Teddy問這個團隊的Product Owner們（這個團隊有兩位Product Owner（PO），這一點和Scrum的建議有點出入，細節日後有時間再說明）：

Teddy：請問我們的專案變動得很快，我們開始實施Scrum之後，有辦法兩周之內需求都不改變嗎？

PO1：嗯，可能有困難耶。有些需求與客戶討論的時間會比較長，可是一旦確定之後，經常是「馬上」就要動手做給對方。

Teddy：這樣啊…我們的sprint長度是兩周，所以平均算起來，一個很緊急的工作，需要等待一周的時間才可以被排入下個sprint。你們覺得等待一周的時間可以接受嗎？

PO1：這要看情況耶，如果很緊急的工作就不能等，有些沒那麼急的工作是還好。

PO2：我的情況也是一樣。

Teddy：所以就算是我們把sprint長度改成一周，平均等待時間變成2.5天，這樣也不符合我們應付緊急工作的需求嗎？

PO們：對啊。

此時Teddy心理的第一個念頭就是：「那你們要不要改採用Kanban算了，沒有sprint的限制對你們來說可能會比較自由」。但是仔細一想，採用Kanban不見得會比較好。

• 首先，除非看板的第一個階段的WIP永遠都沒有達到上限，否則就算是有新的緊急工作臨時插入backlog當中，也必須要等待第一個階段的某一項工作被做完，才可以再認領這個緊急工作。換言之，對於所謂的緊急工作還是無法達到立即施工的目的。
• 其次，雖然PO們依據以往經驗直覺認為緊急工作一定要馬上開工，但是對於這類的工作發生的頻率與比例有多高，並沒有詳細的數據。
• 再來，基本上團隊的工作大部分都還是可預期的，不應該只因為可能發生緊急的工作就打破sprint的步調。
• 最後，之前已經幫團隊上過Scrum的課程，所有團隊成員接受度都很高，也很期待可以儘快實施Scrum。如果貿然改成Kanban，反而會對團隊造成困擾。

後來PO1的一句話提醒了Teddy…

PO1：反正就先做嘛，做了之後看狀況如何再來調整啊。

對啊，inspect與adopt不就是Scrum的精神嗎，怎麼Teddy自己突然傻了。在「拚經濟 導入Scrum，做，就對了」的前提之下，原本的問題突然迎刃而解。反正出了問題有Teddy在現場幫忙處理，這麼想就沒什麼好怕的了。

***

會出什麼問題？

• PO不太會寫story怎麼辦？很簡單，先開個requirement workshop，幫PO們挑選出重要的story，然後第一個sprint的story先請ScrumMaster幫忙把需求寫成story的格式。如果ScrumMaster也不知道怎麼寫再找Teddy幫忙。同時間請PO從實際案例中學習如何寫story。
• 萬一Sprint進行中有緊急的工作怎麼辦？很簡單，拿出unplanned item這一招。關於unplanned item的說明，請參考《Scrum 是什麼（12）：不要再用focus factor與unplanned items了》。疑，不是說好了不再使用unplanned item怎麼又拿出了用了 ？嗯嗯，特殊情況要用特殊手段。總之叔叔有練過，小朋友不要學。
  
• Sprint很混亂怎麼辦？很簡單，增加slack。因為預期可能會有突發狀況，所以在sprint planning meeting時不要把團隊成員全部的時間都用完。例如，留下40個小時作為彈性處理突發狀況的時間。就算是沒有突發狀況發生，這40個小時也不會被浪費掉。因為根據心理學家的研究，人類在估算的時候都很樂觀，所以團隊成員估算每一件工作（task）要完成的時間很有可能被低估。尤其是在第一個sprint的時候，估算的誤差可能會更大。所以剛開始留點彈性對團隊來講壓力會比較小一點。

***

就這樣，開始了第一個sprint，最後也順利結束。雖然遺留了幾個未完成的unplanned item（大部分是修改之前產品的bug）以及一個沒做完的story，但把這些unplanned item、這個sprint未完成的story、以及尚未開工的story，一起交給PO超級比一比（排優先順序），下一個sprint的story又有了。

***

友藏內心獨白：雖然說做就對了，但是別忘了還要搭配一位好顧問才不會走火入魔喔。