如何创建准确的小时估算? [英] How to create an accurate hour estimate?

问题描述

• 您如何看待 项目计划和创建时间 新项目的预算?

• What are your experiences regarding project planning and creating hour estimates for new projects?

您正在使用的方法是什么， 以及为什么有或没有用 给你吗?

What is the approach you are using, and why has or has it not worked for you?

是否有任何最佳做法可采取 考虑到?

Are there any best practices to take into account?

推荐答案

估算任务

我尝试使用的原则(我并不总是有机会)是

Estimation Tasks

The principles that I try to use (I don't always get the opportunity) are:

• 逐步完善
• 3分估算
• 风险分析

进行估计时，重要的一点是要以正确的粒度进行估计，并不断分解并添加任务，直到您对估计值充满信心为止.估算经常会突显出一项漫长而关键的任务，可能需要更多的改进和风险分析.

When estimating it's important to estimate at the right granularity and to continually break down and add tasks until you're confident in the estimates. Quite often, estimating highlights a lengthy, critical path task that may need more refinement and risk analysis.

尝试弄清每项任务的风险所在(某件事情的交货时间是否到了?是否缺乏知识?竞争对手会击败您吗?等)，这有助于确定您对估算的信心，这样您就可以确定如何处理这些估算值.风险分析还有助于确定是否需要进一步逐步完善.

Trying to work out where risks lie in each task (are there lead times for something? is there a lack of knowledge? could a competitor beat you to it? etc. etc.) helps to determine your confidence in the estimates, which allows you to determine how to treat those estimates. Risk analysis also helps to determine if further step-wise refinement is required.

为每个任务(包括设计，开发，测试和错误修复)指定最佳，可能和最坏情况的估计值有助于进行风险分析和计划.估算值可用于计算达到该任务特定百分比成功的最可能持续时间.连同有关其他相关任务的信息以及风险分析，项目经理可以将风险以及其他已知要素(例如系统测试)纳入估算之中，以获得更可靠的估算.

Specifying the best, probable, and worst case estimates for each task (including design, development, testing, and bug-fixing) helps with risk analysis and planning. The estimates can be used to calculate the most likely duration to hit particular percentage success of that task. Together with information on other related tasks, and risk analysis, a project manager can factor the risk, and other known elements like system testing into the estimates to get a more reliable estimate.

当然，估计的粒度也很重要.估计大多数任务的小时数是没有意义的.在软件中，通常最好是几天，但有时可能要数周或数月(例如，如果您外包工作量).选择对项目中所有任务都有意义的时间粒度(我通常用几天时间来完成需求捕获和功能规格说明阶段，而之后半天时间，因为我会更多地了解任务及其子任务).

Of course, the granularity of estimates is also important. There's no point in estimating in hours for most tasks. In software, days is usually best, but sometimes it could be weeks or months (such as if you are out-sourcing blocks of work). Choose a time granularity that makes sense for all the tasks in a project (I usually use days for the requirements capture and functional specification phases, and half-days thereafter as I learn more about the tasks and their sub-tasks).

所有这三个项目都相互补充，因此很多时候您必须多次优化每个步骤.例如，您可能在需求阶段有一个刺，然后在功能说明中又是刺刺，在设计说明中又是刺刺.

All three of these items feed into each other, so quite often you have to refine each step a number of times. For example, you might have a stab at the requirments stage, then again during functional specification, and again during design specification.

估计是一种学习的技能；您做得越多，您就会越好.当您了解更多有关未知的知识时，风险分析会不断改善；当您了解更多有关未知的知识时，三点估计会提高；在您完成设计过程的每个步骤时，逐步完善也会有所改善.

Estimation is a learned skill; the more you do, the better you get. Risk analysis improves as you learn more about what you don't know, 3-point estimates improve as you learn more about what you do know, and stepwise refinement improves as you go through each step of a design process.

如果有时间，请在完成任务后重新查看原始估算，并查看实际时间如何与3点估算和项目计划相加.如果有所不同，请查看丢失或增加的时间，并尝试从中获取可用于未来项目的信息.

If you have the time, revisit your original estimates after you've completed a task and see how the actual time stacks up against your 3-point estimates and your project plan. If it differs, see where the time was lost or gained and try to learn what you can take from that for future projects.

估算不应该是一项艰巨的任务-我总是觉得自己在估算之后比以前更了解自己的工作.

Estimation should not be a daunting task - I always feel like I know more about my work after estimation than before.

这篇关于如何创建准确的小时估算?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！