Estimation is often considered a black art, but it's actually much more manageable than people think.
At Inntec, we do contract software development, most if which involves working against a fixed cost. If our estimates were constantly way off, we would be out of business in no time.
But we've been in business for 15 years and we're profitable, so clearly this whole estimation thing is solvable.
Getting Started
Most people who insist that estimation is impossible are making wild guesses. That can work sporadically for the smallest projects, but it definitely does not scale. To get consistent accuracy, you need a systematic approach.
Years ago, my mentor told me what worked for him. It's a lot like Joel Spolsky's old estimation method, which you can read about here: Joel on Estimation. This is a simple, low-tech approach, and it works great for small teams. It may break down or require modification for larger teams, where communication and process overhead start to take up a significant percent of each developer's time.
In a nutshell, I use a spreadsheet to break the project down into small (less than 8 hour) chunks, taking into account everything from testing to communication to documentation. At the end I add in a 20% multiplier for unexpected items and bugs (which we have to fix for free for 30 days).
It is very hard to hold someone to an estimate that they had no part in devising. Some people like to have the whole team estimate each item and go with the highest number. I would say that at the very least, you should make pessimistic estimates and give your team a chance to speak up if they think you're off.
Learning and Improving
You need feedback to improve. That means tracking the actual hours you spend so that you can make a comparison and tune your estimation sense.
Right now at Inntec, before we start work on a big project, the spreadsheet line items become sticky notes on our kanban board, and the project manager tracks progress on them every day. Any time we go over or have an item we didn't consider, that goes up as a tiny red sticky, and it also goes into our burn-down report. Those two tools together provide invaluable feedback to the whole team.
Here's a pic of a typical kanban board, about halfway through a small project.
You might not be able to read the column headers, but they say Backlog, Brian, Keith, and Done. The backlog is broken down by groups (admin area, etc), and the developers have a column that shows the item(s) they're working on.
If you could look closely, all those notes have the estimated number of hours on them, and the ones in my column, if you were to add them up, should equal around 8, since that's how many hours are in my work day. It's unusual to have four in one day. Keith's column is empty, so he was probably out on this day.
If you have no idea what I'm talking about re: stand-up meetings, scrum, burn-down reports, etc then take a look at the scrum methodology. We don't follow it to the letter, but it has some great ideas not only for doing estimations, but for learning how to predict when your project will ship as new work is added and estimates are missed or met or exceeded (it does happen). You can look at this awesome tool called a burn-down report and say: we can indeed ship in one month, and let's look at our burn-down report to decide which features we're cutting.
FogBugz has something called Evidence-Based Scheduling which might be an easier, more automated way of getting the benefits I described above. Right now I am trying it out on a small project that starts in a few weeks. It has a built-in burn down report and it adapts to your scheduling inaccuracies, so that could be quite powerful.
Update: Just a quick note. A few years have passed, but so far I think everything in this post still holds up today. I updated it to use the word kanban, since the image above is actually a kanban board.
There is no general technique. You will have to rely on your (and your developers') experience. You will have to take into account all the environment and development process variables as well. And even if cope with this, there is a big chance you will miss something out.
I do not see any point in estimating the programming times only. The development process is so interconnected, that estimation of one side of it along won't produce any valuable result. The whole thing should be estimated, including programming, testing, deploying, developing architecture, writing doc (tech docs and user manual), creating and managing tickets in an issue tracker, meetings, vacations, sick leaves (sometime it is batter to wait for the guy, then assigning task to another one), planning sessions, coffee breaks.
Here is an example: it takes only 3 minutes for the egg to become roasted once you drop it on the frying pen. But if you say that it takes 3 minutes to make a fried egg, you are wrong. You missed out:
taking the frying pen (do you have one ready? Do you have to go and by one? Do you have to wait in the queue for this frying pen?)
making the fire (do you have an oven? will you have to get logs to build a fireplace?)
getting the oil (have any? have to buy some?)
getting an egg
frying it
serving it to the plate (have any ready? clean? wash it? buy it? wait for the dishwasher to finish?)
cleaning up after cooking (you won't the dirty frying pen, will you?)
Here is a good starting book on project estimation:
Good estimation comes with experience, or sometimes not at all.
At my current job, my 2 co-workers (that apparently had a lot more experience than me) usually underestimated times by 8 (yes, EIGHT) times. I, OTOH, have only once in the last 18 months gone over an original estimate.
Why does it happen? Neither of them, appeared to not actually know what they are doing, codewise, so they were literally thumb sucking.
Bottom line:
Never underestimate, it is much safer to overestimate. Given the latter you can always 'speed up' development, if needed. If you are already on a tight time-line, there is not much you can do.
This is probably one of the big misteries in the IT business. Countless failed software projects have shown that there is no perfect solution to this yet, but the closest thing to solving this I have found so far is to use the adaptive estimation mechanism built in to FogBugz.
Basically you are breaking your milestones into small tasks and guess how long it will take you to complete them. No task should be longer than about 8 hours. Then you enter all these tasks as planned features into Fogbugz. When completing the tasks, you track your time with FogBugz.
Fogbugz then evaluates your past estimates and actual time comsumption and uses that information to predict a window (with probabilities) in which you will have fulfilled your next few milestones.
Overestimation is rather better than underestimation. That's because we don't know the "unknown" and (in most cases) specifications do change during the software development lifecycle.
In my experience, we use iterative steps (just like in Agile Methodologies) to determine our timeline. We break down projects into components and overestimate on those components. The sum of these estimations used and add extra time for regression testing and deployment, and all the good work....
I think that you have to go back from your past projects, and learn from those mistakes to see how you can estimate wisely.
发布评论
评论（6）
估算通常被认为是一门黑术，但它实际上比人们想象的要容易管理得多。
在 Inntec，我们从事合同软件开发，其中大部分涉及固定成本。如果我们的估计总是偏离预期，我们很快就会倒闭。
但我们已经经营了 15 年并且盈利，所以显然整个估算问题是可以解决的。
入门
大多数坚持认为估计不可能的人都是在胡乱猜测。对于最小的项目来说，这可以偶尔工作，但它绝对无法扩展。为了获得一致的准确性，您需要一种系统的方法。
几年前，我的导师告诉我什么对他有用。这很像 Joel Spolsky 的旧估算方法，您可以在这里阅读：Joel 谈估算。这是一种简单、技术含量低的方法，非常适合小型团队。对于较大的团队来说，它可能会崩溃或需要修改，因为沟通和流程开销开始占用每个开发人员很大一部分时间。
简而言之，我使用电子表格将项目分解为小块（少于 8 小时），同时考虑到从测试到沟通到文档的所有内容。最后，我为意外项目和错误添加了 20% 的乘数（我们必须在 30 天内免费修复）。
很难让某人坚持自己没有参与设计的估算。有些人喜欢让整个团队估算每个项目并选择最高的数字。我想说的是，至少，你应该做出悲观的估计，如果你的团队认为你的想法不对，就给他们一个大声说出来的机会。
学习和改进
您需要反馈才能改进。这意味着跟踪您实际花费的时间，以便您可以进行比较并调整您的估计意义。
现在在 Inntec，在我们开始一个大项目之前，电子表格行项目会变成我们看板上的便签，项目经理每天都会跟踪它们的进度。每当我们检查或有一个我们没有考虑到的项目时，它都会以红色小便签的形式出现，并且也会进入我们的燃尽报告中。这两个工具一起为整个团队提供了宝贵的反馈。
这是一张典型看板的图片，大约是一个小项目的一半。
< img src="https://farm6.staticflickr.com/5473/11871600416_9496db37df.jpg" width="375" height="500" alt="2011-09-30 10.35.12">
您可能不会能够阅读列标题，但他们显示“待办事项”、“布莱恩”、“基思”和“完成”。待办事项按组（管理区域等）细分，开发人员有一列显示他们正在处理的项目。
如果你仔细观察，所有这些笔记上都有估计的小时数，而我专栏中的那些，如果你把它们加起来，应该等于 8 左右，因为这就是我一天的工作时间。一天有四个人是很不寻常的。基思的专栏是空的，所以他今天可能不在。
如果您不知道我在说什么：站立会议、scrum、燃尽报告等，请查看 scrum 方法。我们不会严格遵循它，但它有一些很棒的想法，不仅可以进行估算，还可以学习如何预测项目何时发布，因为添加了新工作以及错过、达到或超过了估算（这种情况确实发生了） ）。您可以查看这个名为燃尽报告的出色工具并说：我们确实可以在一个月内发货，让我们看看我们的燃尽报告来决定我们要削减哪些功能。
FogBugz 有一种叫做“基于证据的调度”的东西，这可能是一种更简单、更自动化的方式来获得我上面描述的好处。现在我正在一个几周后开始的小项目上进行尝试。它有一个内置的燃尽报告，可以适应您的日程安排的不准确性，因此它可能非常强大。
更新：只是一个简短的说明。几年过去了，但到目前为止，我认为这篇文章中的所有内容今天仍然有效。我将其更新为使用“看板”一词，因为上面的图像实际上是一个看板。
Estimation is often considered a black art, but it's actually much more manageable than people think.
At Inntec, we do contract software development, most if which involves working against a fixed cost. If our estimates were constantly way off, we would be out of business in no time.
But we've been in business for 15 years and we're profitable, so clearly this whole estimation thing is solvable.
Getting Started
Most people who insist that estimation is impossible are making wild guesses. That can work sporadically for the smallest projects, but it definitely does not scale. To get consistent accuracy, you need a systematic approach.
Years ago, my mentor told me what worked for him. It's a lot like Joel Spolsky's old estimation method, which you can read about here: Joel on Estimation. This is a simple, low-tech approach, and it works great for small teams. It may break down or require modification for larger teams, where communication and process overhead start to take up a significant percent of each developer's time.
In a nutshell, I use a spreadsheet to break the project down into small (less than 8 hour) chunks, taking into account everything from testing to communication to documentation. At the end I add in a 20% multiplier for unexpected items and bugs (which we have to fix for free for 30 days).
It is very hard to hold someone to an estimate that they had no part in devising. Some people like to have the whole team estimate each item and go with the highest number. I would say that at the very least, you should make pessimistic estimates and give your team a chance to speak up if they think you're off.
Learning and Improving
You need feedback to improve. That means tracking the actual hours you spend so that you can make a comparison and tune your estimation sense.
Right now at Inntec, before we start work on a big project, the spreadsheet line items become sticky notes on our kanban board, and the project manager tracks progress on them every day. Any time we go over or have an item we didn't consider, that goes up as a tiny red sticky, and it also goes into our burn-down report. Those two tools together provide invaluable feedback to the whole team.
Here's a pic of a typical kanban board, about halfway through a small project.
You might not be able to read the column headers, but they say Backlog, Brian, Keith, and Done. The backlog is broken down by groups (admin area, etc), and the developers have a column that shows the item(s) they're working on.
If you could look closely, all those notes have the estimated number of hours on them, and the ones in my column, if you were to add them up, should equal around 8, since that's how many hours are in my work day. It's unusual to have four in one day. Keith's column is empty, so he was probably out on this day.
If you have no idea what I'm talking about re: stand-up meetings, scrum, burn-down reports, etc then take a look at the scrum methodology. We don't follow it to the letter, but it has some great ideas not only for doing estimations, but for learning how to predict when your project will ship as new work is added and estimates are missed or met or exceeded (it does happen). You can look at this awesome tool called a burn-down report and say: we can indeed ship in one month, and let's look at our burn-down report to decide which features we're cutting.
FogBugz has something called Evidence-Based Scheduling which might be an easier, more automated way of getting the benefits I described above. Right now I am trying it out on a small project that starts in a few weeks. It has a built-in burn down report and it adapts to your scheduling inaccuracies, so that could be quite powerful.
Update: Just a quick note. A few years have passed, but so far I think everything in this post still holds up today. I updated it to use the word kanban, since the image above is actually a kanban board.
没有通用技术。您将不得不依赖您（和您的开发人员）的经验。您还必须考虑所有环境和开发过程变量。即使处理好这个问题，你也很有可能会错过一些东西。
我认为仅估计编程时间没有任何意义。开发过程是如此相互关联，以至于对其一侧的估计不会产生任何有价值的结果。应该对整个事情进行估计，包括编程、测试、部署、开发架构、编写文档（技术文档和用户手册）、在问题跟踪器中创建和管理票证、会议、假期、病假（有时等待会更好）那个人，然后将任务分配给另一个人），计划会议，喝咖啡休息。
举个例子：鸡蛋放到煎锅上，只需要3分钟就可以烤熟。但如果你说做一个煎蛋需要3分钟，你就错了。你错过了：
这是一本关于项目估算的很好的入门书：
http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
它对几种估计技术有很好的描述。它可以让你在几个小时的阅读中振作起来。
There is no general technique. You will have to rely on your (and your developers') experience. You will have to take into account all the environment and development process variables as well. And even if cope with this, there is a big chance you will miss something out.
I do not see any point in estimating the programming times only. The development process is so interconnected, that estimation of one side of it along won't produce any valuable result. The whole thing should be estimated, including programming, testing, deploying, developing architecture, writing doc (tech docs and user manual), creating and managing tickets in an issue tracker, meetings, vacations, sick leaves (sometime it is batter to wait for the guy, then assigning task to another one), planning sessions, coffee breaks.
Here is an example: it takes only 3 minutes for the egg to become roasted once you drop it on the frying pen. But if you say that it takes 3 minutes to make a fried egg, you are wrong. You missed out:
Here is a good starting book on project estimation:
http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
It has a good description on several estimation techniques. It get get you up in couple of hours of reading.
良好的估计需要经验，或者有时根本不需要。
在我目前的工作中，我的 2 位同事（显然比我更有经验）通常会低估 8 倍（是的，八）次。我，OTOH，在过去 18 个月里只有一次超出了最初的估计。
为什么会发生这种情况？他们俩似乎都不知道自己在做什么，从代码角度来说，所以他们实际上是在吮拇指。
底线：
永远不要低估，高估会更安全。鉴于后者，如果需要，您始终可以“加速”开发。如果您的时间已经很紧，那么您无能为力。
Good estimation comes with experience, or sometimes not at all.
At my current job, my 2 co-workers (that apparently had a lot more experience than me) usually underestimated times by 8 (yes, EIGHT) times. I, OTOH, have only once in the last 18 months gone over an original estimate.
Why does it happen? Neither of them, appeared to not actually know what they are doing, codewise, so they were literally thumb sucking.
Bottom line:
Never underestimate, it is much safer to overestimate. Given the latter you can always 'speed up' development, if needed. If you are already on a tight time-line, there is not much you can do.
如果您使用FogBugz，那么它的基于证据的计划使得估计完成日期变得非常容易。
您可能不是，但也许您可以应用 EBS 的原理来进行估算。
If you're using FogBugz, then its Evidence Based Scheduling makes estimating a completion date very easy.
You may not be, but perhaps you could apply the principles of EBS to come up with an estimation.
这可能是 IT 行业的一大谜团。无数失败的软件项目表明，目前还没有完美的解决方案，但迄今为止我发现的最接近解决此问题的方法是使用 FogBugz。
基本上，您将里程碑分解为小任务，并猜测完成它们需要多长时间。任何任务的时间不应超过 8 小时。然后，您将所有这些任务作为计划的功能输入到 Fogbugz 中。完成任务后，您可以使用 FogBugz 跟踪您的时间。
然后，Fogbugz 评估您过去的估计和实际消耗时间，并使用该信息来预测您将完成接下来的几个里程碑的窗口（带有概率）。
This is probably one of the big misteries in the IT business. Countless failed software projects have shown that there is no perfect solution to this yet, but the closest thing to solving this I have found so far is to use the adaptive estimation mechanism built in to FogBugz.
Basically you are breaking your milestones into small tasks and guess how long it will take you to complete them. No task should be longer than about 8 hours. Then you enter all these tasks as planned features into Fogbugz. When completing the tasks, you track your time with FogBugz.
Fogbugz then evaluates your past estimates and actual time comsumption and uses that information to predict a window (with probabilities) in which you will have fulfilled your next few milestones.
高估总比低估好。这是因为我们不知道“未知”和（在大多数情况下）规范在软件开发生命周期中确实会发生变化。
根据我的经验，我们使用迭代步骤（就像敏捷方法论一样）来确定我们的时间表。我们将项目分解为多个组件，并高估了这些组件。使用的这些估计的总和增加了回归测试和部署的额外时间，以及所有好的工作......
我认为你必须从过去的项目中回顾，并从这些错误中学习，看看如何能够明智地估计。
Overestimation is rather better than underestimation. That's because we don't know the "unknown" and (in most cases) specifications do change during the software development lifecycle.
In my experience, we use iterative steps (just like in Agile Methodologies) to determine our timeline. We break down projects into components and overestimate on those components. The sum of these estimations used and add extra time for regression testing and deployment, and all the good work....
I think that you have to go back from your past projects, and learn from those mistakes to see how you can estimate wisely.