前言

今天來聊一個看起來不浪費的浪費。

多工會怎樣

在我們的成長過程中，應該不只一次會聽到前輩們的告誡，強調專心一致，一次只做一件事情的重要性，這個概念在書籍或相關研究上也時常提出；在身心靈領域當中，也會從專一、專心、不散亂的基本工出發；而科學也告訴我們，多工可能正在傷害著我們。

如果上面的說明太過奇幻，我們可以從 Scrum 來抽絲剝繭。Scrum Guide 是這樣說明 Scrum 的：

Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.

中譯為：

Scrum 建立在經驗主義（empiricism）和精實思維（lean thinking）之上。 經驗主義（empiricism）堅信，知識來自經驗，以及根據觀察到的事物做出決策。 精實思維（lean thinking）減少浪費，專注於根本。

發現了嗎？精實思維當中的「減少浪費、專注根本」也是 Scrum 的基礎，而這個減少浪費來頭不小，對於軟體開發團隊來說，浪費可能稍然產生，例如「多工」。為了討論這個議題，我先對多工做個小分類：

1. 被迫多工：做事做到一半被插斷，例如要接電話、要回應他人、臨時放指派的任務，這會立即進行工作切換，有時還得一心多用。
2. 可選多工：自行選擇這樣做，例如同時間進行多項任務的開發。(當然也有可能是被迫選擇多工的…)

被迫多工的情況，我認為沒什麼太好的方案，也很難防範，或許番茄鐘原則可以幫助到你，但具體還得視事情的輕重緩急。而可選多工屬於我們可以控制的範圍，所以我們來看看它會形成什麼浪費。

工作能塞就塞，錯了嗎

當團隊評估完 PBI、拆解為可以實作的任務，並完成任務領取(或派發)，就進入了實戰開發環節，開發過程往往是充滿變數的，一個不剛好就會遇到合作銜接的問題，當停等發生時，常見的「利用時間」思維就會跑出來，驅使我們趕快切換到下一個可執行的任務，若不幸再遇到困難，則再展開下一個任務，如何？這看起來很正常、很上進、很會利用時間，這會有什麼問題嗎？

這可以從幾個方向來看，首先為了要多工引發的「工作切換」本身就會帶產生一些代價，可能包含開發環境上的變更、網路連線變更、程式碼切換(如 Git checkout branch)、資料庫切換、依賴套件安裝與建置(build)等；以及因人而異的頭腦準備時間，為了帶入新的情境、了解新的開發需求、重新整理思路，並非人人都能快速切換，更別說切換後還可能需要進行回憶來補足細節，整個過程通常是耗時的，特別對於軟體開發而言。也就是說，我們切換越多次，產生的浪費就越多，這個浪費除了是自己與他人的時間，也可能是運算資源。

而當切換終於告一段落時，正在著手的工作能否完成又是個新問題。若它又因為停等或技術上的困難而停滯，就會成為一種半成品 (不同書籍有不同的稱呼，例如：半成品、在製品、WIP)。

半成品在軟體世界中會有什麼危害呢？讓我們來看幾個例子：

1. 使用 Git 的人員應該可以體會，如果主要分支(main) 之外還散落了許多分支，並且遲遲沒有收回，那可以預期未來會有解不完的衝突。當有越多沒做完、沒回去的分支存在，合併的成本持續累積，也有可能因為時代變遷以致那些半成品被汰除。
2. 寫到一半的程式，放太久後連開發者都失憶了，下次再辛苦的「切回來」繼續開發，還得重新思索一番，好在有 Git，否則還會開始質疑起這是誰寫的程式。
3. 越來越難估計，好多任務看起來都快完成了，但卻沒有一個驗證過，這在 Burndown Chart 上面也會停滯不前。
4. 讓你停等的夥伴回來了！於是你再一次經歷了工作切換，好跟他繼續合作。
5. ……

這也是看板方法(Kanban) 會去限制 WIP 數量的其中原因，無論團隊採用何種敏捷的實踐方法，對於 WIP 的態度都需要審慎。

那該怎麼辨

來自《Scrum 精髓》一書當中的有趣例子，我把它精簡了一下：「接力賽運動選手一次只有一棒在跑，為了增加其他選手的利用率，第二棒、第三棒就先去跑別場，等下再回來接」。

至此，相信我們不會再偏向主動同時開展多項工作，但是因為「停等」造成的空窗期，該怎麼運用呢？

正向的態度是主動協助，哪怕該任務不是自己負責的，與配合的團隊成員一同攻克問題是我最推薦的方式。或許這之間還會有技能的問題，如前端該如何去協助後端？倘若技能無法如此的重疊，仍然可以代為求助、尋求有該專長的成員一起來解決，甚至進行 Mob Programming，特別是在面對高價值的項目時，優先解決是尤為重要的。如果你能從夥伴取得更多的設計資訊，例如介面、API，還是可以回到目前的工作上，將可以事先定義的部份完成。

退一萬步言，該做的都做了，空窗依然存在，我會建議轉去學習；或另一種方案，我曾利用空檔執行 Side project，這時讀者可能會說，不是不要切換嗎？的確是，但 Side project 若與平時工作有一些差距，例如使用不同的技術、執行在不同的環境上，那它的切換成本並不高，若這個 Side project 能夠為日常開發帶來的效率提升，那是相當有意義的投資，一種利用停等創造未來機會的概念。

再繼續退，如果團隊始終在停滯，那也許問題不是多工不多工了，可以反思團隊是否正在「越級打怪」，若基本能力不足，永遠無法消化並交付高價值項目，那就是另一個層面的問題了。

敏捷原則怎麼看

我們可以從多工與它的危害，對應到哪些敏捷原則呢？

我們最優先的任務，是透過及早並持續地交付有價值的軟體來滿足客戶需求。

這是一種優先順序的展現，我們要的是交付客戶想要的，而且是最有價值的。因此眼下的障礙優先要排除，而不是自動繞開先去處理相對低價值的任務。沒有完成最重要的任務，卻完成一些不重要的任務，這樣客戶是不會買單的。

可用的軟體是最主要的進度量測方法。

避免多工展開，結果沒有一個任務是完成的，產出必須是可用的。

精簡──或最大化未完成工作量之技藝──是不可或缺的。
Simplicity--the art of maximizing the amount of work not done--is essential.

中英一起列，反正都不容易理解。在這篇文章「Scrum 是萬靈丹嗎？. 前幾天看到Vince 哥的文章：【文思不藏私】@Scrum… | by 王泰瑞Terry Wang」對此原則有清楚的說明。我想，精簡仍是上策，對於同一時間的工作開展是如此，對於任何的事物也是如此，無端增加複雜度只會帶來更多的挑戰。