当”承诺”变成了负担，经验主义Scrum的困境

经验主义是基于现实情况做出决策的行为。Scrum是一个经验主义过程，有时被描述为”可能性的艺术”。这意味着我们用现有的资源尽最大努力去做。

产品负责人PO基于所有当前信息来规划发布Planning。他们制定目标，确定能实现这些目标的功能和能力，并估算可能的成本和交付日期。从那时起，产品负责人的工作就是评估团队能力下的可能性，并做出最佳决策以达成预期目标。考虑到技术、市场、需求和人员的特性，需要做出权衡。有时目标无法以合理的价格达成，有时目标能够达成，但方式可能与产品负责人最初的设想不同。这就需要经验主义的实践。

Scrum团队中的开发团队也是如此。他们与产品负责人会面，评估产品负责人认为下一步最重要的事项。完成这些事项将使正在形成的产品朝着预期目标的最佳方向发展。团队选择他们认为在即将到来的冲刺Sprint中能够完成的工作量。团队成本（由于团队人员固定）和冲刺长度是固定的，只有选择的产品待办事项列表的数量可以变化。产品负责人和团队通常会为冲刺定义一个目标，这是发布目标的一个子集。

当团队在冲刺规划会议Sprint Planning中选择产品待办事项时，他们承诺在冲刺期间完成这些项目。

“承诺”的定义是：通过保证或担保来约束或责成。

而”保证”的定义是：承诺履行一个诺言，承诺采取某个具体的行动方案。

这是我对”承诺”一词的理解，即一个保证，是对某个具体行动方案的承诺。

然而，许多Scrum团队将”承诺”视为”保证”。这是瀑布式开发方式的残留，在这里面，估算会被视为是合同。这种观念仍然存在于产品负责人和开发人员的头脑中。我发现一个又一个团队觉得他们必须不惜一切代价来兑现承诺。通常的牺牲品是质量。

我在想，我们是否应该将”承诺”改为”预测”？这可能会让人联想到天气预报员试图提供最佳可能信息的情景。她基于已知信息和气象学知识工作。她不提供保证，而是提供一些我们可以用来做决策的信息。我们也在销售组织中看到预测的使用。也许这种澄清将帮助我们理解，Scrum中的”承诺”是尽我们所能的保证。