计算项目编程时间

Question

作为一名首席开发人员，我经常会获得新项目的规范，并且会被问及完成所涉及工作的编程方面需要多长时间。

我只是想知道其他开发者如何准确计算这些时间？

谢谢！

哦，我希望这不是一个有争议的问题，我只是想找到最好的技术！

Answer 1

估计通常被认为是一种黑色艺术，但它实际上比人们想象的更容易管理。

在Inntec，我们承包软件开发合同，大多数涉及固定成本。如果我们的估计一直没有，我们很快就会破产。

但是我们已经经营了15年并且我们有利可图，所以很明显这整个估算是可以解决的。

使用入门

大多数坚持估计不可能的人正在做出疯狂的猜测。对于最小的项目，这可能偶尔会起作用，但它肯定不会扩展。为了获得一致的准确性，您需要一种系统的方法。

多年前，我的导师告诉我对他有用的东西。它与Joel Spolsky的旧估算方法非常相似，您可以在这里阅读：Joel on Estimation。这是一种简单，低技术的方法，对小型团队来说非常有用。它可能会破坏或需要修改大型团队，其中通信和流程开销占据每个开发人员时间的很大一部分。

简而言之，我使用电子表格将项目分解为小的（少于8小时）块，同时考虑从测试到通信到文档的所有内容。最后，我为意外物品和错误添加了20％的乘数（我们必须免费修复30天）。

很难让某人估计他们没有参与设计。有些人喜欢让整个团队估计每个项目并使用最高数字。我会说，至少，你应该做出悲观的估计，如果他们认为你已经离开，你的团队就有机会说出来。

学习和改进

您需要反馈以改进。这意味着跟踪您花费的实际时间，以便您可以进行比较并调整您的估算意识。

目前在Inntec，在我们开始处理一个大项目之前，电子表格行项目在我们的看板上成为便利贴，项目经理每天都会跟踪它们的进度。任何时候我们过去或者有一个我们没有考虑的项目，这会变成一个小小的红色粘性，它也会进入我们的烧毁报告。这两个工具共同为整个团队提供了宝贵的反馈。

这是一张典型的看板上的照片，大概是一个小项目的一半。

您可能无法读取列标题，但他们会说Backlog，Brian，Keith和Done。积压按组（管理区域等）细分，开发人员有一个列显示他们正在处理的项目。

如果你仔细观察，所有这些笔记都有估计的小时数，而我列中的那些笔记，如果要加上它们，应该等于8，因为那是我工作的小时数天。一天中有四个是不寻常的。凯斯的专栏是空的，所以他可能在这一天出局。

如果你不知道我在说什么：站立会议，scrum，烧毁报告等，那么看看scrum methodology。我们没有遵循它，但它有一些很好的想法，不仅用于做估计，而且用于学习如何预测你的项目何时会在新工作被添加并且估计被错过或达到或超过时发生（确实发生了） ）。您可以查看这个名为“烧毁报告”的精彩工具并说：我们确实可以在一个月内发货，让我们看看我们的烧毁报告，以确定我们正在削减哪些功能。

FogBugz有一种称为循证调度的东西，它可能是一种更容易，更自动化的方式来获得我上面描述的好处。现在我正在尝试一个几周内开始的小项目。它有一个内置的烧毁报告，它可以适应您的日程安排不准确性，因此可能非常强大。

更新：快速说明。几年过去了，但到目前为止，我认为这篇文章中的所有内容今天仍然存在。我更新它使用单词kanban，因为上面的图像实际上是看板。

Answer 2

没有通用技术。您将不得不依赖您（以及您的开发人员）的经验。您还必须考虑所有环境和开发过程变量。即使应对这种情况，你也很有可能会错过任何一件事。

我认为估计编程时间没有任何意义。开发过程是如此相互关联，对其一侧的估计不会产生任何有价值的结果。应该估计整个事情，包括编程，测试，部署，开发架构，编写doc（技术文档和用户手册），在问题跟踪器中创建和管理门票，会议，休假，病假（有时等待等待那家伙，然后将任务分配到另一个），计划会议，喝咖啡休息时间。

这是一个例子：一旦将鸡蛋放在煎锅上，鸡蛋只需要3分钟即可烘烤。但如果你说制作煎蛋需要3分钟，你错了。你错过了：

• 拿着煎锅（你准备好了吗？你必须去一个吗？你还要排队等候这支煎锅吗？）
• 着火（你有烤箱吗？你需要用原木来建造一个壁炉吗？）
• 获得石油（有没有？必须购买一些？）
• 得到一个鸡蛋
• 煎炸
• 将它送到盘子里（准备好了？干净？洗吗？买吗？等待洗碗机完成？）
• 烹饪后清理（你不会用脏的煎锅，不是吗？）

这是一本关于项目评估的好书：

http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

它对几种估算技术有很好的描述。它会在几个小时的阅读中帮助你。

Answer 3

如果您使用的是FogBugz，则其Evidence Based Scheduling可以非常轻松地估算完成日期。

你可能不是，但也许你可以运用EBS的原则来估算。

Answer 4

良好的估计来自经验，有时根本没有。

在我目前的工作中，我的2名同事（显然比我有更多的经验）通常低估了8倍（是的， EIGHT ）次。我，OTOH，在过去的18个月中只有一次超过原始估计值。

为什么会这样？他们两个似乎都没有真正知道他们在做什么，代码，所以他们实际上是拇指吸吮。

底线：

永远不要低估，过高估计要安全得多。鉴于后者，如果需要，您可以随时“加速”开发。如果你已经处于紧张的时间线上，你就无能为力。

Answer 5

这可能是IT业务中最重要的一个。无数失败的软件项目已经表明目前还没有完美的解决方案，但到目前为止我发现最接近解决这个问题的方法是使用内置于FogBugz的自适应估计机制。

基本上，您将里程碑分解为小任务，并猜测需要多长时间才能完成它们。任务不应超过8小时。然后，您将所有这些任务作为计划功能输入到Fogbugz中。完成任务后，您可以使用FogBugz跟踪您的时间。

然后，Fogbugz评估您过去的估计和实际时间消耗，并使用该信息预测一个窗口（具有概率），您将在其中完成接下来的几个里程碑。

Answer 6

过高估计比低估要好。那是因为我们不知道“未知”和（在大多数情况下）规范在软件开发生命周期中会发生变化。

根据我的经验，我们使用迭代步骤（就像在敏捷方法中一样）来确定我们的时间表。我们将项目分解为组件并高估这些组件。使用这些估算的总和，为回归测试和部署增加了额外的时间，以及所有好的工作......

我认为你必须从过去的项目中回过头来，从错误中吸取教训，看看你如何明智地估计。