-1

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

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

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

天真的解决方案是获取可以提供可演示产品的最少故事列表，单独估算所有这些故事，然后将它们加起来并结合我们的速度来确定日期，然后宣布我们将从那时开始进行演示。但这没有任何余地，而且似乎很可能在我们赶到最后期限时导致疯狂的紧缩，我非常想避免这种情况。

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

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

是否有推荐的方法来处理设置截止日期以允许敏捷开发过程？我看到的大部分信息似乎都是在你有一个固定的最后期限来处理这种情况。我也会对任何涵盖此问题的相关文献或有趣的博客文章感兴趣。

4

3 回答 3

2

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

于 2014-01-10T06:12:38.780 回答
1

天真的解决方案是获取可以提供可演示产品的最少故事列表，单独估计所有这些故事，然后将它们加起来并结合我们的速度来确定日期，然后宣布我们将从那时开始进行演示。但这没有任何余地，而且似乎很可能在我们赶到最后期限时导致疯狂的紧缩，我非常想避免这种情况。

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

于 2014-01-09T13:52:47.017 回答
0

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

于 2014-01-09T13:59:35.973 回答