插單處理一直是在線營運的產品必定會發生的活動(Activities)。研發人員不喜歡插單，特別是以Scrum框架來run的團隊，不僅僅是帶來的是Context Switch的嚴重影響，並且也與Scrum Guideline嚴重抵觸，很大程度會影響團隊是否有辦法達到允諾的Sprint目標。因此，插單一直是個在跑Scrum框架的團隊中很具爭議性的議題，甚至常常有團隊自己得到的結論就是：Scrum不適合營運中的產品開發。這話題，大家話匣子一開一定是講不完，火力四射。
插單看板可視化誕生的原由：
延續上個 Sprint 的 Retrospective 項目(實體看板的再度邂逅系列 - Part 1 )，資深成員提出來，Sprint Fail有很大一個因素是插單太多，所以提議團隊新增一個看板，來將插單(Interrupt tasks)可視化呈現。
本文的重點也就針對這個 插單看板的演化過程及Retrospective的討論過程跟大家做個分享。
其演化過程如下:
1. 一開始只有 Sprint 中每日的滑水道 (依每日發生時間貼上)
2. 有插單要處理時，Daily Scrum討論到，開始需要處理時，
壓上負責的 Owner，最後覺得要有個 Reviewer，故又決定壓上 Reporter/Reviewer
3. 處理完 Mark 上 DONE 字樣。最後覺得有點項目混在一起，故開始把處理完的集中到滑水道的右邊。
4. 有討論是否需紀錄時間，但不強制。
本Sprint 仍盡可能 每日 Daily Scrum 後大家聚在白板前反思及討論
Sprint結尾，殘酷的事實顯示是這樣的：
( 上圖 - 本次的 "插單看板" 於 Retro 當日的狀態，天天都有插單，天天都在處理插單 )
( 上圖 - 本次Sprint的於 Review當天的看板狀態 )
就帳面上看來的事實有:
本Sprint有被登記下來的的插單共 27個 Items
本Sprint依然是Fail，留下 3個 Todo、4個In Progress、3個Ready to Verify。(原先Planning結束時是覺得略有留下些微的buffer時數)
經過上個Sprint大家對於 Sprint Success/Fail的認知同步後，大家對於Sprint Fail的狀態比較能坦然面對。但也因為有這些數據依據，這次其實大家都有心理準備要來討論更深一層次的問題了，為什麼狀態是這樣? 看板盤面背後的意函是什麼?
團隊依序較深入的討論了幾個插單看板的議題，並且有很明確的數字可以佐證討論：
議題1. 有沒有跟PO討論過?
全部的插單 27，其中10個有跟PO討論過(有討論做與不做/優先序):
PO確認率 10/27 = 37%
PO確認率 5/17 = 29%
bad smell: PO/SM不是應該當防火牆的嗎? 怎麼有這麼多直接跳過了呢?
肇因: 本團隊大家都是接了單就開工了。很大一部份是，因為TenMax產品在營運中，營運中所接受到的議題是不太有緩衝空間，都得第一時間釐清問題。故，本團隊很常發生BD就直接把問題反應到 Slack 上，然後 Run Sprint中的 RD 成員自己就接單了先去排除去了。雖然去年後半年有成立產品營運支援部，且有兩個營運工程師的配置，但還是常常會有Leaks或需要後送。
議題2. 是否一定要找到PO討論完才能決定是否動手解決?
插單優先序，PO認知是否該這個sprint處理 及 成員自主判斷優先序:
同調誤差率 5/27 = 18% (此項目包含: PO覺得該處理而未處理 及 PO覺得不該處理但處理 的數量有5個)
Good Smell: 大家價值觀跟判斷上的誤差率在可接受範圍。太棒了! PO的loading可以share出去了。而且大家價值觀差很接近，同時也代表產品熟悉度高，商業優先序及問題輕重緩急度大家對齊度很高。
Bad Smell: 資訊不透明。忘了考慮Ownership/不夠尊重Onwership。PO/SM沒辦法當防護網。Sprint Fail容易發生。議題3： 插單的數量及完成率
插單完成率 17/27 = 62%
Good Smell: 這團隊真是棒，明明沒留太多Buffer，但可以完成這麼多插單的處理!
Bad Smell: 呃~~ Sprint Goal 的 Commitment 擺哪裡了? 你看Sprint 又 Fail 了吧! Sprint 可以這樣 fail 又 fail 嗎?議題4: 這些插單是不是自己以前種的因所長成的果
Bug占插單的比例 13/27 = 48% (剩下的 14張包含有 out of story scope, undefined...這類就不算是Bug)
因上個Iteration沒做好而延伸出來需要處理的Bug，其插單率 7/27 = 26% (短期長尾)
更久之前的Interation沒做好，而延伸出來需要處理的Bug，其插單數量 6/27 = 22%(長期長尾)
Bad Smell: 插單的問題徵結，其實有一半數量是自己以前於程式碼中種下的因。(其餘的可能是 需求變更、先前產品未定義到、使用者的回饋.... etc 等產品需求grooming的議題)
( 上圖 - PO 與 Dev 一起討論判定插單 Task 的認知並標上記號 來協助統計及討論 )
綜合以上的資訊與討論，因此，有些議題的討論重點就可以轉移到另一個層次了:
議題1: 未跟PO討論就動手、找不到PO
因為 優先序的同調誤差率 只有 5/27 = 18%
轉變為 仍需尊重Ownership以及維持團隊資訊透明度。也就是，就算自己判斷完而先決定處理了，仍需盡速知會PO及相關權責/會被影響到的成員。
議題 2. 插單的處理流程確認為:
(1)第一時間研發同仁仍先確認問題所在
(2)ASAP 找PO 說明狀況 一起判讀情勢及影響
(3)設定優先序，以不同Post-IT顏色來區分。並且為了加速建立填寫共識，弄了個Sample示意，也實際貼出來。
( 新的標示法： 紅色 ASAP, 黃色 Sprint中處理, 綠色 以後找時間處理 )
議題3. 插單多，有一半原因是Bugs，因此，如何解決長尾:
(1) Ask for Help, ASAP. (不論是: scope不明確或是遇到障礙想問資深人員，或實作下去才發現有新的議題。甚至是如果找不到最合適人選求助或詢問時，也仍需思考是否有第二人選可問)
(2) 需加重來恢復力道的事: 提早找PO/BD人員使用玩玩 (潛藏心理: 自己做的不理想、沒信心就愈不想找人玩玩，需克服此種負向心理)
(3) 需加重來恢復力道的事: Rehersal 需找PO/BD人員。(頻次減少也與上述負向心理有關)
(4) 即早準備 Test Data 及 end-to-end testing scenario 與 Environment (可增強自己信心 讓大家可以走出「愈沒信心就愈想遮掩訊息、不肯即早面對使用者」的負向循環)
其中一名成員發下"豪"語：
我們的終極目標就是讓這塊板子消失
總結而言，這塊新的可視化插單看板發揮了很不錯的價值。雖然這個sprint之前，其實這些插單的統計是在Jira上，是團隊的Team Leader平常是有偷偷在記，但總沒辦法這麼透明的讓大家可以意識到問題的嚴重性及程度，大家反而比較不會有這樣的機會這麼正面且攤看來的去面對這些問題，不僅可以很快的去討論、歸類，並可以再去討論更深層的心理因素問題。
而這次的結果感受是，大家都很能公開透明的討論，並且追求好還要更好，心態上也更健康更有驅動力。
補充後記：
(2017/04/04補充) 提出插單看板可視化的成員 Howie 所撰寫的補充文章，請參見：
Scrum Team 中關於插單事件的視覺化的感想
沒有留言:
張貼留言