松弛

使用时间盒迭代的一种常见方法是，将尽可能多的用户故事分配到每个迭代中，以最大限度地利用参与的员工。松弛是指故意留出一些没有分配给故事的时间，将这些时间用于计划外的工作。虽然这看起来效率低下，但它通常会显着提高团队的生产力。

将松弛引入规划的一个好方法是利用它来应对规划中固有的不确定性。一个平均每个迭代完成 20 个故事的团队，不会每个迭代都恰好完成那么多故事。相反，我们会看到一个范围：比如从 15 到 22。在这种情况下，团队可以在他们最低的持续数量（15）上进行规划，并将额外的时间视为松弛。

这种方法的一个好处是它减少了故事完成的变异性。与其担心这个迭代是否能完成 20 个故事分配中的最后 5 个，我们可以放心地预期完成 15 个。对于规划和协调来说，更高的信心往往比试图最大化吞吐量更有价值。

人们经常担心松弛会导致无所事事，但有很多富有成效的方式来利用这些松弛时间。最明显的是，将额外的故事作为未承诺的奖励来处理。这不会影响较低承诺率的可预测性，但会尽可能多地完成更多工作。

但做更多故事往往不是最有效的事情。大多数团队都受到工作环境中因素的阻碍。构建过程中可能存在效率低下，代码库中可能存在垃圾代码，或者对生产力工具不熟悉（大多数人都在他们的 IDE 中有各种各样的未发现的宝石）。在松弛时间花在这些方面可以产生重大影响，因为这会提高未来交互的生产力。事实上，团队面临的最常见的生产力问题是由于拥挤的日程安排，导致这些障碍滋生。

松弛的另一个好用途是增加与客户合作的活动。通常，真正阻碍生产力的最大障碍是开发团队并没有真正理解如何最好地改进客户和用户的成果。更多地了解他们，即使只是花一个下午跟踪用户，也可以极大地放大其功能的价值。

松弛提高了团队响应紧急请求的能力。团队经常需要协作，例如为另一个团队的功能扩展 API。如果没有松弛，此类工作需要安排到计划中，从而增加延迟，并增加其他团队的循环时间。小任务可以在松弛中处理，快速完成，无需太多仪式。请记住，高利用率会增加延迟。

虽然我在此描述了松弛在时间盒迭代中的作用，但它在持续流中也很重要。这里的气味是，如果一个持续流团队总是很忙，这表明没有足够的松弛，这会使他们对请求的响应速度变慢，也无法照顾好他们的工作环境。

虽然松弛很重要，而且经常被低估，但它是一种调味品，而不是主菜。一个全是松弛的计划会放弃可见性和长期规划。但没有它运行就像省钱不换机油一样。