作为首席开发人员，我经常收到一个新项目的规范，并被问到完成所涉及工作的编程方面需要多长时间，以小时计。
我只是想知道其他开发人员如何准确计算这些时间？
谢谢！
哦，我希望这不是一个有争议的问题，我只是对找到最好的技术感兴趣！
问问题
6177 次
6 回答
20
估算通常被认为是一种魔法，但它实际上比人们想象的更容易管理。
在 Inntec，我们进行合同软件开发，其中大部分涉及固定成本。如果我们的估计经常偏离，我们很快就会倒闭。
但是我们已经经营了 15 年，而且我们是盈利的，所以很明显，整个估算问题是可以解决的。
入门
大多数坚持估计是不可能的人都是在胡乱猜测。对于最小的项目，这可能偶尔会起作用，但它绝对不能扩展。为了获得一致的准确性，您需要一种系统的方法。
多年前，我的导师告诉我什么对他有用。这很像 Joel Spolsky 的旧估计方法，您可以在此处阅读：Joel on Estimation。这是一种简单、技术含量低的方法，非常适合小型团队。对于较大的团队，它可能会崩溃或需要修改，其中沟通和流程开销开始占用每个开发人员大部分时间。
简而言之，我使用电子表格将项目分解为小块（少于 8 小时），同时考虑到从测试到沟通再到文档的所有内容。最后，我为意外项目和错误添加了 20% 的乘数（我们必须免费修复 30 天）。
很难让某人做出他们没有参与设计的估计。有些人喜欢让整个团队估计每个项目并选择最高的数字。我想说的是，至少，你应该做出悲观的估计，并让你的团队有机会在他们认为你不合适的情况下发表意见。
学习与改进
你需要反馈来改进。这意味着跟踪您花费的实际时间，以便您可以进行比较并调整您的估计意义。
现在在 Inntec，在我们开始着手一个大项目之前，电子表格行项目变成了我们看板上的便签，项目经理每天都在跟踪他们的进度。每当我们检查或有一个我们没有考虑过的项目时，它会变成一个小小的红色粘性物，它也会进入我们的燃尽报告。这两个工具共同为整个团队提供了宝贵的反馈。
这是一个典型的看板图，大约在一个小项目的一半。
您可能无法阅读列标题，但它们会显示 Backlog、Brian、Keith 和 Done。积压工作按组（管理区域等）细分，开发人员有一列显示他们正在处理的项目。
如果你仔细观察，所有这些笔记上都有估计的小时数，我专栏中的那些，如果你把它们加起来，应该等于大约 8，因为那是我工作日的小时数。一天有四个是不寻常的。基思的专栏是空的，所以他可能在这一天不在。
如果你不知道我在说什么：站立会议、Scrum、燃尽报告等，那么看看Scrum 方法论。我们并没有严格遵守它，但它有一些很棒的想法，不仅可以用于进行估算，而且可以用于学习如何预测您的项目何时会随着新工作的添加以及未达到或达到或超过估算值（确实会发生） ）。你可以看看这个很棒的工具，叫做燃尽报告，然后说：我们确实可以在一个月内发货，让我们看看燃尽报告来决定我们要削减哪些功能。
FogBugz 有一个叫做 Evidence-Based Scheduling 的东西，它可能是一种更简单、更自动化的方式来获得我上面描述的好处。现在我正在一个几周后开始的小项目上进行尝试。它有一个内置的燃尽报告，它可以适应你的日程安排不准确，所以它可能非常强大。
更新：只是一个简短的说明。几年过去了，但到目前为止，我认为这篇文章中的所有内容今天仍然有效。我更新了它以使用看板这个词，因为上面的图像实际上是一个看板。
于 2010-08-06T12:03:36.127 回答
4
没有通用的技术。您将不得不依赖您（和您的开发人员）的经验。您还必须考虑所有环境和开发过程变量。即使解决了这个问题，你也很有可能会错过一些东西。
我认为仅估计编程时间没有任何意义。开发过程是如此相互关联，以至于对其一侧的估计不会产生任何有价值的结果。应该估计整个事情，包括编程，测试，部署，开发架构，编写文档（技术文档和用户手册），在问题跟踪器中创建和管理票证，会议，假期，病假（有时等待是击球手）那个人，然后将任务分配给另一个人），计划会议，茶歇。
举个例子：鸡蛋放在煎锅上后，只需 3 分钟即可烤熟。但如果你说做一个煎蛋需要3分钟，那你就错了。你错过了：
- 拿着炸笔（你准备好了一个吗？你必须一个接一个去吗？你必须在队列中等待这个炸笔吗？）
- 生火（你有烤箱吗？你必须得到原木来建造壁炉吗？）
- 取油（有吗？必须买一些？）
- 得到一个鸡蛋
- 煎它
- 把它端到盘子里（准备好了吗？干净吗？洗吗？买它？等待洗碗机完成？）
- 烹饪后清理（你不会弄脏炸笔，对吗？）
这是一本关于项目估算的好入门书：
http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
它对几种估计技术有很好的描述。它能让你在几个小时的阅读中起床。
于 2010-08-10T06:42:04.877 回答
2
良好的估计伴随着经验，或者有时根本没有。
在我目前的工作中，我的 2 位同事（显然比我有更多的经验）通常低估了 8 倍（是的，8倍）。我，OTOH，在过去的 18 个月中只有一次超出了最初的估计。
为什么会这样？从代码上看，他们俩似乎都不知道自己在做什么，所以他们简直是在吮吸拇指。
底线：
永远不要低估，高估要安全得多。鉴于后者，如果需要，您始终可以“加速”开发。如果您的时间线已经很紧，那么您无能为力。
于 2010-08-06T12:03:06.250 回答
1
这可能是 IT 业务中的一大难题。无数失败的软件项目表明，目前还没有完美的解决方案，但到目前为止，我发现最接近解决这个问题的方法是使用FogBugz内置的自适应估计机制。
基本上，您将里程碑分解为小任务，并猜测完成它们需要多长时间。任何任务都不应超过 8 小时。然后，您将所有这些任务作为计划功能输入到 Fogbugz。完成任务时，您可以使用 FogBugz 跟踪您的时间。
然后，Fogbugz 评估您过去的估计和实际时间消耗，并使用该信息来预测您将完成接下来的几个里程碑的窗口（有概率）。
于 2010-08-06T12:10:26.367 回答
0
高估总比低估好。那是因为我们不知道“未知”并且（在大多数情况下）规范在软件开发生命周期中确实会发生变化。
根据我的经验，我们使用迭代步骤（就像在敏捷方法中一样）来确定我们的时间表。我们将项目分解为组件并高估这些组件。这些估计的总和为回归测试和部署增加了额外的时间，以及所有的好工作......
我认为你必须从你过去的项目中回顾过去，从那些错误中吸取教训，看看你如何才能做出明智的估计。
于 2010-08-06T12:26:17.907 回答