前言

今天来聊一个看起来不浪费的浪费。

多工会怎样

在我们的成长过程中，应该不只一次会听到前辈们的告诫，强调专心一致，一次只做一件事情的重要性，这个概念在书籍或相关研究上也时常提出；在身心灵领域当中，也会从专一、专心、不散乱的基本工出发；而科学也告诉我们，多工可能正在伤害着我们。

如果上面的说明太过奇幻，我们可以从 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」对此原则有清楚的说明。我想，精简仍是上策，对於同一时间的工作开展是如此，对於任何的事物也是如此，无端增加复杂度只会带来更多的挑战。