[工作效率] 續論Scrum — 如何應付突然

所謂的人生，就是充滿了不確定的突然．
放在一個工作計畫來講，尤其是越精密越龐大的計劃，其中出差錯或是發生意料之外的突發狀況的頻率就越高．
所以在一個計畫之中安排後路，也就是所謂的『備案』，就成了一種必然．

我大學的時候參加一個營隊的策畫，營隊裡每個人都有負責的活動，也都要針對自己的活動寫企劃書．
一般來說，對於在戶外的活動，我們會準備所謂的『雨天備案』，就是應付天公不做美，天氣不佳時，讓這段時間還有其他的活動可以進行，以免行程開天窗．
有位老兄，他不只寫了一個備案，他寫了好幾份：晴天正案，小雨備案，大雨備案，先晴後雨備案，先雨後晴備案．
他的組長看了這幾份企劃案，在感嘆此人真是天縱奇才之後，把他罵個狗血淋頭：只要寫一份雨天備案就好了，不需要如此＂搞剛＂（台語的畫蛇添足之意）！

Scrum的特點，就是靈活彈性，不過在實際應用上，是要怎麼應付突發狀況呢？

一般來說，Scrum team的組合還是以原有的公司組織架構為主，當然也有專門為了一個新的專案而四處拉人組合的情況，不過在一個公司中，多少還是從上而下，盡量利用原有的組別的人員為主來組成一個Scrum team．
譬如說，原本就有個小組，本職是負責某個軟體或是軟體的某部分，就在日常中採用Scrum在這個原有的小組進行專案開發的管理．
如果碰到這個小組的成員缺乏某種需要的技能，那就從別的組借調人才，暫時性地進入這個Scrum team工作，但是在專案完成之後就會歸建．
總而言之，Scrum team的骨架成員是以公司組織的原有組織成員來擔當，而他們的專案通常也是針對同性質的開發案或是產品．

這時候最常發生的情況，就是這個小組除了進行新的專案，還必須維護已完成的專案的軟體．
譬如說一個小組開發出了Windows 10，等Windows 10上市後他們繼續開發Windows 11．
俗話說得好，有軟體必有臭蟲（bug）．原來的軟體在發行之後多多少少會有當初測試沒發現的臭蟲被使用者發現，當這些錯誤的臭蟲被回報之後，總要有人去處理，不能放著不管吧．
誰去處理呢？當然就是當初寫出這些有臭蟲軟體的人啊！
在大一點的公司組織也許會有專門做＂售後服務＂，針對以發行的軟體進行除錯維護的單位，不過在實務上就是各人造業各人擔，由原有的開發小組去做．
可是這時候這個小組已經在開發新專案，每個Sprint該做的任務都已經安排好，每天的日程已排滿，是要怎麼插入這些突然加入的除錯任務呢？