与程序员讨论估计

Question

对于程序员来说，他们提供的估算最不具攻击性的方法是什么？

即使考虑到一些程序员一直在低估或高估，有时估计远远超出你的想象（其中一个...... 你在开玩笑时刻） 。如何在没有将其置于防守的情况下与他们对抗？

Answer 1

要求他们分解。估算通常应该是较小任务估算的总和。然后，如果缺少任务或者有不需要完成的任务，您可以对其进行排序。

Answer 2

“你是怎么得出估计的？你可以为我分解吗？”

Answer 3

实施Joel Spolsky的Evidence-Based Scheduling。

Answer 4

让他Software Estimation: Demystifying the Black Art (Paperback) by Steve McConnell为他的生日，父亲节，七月四日等等。

Answer 5

要求他们提供进一步的估算细目。 1-2天的估算水平运行良好，其中每个8-16小时的估算必须与特定任务一起指定。一般来说，这足以满足管理层的要求，而且它具有足够的特异性，但足够通用，可由相关工程师明确定义。

Answer 6

我会从试图弄清​​楚他们想要解决的问题的立场来面对他们。通常当我与客户打交道并且我们没有明智地看到项目预算时，这是因为客户正在考虑系统的一种方式，而我正在考虑系统完全不同的方式。

一个很好的例子就是说我的客户告诉我要建立一个CMS系统来处理他们的业务流程。我看看他们的要求，并从他们中推断出我需要为他们建立一个完整的系统。但是，客户端真的试图告诉我，部署已由第三方构建的CMS系统，并尽可能填写其他详细信息。

两种不同的方案有完全不同的预算

Answer 7

与他/她一起了解估计的结果。您可能会惊讶地发现可能已经积累的蠕变量，或者如果估计不足，我认为您不会抱怨。

Answer 8

请他们为您解释估算所依据的原因。你可以这样说，这似乎只是为了帮助你了解情况，即使你内心真的在质疑他的估计。

Answer 9

我会假设他是正确的（假设他有一些知识/ exp）并且告诉他你在X周围考虑估计，然后询问是否有一些细节或问题我缺少解释额外的努力。我也会单独做，而不是让他当场。

Answer 10

我只想说，“这似乎比我想象的要高一点。你可以一次把它分解成几小时的小块，所以我能理解所涉及的一切吗？”

基本上，不要指责，让程序员感觉他/她在帮助你理解某些东西。

Answer 11

最初，当我要求某人给出他们曾经给出的任务估计时，他们会给出一个大概的数字。有时它过去很好，很多时候它曾经像“什么......！”。任何一个人的一般趋势是添加缓冲区并给出估计值。但问题是程序员添加了多少缓冲区？问题始终是每个成员计划他/她的工作的程度。

当我要求估算时，我后来使用了简短的清单。这有助于每个人更好地理解任务，并且与团队成员没有“强烈尴尬的对抗”。以下是我要求的估计......

• 工作分解这有助于程序员以一种他必须考虑任务和所涉及的不同步骤的方式。每项任务不应超过1个工作日。任何人都说自然倾向于......每天都不可能分手，但可能。
• 技术依赖性程序员期望的所有技术依赖关系列表。例如任何需要做的研究或概念证明。关于图书馆使用的任何决定。
• 进程依赖性程序员期望的所有进程依赖性列表。例如内部评论和外部架构评审等内容需要时间来邀请，设置和最终解决问题。

一旦我掌握了上述细节，每个人都很容易谈论估算。在这种情况下，唯一的瓶颈是与团队沟通他们需要提供工作分解任务，技术和流程依赖性。

Answer 12

你真的不能说，“你错了”。

• 要求他们将其分解为子项目
• 检查每个子项目并将其与原始估算值进行比较
• 要求他们调整估算值

如果他们给出的估计似乎有点偏僻，他们可能无法做出正确的估计。如果每次为每个项目询问他们，他们都可以学习如何调整。

虽然这绝不是一门完美的科学。

Answer 13

我会请程序员为您分解工作中涉及的每项任务，并详细估算每项任务。 我认为，在给出估计时，这是一个非常合理的要求，并且应该澄清估计出错的地方。

Answer 14

实际上，要求更快地完成这项所需的知识/技能类型。重要的是程序员的技术诀窍。还与程序员进行某种项目管理讨论。你将获得良好的结果和尊重。

Answer 15

你要求＆＃34;最不具攻击性的方式＆＃34;。那就是沉默，走开。你唯一真正的选择是获得竞争优势，并了解他的特点，计算机语言和他使用的框架。如果你是懒惰的，喜欢一个漂亮的服装，在夜间用优质的电子热浪从多个显示器上看到令人敬畏的电子热浪，那么就不要说一句话。请不要。

Answer 16

我们这样做的最佳方式之一是允许开发人员选择并取消设施。不要只给他/她一份任务清单，但要尽量鼓励他们参与＆amp;参与任务/项目。

对于项目估算，您如何看待https://stackoverflow.com/questions/12552049/would-programmers-use-contribute-to-a-crowd-sourced-estimation-tool？

Answer 17

你只需要问他们而不是真正“对抗”他们。询问他们如何得出他们的估计或他们的估计细分。另外，如果您有任何问题，请告诉他们您的顾虑，并给出正当理由。一个有效的理由是“我需要这个和这个日期的生活，因为它是关键业务”而不是“我希望这个和这个日期生活，因为这是我向老板承诺的“

如果开发人员看起来很和蔼可亲，那么当他们为您提供细分时，您可以尝试与他们的估算进行协商。但是，不要太用力。毕竟，你 让其他人为你做这件事。如果你认为它可以如此快速地完成，那么也许你应该自己做。

Answer 18

当我无法按时获得某些东西时，通常是因为与未知的相遇。因此，如果发现任何未知因素，开发人员不应该冒犯它。我现在可以列出两种类型的未知数：（i）开发人员找到了需要研究理论的新领域; （ii）开发商已发现本规范中应有的隐含要求或缺失部分。

最少“冒犯性”的查询是关于（ii）因为开发人员在这里没有错，应该更愿意谈论这个。

当你搞砸了（i）你可以进入自我地狱。大多数商业IT商店对问题（i）完全没有任何怜悯，因为许多这些“明智的”商业领袖都认为开发商正在窃取付费时间，以牺牲公司为代价来学习。因此，提问者谈论“面对面”是正确的 - 因为这（i）遭遇等于指责某人是小偷。

Answer 19

在考虑要求他提供更多解释之前，您需要考虑多种事项：

1. 获取个别项目的估算值。
2. 要求您单独提供单元测试（如果您关心）
3. 验证他是否正在考虑任何依赖项。
4. 确保您对范围保持同步。
5. 他是高年级的吗？如果是，那总是这样吗？

最后，唯一的方法是让他/说服他重新考虑估计数，因为预算不会允许这么多时间，并要求他重新考虑他的估计。

Answer 20

记住他/她最初提供的估算的精确程度，并且不要让他们对在该精度水平的合理范围内的错误负责。如果你不清楚这个精确度是多少，请查询它，也许你至少可以从中立开始