在某個我輔導過的團隊，我曾觀察到一個現象： RD 在評估工作時數，總是會估出不合理的長時間。是 RD 在打混嗎？還是能力不足？通常有這樣的現象，都是開發系統有內部張力，造成 RD 用預留大量的緩衝時間來紓緩。透過訪談才知道，開發團隊總是預期每個 Sprint 當中會有插件，而 PM 與客戶也總是不讓團隊失望。

腦力密集工作者最痛恨的事情沒有之一，就是工作節奏被破壞。相關的負面影響的研究已經很多，但實務上卻不可能完全的避免。我相信利害關係人也都明白這些事件對團隊的不良影響，但因為公司的固有結構使然，總是會很自然的選擇了會干擾開發流程的方式來解決問題。公司指著員工帶來營收，員工指著公司按時發薪水，在這樣的依存關係下，負面情緒與消極心態，無法帶來雙贏，但我們總是可以透過系統化的方式來減輕各方的張力。本篇文章，我們來談談實務上的系統保護策略。

鐵穹防禦

前陣子的以巴衝突中，以色列的鐵穹防禦系統讓人大開眼界。在開發現場，我認為團隊的保護系統，可以由主管與 PM 可以合作組成。不要誤會我要擊落任何臨時性的需求，這只是把壓力過度的累積在需求端。對開發團隊系統來說，系統邊界很容易辨識，凡是不屬於 Scrum 團隊成員，皆屬邊界外，訊息都不應直接進入系統。主管/Scrum Master 與 PO/PM 是對外的溝通「界面」，任何「流程內」（如前面文章介紹的規畫系統）與「流程外」（俗稱隕石）的需求，都該透過這兩個角色進入系統。

此時面對外部的紛亂需求，開發團隊先受到了保護，此時張力移轉到了主管與 PM 身上 (這裡我們談的是保護團隊，但主管與 PM 如何自處，如何建立新的工作結構，之後再來聊)。團隊在防禦系統內部，就會逐漸型成良好的工作文化與自組織。

插件處理

Scrum 不能插件是個迷思，如果插件處理是不得不面對的事實，不如就想辦法讓它優雅一些。我們把插件先分成兩大類：Refined 以及 Non-Refined。對於已經 Refined 的需求插件，由於已經評估過點數，處理上相對單純，抽換 Task。在工作負擔不變的情況下，讓開發團隊調整計畫，調整計畫帶來的時間成本，也一併計入工作時間。最後要讓插件來源，不管是客戶、老闆，都了解到被交換掉的價值是什麼，影響原訂交付項目是什麼。

而對於 Non-Refined 的 Task，那就必須走一遍 Refinement 流程。如下圖，Refined 後的任務點數也是 5 點，但 Refinement 本身也需要花時間，所以影響範圍就會更大。

總之，讓利害關係人了解插件的「量化」影響，會比「質化」的去說服他們團隊士氣、效率會受影響，更有感。潛移默化下，插件的次數也會慢慢變少。

即時的反饋與感謝

之前提過，Retro 是整個開發系統中最有價值的會議。很多論述都提到過，教育體制把我們訓練成傾向順應，而不是創新。在 Retro 中針對團隊的付出與進步，要能即時的反饋，勿以善小而吝惜讚美。一場踴躍發言的會議是非常難能可貴的，這是累積多久的互信才能有的成果。為了讓動能持續，就必須尊重會議的決策，有意識的去推動與追踨成效。