没有经验的人如何估算编程任务

我在与管理层的交往中遇到困难，要求对使用我以前没有经验的第三方控件的编程任务进行估算。

我绝对理解为什么他们会想要这些估计，但是我觉得我给出的任何估计要么是a）太短而使我看起来很糟糕，要么b）太长而使我看起来很糟糕。

我可以给管理层以什么估计或答复，以使他们摆脱困境，以便我继续工作！

您能给出的最佳答案是要求时间来敲定一个快速的原型，以便您进行更准确的估算。如果没有一些使用工具或问题的经验，你给任何估计基本上是没有意义的。

顺便说一句，给出太长时间的估计很少有问题。发生无法预料的问题，更改优先级，并且“更新”需求。即使您不花所有的时间，您也会有更多的测试时间，或者可以“提前”发布。

我的估计总是过于乐观，这会给您的生活带来很大压力，尤其是当您是一个年轻的程序员时，没有经验和自信来告诉老板不舒服的真相。

我让你秘密。即使您是该技术的专家，您的估计也可能非常不准确。做某事本身就是研发任务，这就是野兽的天性。不幸的是，管理层经常试图应用制造模型并要求准确的估计。为了说明我的观点，请考虑准确估算以下两项工作的难度：

A）再制造11K伞，与您上个月生产的2K伞完全相同。B）设计一种新型的雨伞并制造第一个。

软件开发为B，但他们要求假设A为一个估计。

您能做的最好的事情就是将任务分解成最小的部分（每次不超过1/2天），然后将最终的数目增加三倍。（Spolsky方法）

另外，史蒂夫·麦康奈尔（Steve McConnell）有一本关于软件工程这方面的整本书（可以说是几本）。 http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

史蒂夫·麦康奈尔（Steve McConnell）和其他人谈论不确定性的锥体。基本上，您提供的估算值如下所示：

这项工作将需要3到9个星期，最有可能需要4个星期。

随着项目的进行，您可以优化估算。随着您完成更多工作并更好地了解所需的工作，您可以优化估算以使其更加准确。

它对我有用，但是可能需要一些努力才能使项目中的其他利益相关者了解过程。

您可能要考虑同时给出估计值和置信度，即50/50将需要3-6个月或6-9个月，或者9个月内有75％的机会完成，而90％的机会将使您信心十足。一年完成。

您可能要考虑的另一件事是使用“ 人群智慧 ”方法。四处询问25至50个人，他们认为需要多长时间并平均估算值。我认为，迈克·科恩（Mike Cohn）的“ 规划扑克”与此非常相似，尽管仅由一个开发人员进行规划就很难。

将您的估算细分为：

• 已知的已知 ; 做您知道怎么做需要多长时间。您应该能够高度自信地给出此估计值。
• 已知的未知数 ; 您认为做不知道的事情要花多长时间。您可以使用类似dacracot的方法来对此估计值给出不同的置信度。
• 未知的未知数 ; 这是实时的黑洞。这些都是在最不合时宜的时间里发生的事情，并且会在无聊中咬你。根据您预期的风险提供合理的估计范围。

提议一路调整估计和某些里程碑。任何未知的未知数都将成为已知的未知数，随着您的经验积累，已知的未知数应成为已知的已知数，并且可以根据迄今为止的进度来调整已知已知数的估计。您可以进行初步估算，然后在完成约25％时重新估算，然后再次估算50％，然后再次估算85％。在每个里程碑，您的估计应开始收敛于任务实际花费的时间。

我为我的估算使用了明确的标签系统... A级，B级和C级。

他们首先得到了C级估计。由于未知原因，公开表示为正负50％。如果他们希望我继续给他们B类，那么我需要钱来研究。

B类为正负25％。有时候，这足够好，他们会给我钱来建造。如果没有，更少的钱和更多的研究。

A类为正负10％，最终为合格或不合格。如果这是一次尝试，而我却偏离了我经常和提早承认的估计值。

我认为，如果删除短语“正在使用我以前没有经验的第三方控件”，则可能会对较大的问题有更好的描述。

如果“敏捷”教会了我们任何东西，那就是，如果管理层希望您不断地以这种方式估算项目，并且您说“无法提供”，因为您没有提供，您就会“看起来很糟”。足够的信息，您在通往失败的路上。

最大的问题将是您无法控制，甚至尚未发现的问题。您有多少次回头对自己说：“好吧，我在确定了...并且我需要版本...并且dba会在休假一周，项目经理将需要我……一周，而我的妻子怀孕了……”。

我会很努力地说：“我可以确定关键的风险因素，并提出可交付成果的清单，以便在xx天内对其进行测试。届时，我将再给您提供增量估算。”

如果您可以建议他们应该“真的，那就太好了”，请您坚持认为我以后永远不要给您这种类型的可信估计。如果尝试，请解雇我。”

（夸大了，但只是略有增加。）

甚至不要尝试估计。您的估计没有任何办法是正确的。毕竟这只是一个估计。

相反，我建议您将功能拆分成小块（不超过1-2天），然后尝试将这些块作为有效，完整，可测试且有价值的代码交付给客户/经理。这样，他将每天看到自己的进度。这也意味着，即使开发未达到全部目标，他实际上也可以决定停止开发并认为开发已完成。

请查看敏捷实践“发布计划”和“迭代计划”，以获取有关此方法的更深入信息。

请记住，如果您要求更大的时间估计，但是要按时进行，则它看起来比估计并要求延期要好得多。

我会尝试模拟一个原型，以便您更好地了解所需的时间。对您的管理层诚实，以便他们可以预算学习曲线中意外的延迟。

编辑：您可能还会看到是否可以得到一个更“迭代”的截止日期。在《实用思维与学习》中，安迪·亨特（Andy Hunt）提出了一个很好的观点，即人们是项目专家，他们离项目结束越近，一开始的知识就越少。当每个人对项目的了解都不多时，在一开始进行所有设计和时间估算就没有多大意义。如果您“注明”最后期限并分批解决问题，您将获得更大的成功。

许多准确的估计是自知之明。如果您编写了很多代码，或者必须学习很多API，那么您就会开始对以下问题有所了解：

• 我学习新API需要多长时间？
• 我学习一种新语言要花多长时间？
• 我要花多长时间学习一个新的工具集（编译器/链接器/ IDE）？
• 我完成一项典型任务需要多长时间？
• 我要花多长时间测试我的工作？
• 我部署工作需要多长时间？

在整个过程中，您应该对以下内容有所了解：

• 您创建了多少个典型的错误以及如何对其进行分类（即，简单，困难，不可能）
• 引入了多少复杂性（即，由于缺乏第三方API或错误的API而需要重构；由于对功能的误解而需要重新设计；非标准的工具/构建过程）
• 由于中断/外部问题而浪费了多少时间

基于所有这些内容，即使面对严重不完整的信息，您也将能够弄清需要花费多长时间，并能够陈述您的假设（“假设API正确……”）。

估算您需要多长时间才能学到足够多的知识，以便做出更好的估算，例如，“我不知道：我以前从未使用过此估算。为了估算出什么，可能需要我在此处插入估算值您需要先了解一下它，然后才能为使用此完成您的项目提供一个好的估计。”

进行编程时，我总是接受我真正认为会花费的东西，并将其乘以3以得出估算值。如果我认为我可以在1周内完成工作，我会告诉客户它将花费3个小时，如果我真的需要3周，那么我会告诉客户9个星期。

通过这样做，我将自己设置为“承诺，超额交付” —如果您能够成功做到这一点，您的生活将会变得更好，并且您的客户将会非常高兴。

在您的情况下，您肯定希望在提供估计值之前至少对您要研究的内容有所了解。也许您甚至需要提供估计所需的时间。乘以3可使客户满意。

将其分解为您确实有经验的东西。将其切碎的动作将使您对所知道的和不知道的有更好的了解。

一旦碎片很小，可以将它们视为单个定义的任务，其中的一些将完全不可估量。对于这些，要么先制作原型，要么就给自己一些合理的时间，具体取决于作品的大小。如果发现您的不可估量的部分超过了2-4周的工作量，请先将其切碎。

最终，您将获得一些非常奇怪的技术解决方案（您认为应该可行，但不确定），一旦可行，需要做很多工作来备份这些东西。会缺少一些设计，为此，最好为初始版本选择一些知名的库或一种非常简单的算法。

如果您无法分解任务，那么您应该雇用具有足够经验的人（因为缺乏经验也会以其他方式困扰您）。如果您不能雇用某人，那么您应该随机讨价还价（6个月至2年），然后直接进入一个凌乱的原型（直到您设法给自己足够的经验来知道什么是对的，什么是对的）错误）。但是，如果最终遇到了麻烦，那么重要的是不要开玩笑，并认为您正在按照正确的“方式”进行操作。原型本应被丢弃。希望一旦原型倒计时完成，您就可以真正构建它了。

保罗

您只需猜测一个外部数字并立即进行评估，就可以让他们知道将来的信息可能会影响您的估算，但是您将使它们保持最新。

在评估时，请通过网络上发布的文档或每周更新的方式通知他们，但始终包括更新的“预计结束日期”以及扩展原因（如果有）。

大多数经理应该明白，通过询问结束日期，他们实际上是在说“给我们一些我们如何计划日程的想法”和“不要花很多时间”。

如果最终延长了一次或两次以上，请根据估计的新知识重新评估整个计划。

我想补充一下RB所说的话，当我发现自己处在这种情况下时，我估计使用自己熟悉的工具需要花费多长时间，然后将该估计值加倍以建立一些学习曲线。

最主要的是沟通，管理的估计是猜测，如果他们按了一个更准确的估计，或者如果他们尝试-亲爱的上帝- 卖你的时间限制（当然它会只需要你 2天建星舰企业，你很好，你是）坚持不懈，不要妥协您的估计，或事实不可靠。

如果管理层不顾您的要求而给任务设定时间，例如“好，必须在2天内完成”，请再次让他们知道这是他们的估计，这与您自己的估计一样可靠。

写下所有这些。

我在工作中处理很多估算工作，这是一个真正的挑战。我最大的挑战之一是估计不知道该开发人员的熟练程度的不同开发人员完成任务所需的时间。

尽管您可能会看到“承诺不足，交付过度”方法取得了一些初步的成功，但是您会发现，随着时间的流逝，遵循“承诺过度，交付不足”思想的其他人将超越您。缺乏准确性会以任何一种方式再次困扰您。准确性与经验密切相关，并限制了该技术的未知数。

我建议的一件事是对您的估算将使用哪种预算有所了解。如果预算有限，请不要对陌生的技术发疯，并坚持自己所知道的。如果您的预算稍微灵活一点，那么您可以承受一些实验费用。

还应认识到，在某些任务中，您只能提供Wild Ass Guess（WAG）。对于这些，您应该设置一个最短的估计时间，并明确表示您不知道最大值。通常，这种估算是管理层拒绝使用某些功能/要求的充分理由。

这是项目经理和程序员都可能具有的必不可少的技能（当然也可能是大师！），我发现了一篇文章，《简化软件开发任务的估计（一点）》，希望对更好地估计项目任务有帮助。

以上所有答复几乎涵盖了有关估算本身的所有内容。

我要强调的一件事是跟踪您的估算（一个很小的Excel电子表格，一个la Joel甚至是一个记事本文档，如果它很简单的话），并在每天结束时将其更新为您现在可以提供的最准确的数字。即使您不需要将其转给老板，也可以通过保持最新状态来更好地了解事情的进展情况，更重要的是，您会很好地理解为什么预算随着工作的进展而变化。

这样一来，您可以针对此特定技术以及您以前从未使用过的其他技术，更好地估算未来，这仅仅是因为它要求您在某种程度上注意期望值何时定期更改，并找出发生这种情况的原因。

估计需要花费多长时间是您工作的一部分。只要将其理解为是一个估计而不是最后期限，您就不必担心。没有人比准备编写代码的人能提供更好的估计。如果您无法提供良好的估计，则需要让管理层意识到您的不良估计带来的风险，以便他们可以重新考虑针对这些未知的第三方控件进行编程是否值得冒这个风险。

这是一个非常普遍的情况：应对未知的必要性。解决此问题的一种有用方法是认识到，除了实际的编程任务外，您还需要学习一些知识-管理层应该意识到这一点。

当您处于这种情况时，该项目突然变成了R＆D项目，比正常情况更长的时间不会使您看起来很糟，因为您正在学习和制作程序。我不知道您学习速度有多快，或者需要处理什么资源才能解决可能遇到的任何问题（堆栈溢出是您拥有的选择之一）。

我想说的是，您应该像往常一样进行估算，然后乘以1.5（如果您是一个快速的学习者并且可以使用资源来解决问题），或者乘以2.5（如果您是一个普通的学习者并且仅依靠自己）。

我希望这有帮助！

尽最大努力将任务分成可管理的部分。运气好的话，有一些特定的任务与所涉及的第三方组件有关，而其他的则较少耦合（因此更容易估算）。为管理层提供分散的估计值，并指出最不确定的估计值所在。

我完全同意建议玩转原型并进行原型制作的任何人。为原型活动设置一个固定的时间框。（“我需要两天的时间来使我的估算结果更好。”）

你能给个范围吗？40-60小时，像这样？

任务越小越困难，如果可以将它们组合在一起，则“斜率”会更多一些，因为错误可能会在项目结束时得到平衡。

查看您确实有经验的任何领域，并作为指导使用。“上次需要创建一个功能来更改数据库，这花了我X时间。” 祝好运。