最近做了一个关于如何评估任务和时间的内部培训（主要是针对软件工程方面）。本以为很简单，在准备中才发现其实挺有意思，一个好的评估需要用到管理学、心理学和软件工程学等多方面知识。培训的材料是用英文准备的，这里就不翻译了。

1. Why do we need estimate?

• Many projects fail because it was grossly under estimated and the project was completed much later than anticipated.
• Estimate will make your managers clear and confident about your task.
• A reasonable and realistic estimate will drive you work on schedule. When you are working ahead of schedule, you are cheerful and productive. Otherwise, you will feel doomed, depressed and unmotivated.

2. Which estimate do you prefer?

Nearly all executives will choose Option #2. The shorter schedule offered by Option #1 won’t do the business any good because the business can’t depend on it. Because the overrun could easily be as large as 4 months, the business has to plan on an 8-month schedule rather than a 4-month schedule. Or it delays making any plans at all until the software is actually ready. In comparison, the guaranteed 5-month schedule of Option #2 looks much better.

3. Value of Accurate Estimates

• Improved status visibility
  –One of the best ways to track progress is to compare planned progress with actual progress.
• Higher quality
  –Accurate estimates help avoid schedule-stress-related quality problems.
• Better coordination with nonsoftware functions
• Better budgeting
• Increased credibility for the development team
• Early risk information

4. Overestimate or Underestimate?

If you can’t estimate with complete accuracy, try to err on the side of overestimation rather than underestimation.

5. No estimate is a good estimate!

It will tell the manager you have not get enough information to make a estimate! That is much better than giving a rough and perfunctory estimate!

6. Ignore business needs and your manager wish!

The business is best served if estimates are as realistic as possible. While estimating, you must completely ignore the wishful thinking of the client and focus on what is really going to happen.

7. Relationship Between Estimates and Plans

• Estimation and planning are related topics, but estimation is not planning, and planning is not estimation. Estimation should be treated as an unbiased, analytical process; planning should be treated as a biased, goal-seeking process.
• Estimates form the foundation for the plans, but the plans don’t have to be the same as the estimates.

8. How to estimate?

1. Design first, and in detail
2. Break things down to very small pieces
3. Estimate the duration of every piece
4. Calculate the total duration
5. Account for designing, leaving and buffer time
6. Track actual times and learn from mistakes

8.1 Design first, and in detail

• Find any historical information that is available dealing with the task at hand. You may also use your experience to assist in coming up with estimates.
• The nature of software development is that things which seem simple are often surprisingly complicated when you think about all the details.
• Until you try to figure out the design of all things, you have no basis for an estimate at all.

8.2 Break things down to very small pieces

• Small piece is much easier and practical to estimate.
• When you have to pick fine grained tasks, you are forcing yourself to actually figure out what steps you are going to have to take.
• Your tasks should be measured in hours, not days.
• As a rule of thumb, each task should be from 1 to 16 hours. If you have a 40 hour (one week) task on your schedule, you’re not breaking it down enough.

8.3 Estimate the duration of every piece

Use the three-point estimating technique. What you do is come up with three estimates:

• An optimistic estimate is based on if everything goes right.
• A pessimistic estimate is based on if everything goes wrong.
• An expected estimate is using your best judgment as the most likely to occur in this situation.

8.4 Calculate the total duration

• Simply average the three estimates out by adding them all together and divide by 3.
• Use the weights for duration estimates if you think that the expected duration estimate is more likely than either the optimistic or pessimistic estimate.

For example, your optimistic duration is 3 hours, pessimistic duration is 6 hours, expected duration is 4 hours. Using the weights 1:1:4, as shown in the following equation:
Total duration = (3 + 6 + 4*4) / 6 = 4.17 hours

8.5 Account for designing, leaving and buffer time

• Do not forget to calculate the time of designing, debugging, testing, meetings, discussions, etc.
• You will probably take quite a few days of vacation, holidays and sick leaving, if your schedule is going to take a long term.
• Buffer time is the extra time in each developers’ schedule to account for unplanned features and tasks.

8.6 Track actual times and learn from mistakes

Most programmers have no idea how to guess how long things will take. As long as you are continuously learning and continuously updating your estimates as you learn, the schedule will work. (You may have to cut features or slip, but the schedule will still be working correctly, in the sense that it will constantly be telling you when you have to cut features or slip).

9. Estimating is a skill, not an art.

References

1. Software Estimation: Demystifying the Black Art, Steve McConnell, published by Microsoft Press.
2. How to estimate software tasks, http://www.fogcreek.com/FogBugz/docs/60/topics/schedules/Estimatingsoftwaretasks.html
3. How to estimate duration for a project task, http://www.ehow.com/how_2263730_estimate-duration-project-task.html
4. Use a PERT analysis to estimate task durations, http://office.microsoft.com/en-us/project/HA101130821033.aspx