未计划的工作和返工

所有开发人员都知道，频繁的上下文切换会导致生产力下降。如果我们在编程时受到打扰，恢复到之前的工作状态需要一些时间，而且通常很难恢复到打扰发生时的生产力。因此，处理多个项目或任务也会降低生产力。在他的《质量软件管理：系统思维》一书中，Gerald M. Weinberg 提出了一个研究结果，该研究得出结论，当同时进行两个项目时，性能下降约20%（Weinberg G.M. 1991）。每增加一个项目，性能下降进一步增加20%（见图2.1）：

另一项2017年的研究表明，参与两个或三个项目的开发人员平均花费17%的精力进行上下文切换（Tregubov A., Rodchenko N., Boehm B., & Lane J.A., 2017）。我认为，实际的百分比可能会因产品和团队的不同而有很大差异。那些以小批量工作方式进行开发的开发人员，比那些处理更大批量任务的开发人员更容易切换上下文。事务的复杂性越高，恢复到中断时的工作状态所需的努力也就越大。像测试驱动开发（TDD）这样的实践可以帮助你在上下文切换后更容易地恢复工作。

但无论实际的百分比如何，上下文切换都会严重影响生产力，开发人员专注于单一任务的时间越长，他们的工作效率就越高。这意味着你应该减少团队的进行中的工作（WIP），尤其是未计划的工作和返工。

为了帮助你后续优化工作流程，应该从一开始就正确地标记工作项。未计划的工作可能来源于项目内部或外部。返工可能发生在出现bug、技术债务或误解需求时。确保你能够在后续分析工作时，通过从一开始就应用正确的标签来实现。这不应是一个复杂的治理框架——只需挑选一些标签，帮助你后续优化工作。表2.1只是一个示例，展示了如何对工作项进行分类：

保持简单，选择一种简单明了的分类方式，使团队成员容易理解。