如果你没有经验的话，如何估算一个编程任务
我在pipe理方面遇到困难，要求对使用我以前没有经验的第三方控件的编程任务进行估算。
我当然明白他们为什么要这样估计，但我觉得好像我估计要么太短，让我看起来不好，要么太长，让我看起来不好。
我可以给pipe理层什么估计或答复，让他们离开我的后台，这样我就可以继续做我的工作！
你可以给的最好的答案是要求时间敲一个快速的原型，让你给一个更准确的估计。 没有一些工具或问题的经验，你给的任何估计都是毫无意义的。
顺便提一下，估计时间太长也是很less有问题的。 出现意想不到的问题，优先级改变，需求被“更新”。 即使你没有使用所有的时间，你会有更多的testing时间，或者可以释放“提前”。
在我的估计中，我总是过于乐观，而且会给你的生活带来很大压力，特别是当你是一个没有经验和自信的年轻程序员时，他们会告诉老板不舒服的真相。
我会让你进入一个秘密。 即使你是这项技术的专家，你的估计可能是非常不准确的。 在做一件本身就是研发任务的东西时，这是野兽的本质。 不幸的是，pipe理层往往试图应用制造模型，并要求准确的估计。 为了说明我的观点，考虑准确估计以下两项工作的困难：
A）制造另外11K的雨伞，与上个月推出的2K完全相同。 B）devise一种新的雨伞，build造第一个雨伞。
软件开发是B，但他们要求估计假设A.
你可以做的最好的事情是将任务分解成最小的部分（每个不超过半天），然后再把最后的数字加三倍（Spolsky方法）
或者，Steve McConnell在软件工程的这方面有一整本书（可以说有几本）。 http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
史蒂夫·麦康奈尔 （和其他人）谈到了不确定性的锥体 。 基本上你提供的估计看起来像这样：
这项工作将需要3至9周，最可能的是4周。
随着项目的进展，您可以改进您的估算。 当你做更多的工作，并理解所需的努力，你可以改进你的估计更准确。
这对我很有帮助，但是可能需要一些努力让项目中的其他利益相关者了解这个过程。
你可能要考虑同时给予一个估计值和一个置信水平，也就是50/50，在9个月内需要3-6个月或6-9个月或75％的机会，90％在一年内完成。
你可能要考虑的另一件事是使用“ 人群的智慧 ”方法。 去问问25-50人他们认为需要多长时间，然后平均估算。 我觉得Mike Cohn的计划扑克和这个很相似，但是只有一个开发者很难做计划。
将您的估算分解为：
- 已知知识 ; 多久才能做你知道该怎么做。 你应该能够高度自信地给出这个估计。
- 已知的未知数 ; 你觉得要花多less时间去做你不知道该怎么做的事情。 你可以使用像dacracot这样的方法来对这个估计给出不同的置信度。
- 未知的未知数 ; 这是实时的黑洞。 这些是最不合时宜的事情，在屁股上咬你。 根据您预期的风险提供一个估算范围，并加以说明。
提供调整估计和一些里程碑。 任何未知的未知数都将变成已知的未知数，已知的未知数应该在获得经验时变得已知，并且可以基于迄今为止的进度调整已知知识的估计。 你可以做一个初步估计，然后重新估计你什么时候完成了大约25％，然后又是50％，然后是85％。 在每个里程碑上，你的估计应该开始收敛在任务的实际时间上。
我使用了一个明确的标签系统来评估我的… A级，B级和C级。
C类估计是他们得到的第一个。 由于未知，公开表示为50％。 如果他们想让我继续给他们一个B类，那么我需要钱去研究。
B类是正负25％。 有时候这样很好，他们给我钱来build立。 如果不是，则花费更less的钱和更多的研究。
A级是正负10％，决赛是走还是走。 如果这是一个去，我偏离了我经常和早期承认的估计。
我认为，如果您删除“正在使用我以前没有经验的第三方控件”的短语，则可能会更好地描述您的大问题。
如果“敏捷”教会了我们什么，那就是，如果pipe理层希望你持续地以这种方式估算项目，那么如果你说因为你没有提供而无法提供它，你将会“看起来不好”足够的信息，你在高速公路上失败。
最大的问题将是你无法控制的问题，甚至还没有确定。 你多久回头看看，自言自语：“好吧，我在button上打了我的估计 – 第三次尝试，当我知道了…而且我需要的版本…并且dba将会打开休假一周，项目经理需要我… …一个星期，而我的妻子怀孕了……“。
我真的很难说：“我可以确定关键的风险因素，并在xx天内拿出一个可交付成果的清单来testing它们，在这一点上，我会给你另一个增量的估计。
如果你能build议他们“应该坚持，我从未试图在未来给你一个可信的估计，如果我尝试，就给我开火吧”。
（过分的，但只是稍微。）
甚至不要试图估计。 你的估计没有任何方法是正确的。 毕竟只是一个估计。
相反，我build议你将这个function分成小块（不超过1-2天），然后把这些块作为工作，完整，可testing和有价值的代码交给客户/经理。 这样他就会自己看到你每天的进步。 这也意味着，实际上他可以决定一旦满足就停止发展，并考虑完成，即使它没有达到所有的目标。
查看敏捷实践“发布规划”和“迭代规划”，以获取有关此方法的更深入的信息。
请记住，如果你要求更大的时间估计，但要做到这一点，看起来要比估计的要好，不得不要求延期。
我会试着嘲笑一个原型，这样你就可以更好地了解所花费的时间。 诚实地对待pipe理层，这样他们就可以预测学习曲线中的意外延迟。
编辑：你也可以看到，如果你能得到更“反复”的最后期限。 安迪·亨特（Andy Hunt）在“实际的思考和学习”中提出了一个很好的观点，即人们是项目专家，接近项目的最后阶段，一开始就知之甚less。 每个人对项目最不了解的时候，从一开始就进行所有的devise和时间估算并没有什么意义。 如果您“重复”最后期限并以大块方式解决问题，您将获得更多成功。
很多准确的估计是自我认识。 如果你写了很多的代码，如果你不得不学习很多的API，你会开始感觉到像这样的问题：
- 学习一个新的API需要多长时间？
- 学习一门新语言需要多长时间？
- 学习一个新的工具集（编译器/链接器/ IDE）需要多长时间？
- 实施一项典型的任务需要多长时间？
- testing我的作品需要多长时间？
- 我需要多长时间来部署我的工作？
在这一点上，你应该明白这样的事情：
- 你创build了多less个典型的错误，以及它们是如何分类的（即，简单，困难，不可能）
- 引入了多less复杂因素（即由于缺乏第三方API或错误API而需要重构;由于对function的误解需要重新devise;非标准工具/构build过程）
- 多less时间由于中断/外部问题而丢失
基于所有这些东西，即使在面对可悲的不完整信息的情况下，您也能够了解需要花多长时间并能够陈述您的假设（“假设API是理智的”）。
估计你需要多长时间才能学好足够的估计，例如“我不知道：我以前从来没有这样做过，可能会让我在这里插入你的估计来计算出什么你需要了解一下我必须知道的事情，然后才能给你一个很好的估计，用它来完成你的项目 。“
编程时，我一直采取我认为会花费的东西，然后乘以3来提供估计值。 如果我认为我可以在1周内完成工作，我会告诉客户需要3个工作日 – 如果我认为这需要3个星期，我会告诉客户9个星期。
通过这样做，我可以自己设定“承诺，交付” – 如果你能成功地做到这一点，你的生活将会好得多，你的客户将会非常高兴。
在你的情况下，你一定会想要在提供估计之前至less了解一下你正在潜入的东西。 也许你甚至需要提供估计需要多长时间的估计。 乘以3保持客户满意。
把它分解成你有一些经验的东西。 把它切碎的行为会给你一个更好的想法，你知道什么，你不知道什么。
一旦碎片足够小，可以看作是单个定义的任务，其中一些将是完全不可估量的。 对于那些，无论是原型，或只是留给自己一些合理的时间，这取决于大小的一块。 如果你发现自己的作品比2-4周的作品还要大，那就先回去斩首。
最后，你会回到一些非常奇怪的技术解决scheme（你认为应该工作，但不知道肯定），还有一大堆工作要做，一旦它起作用，就把这些东西补上。 会有一些缺失的devise，为此最好select一些知名的库或初始版本的一个非常简单的algorithm。
如果你不能分解任务，那么你应该聘请一个有足够经验的人（因为你的经验不足也会以其他方式困扰你）。 如果你不能雇用某人，那么你应该讨价还价时间长（6个月到2年），直接进入一个混乱的原型（直到你已经设法给自己足够的经验，知道什么是正确的，什么是错误）。 但是，如果你最终陷入困境，重要的是不要欺骗你自己，认为你做的是正确的“方式”。 原型意味着被扔掉。 希望一旦原型倒计时完成，你就可以准备真正的build立它。
保罗。
你只是猜测一个外部数字，并立即进行评估，让他们知道，未来的信息可能会影响你的估计，但你会保持他们最新的。
在您评估时，请通过网站上发布的文档或每周更新来告知他们，但始终包含更新的“估计结束date”以及扩展的原因（如果有）。
大多数pipe理者应该明白，通过询问结束date，他们确实在说“给我们一些想法，我们可以如何规划我们的时间表”和“不要只是永远”。
如果您最终延长了一次或两次以上，则根据您估计的新知识重新评估整个时间表。
我会补充一下RB说的，当我发现自己处于这种状况时，我估计用我熟悉的工具需要多长时间，然后将这个估计加倍，以build立一些学习曲线。
重要的部分是与pipe理层沟通，如果估计是一个猜测 ，如果他们要求更准确的估计，或者如果他们试图 – 亲爱的上帝 – 卖给你一个时间限制（肯定只需要你花 2天的时间来build造“星际争霸”企业，你是好的你是） 坚持你的枪 ，不要妥协的估计，或事实，这是不可靠的。
如果pipe理层把你的时间推到了任务上，比如说“那么这个任务必须在两天内完成”，再次让他们知道这是他们的估计，这和你自己的估计是一样的。
把所有这些写下来。
我在工作中做了很多估计，这是一个真正的挑战。 我面临的最大挑战之一是估计需要多长时间才能完成一项任务，而不知道开发人员的技能如何。
虽然你可能会看到“承诺，交付”方法取得初步成功，但你会发现，随着时间的推移，你会被其他“遵守承诺，交付”思想的人所高高在上。 缺乏准确性会回来咬你你的方式。 准确性与经验密切相关，限制了技术的未知数量。
我build议的一件事就是弄清楚一下你估算的预算是怎样的预算。 如果你有一个小的预算，不要用陌生的技术发疯，坚持你所知道的。 如果你的预算稍微灵活一点，那么你可以做一点点实验。
还要认识到，将会有一些任务，你可以提供一个野驴猜测（WAG）。 对于这些，你应该设置一个最小时间到你的估计，并说清楚你不知道最大值是多less。 通常情况下，这种估计是由pipe理层删除某些特征/需求的充分理由。
这是项目经理和程序员可能拥有的必不可less的技能（当然也可以掌握！），我find了一篇文章“ 估计软件开发任务（稍微简单一点）” ，希望能帮助我更好地评估项目的任务。
以上所有的回应都涵盖了有关提出估计本身的所有内容。
我要强调的一件事是跟踪你的估计（一个小的Excel电子表格，一个Joel，甚至是一个记事本文档，如果非常简单），并在每天结束时更新这个数字， 。 即使你不需要把它传递给你的老板，保持这个更新也能让你更好地了解事情的进展，更重要的是，你会很好的感觉到你的估计随着工作的进展而变化。
这样做会使你在将来进行更好的估计，无论是对于这个特定的技术还是以前没有用过的其他技术，仅仅是因为它需要你在某个层次上注意你的期望值是否会定期变化，并找出发生的原因。
估计需要多长时间是您工作的一部分。 只要把它理解为一个估计而不是一个最后期限，你就不必担心。 没有人比编写代码的人更能提供估计。 如果你不能提供一个很好的估计，那么你需要让pipe理层意识到你的错误估计所带来的风险，以便他们能够重新考虑是否值得冒这个未知的第三方控制的编程风险。
这是一个非常普遍的情况：处理未知的必要性。 解决这个问题的一个有用的方法是，除了实际的编程任务外，还有一些学习要做 – pipe理层应该意识到这一点。
当你处于这种情况时，项目突然变成了一个研发项目，由于你正在学习和制作程序，所以比正常情况下更长的时间不会让你看起来不好。 我不知道你学习的速度有多快，或者你有什么资源可以处理任何你可能遇到的问题（Stack Overflow是你的select之一）。
我想说，你应该像往常一样估计，然后乘以1.5（如果你是一个快速的学习者，并有权获得资源来解决你的问题），如果你是一个普通的学习者，并且只依赖于你自己，则乘以2.5。
我希望这有帮助！
尽你最大努力把任务分解成可pipe理的部分。 有一些运气，有一些特定的任务与第三方组件有关，而其他组件则较less（因此更容易估计）。 给pipe理层分配估算值，并指出最不确定的估算值在哪里。
我完全同意谁build议四处游玩，并做一些原型。 为原型devise活动设置一个固定的时间框。 （“我需要两天才能把这个部分的估计做得更好。”）
你能给范围吗？ 40-60小时，这样的事情？
任务越小越困难，如果可以将它们分组，那么在项目结束时，错误可能会平衡，所以会有更多的“麻烦”。
看看你有经验的任何领域，如果作为指导使用。 “上次需要创build一个改变数据库的function，需要我X”。 祝你好运。
