遇到插件要怎麼辦？

常常有人問我遇到插件要怎麼辦，原本的 Sprint 裡所拿的 Story 要怎麼處理？這個問題我們可以分幾個方面來看。

• 新的需求
• 舊的修改
• 產品的 Bug

這是新的需求嗎？

• 如果是新的需求，我們必需要討論，
  • 發生的頻率如何？
    • 高
    • 低

從新需求插件發生的頻率來看

新需求插件發生的頻率高

是否我們的 Sprint 長度太長，改短一點有幫助嗎？

也許把 Sprint 的長度從四個星期改成兩個星期，或是從兩個星期改成一個星期，看看在週期短一點的時候是否還有幫助。

大部分是什麼時候會發生的呢？

假設星期一 Sprint 開始，通常星期三會有插件。這時我們就要想一下插件的來源是哪裡，為什麼有新的插件。

也許是星期二下午 PO 會和外部客戶開會，開完會後客戶會有新的需求，所以 PO 會把它們當插件放到這個 Sprint 裡。

在這樣的情況下，我們是不是考慮改一下 Sprint 開始的時間，把它改成星期三開 Sprint planning meeting， 是否可以解決這樣的問題呢？

新需求插件發生的頻率低

如果這是偶發事件，那就讓插件進入這個 Sprint， 也許我們會產生一些半成品，浪費一些資源，這些我們記在心上就可以了。當然可以討論如何避免，但下次什麼時候發生都不知道，就算我們做了些行動想避免，也很難驗證是否有效。

如果不是新的需求，那就是舊的東西的修改

• 這個 sprint 做的東西， PO 看過後又想到新的想要做。
• 這個 sprint 做的東西， PO 看過後想調整。
• 已經上線的功能想要修改。

這個 sprint 做的東西， PO 看過後又想到新的想要做

當然這有可能，那我們可以想一想，如果這樣的次數頻繁， Scrum 是否真的適合我們。這個新的需求放到下個 Sprint 在做會有什麼影響？先讓這個 Sprint 做的東西上去看看市場的反應再做決定會不會更好？

這個 sprint 做的東西， PO 看過後想調整

如果是這種情況，我個人覺得這不算插件，這個 Story 還沒做完，本來在做的過程中就會有些調整，這是正常的。但如果頻率太高，是否代表我們在 Refinement 時，需求沒有釐清清楚，驗收條件沒有考慮好呢？

已經上線的功能想要修改

這個東西是 Bug 嗎？ 如果是，那是下一小節會討論，如果不是，那它跟新需求有什麼不同，可以把它歸類到新需求的部分。

已經上線的東西出現問題必需要修改

這就是上線產品的 Bug ，先想想我們明天再來討論。