你有聽過『半成品』（Working In Progress）嗎？你知道『半成品』的傷害是什麼？你常常製造『半成品』嗎？你了解『半成品』背後的問題是什麼嗎？

什麼是『半成品』呢？

簡單來說，在預定時間內『無法完成』的工作就是『半成品』。比如說：在『衝刺計畫會議』（Sprint Planning Meeting）中規劃要完成五個故事（Story），分別是 A, B, C, D, E。請問下列哪一種故事是『半成品』呢？
A 已經實作完成也測試驗收完成。
B 已經實作完成，但是測試驗收未完成。
C 已經實作完成，但是測試驗收發現一些 Bug 還未修正。
D 實作到一半，也還沒進行測試驗收。
E 還未實作，當然也還沒進行測試驗收。

答案是『B, C, D』，因為只要『衝刺計畫會議』規劃要進行的故事，但已經開工，但無法完成驗收上線的『故事』就算是『半成品』。E 雖然不算『半成品』，但也是怪怪的，也是需要特別注意！

什麼樣的狀態才是能『驗收上線』呢？這取決於團隊對『完成的定義』的認定。比如說『故事完成』要確認的『驗收條件』（Accetance Criteria）是否都通過！

比如說『可以發版』要確認的『發版完成定義』（Release Definition of Done）是指所有要上線的故事都在『預備上線環境』（Staging）完成所有驗收測試。

半成品的處理

如果在『衝刺』（Sprint）結束時有『半成品』，這時候你身為團隊一員，你的選擇是？如果你是團隊的 Scrum Master 你的選擇是？如果你是『產品負責人』（Product Owner）你的選擇是？

如果你是『產品負責人』（Product Owner）你的選擇可能是

1. 繼續把『未測試』的故事測完再發版？還是直接先把『已測試』的發版？
2. 繼續把『已測試』，但還有 bug 的故事延到下個 Sprint？還是一起移到下個 Sprint 一起進行？
3. 繼續把『未進行』的故事移到下個 Sprint 一起進行 Planning？還是？
   絕對沒有完美的解決方案，最佳的處理方式是在不同的情境中選擇出『最佳利益』。比如說：客戶急需的功能是『已實作未測試』，這時候或許盡可能『讓衝刺的故事測完為優先考量』。

半成品的傷害

如果在『衝刺』（Sprint）結束時還有很多半成品，這表示團隊在『衝刺計畫會議』時過度樂觀？這也可能表示會影響到下個『衝刺』的進度？這也可能造成客戶期待後的失望？這也可能讓團隊需要加班？
但持續有『半成品』的背後的問題才是需要深思的。團隊討論過了嗎？

後記

本來只想寫到這裡，但一定會有人會說，你提了一堆問題，又沒說提出解法，但一直在講幹話。『半成品』是問題嗎？誰認定是問題時才是呢？

所以我想想後，想補充一下，我的作法，但不一定是完美作法，也不一定合用你的情境。

作為一個『產品負責人』（PO），我會在『衝刺計畫會議』中多次請團隊成員，確認手上的票是否都能在這個『衝刺』（Sprint）內完成。同時在『衝刺』進行的階段，我也會不定期的提醒是否手上的票是否能在這個『衝刺』（Sprint）內完成。

只是說歸說，還是會有一些團隊成員太過於樂觀，總在 code freeze 的最後一刻才進了一堆功能。這時候會造成 SQA 無法在 Sprint 結束前完成所有的測試。我的選擇是，還是繼續測，但需要等所有待測的票都測試沒問題再上線，只是新的 Sprint 還是會準時開始。

我考量的點是：這些已經做完但還沒有測試完成的故事，如果沒重大問題的話，在不影響產品品質的前提下，盡可能都測完後一起上版。但如果發現重大問題，則這張票可以延到下一版再進。

如何改善這類問題呢？我覺得要團隊成員自行意會到這個問題造成影響，體認到在 Sprint Planning Meeting 時不要過度樂觀認領票，再來盡可能 break down 充分了解每張票的細節，盡可能都在掌控之中。當團隊成員願意調整時，這時候才可能改變現況。

【文思不藏私】敏捷 30 天養成計劃～搶先看