在这些限制内，团队可以定义交付时间 - 例如在冲刺结束时。这实现了对迭代产品开发的必要关注。同时，可以更早和/或更便宜地交付。当没有具体的预算或时间限制时，这种方法也很有用。随着团队在使用持续交付方法方面的成熟，对明确命名的临时版本的需求会减少。
在开始时指定一个解决方案（这是估计持续时间所必需的）或为每个冲刺预测它（完成了很多故事点或故事）对我来说似乎没有多大意义。团队应该致力于在给定的时间和预算内构建尽可能最好的产品。当您估计并使用速度进行规划时，您会假设在给定时间内可以完成多少工作。为了使这些信息有用，您必须已经知道总体上需要完成什么。这意味着必须提供完整估计的产品积压。我不认为这是一个牵强的假设，即估计积压项目所需的所有时间，然后根本没有开发可以被视为精益意义上的“浪费”。
但是，用于估算实际开发的积压项目的时间又如何呢？为了回答 外汇电子邮件列表 这个问题，我问另一个问题：您是否认识一个产品负责人，由于较低的故事点（估计成本）而将一个故事的优先级高于另一个故事？如果这个问题的答案是“否”，那么我的结论是，在这种情况下的所有估计都是“浪费”。因为没有根据估计做出任何决定。相反，产品负责人只是简单地优先考虑价值最高的故事。
然而，如果答案是肯定的，那么成本估算将被用作本应根据效益做出的决策的基础。提前估计积压，然后根据速度规划交付时间是一种基于成本的方法。
尝试一下，不要估计
我相信迭代（敏捷）开发是基于有关客户和/或业务利益的决策，这些决策强调经验证据而不是估计。这种情况下的成本应该通过保持团队不变并明确时间框架（频繁、可预测的交付时间而不是“最后期限”）来确定。如果您知道成本和交货时间，您就有安全感。这种安全性为开发过程中的敏捷思维提供了空间。此外，固定的交付日期并不意味着您此时停止开发产品。此时您可能已经完成，或者您可能决定继续工作。重要的是根据正在开发的产品已实现的或潜在的利益不断做出继续和不继续的决定。不基于特定解决方案的估计成本。
如果团队能够尽快向用户提供产品的进一步开发和改进，那么每个冲刺交付多少故事或点并不重要。在我看来，这就是软件项目和整个公司尝试采用敏捷思维的原因。
然而，只要您继续感受到价值的压力，您在向客户提供真正出色的软件的过程中就可能总会受到一些阻碍。
您想了解更多关于 adesso 世界中令人兴奋的话题吗？那么请看一下我们之前发布的博客文章。