duration - 软件估算速度和准确性

Question

假设您有一个涉及两个 Web 应用程序的项目(将共享 DAL/DAO/BO 程序集和一些 OSS 库):

• 一个半复杂的管理应用程序，使用 Windows Live ID 进行身份验证，并且还能够与各种通知程序服务(电子邮件、短信、Twitter 等)进行通信，目标通知程序约占功能的 10%
• 低到半复杂的用户应用程序，功能较少，但更加稳健，还使用 ​​Windows Live ID 进行身份验证

我们两个人的估计能力中等，即使我们想要/必须在两天内完成，我们也无法完成。至少这是一个远远的估计。

问题

1. 您通常需要多长时间才能做出可靠/有值(value)的估算？
2. 您有什么建议可以在不牺牲准确性的情况下加快估算速度？
3. 根据估计速度，您会添加多少松弛度(就成本/时间而言)(当您说:我可以多估计一点，因为我认为它仍然很偏离)

Answer 1

由于我们使用敏捷方法(特别是 Scrum)，因此我们比用户确定优先级所花费的时间多了大约一个小时。

更多的时间并不会带来更高的准确性。

困难的部分是让用户确定优先级。我们经常听到这样的讨论:“如果整个事情不能按时完成，一切都毫无值(value)。” “除了 XYZZY 组件，它确实有一些值(value)。”这种争论可能会持续几个小时，直到最终确定 XYZZY 应该是第一位。

通常，我们尝试创建 4 周的冲刺。前几个很复杂，因为总是有新的东西。在前两个(或三个)之后，我们似乎设定了稳定的步伐。

每个用例都有一个相对简单、主观的评估来评估完成它需要付出的努力。任何超过一个完整冲刺持续时间的事情都必须分解。大多数时候，几个用例被捆绑到一个冲刺中。

这些是对每个用例进行评分的正式方法，以更好地处理成本和进度问题。我们不使用它们，因为额外的努力没有帮助。

在前两次冲刺之后，

1. 有新的和不同的功能，

2. 优先事项都发生了变化，

3. 每个用例的详细信息都经过了大幅修改。

当您尝试估计的内容在每个冲刺结束时发生变化时，“准确性”意味着什么？

<小时/>

一个教训。我公司的部分部门花了很长时间时间来完全定义准确将要交付的内容，然后衡量他们是否准确地交付了他们想要的内容。

客户注意到了这一点，有人说我们“花了很多时间来交付契约(Contract)中规定的内容，但这不是我们所需要的。”

严格的预先估​​算的问题在于它们有自己的生命力。您在估算中“投入”的越多，估算的交付成果就越有用。它们没有用，因为它们通常是完全错误的。它们基于完全错误的预先假设。

在估算上投入更多时间是一个糟糕的策略。 “准确”的答案并不是更准确，而是每层管理层都更珍惜。当您和客户了解时，您会发现许多假设无效，并且您绝对必须不断重新估计。

不要预先这样做。如果您的契约(Contract)要求您预先进行更改，那么请确保您有变更控制条款，并告诉客户您绝对会在以后进行更改。随着您和客户双方的学习，你们都必须做出改变。