下载掌阅APP，畅读海量书库
立即打开
所有开发者都知道频繁的情境切换会降低生产力。如果开发者在编码时受到干扰，那么在恢复到相同的生产力水平时需要一些时间。因此，同时处理多个项目或任务也会降低生产力。杰拉尔德·韦恩伯格在《优质软件管理：系统思维》（ Quality Software Management : Systems Thinking ）中，提出了一项研究结果：仅同时在两个项目上工作时，效率下降约20%（Weinberg G.M.1991）；每增加一个项目，效率会再下降20%（见图2-1）：
图2-1 情境切换时生产力的损失
另一项来自2017年的研究表明，同时参与两个或三个项目的开发者平均花费17%的时间进行情境切换（Tregubov A.、Rodchenko N.、Boehm B.和Lane J.A., 2017）。作者认为实际百分比可能因产品和团队而异。采用小工作批量进行开发的开发者可以更容易进行情境切换，而工作批量较大的开发者则难以进行情境切换。问题越复杂，重新开始工作所需的努力就越大。像测试驱动开发（TDD）这样的实践可以帮助开发者更容易地在情境切换后重新开始工作。
但是，无论实际百分比如何：情境切换都会降低生产力，开发者如果将时间更多地专注到一个任务上，就会更加高效。这意味着管理层应该减少团队的在制品（WIP），尤其是非计划工作和返工。
为了帮助企业进行优化，应该从一开始就正确地标记工作项。非计划工作可能起源于项目内部或外部。如果出现错误、技术问题或误解了需求，就可能需要返工。确保开发者可以通过正确的标签从一开始就分析工作。这不应该成为一个复杂的治理框架，而是只需选择一些标签，这些标签将有助于以后优化团队工作。表2-1展示了如何对工作项进行分类。
表2-1 工作项的示例分类法
保持简单，并选择一些措辞简单的分类法，清晰地传达给团队。