我们如何“设定”最后期限，以便我们能够以敏捷的方式有效地完成工作？[关闭]

Question

关闭。 这个问题是 无关. 。目前不接受答案。

---

想要改进这个问题吗？ 更新问题 所以就是 切题 对于堆栈溢出。

关闭 2年前.

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

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

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

最简单的解决方案是获取提供可演示产品的最小故事列表，单独估计所有这些故事，然后将它们相加并与我们的速度结合起来以获得日期，并宣布我们将从那时起进行演示。但这没有留下任何余地，而且当我们到达最后期限时，似乎可能会导致疯狂的紧缩，这是我迫切希望避免的。

作为一项改进，我想添加一些更多可选故事的比例，作为应急或奖励改进，具体取决于我们的进展情况，但我们不知道什么比例是明智的，或者这是否是标准方法。

我还担心必须预先一次性估算出我们的全部积压工作，因为这似乎非常耗时，而且我们很可能会在开始讨论该故事之前的几个月内发现更多信息，这将影响我们的估计。

是否有推荐的方法来处理设置最后期限以实现敏捷开发过程？我看到的大多数信息似乎都是围绕在达到固定期限后如何处理这种情况。我还对涵盖此问题的任何相关文献或有趣的博客文章感兴趣。

Answer 1

关于文学：我所知道的关于软件估算的最好的书是“软件估算：揭秘黑人艺术”作者：史蒂夫·麦康奈尔。它涵盖了您的情况。另外，它描述了之间的区别 估计 和 承诺 （换句话说，设定截止日期）并解释如何从第一个可靠地导出第二个截止日期。

Answer 2

幼稚的解决方案是获取最低限度的故事清单，这些故事将提供可演示的产品，单独估算所有这些产品，并将它们添加并与我们的速度相结合以获得约会，并宣布将从那时起进行演示。不过，这并没有留下余地，而且在我们踏上截止日期时，我迫切希望避免时会导致疯狂的紧缩。

这是我过去使用过的解决方案。您的初步估计会有点偏差，因此在设定发布日期之前，可以通过几次额外的冲刺来增加一些宽松的时间。如果你落后了，你可以在空闲时弥补。如果没有，您的产品待办事项列表将为您提供额外的功能，您可以选择将这些功能包含在版本中。但这将取决于您团队的速度指标。根据您认为该指标对于当前团队的准确程度来调整您的宽松时间。一旦有了目标版本，您就可以回过头来看看是否有任何可能影响该版本的已知资源限制。

Answer 3

您描述的方法可能是正确的。您可能想要估计所有理想的功能，并优先考虑 UI 元素（因为投资者和客户基本上只会看到闪亮的 UI），然后您的截止日期将是估计完成的日期；然后以缩放估计的形式添加一些余量。使用当前生产力与最差时期之间的比率来创建悲观估计。您可以使用相同的比率来缩放较短的估计值（例如用于您对最小功能集的估计）。