105

我很难与管理层要求对使用我之前没有经验的第三方控件的编程任务进行估算。

我绝对理解他们为什么想要估算，但我觉得我给出的任何估算要么a）太短，让我看起来很糟糕，要么b）太长，让我看起来很糟糕。

我可以给管理层什么样的估计或答复来让他们摆脱我的支持，以便我可以继续工作！

4

22 回答 22

93

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

顺便说一句，给出太长的估计很少有问题。出现意想不到的问题，优先级改变，需求被“更新”。即使你不使用你要求的所有时间，你也会有更多的测试时间，或者可以“提前”发布。

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

于 2009-01-08T17:05:43.443 回答
40

我会让你知道一个秘密。即使您是该技术的专家，您的估计也可能非常不准确。当做一些天生的研发任务时，这是野兽的本性。不幸的是，管理层经常试图应用制造模型并要求准确的估计。为了说明我的观点，请考虑准确估计以下两项努力的难度：

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

软件开发是 B，但他们要求假设 A 的估计。

你能做的最好的事情是将任务分解成尽可能小的部分（每个不超过 1/2 天），然后将你想出的最终数字增加三倍。（Spolsky 方法）

或者，Steve McConnell 有一整本书（可以说是几本书）关于软件工程的这一方面。 http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

于 2009-01-08T17:13:05.563 回答
32

Steve McConnell（和其他人）谈到了不确定性的锥体。基本上，您提供的估计看起来像这样：

这项工作需要 3 到 9 周，最有可能的是 4 周。

随着项目的进展，您可以细化您的估算。随着您完成更多工作并更好地了解所需的工作，您可以改进您的估计以更准确。

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

于 2009-01-08T17:10:01.467 回答
13

您可能要考虑同时给出估计值和置信水平，即 50/50 表示需要 3-6 个月或 6-9 个月或 75% 的机会在 9 个月内完成，90% 的可能性是一年内完成。

您可能要考虑的另一件事是使用“群体智慧”的方法。四处走走，问 25-50 个人他们认为需要多长时间，然后平均他们的估计。我认为Mike Cohn 的Planning Poker与此非常相似，尽管很难仅由一个开发人员进行计划。

于 2009-01-08T17:36:02.367 回答
12

将您的估计分解为：

  • 已知的；做你知道该怎么做的事情需要多长时间。您应该能够以高度的信心给出这个估计。
  • 已知的未知数；你认为做你不知道怎么做的事情需要多长时间。您可以使用 dacracot 之类的方法对该估计值给出不同程度的置信度。
  • 未知的未知数；这是实时黑洞。这些是在最不合时宜的时候出现并咬你屁股的东西。根据您预期的风险提供估算范围，并说明理由。

提议在此过程中调整估计和某些里程碑。任何未知的未知都将成为已知的未知，随着您获得经验，已知的未知应该成为已知的已知，并且您对已知已知的估计可以根据迄今为止的进展进行调整。您可以进行初步估算，然后在完成大约 25% 时重新估算，然后再次估算为 50%，然后再次估算为 85%。在每个里程碑，您的估计应该开始收敛于任务将花费的实际时间。

于 2009-01-08T17:21:51.083 回答
8

我对我的估计使用了明确的标签系统……A 类、B 类和 C 类。

C类估计是他们得到的第一个。由于未知，它公开表示为正负 50%。如果他们想让我继续给他们B级，那么我需要钱来研究。

B类为正负25%。有时这已经足够好了，他们给了我建造的钱。如果没有，更少的钱和更多的研究。

A类是正负10%，最终和go or no go。如果这是一次尝试，而我与估计相差太远，我会经常和早日承认。

于 2009-01-08T17:09:05.743 回答
8

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

如果“敏捷”教会了我们什么，那就是，如果管理层希望你持续地以这种方式估计项目，如果你说因为没有能力而无法提供，你会“看起来很糟糕”足够的信息，你在高速公路上失败。

最大的问题将是您无法控制的问题，甚至还没有发现。你有多少次回头对自己说：“好吧，我在第三次尝试时按了我的估计，在我发现......并且我需要版本......并且 dba 将开启一个星期的假期，项目经理需要我……一个星期，我的妻子怀孕了……”。

我会非常努力地说，“我可以确定关键的风险因素，并提出一份可交付成果清单，以便在 xx 天内对其进行测试。届时，我会给你另一个增量估计。”

如果你能建议他们应该“请坚持说我以后永远不会给你这种类型的可靠估计。如果我尝试就解雇我”，那将是非常好的。

（夸大了，但只是轻微的。）

于 2009-01-08T17:11:37.783 回答
7

甚至不要试图估计。你的估计不可能是正确的。毕竟只是一个估计。

相反，我建议您将功能分成小块（不超过 1-2 天），并尝试将这些小块作为工作、完整、可测试和有价值的代码交付给客户/经理。这样，他就会亲眼看到你每天的进步。这也意味着他实际上可以决定一旦满足就停止开发并认为它已经完成，即使它可能没有达到所有目标。

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

于 2009-01-15T13:56:42.347 回答
6

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

我会尝试模拟一个原型，以便您更好地了解它将花费的时间。对你的管理层诚实，这样他们就可以为学习曲线中的意外延迟做预算。

编辑：您可能还会查看是否可以获得更“迭代”的截止日期。在“Pragmatic Thinking and Learning”中，Andy Hunt 提出了一个很好的观点，即人们是接近项目结束的项目专家，并且在一开始时知识最少。当每个人都对项目了解最少的时候，在一开始就进行所有的设计和时间估算是没有多大意义的。如果您“迭代”截止日期并分块解决问题，您将获得更大的成功。

于 2009-01-08T17:08:31.393 回答
5

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

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

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

  • 您创建了多少个典型错误以及它们是如何分类的（即，容易的、困难的、不可能的）
  • 引入了多少复杂性（即，由于缺少 3rd 方 API 或错误 API 需要重构；由于对能力的误解需要重新设计；非标准工具/构建过程）
  • 由于中断/外部问题而浪费了多少时间

基于所有这些，即使面对非常不完整的信息，您也将能够了解某件事需要多长时间，并能够陈述您的假设（“假设 API 是健全的......”）。

于 2009-01-08T17:13:24.067 回答
5

估计你需要多长时间才能学会足够的知识来做出更好的估计，例如，“我不知道：我以前从来没有用过这个。我可能需要在此处插入你的估计才能弄清楚什么你需要了解它，我必须先了解它，然后我才能给你一个很好的估计，以便用它来完成你的项目。”

于 2009-01-08T17:13:31.273 回答
3

您只需猜测一个外部数字并立即进行评估，让他们知道未来的信息可能会影响您的估计，但您会及时更新。

在您评估时，让他们了解情况——通过在网络上发布的文档或每周更新，但始终包括更新的“预计结束日期”，以及延期的原因（如果有的话）。

大多数经理应该明白这一点——通过询问结束日期，他们实际上是在说“给我们一些想法，我们可以如何计划我们的日程安排”和“不要永远拖延”。

如果您最终延长超过一两次，请根据您在估算方面的新知识重新评估您的整个日程安排。

于 2009-01-08T17:09:10.673 回答
3

在编程时，我总是采用我真正认为需要的东西并将其乘以 3 来提供估计值。如果我认为我可以在 1 周内完成一项工作，我会告诉客户需要 3 周——如果我认为我真的需要 3 周，我会告诉客户需要 9 周。

通过这样做，我将自己设置为“承诺不足，交付过多”——如果你能成功地做到这一点，你的生活会好得多，你的客户也会非常高兴。

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

于 2009-01-08T17:29:41.833 回答
3

把它分解成你确实有一些经验的事情。切碎它的行为会让你更好地了解你知道什么和不知道什么。

一旦这些碎片足够小以至于它们可以被视为单个定义的任务，其中一些将是完全不可估量的。对于那些，要么先做原型，要么给自己留一些合理的时间，这取决于作品的大小。如果你发现你有比 2-4 周的工作更大的不可估量的碎片，那就先回去把它们切碎。

最终，您会遇到一些非常奇怪的技术解决方案（您认为应该有效，但不确定），并且一旦有效，就需要做大量工作来支持这些东西。会有一些缺失的设计，最好为初始版本选择一些知名的库或非常简单的算法。

如果你不能分解任务，那么你应该雇佣一个有足够经验的人（因为你缺乏经验也会以其他方式困扰你）。如果你不能雇用某人，那么你应该随机讨价还价（6 个月到 2 年），然后直接进入一个凌乱的原型（直到你设法给自己足够的经验来知道什么是正确的，什么是正确的）错误的）。但是，如果你最终失败了，重要的是不要自欺欺人并认为你正在做正确的“方式”。原型本来是要扔掉的。希望原型倒计时完成后，您就可以真正构建它了。

保罗。

于 2009-01-08T22:33:57.773 回答
2

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

重要的部分是与管理层沟通，估计是猜测，如果他们要求更准确的估计，或者他们试图 - 亲爱的上帝 -卖给你一个时间限制（当然，建造星际飞船只需要你2 天）企业，你很好）坚持你的枪，不要妥协你的估计，或者它不可靠的事实。

如果管理层凌驾于您之上，并为任务设置时间，例如“嗯，必须在 2 天内完成”，再次让他们知道这是他们的估计，这与您的估计一样可靠。

把这一切都写下来。

于 2009-01-08T17:12:00.917 回答
2

我在工作中经常处理估算，这是一个真正的挑战。我最大的挑战之一是在不知道该开发人员的技能水平的情况下，估计不同的开发人员完成一项任务需要多长时间。

虽然您可能会看到“承诺不足，交付不足”的方法取得了一些初步成功，但随着时间的推移，您会发​​现其他遵循“过度承诺，​​交付不足”思想流派的人会超过您。无论哪种方式，缺乏准确性都会反过来咬你。准确性与经验密切相关，并限制了该技术的未知数。

我建议的一件事是了解您的估算将针对哪种预算。如果你的预算很少，不要对不熟悉的技术发疯，坚持你所知道的。如果您的预算更灵活一点，那么您可以进行一些试验。

还要认识到，在某些任务中，您只能提供 Wild Ass Guess (WAG)。对于这些，您应该为您的估计设置一个最短时间，并明确表示您不知道最大值是多少。通常，这种估计足以使某些功能/需求被管理层删除。

于 2009-01-08T20:00:39.110 回答
2

这是项目经理和程序员都可能拥有（当然也可能掌握！）的一项不可或缺的技能，我发现了一篇文章，估计软件开发任务变得（一点点）更容易，我希望它有助于更​​好地估计项目的任务。

于 2013-04-15T11:51:51.320 回答
1

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

当你遇到这种情况时，项目突然变成了研发项目，比平时更长的时间不会让你看起来很糟糕，因为你正在学习和制作程序。我不知道你的学习速度有多快，或者你有什么资源来处理你可能发现的任何问题（Stack Overflow 是你的选择之一）。

我会说你应该像往常一样估计，然后乘以 1.5（如果你是一个快速学习者并且可以访问资源来解决你的问题），或者如果你是一个普通的学习者并且只依靠自己，则乘以 2.5。

我希望这有帮助！

于 2009-01-08T17:13:42.787 回答
1

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

我要强调的一件事是跟踪您的估计（一个小的 Excel 电子表格，如果它非常简单，甚至是记事本文档），并在每天结束时将其更新为您现在可以提供的最准确的数字. 即使您不需要将其反馈给您的老板，保持更新也能让您更好地了解事情的进展情况，更重要的是，您会很好地了解您的估算为何会随着工作的进展而变化.

这样做会让你更好地估计未来，无论是对于这项特定技术还是你以前没有使用过的其他技术，仅仅是因为它需要你在一定程度上注意到你的期望何时会定期发生变化，并找出发生这种情况的原因.

于 2009-01-08T17:20:53.567 回答
1

估计某件事需要多长时间是你工作的一部分。只要它被理解为估计而不是截止日期，您就不必担心。没有人比编写代码的人更适合提供估算了。如果你不能提供一个好的估计，那么你需要让管理层意识到你的错误估计所带来的风险，这样他们就可以重新考虑是否值得冒险针对这些未知的第三方控制进行编程。

于 2009-01-08T17:29:16.297 回答
0

能给个范围吗？40-60小时，类似的东西？

任务越小越困难，如果你可以将它们分组，你会有更多的“slop”，因为错误可能会在项目结束时平衡。

看看你有经验的任何领域，如果作为指导的话。“上次需要创建一个更改数据库的功能，我花了 X”。祝你好运。

于 2009-01-08T17:10:10.047 回答
0

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

我完全同意任何建议玩并制作原型的人。为原型制作活动设置一个固定的时间框。（“我需要两天时间才能使我的这部分估计更好。”）

于 2009-01-08T17:16:19.723 回答