logo标签列表

如何针对从未做过的事情给出有效的时间估计？

project-managementtimeproject-planning
30
作为一名新的开发者，我是公司里唯一的软件人员，我面临了一些挑战，但可能最困难的是时间估计。每次需要提供项目估算时，我都很吃力。
那么我的问题是：如果我没有任何经验，也没有其他开发者在身边，该怎么做才能提供一个可靠的估计？我已经阅读了 Joel Spolsky 在 Evidence Based Scheduling 中的文章，但是如果我没有任何证据，那么如何应用它呢？
非常感谢您对这个问题的任何建议。
13个回答
30

你没有提供一个确切的估计。你尽可能给出一个好的答案，并解释它只是一个非常粗略的估计，以及为什么它这么粗略。

如果你清楚地表明：

  • 你不能提供准确的估计
  • 你不能给出准确的估计是合理的，因为它与你之前做过的工作不同
  • 随着时间的推移和你对主题的了解越来越深入，你会更新估计

我认为你应该没问题。不过，你需要在书面上非常清楚地阐明这些事情，以便以后不要被粗略的估计束缚。

我不同意。程序员可以而且应该提供真实的估计。你不能基于“完成时间未知”来经营业务。 - John Dibling
@JohnD - 你有关于我如何处理从未接触过的事情的建议吗？谢谢！ - Refracted Paladin
我刚刚发布了。让我向您保证，如果您希望您的估算有价值，那么估算开发工作是非常困难的。 - John Dibling
John Dibling：我不同意。作为一名初级开发人员，我经常被要求做我从未做过的事情。在被要求估计时，我就像Jon在这里说的那样做。我直接向工程副总裁报告，并被他告知他很欣赏我的坦率。 - Ed S.
让某人估计他们还不知道如何完成的事情是不合理的。让我问你：编写一个功能性的网络协议需要多长时间？假设你还没有完成过这样的任务，你会如何估计它的时间？ - Ed S.
14
@John: 您刚刚发表了一篇帖子，表示在给出估计之前，通常会完成90%的工作。这是否与您在此处的第一条评论相符？如果您要等到非常接近完成才给出估计，那么这非常接近于“在准备好时完成”。 - Jon Skeet
6

你可以说：“我不知道，我没有足够的证据。”

然后进行一些原型制作，以获取一些证据。

然后回答这个问题。

因此，您实际上可能能够估计何时能够给出估计。

通常情况下，您已经完成并可以估计的请求部分 - 将其分离出来，原型化其他部分（尽量不要花费超过必要的时间），并提供一个估计时间，同时声明您对时间的确定度为x％。（通常情况下，当您确定时，希望在75％左右） - meade
6
IMO Joel在他的文章中非常偏离实际，他的结论和建议都没有基于任何现实。他基本上认为你应该在开始工作之前就能够将你的工作安排到每个小时或更短的时间单位。但现实是，在进入代码之前，你不知道这些工作单元会是什么（在非平凡系统中）。因此，你无法事先制定一个小时级别的详细计划，并使其反映出实际情况。
如果想要一个有价值的项目估算，那么给出一个准确的估算是非常困难的。对于程序员来说，制定准确的估算很困难，因为往往只有在深入了解之后才能发现项目的所有复杂性。
因此，解决这个问题的方法是在制定估算时深入了解项目。对于较小的项目和错误修复，这比较简单：
- 在你的机器上复制错误。 - 找到导致错误的代码。 - 弄清楚如何编写修复错误的代码。 - 估计编写该代码需要多长时间。
在找到你必须编写的代码时，你必然会发现可能会影响你估算的大部分或全部复杂性。
这种方法的有趣之处在于，生成估算所需的时间往往占实际工作总时间的90%。你几乎必须在实际工作中才能得出一个估算。特别是对于错误修复，解决方案通常只需要一行代码，因此你的估算最终可能只需要5分钟。这很好，因为可以根据这样的估算来设定截止日期。
随着你的练习，你会越来越擅长“知道”事情需要多长时间。起初，你只能“知道”最小项目需要多长时间。但随着时间的推移，你将能够估计越来越大的项目。
1
你刚刚描述了基于证据的进度安排的本质。你使用以往的经验来估计未来的工作。随着你获得越来越多的经验（证据），你会“知道”（通过记录的经验）未来项目需要多长时间。 - JeremyDWill
@JDW：谢谢。我从未听说过它被称为基于证据的进度安排。我实际上以为这是我的原创想法。 :) - John Dibling
@john：我来找你问一下修复这个bug需要多长时间。请在10分钟内告诉我。修复一个bug的一部分是找到它并重现它，很多情况下这需要比实际修复更长的时间。 - JoshBerke
1
这种方法有趣的地方在于，生成估计所需的时间往往占实际工作总时间的90%。到那时，你的估计几乎毫无价值。我认为这种方法对于设计一个新功能而言是有效的，因为没有太多未知因素。 - Davy8
1
我的意思是，在设计过程中，你可以弄清楚需要完成什么任务，这通常不到总时间的50％，但对于那些你不知道涉及哪些内容的错误修复，从管理角度来看，你最好给出一个粗略的猜测或者说我不知道。 - Davy8
@Davy，就像我说的那样，你可以开展一个基于“完成时机不确定”的软件业务。 - John Dibling
3
我首先根据问题的复杂程度估算。这个问题有多大？可能会触及或需要多少部分？这给了我一个大致的指导方针。然后，我总是确保增加15-25％的余地，因为你肯定会漏掉某些东西。
最后，你要非常清楚地表明，这只是一个粗略估计，基于你对问题的理解以及如何解决它。
同时，不要用非常精确的时间单位来给出粗略估计。4.5小时不是一个粗略估计。半天是一个粗略估计。
3
虽然很粗略，但我估计代码行数。这个参数对于生产力的意义接近于零，但仍然让你了解项目的复杂性。
平均而言，开发人员每天可以编写约200到最多300行代码。请考虑单兵作战的编码：
- 小型项目的1000行（逻辑）代码可以在一两周内完成。 - 平均复杂度的10,000行（逻辑）代码项目可能需要两到三个月才能完成。 - 大型项目的100,000行（逻辑）代码至少需要几年时间。
对于逻辑代码，您必须添加测试，这已包含在先前的估计中。为了了解复杂性，Gimp有600,000行代码，内核范围在百万或更高。
此外，如果您正在瀑布模型下工作，则开发代码所需的时间实际上只占开发规格和设计所需时间的一小部分。我会估计2/3的时间用于规格+设计，剩余的1/3用于编码，甚至更多用于规格+设计部分。这真的很耗时。
所以，从复杂度到代码行数追踪您的估计，考虑您拥有的人力资源以及他们可以并行工作的数量，再加上规格和设计的开销，您将得到一个非常粗略的估计。
我建议您阅读神话般的程序员之月。这是一本关于此方面的绝妙书籍。
1
如果有人平均每天编写 200-300 行代码，那么这个人需要学习一些设计技能，因为他们在大量复制和粘贴。难道这个人也不测试他们的代码吗？ - Dunk
1
嗯，我不完全同意。我个人编写了一个已经完全设计好的应用程序模块。我只有接口。最终的代码行数是9200行，我在45天内完成了编写，平均每天200行代码。其中一半是测试代码。 - Stefano Borini
如果你每天只写200行代码，那么你的计划不够充分。我见过一些人平均每天不到1行代码，因为在高可靠性行业中需要进行正式的计划和测试开发阶段。 - Adam Hawes
1
其中没有一个是自动生成的。在9200个文件中，有4500个是代码，其余的是测试。编程语言是Python。不，当我们第一次开始处理这些相当具有欺骗性的规格时，设计确实存在缺陷，但是最终确定的设计是坚固的，并且完美地满足了需求，没有出现问题。 - Stefano Borini
@Dunk 看起来你来自 WEB/OO/framework-aware 的世界。在嵌入式或加密项目上工作时，由于任务特定性，我的代码行生产率可能会降低10倍。 - gavenkoa
显示剩余2条评论
1

就个人而言，我将估计看作统计分布，并尝试通过它来传达标准差的概念：

10意味着“有50%的可能性在8和12之间”

对于整体项目估计来说，很难比这更精确了。当然可以变得更加精确（将其拆分为独立的单个用户故事、集体估算每个故事以及其他敏捷实践），但这是有成本的。

（此外，估算不应该成为可交付成果的承诺，否则它会被无限增加而变得毫无用处）

1
如果你拒绝为从未做过的事情提供估计，那么你可能会一辈子都这样做。首先尽可能地将任务分解，这将有助于澄清你将如何完成它。这样你就更有机会将任务的一部分与以前做过的类似任务进行比较。不要犹豫，向你的经理传达你的确定程度。
1
对于一位有经验的程序员来说，至少了解系统并且面前有一组合理的需求，“我不知道”不是一个有效的答案。如果你说你不知道，你的PHB会去应用他们的1337 h4x0r sk1lz并给出一个估计值，大约为“听起来很简单，需要1小时左右”。
你应该能够将问题分解成一系列较小的问题，并为每个部分提出一个合理的数字。指出这只是一个非常粗略的估计，一旦你进行全面的问题分析，它可能会大幅度增加。
它们被称为“估计”，因为它们是粗略的。通过更多地实践和尽可能地借鉴过去的经验，你可以更好地进行估算。记得考虑到容错（中断、任务切换、可能生病、可能需要重新工作等）。通常增加50%可以使估计更接近实际情况。
0

提供一个粗略的估计，并且要非常清晰。

确定解决项目的策略。特别是要确定您可以交付作为工作中间版本的系统部件。请特别注意最接近完全功能性发布的中间版本，如果可能的话，将其余的内容排除在外（保留这些和任何出现的列表，计划作为后续项目）。

使用短迭代周期。考虑/分析中间版本如何适合2-6周的迭代周期。考虑到这给你带来的学习，并调整整体估计。

进行第一次迭代，并应用您对假设的了解。早期迭代中的偏差通常指估计存在问题。抵制考虑估计偏差是初始开销的诱惑，因为这可能会延迟您认识到估计存在偏差的时间点。请注意，我确实理解并同意项目速度随时间增加，但考虑这一点往往会隐藏/延迟问题。

0

我经常这样做。我做的几乎所有事情都是第一次。我如何估计？我猜测！然后我再猜测。每当进度表重新制定时，我会在每个时间间隔内继续这样做，因为项目计划是迭代的，只有在实际操作中才能知道。我的猜测相当准确，因为经过多年的实践，我已经弄清楚了什么看起来容易，什么看起来困难。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接