软件估算速度和准确性
假设您有一个项目涉及两个 Web 应用程序（将共享 DAL/DAO/BO 程序集和一些 OSS 库）：
- 一个半复杂的管理应用程序，它使用 Windows Live ID 进行身份验证，并且还能够与各种通知程序服务进行通信（电子邮件、短信、twitter 等），目标通知程序约占功能的 10%
- 低到半复杂的用户应用程序，功能较少但更稳健，还使用 Windows Live ID 进行身份验证
我们中有两个人具有中等估计能力，我们即使我们想要/必须这样做，两天内也无法完成。至少这是一个远远的估计。
问题
- 您通常需要多长时间才能做出可靠/有价值的估计？
- 您有什么建议可以在不牺牲准确性的情况下加快估算速度？
- 根据估计速度，您会添加多少松弛度（就成本/时间而言）（当您说：我可以多估计一点，因为我认为它仍然很差）
Let's say you have a project that will involve two web applications (that will share DAL/DAO/BO assemblies and some OSS libraries):
- a semi complex management application that uses Windows Live ID for authentication and is also capable of communicating with various notifier services (email, sms, twitter etc.), targeted notifiers being about 10% of functionality
- a low to semi complex user application with less functionality but more robustness that also uses Windows Live ID for authentication
There are two of us with medium estimation capabilities and we won't be able to do it in two days even if we wanted/have to. At least it would be a far off estimate.
Questions
- How long would/does it normally take you to make a reliable/valuable estimate?
- What would you suggest to speed-up estimation without sacrificing accuracy?
- How much slack (in terms of cost/time) would you add depending on estimation speed (when you would say: I could estimate it a bit more, because I think it's still quite off)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
由于我们使用敏捷方法（特别是 Scrum），因此我们比用户确定优先级所需的时间多了大约一个小时。
更多的时间并不会带来更高的准确性。
那么，困难的部分是让用户确定优先级。我们经常听到这样的讨论：“如果整个事情不能按时完成，一切都毫无价值。” “除了 XYZZY 组件，它确实有一些价值。”这种争论可能会持续几个小时，直到最终确定 XYZZY 应该是第一位。
一般来说，我们尝试创建 4 周的冲刺。前几个很复杂，因为总是有新的东西。在前两个（或三个）之后，我们似乎设定了稳定的步伐。
每个用例对于完成它需要付出的努力都有一个相对简单、主观的评估。任何超过一个完整冲刺持续时间的事情都必须分解。大多数时候，几个用例被捆绑到一个冲刺中。
这些是对每个用例进行评分的正式方法，以更好地处理成本和进度问题。我们不使用它们，因为额外的努力没有帮助。
在前两个冲刺之后，
出现了新的不同功能，
优先级都发生了变化，
详细信息每个用例都经过了大幅修改。
当您尝试估计的内容在每次冲刺结束时发生变化时，“准确性”意味着什么？
吸取了一个教训。我公司的部分部门花费了很长时间来完全定义准确将要交付的内容，然后衡量他们是否准确地交付了他们想要的内容。
客户注意到了这一点，有人说我们“花了很多时间来交付合同中规定的内容，但这不是我们所需要的。”
严格的预先估算的问题在于它们有自己的生命力。您在估算中“投入”的越多，估算的交付成果就越有用。它们没有用，因为它们通常是完全错误的。它们基于完全错误的预先假设。
在估算上投入更多时间是一个糟糕的策略。 “准确”的答案并不是更准确，而是每层管理层都更珍惜。当您和客户了解时，您会发现许多假设无效，并且您绝对必须不断重新估计。
不要预先这样做。如果您的合同要求您预先进行更改，请确保您有变更控制条款，并告诉客户您绝对会在以后进行更改。随着您和客户双方的学习，你们都必须做出改变。
Since we use Agile methods (Scrum, specifically) it takes us about an hour longer than it takes the users to prioritize.
More time doesn't lead to more accuracy.
The hard part, then, is getting the users to prioritize. We hear this discussion all the time "if the whole thing isn't completed on time, it's all worthless." "Except for the XYZZY component, which does have some value." That argument can go on for hours until it's resolved that XYZZY should be first.
Generally, we try to create 4-week sprints. The first few are complicated because there's always something new. After the first two (or three) we seem to set a steady pace.
Each use case has a relatively simple, subjective valuation of how the effort it will take to finish it. Anything over one full sprint in duration has to be decomposed. Most times a few use cases are bundled into a single sprint.
The are formal ways of scoring each use case to better handle the cost and schedule issues. We don't use them because the extra effort doesn't help.
After the first two sprints,
There's new and different functionality,
The priorities have all changed,
The details of each use case have been dramatically revised.
What does "accuracy" mean when the thing you're trying to estimate changes at the end of each sprint?
One lesson learned. Parts of my company spend a long time fully defining exactly what will be delivered, and then measuring that they are delivering precisely what they want.
Customers notice this, and one said we "spend a lot of time delivering what the contract says, but it isn't what we needed."
The problem with firm up-front estimates is that they take on a life of their own. The more you "invest" in the estimating, the more the estimates seem to be a useful deliverable. They aren't useful because they're generally totally wrong. They're based on up-front assumptions that are totally wrong.
It's a bad policy to invest more time in estimating. The "accurate" answers aren't more accurate, but they are more treasured by every layer of management. As you and the customer learn, you invalidate numerous assumptions and you absolutely must re-estimate constantly.
Don't do it up front. If your contract requires you to do it up front, then make sure you have a change control provision and tell the customer that you absolutely will make changes as you go forward. As both you and the customer learn, you both must make changes.
有趣的问题。恐怕答案是“这真的要看情况！”我知道这并不是很有用（尽管这是事实），所以这里有一些因素：
1）需求及其规范的质量和完整性。对我来说，这通常是项目估算的杀手。如果你没有质量要求，你就没有合理的估算依据。我们在这里使用“RUP-lite”风格的产品开发，因此作为工程经理，我不会给出任何内容，除了最粗粒度的估计，直到我们完成“精化”阶段并获得产品管理部门的批准为止。事实上准确覆盖了产品80%的核心功能。
2) 范围及内容产品的性质。更大/更贵/更复杂=估计时间要长得多。我在电信运营商陆地交付解决方案方面工作了多年，这些解决方案具有正常的稳健运营商要求（SLA 要求的“5 个 9”的正常运行时间意味着您必须真正做好解决方案设计和故障恢复！）。在那种跨业务职能领域的所有移动部分的环境中，工作的估计将取决于了解整体情况……具体来说，跨职能依赖性和外部依赖性可能是真正的杀手。也就是说，我还构建了许多收缩包装软件和企业软件。在这些环境中，这要容易得多，因为范围通常要小得多，因此更容易估计。
3）这个项目有多“新”？团队对该产品或技术的“新”程度如何？产品或团队越新，您应该分配的缓冲时间越长、越多。
4）我们需要具体到什么程度？如果这是一个“粗略的猜测”，那么我将依靠我的工程团队提供保守的估计，然后我将对此进行补充。如果我们需要一个“真实”的估计（例如，我的老板使用的估计，我将负责实现），我需要许多不同的经理和团队成员的输入，他们需要时间分析需求并相互协商。
这可能需要几天或几周的时间……这一切都取决于大小。坦率地说，“两三天”的时间不足以确定除了最琐碎的项目之外的任何项目的规模。
为了提高估计的质量，你能做的最好的事情就是提高需求的质量，并毫不留情地识别隐藏的依赖关系。
最后一件事：FWIW，我自 81 年以来一直在这样做，我认为准确估计项目的持续时间/成本是工程管理中最困难/充满危险的部分。
Interesting question. I'm afraid the answer is "it really depends!" I know that's not terribly useful (although it IS true) so here are some factors:
1) Quality and completeness of requirements and their specification. This is, to me, most often the project-estimate killer. If you don't have quality requirements, you have no reasonable basis for an estimate. We use a "RUP-lite" style of product development here, so as the engineering manager I won't give anything but the coarsest-grain estimate until we've completed our "elaboration" phase and gotten sign-off from product management that the core 80% of the product features are in fact accurately covered.
2) The scope & nature of the product. Bigger/more expensive/more complicated = substantially longer to estimate. I've spent years working in telco-carrier land delivering solutions which have the normal robust carrier requirements ("5 9's" of uptime required by SLA mean you must really do a good job of solution design and failure recovery!). In that sort of environment with all the moving parts across functional areas of the business, the estimation of work is going to hinge on getting the whole picture...specifically, cross-functional dependencies and external dependencies can be a REAL killer here. That said, I've also built lots of shrink-wrapped and enterprise software, too. In those environments it's much easier as the scope is typically substantially smaller, so thus easier to estimate.
3) How "new" is this project? How "new" is the team to this product or technology set? The newer the product or team, the longer and more buffer you should allocate.
4) How specific do we need to be? If this is a "rough guess" then I'll lean on my engineering leads to provide a conservative estimate, then I'll pad that. If we need a "real" estimate (e.g., one which is used by my boss and which I'll be responsible for hitting), I'd need the input from a number of different managers and team members, who will need time to analyze the requirements and confer amongst themselves.
That can take as little as a couple days, or weeks..it all depends on the size. "Two or three days" is, frankly, not long enough for sizing anything but the most trivial of projects.
The best thing you can do to improve the quality of your estimates to to improve the quality of your requirements, and be ruthless in identifying hidden dependencies.
One final thing: FWIW, I've been doing this since '81 and I regard accurately estimating a project's duration/cost as the single most difficult/fraught with peril part of engineering management.
为了做出可靠的估计，您确实需要创建一个要完成的任务列表。将其分解为故事/任务（即使您不使用敏捷）并评估它们。这可能已经花费了大量时间 - 尤其是大量的研究（寻找库来执行此通知程序以降低成本）。我至少需要 3 天 - 然而 1-2 周对我来说听起来更合理。这看起来不是一个小工程。
如果你不想得到合理的结果，我不敢加快估算过程。估计永远不会准确，你只会让事情变得更糟。
一个选择是在几个小时内做出完全粗略的猜测，然后开始研究（一周左右）。在本周末，您也许能够根据当前的进度给出更好的估计。然而，创建一个好的原型很重要（它看起来很糟糕，但在所有区域都有一些代码）。
To make a reliable estimate you really would need to create a list of tasks to be done. Break it down into stories/tasks (even if you don't use agile) and evaluate them. This can take a lot of time already - especially the amount of research (to look for libraries to do this notifier stuff to reduce the cost). I would take at least 3 days - however 1-2 week(s) sound more reasonable for me. This doesn't seem to be a small project.
I wouldn't dare to speed-up the estimation process if you wan't to have somewhat reasonable results. Estimations are never accurate and you will just make things worse.
An option would be to make a totally rough guess within a few hours and then start to work on it already (for a week or so). At the end of the week you might be able to give a better estimation based on your current progress. However it's important to create a good prototype (which looks like crap but has a little bit of code in all of the regions).
常见的说法是“价格将在我们最初估计的 50% 到 400% 之间”。这句话之所以被广泛传播，是因为它是真实的。估计的准确性很大程度上取决于您的领域知识。如果这是您第 100 次销售特定类型的博客引擎，那么您对估算非常确定。然而，通常情况下，您对该领域没有深入的了解（如果应用程序已经存在，为什么要创建一个新应用程序？）。
敏捷开发之所以变得流行，是因为人们在很大程度上认识到传统的“瀑布”思维方式不适用于大多数现实世界的项目。您应该将相同的思维方式应用于您的估计。显然，你需要某种卖点，但一定要告诉你的客户，这些信息非常模糊（而且无论任何竞争对手会告诉他们什么，他们的估计也很模糊）。
您需要销售迭代，因此也需要估算迭代。我确信任何公司的营销人员都会知道如何处理文书工作和法律事务，所以这应该不是什么大问题。
考虑一个 5 次迭代的项目：
大多数客户宁愿部分估算和部分交付，也不愿某些西装卖给他们的不切实际的目标:)
Well, a common quote is "The price will be between 50% and 400% of our initial estimates". The reason that this quote has grown large is that it's true. Estimation accuracy largely depends on your domain-knowledge. If this is the 100th time you sold a given type of blog-engine than you're pretty sure about the estimates. However, more often than not, you don't have that indepth knowledge of the domain (If the app already exists, why create a new one?).
Agile development has become popular because people largely recognize that the traditional "waterfall" type of thinking just doesn't work for most real-world projects. You should apply the same way of thinking to your estimates. Obviously, you need some kind of selling point, but be sure to tell your customers that this information is very vague (and that no matter what any competitor will tell them, their estimates are vague as well).
You need to sell iterations, and therefore also estimate iterations. I'm sure some marketing-guy in any company will know how to handle the paperwork and the legal stuff for this, so it shouldn't be that big a deal.
Consider a 5 iterations project:
Most customers would rather have part-estimates and part-deliverances than some unrealistic goal that some suit sold them :)
稍微偏离了您最初的问题，但通过保留有关完成您估计的事情实际需要多长时间的信息，从您过去生成的估计中学习也很重要。
我们估计需要 5 天才能生成这些页面，实际需要 10 天，等等。
从长远来看，此类信息将（希望如此！）使您能够生成更准确的估计。
Straying slightly from your original question but it's also important to learn from the estimates that you have produced in the past by keeping information about how long it actually took to do the things that you estimated.
We estimated 5 days to produce these pages, it actually took 10 days, and etc.
In the long term information like this will (hopefully!) enable you to produce more accurate estimates.