作为一名新开发人员，我是员工中唯一的软件人员，我面临着一些挑战，但最困难的可能是时间估算。每次我不得不给出一个项目估算时，我都在挣扎。
那么我的问题是；如果我没有任何经验并且在我的环境中没有开发伙伴，我如何提供可靠的估计？我已经阅读了 Joel Spolsky 关于基于证据的调度的文章，但是如果我没有任何证据，这怎么可能适用？
我很感激关于这个主题的任何建议。
问问题
6075 次
13 回答
30
您没有提供可靠的估计。你尽可能给出一个好的答案，并解释这只是一个非常粗略的估计，以及为什么它如此粗略。
如果你说得很清楚：
- 你无法给出准确的估计
- 您无法给出准确的估计是完全合理的，因为这与您以前所做的工作不同
- 随着时间的推移，您将更新估计值，您会更好地了解该主题
我想你应该没事。但是，您需要以书面形式非常清楚地说明这些事情，以免以后受到粗略估计的束缚。
于 2009-04-08T16:29:37.487 回答
6
你可以说“我不知道，我没有足够的证据”
然后做一些原型设计以获得一些证据。
然后回答问题。
因此，您实际上可能能够估计何时能够给出估计。
于 2009-04-08T16:28:59.110 回答
6
IMO Joel 在他的文章中离得很远，他的结论和建议并非基于任何现实。（对不起，乔尔）从根本上说，您应该能够在开始之前将您的工作安排到小时或更短的时间单位。但现实情况是，在开始编写代码之前，您并不知道这些工作单元（在非平凡系统中）将是什么。因此，在您打开引擎盖并让该细分准确地反映实际发生的情况之前，您无法按小时细分您将要做什么。
如果您希望该估算具有任何价值，那么给出一个项目估算是非常困难的。对程序员来说，做出准确的估计是很困难的，因为很多时候你直到深入了解项目才发现项目的所有复杂性。
因此，解决这个问题的方法是在进行估算时深入了解。对于较小的项目和错误修复，这相当简单：
- 复制您机器上的错误。
- 找到导致错误的代码。
- 弄清楚如何编写修复错误的代码。
- 估计编写该代码需要多长时间。
在查找您必须编写的代码时，您必须发现大部分或所有可能会超出您的估计的复杂性。
这种方法的有趣之处在于，生成估计所需的时间通常是实际完成工作的总时间的 90%。你实际上必须做这项工作才能得出一个估计值。尤其是错误修复，解决方案通常是一行代码，因此您的估计最终将是 5 分钟。这很好，因为可以围绕这样的估计设置截止日期。
随着您对此进行练习，您将越来越擅长“知道”事情需要多长时间。起初，您只能“知道”最小的项目需要多长时间。但随着时间的推移，您将能够估计更大和更大的项目。
于 2009-04-08T16:58:52.473 回答
3
我首先根据我对问题的复杂性进行估计。问题有多大。它可能接触或需要多少件。这给了我一个一般的指导方针。然后我总是确保我添加了 15-25% 的软糖因素，因为你会错过一些东西。
最后，您非常清楚，这是基于您对问题的理解以及如何解决问题的粗略估计。
也不要以非常精确的增量给出任何粗略的估计。4.5小时不是一个粗略的估计。半天是一个粗略的估计。
于 2009-04-08T16:32:32.737 回答
3
虽然它很粗糙，但我估计在代码行数上。这个参数，其对生产力的意义接近于零，仍然可以让您了解项目的复杂性。
衡量一个事实，平均而言，开发人员每天可以编写大约 200 行代码，最多 300 行代码。请记住，仅针对单人军队的编码：
- 一个 1000 行（逻辑）代码的小项目可以在一两周内完成
- 10.000 行（逻辑）代码的平均复杂性项目可以在两三个月内完成。
- 100.000 行（逻辑）代码的大型项目至少需要几年时间
对于逻辑代码，您必须添加测试，这已经包含在之前的估计中。为了了解复杂性，Gimp 是 600.000 行代码，内核范围在百万或更多。
除此之外，添加一个事实，如果您正在使用瀑布，您需要开发代码的时间实际上只是开发规范和设计所需时间的一小部分。我估计 2/3 时间用于规格 + 设计，剩下的 1/3 用于编码，甚至更多用于规格 + 设计部分。这真的很耗时。
因此，从复杂性到代码行数跟踪您的估算，考虑您拥有的人力以及他们可以并行工作的数量，并加上规范+设计的开销，您将得到一个非常粗略的估算。
我建议你神话人月。在这方面，这是一本很棒的书。
于 2009-04-08T17:11:18.497 回答
1
就个人而言，我将估计想象为统计分布 - 并尝试用它传达标准偏差的概念：
10 是 '它有 50% 的机会在 8 到 12 之间'
很难比整体项目估算更精确。完全有可能变得更精确（分成独立的独立故事，集体估计每个故事，以及其他敏捷实践）——但这是有代价的。
（此外，估计不应该是对可交付成果的参与 - 否则它会被填死并变得无用）
于 2009-04-08T17:02:39.937 回答
1
如果你拒绝对你从未做过的事情给出估计，你可能会一辈子都这样做。首先尽可能地拆分任务，这将帮助您弄清楚您将如何做。您将有更多机会将任务的一部分与您以前做过的事情进行比较。不要犹豫，将您的确定程度传达给您的经理。
于 2009-04-09T00:08:08.820 回答
1
对于一个经验丰富的程序员来说，至少了解系统并在他们面前有一套合理的要求，“我不知道”不是一个有效的答案。如果你说你不知道你的 PHB 会去应用他们的 1337 h4x0r sk1lz 并按照“这听起来像小菜一碟，大约 1 小时”的顺序进行估算。
您应该能够将问题分解为您之前解决过的一系列较小的问题，并为每个部分提出一个合理的数字。指出它非常粗糙，一旦你对问题进行了全面分析，它可能会非常糟糕。
它们被称为“估计”，因为它们很粗糙。通过做更多的工作并学习尽可能多地利用过去的经验，您可以更好地进行估算。记住要考虑意外情况（中断、任务切换、生病的可能性、可能的返工等）。通常增加 50% 会使估计值更接近标记。
于 2009-04-09T00:19:38.997 回答
0
提供一个粗略的估计，并对此非常清楚。
确定您将如何处理该项目的策略。特别要确定可以作为工作中间版本交付的系统部分。请特别注意其中最接近的部分，您将能够发布完整的功能，如果可能的话，将其余部分排除在范围之外（保留这些和出现的任何内容的列表，以安排为后续项目）。
使用短迭代。考虑/分析中间版本如何适应 2-6 周的迭代。考虑到这给你的学习，并调整总体估计。
继续第一次迭代，并应用您对所做假设的了解。您在早期迭代中的偏离程度通常表明估计存在问题。抵制考虑初始开销中估计部分的偏差的诱惑，因为您可能会延迟您意识到估计偏离的时间点。请注意，我确实理解/同意项目的速度随着时间的推移而增加，但考虑到这一点往往会隐藏/延迟问题。
于 2009-04-09T00:30:33.323 回答
0
我一直这样做。几乎我所做的一切都是第一次。我如何估计？我猜！然后我又猜了。而且我会在每个 delta-time 间隔重新制定时间表时一直这样做，因为项目计划是迭代的，而您只有在执行时知道的内容。我的猜测非常好，因为多年后我已经弄清楚什么“看起来”容易，什么“看起来很难”
于 2009-04-09T00:44:47.593 回答
0
尝试功能点分析。对于 CRUD 的东西，它给出了很好的数据。它的主要优点是它不是基于您要实现的内容，而是基于用户的要求。不过，您需要找出您的 FP 生产力。您可以使用相同语言的过去项目来做到这一点。
如果您无法构建历史数据集，则可以使用目标语言的平均生产力。它会给你一些东西，不一定接近现实，但至少会让你比较不同项目的努力。
现在，请注意，FPA 不适合算法繁重的软件，并且它依赖于 AVERAGES，这意味着您可能会高估或低估每个项目。
于 2009-04-09T01:19:21.083 回答
0
我的同事总是说，首先估计项目长度，然后将其乘以 2 加 1，然后添加下一个最高单位。所以如果你的答案是 3 天，那么你会说 7 周。这是一个半开玩笑的想法，一个想法是首先估计项目，然后在完成后看看你离你有多远，也许你总是偏离 2 或 3 的倍数，或者其他什么。
于 2009-04-21T19:48:43.720 回答
0
Any unknown task or job always has something which is known to a certain degree and easy to estimate. I split and I give estimates right away for the things I know and for the things I feel I know. The rest is honestly being declared as a thin spot and then we start "bargain". If work giver trusts my competence he will except my rough estimations and risks - we work together. It was never a failure, simply because I would never take a task which I can't lift or run into the ground (gut feeling?). If work giver doesn't trust me, I always recommend who to ask and where to look for a better option. Then we either work together or not. Most of the time we do, but everyone is on the safe side. I do my job, "thin spot specialist" gets his/her cut, managers are happy and customer's satisfied. Perhaps it's a bit naive, but it works for me :)
于 2009-04-21T20:04:43.917 回答