您在项目规划和为新项目创建工时估算方面有何经验？
您使用的方法是什么，为什么对您有效或无效？
是否有任何最佳实践需要考虑？
Aron
问问题
3282 次
7 回答
21
估计任务
我尝试使用的原则（我并不总是有机会）是：
- 逐步细化
- 3点估计
- 风险分析
逐步细化
在进行估算时，重要的是要以正确的粒度进行估算，并不断分解和添加任务，直到您对估算有信心为止。很多时候，估计会突出一个冗长的关键路径任务，可能需要更多的细化和风险分析。
风险分析
尝试找出每项任务的风险所在（是否有某件事的提前期？是否缺乏知识？竞争对手能打败你吗？等等）有助于确定您对估算的信心，这使您可以以确定如何处理这些估计。风险分析还有助于确定是否需要进一步逐步完善。
3 点估计
为每项任务（包括设计、开发、测试和错误修复）指定最佳、可能和最坏情况估计有助于风险分析和规划。估计值可用于计算达到该任务特定百分比成功的最可能持续时间。结合其他相关任务和风险分析的信息，项目经理可以将风险和其他已知元素（如系统测试）纳入估计，以获得更可靠的估计。
当然，估计的粒度也很重要。对于大多数任务，以小时为单位进行估算是没有意义的。在软件中，几天通常是最好的，但有时可能是几周或几个月（例如，如果您将工作块外包）。选择一个对项目中所有任务都有意义的时间粒度（我通常在需求捕获和功能规范阶段使用几天，然后在我了解有关任务及其子任务的更多信息时使用半天）。
结论
所有这三个项目都相互影响，因此您通常必须多次改进每个步骤。例如，您可能会在需求阶段进行一次尝试，然后在功能规范期间再次尝试，然后在设计规范期间再次尝试。
估计是一种习得的技能。你做的越多，你就越好。风险分析随着您对未知事物的了解越多而改进，三点估计随着您对已知事物的了解越多而改进，而逐步细化随着您完成设计过程的每个步骤而得到改进。
如果您有时间，请在完成一项任务后重新审视您的原始估算，看看实际时间与您的 3 点估算和项目计划相比如何。如果有所不同，请查看在哪里浪费或获得了时间，并尝试了解您可以从中获得什么以用于未来的项目。
估算不应该是一项艰巨的任务——我总觉得估算后我对自己的工作比以前了解更多。
于 2008-11-20T17:00:14.050 回答
9
我强烈推荐史蒂夫·麦康奈尔（Steve McConnell）的《软件估计：揭秘黑色艺术》一书。它确实很好地涵盖了这个问题。
于 2008-11-20T15:25:00.077 回答
7
The Pragmatic Programmer中有一些很好的信息。他们建议您使用适当的时间单位而不是估计 130 天估计 6 个月。他们还建议集中精力完成最关键的任务。并避免根据子估计进行估计。
就我个人而言，我发现将任务分解为可理解的块以正确估计它们是有用的。如果任务很大，那么有太多的角落和缝隙会隐藏未曾想到的问题。通过专注于较小块的细节，您可以更成功地评估潜在问题。
于 2008-11-20T15:26:59.200 回答
2
您的问题是一个 NP-Complete 问题:) 有许多算法用于提出估计，但它们总是只是猜测，永远不准确，而且许多算法需要很长时间才能执行。忘记时间估算，使用 scrum 或其他一些敏捷框架。在一开始就在几个小时内对一个项目进行估算简直是在欺骗人们。
在构建功能之前不要进行基于小时的估计，并随着功能的进展不断更新这些估计。
不要忘记在您的估计中包括测试时间。
于 2008-11-20T15:59:18.027 回答
1
练习，练习，练习。为了安全起见，在您完善自己的估计能力时，请高估。当然，如果你是一名顾问，这可能会让你付出代价。如果您害怕失去业务，估计不足，但请注意，您将从空闲时间/底线中弥补额外的时间。
于 2008-11-20T16:05:20.167 回答
1
回复： 如果您害怕失去业务，估计不足，但请注意，您将从空闲时间/底线中弥补额外的时间。
你最好减少你的小时费率，而不是搞乱你向客户展示的时间。至少通过这种方式，您可以向客户展示附加值的外观。
LM
于 2008-11-29T22:56:48.090 回答