与程序员讨论估算
与程序员面对他们所提供的估计时遇到的最不礼貌的方式是什么？即使考虑到一些程序员一直低于或高于估计值，有时候估计值与你想象中的估计值相去甚远（其中一个... 你在开玩笑吧时刻）。你如何面对他们而不让他们进入防守？与程序员讨论估算
让他们分解它。估计通常应该是较小任务估计的总和。然后，如果缺少任务或者有任务不需要完成，您可以将其整理出来。
顺便说一句，没有必要对抗 - 诚实和冷静：“你会通过我的估计走过我吗？我想了解更多关于您提出的解决方案......” – condiosluzverde 2009-06-18 17:54:52
通过使用类似于工作中断结构 - http ：//en.wikipedia.org/wiki/Work_breakdown_structure – RichardOD 2009-06-18 18:03:32
我已经将WBS用作PM，但没有看到许多程序员在使用它......是有原因的吗？ – meade 2009-06-18 19:33:16
请他们提供估算的进一步细分。 1-2天的评估水平运作良好，每8-16小时的评估必须通过特定的任务进行指定。一般来说，这足够满足管理的粒度，并且它足够特异性，但通用性足以由相关工程师明确定义。
我会从试图弄清楚他们设想你希望他们解决的问题的立场来对抗他们。通常，当我处理客户的问题时，我们并没有看到项目预算明智，这是因为客户以一种方式思考系统，而我正在以完全不同的方式思考系统。
一个很好的例子就是说我的客户告诉我建立一个CMS系统来处理他们的业务流程。我看着他们的要求，并从他们身上推断出我需要为他们成长整个系统。然而，客户真的试图告诉我，部署已由第三方构建的CMS系统，并尽可能填写其他详细信息。
两个不同的场景有完全不同的预算
“你怎么会在你的估计到达？你能打破它给我吗？”
与他/她一起了解估计的结果。你可能会惊讶地发现可能已经建立起来的蠕变量，或者如果估计我估计我不认为你会抱怨。
请他们为您解释估算所基于的推理。你可以这样说，看起来好像只是为了帮助你了解情况，即使你在内部真的质疑他的估计。
其实问是需要什么类型的知识/技能来完成这个更快。程序员常常是重要的技术。与程序员一起进行某种项目管理讨论。你真的会获得良好的结果和尊重。
我会请程序员给你一份关于工作中涉及的每个任务的细分，以及每项任务的详细估计。 我认为这是一个完全合理的事情要求，当给出一个估计，并应澄清估计出错的地方。
我只想说，“这看起来比我想象的要高一点，你能把它分解成几个小时的小块给我吗，所以我能理解所涉及的一切吗？”
基本上，不要指责，并让程序员觉得他/她正在帮助你理解某些东西。
你不能只是说“你错了”。
- 要求他们把它分解成子项目
- 审查每一个子项目，并将它与原先的估计
- 请他们调整估计
如果估计他们是给予似乎取消，他们可能会做出适当的估计有困难。他们可以学习如何调整，如果你每次都问他们每个项目。
这是从来没有虽然是完美的科学..
记得他/她原先所提供的估计的精度水平，不追究他们的责任是为精密称水平的合理范围内的错误。如果你不清楚什么是精度水平，打听一下，也许你至少可以开始了在中性点接地
我会假设他是正确的（假设他有一些知识/经验），并告诉他你是在X周围考虑估计，然后询问是否有一些细节或缺失的问题来解释额外的努力。我也会一个人做，而不是把他放在现场。
有你需要考虑你考虑向他进一步解释之前多件事情：
- 获取单个项目的估计。
- Ask'm分别提供单元测试（如果您在意的话）的估计值
- 验证他是否正在考虑任何依赖关系。
- 确保您对范围保持同步。
- 他是大四吗？如果是的话，情况总是如此？
最后，唯一的方法是让他/说服他重新估计估计，因为预算不会允许这么多小时，并要求他重新审视他的估计。
最初，当我要求某人给出一个任务的估计值时，他们曾经给出了一个大概的数字。有时它曾经很好，很多时候它曾经像“什么......！”一样。任何一种趋势都是增加缓冲区并给出估计值。但问题是程序员添加了多少缓冲区？每个成员如何计划他/她的工作始终是个问题。
我后来诉诸短期清单，当我要求估计。这有助于大家了解任务的更好，没有与全队members.Following没有尴尬对抗是我要求与估算值...
- 工作分解这有助于程序员在他必须考虑任务和涉及的不同步骤。每项任务不应超过1个工作日。任何人都会说...这是不可能每天分手，但这是可能的。
- 技术依赖关系程序员期望的所有技术依赖项列表。例如任何需要做的研究或概念证明。任何关于图书馆使用的决定。
- 进程依赖关系程序员期望的所有进程依赖关系列表。例如诸如内部评论和外部架构评论等事情需要时间来邀请，设置并最终结束问题。
一旦我有了上述细节，每个人都可以轻松地谈论估计。在这种情况下，唯一的瓶颈就是与团队沟通，他们需要提供工作分解任务，技术和流程依赖关系。
当我无法及时得到某些东西时，通常是因为遇到了未知的东西。因此，不应该对开发者提出任何未知的问题。我现在可以列出两种类型的未知数：（i）开发者找到了需要研究理论的新领域; （ii）开发者已经发现了应该在规范中的隐含要求或缺失的部分。
最少的“攻击性”查询是关于（ii），因为开发人员在这里没有过错，应该更愿意谈论这一点。
当你与（i）混淆，你可以进入自我地狱。大多数商业IT商店对问题（i）绝对没有怜悯，因为许多这些“明智的”商业领导者认为开发人员正在窃取付费时间，以牺牲公司为代价进行学习。因此，提问者说“面对”是正确的 - 因为这（i）的遭遇无异于指责某人是小偷。
你只需要问他们，而不是真的“对抗”他们。询问他们是如何得出他们的估计或他们估计的细目。另外，告诉他们你的担忧，如果你有任何问题，并给出一个有效的理由。一个有效的原因是“我需要这个和这个日期生活，因为它是关键业务”而不是“我想要这个和这个日期生活，因为这是我答应我的老板”。
如果开发者看起来很和蔼可亲，那么当他们为您提供细分时，您可以尝试与他们的估算进行协商。尽管如此，不要把它们推得太紧。毕竟，你是让别人为你做。如果你认为这么快就能完成，那么也许你应该自己来做。
我们这样做的最好方法之一就是让开发人员选择并取得高分。不要仅仅给他/她一份任务清单，而是试着鼓励他们参与任务/项目，涉及&。
您怎么看这个，https://*.com/questions/12552049/would-programmers-use-contribute-to-a-crowd-sourced-estimation-tool，谈到项目估算？
你问过“最不讨厌的方式”。那将是保持沉默，然后离开。你唯一真正的选择是获得竞争优势，并学习他的特质，计算机语言和他使用的框架。如果你懒惰，并且喜欢在夜间使用来自多个显示器的令人敬畏的温暖电子热浪的特色晚餐，那么不要说一句话。请不要，请。
让这种对抗成为灾难的秘诀。 – 2009-06-18 17:58:45
看起来问题在于如何完成估算 - 你需要一个适当的策略来计算它们应该如何计算 – RichardOD 2009-06-18 18:04:40
对不起 - 并不等于像'讨论'一样对抗 – meade 2009-06-18 18:09:45