Project management 我们如何*设置*截止日期，以使我们能够以敏捷的方式有效地完成这些工作？

我在一个团队中工作，这个团队一直以敏捷的方式工作，并且相当成功，这对于目前的项目非常有效，直到现在，对于我们的初始工作，随着我们逐步构建产品

不过，我们现在正进入下一阶段，管理层希望我们自己设定一些具体的截止日期，以便我们能够在几个月内演示并向真正的客户销售

对于我们想要包含的每一个功能元素，我们都有一个组织良好的大量积压工作，并且对这些功能的各个部分的优先级有很好的认识

最简单的解决方案是获得能够提供演示产品的故事的最少列表，对所有这些故事进行单独评估，然后将它们相加，并与我们的velocity结合以获得日期，然后宣布我们将从那时起进行演示。然而，这并没有留下任何余地，而且似乎很可能导致在我们到达最后期限的时候出现疯狂的紧缩，这是我非常希望避免的

作为一种改进，我想增加一些可选故事的比例，作为应急或奖金改进，这取决于我们的进展情况，但我们不知道什么比例是合理的，或者这是否是标准方法

我还担心的是，必须提前一次估算所有积压工作，因为这似乎非常耗时，而且我们可能会在了解该事件之前的几个月内发现更多信息，这将影响我们的估算

是否有推荐的方法来处理设置最后期限以允许敏捷开发过程？我所看到的大多数信息似乎都是关于一旦你有了一个固定的最后期限来处理这种情况。我也会对任何涉及这个问题的相关文献或有趣的博客文章感兴趣

最简单的解决方案是获得最少的故事列表 提供一个可演示的产品，单独评估所有这些产品，并 将它们相加，并与我们的velocity相结合，得到一个日期，然后宣布 我们将从那时开始演示。但这并没有留下任何余地，而且似乎 很可能会导致我们在截止时间前出现疯狂的紧缩，这 我拼命想避免

---

这是我过去使用过的解决方案。您最初的估计会有点偏差，所以在设置发布日期之前，通过两个额外的sprint增加一些空闲时间。如果你落后了，你就可以弥补你的不足。如果没有，您的产品backlog将为您提供额外的功能，如果您选择的话，您可以将这些功能包含在发行版中。这将取决于你的团队速度指标。根据您认为此指标对于当前团队的准确程度调整您的松弛度。一旦你有了一个目标版本，你可以回头看看你是否有任何已知的资源限制，可能会影响到这个版本。

你描述的方法可能是正确的。您可能希望对所有需要的功能进行评估，并对UI元素进行优先级排序（因为投资者和客户基本上只看到闪亮的UI），然后您的截止日期将是预计的完成日期；然后以调整估计的形式增加一些松弛。使用当前生产率和最差时期之间的比率来创建一个悲观的估计。您可以使用相同的比率来缩放较短的估计值（例如，将您的估计值缩放到最小功能集）。

关于文献：我所知道的关于软件中的估计值的最好的书是Steve McConnel的《软件估计：揭开黑色艺术的神秘面纱》。它涵盖了你的情况。此外，它还描述了估算和承诺（换句话说，设置截止日期）之间的区别，并解释了如何从第一个可靠地导出第二个