以初级程序员的身份处理估算

我已经在一家公司中工作了几个月，该公司估计（针对一般人群，而不是针对初级人群）任务，然后给我们任务，解决它，它经过两次测试，最后估计应该是有点满足。

我感到非常压力，因为其中有些估计根本无法满足。我仍然不知道整个系统（因为它相当庞大），所以有时花一半时间找出我需要做的事情，在完成的地方和时间之前，有时估算已经结束，并且仍然需要进行测试完成（并纠正错误）。

第二次我必须处理类似的功能时，它们的运行速度都快得多，但是到目前为止，我感觉我很不擅长编程。

您刚开始时有什么工作可以帮助您度过这一阶段？当我看到只有很少的时间编写代码时，我感到非常压力，有时候我什至无法正确地专注于我正在做的事情，这使情况变得更糟。

• 许多缺乏管理经验的开发人员使用自己的速度或团队中“最佳”开发人员的速度来估算任务。

• 速度随经验而变化。高级开发人员可能需要3个小时才能解决问题，而解决相同问题则需要2个工作日。

• 从事新工作很少能避免压力。几个月后，假设您做了足够的工作并提出了许多相关问题，通常情况会好转。

• 您的前辈可能不知道您对估算的感觉，因此，重要的是要问他们对您的期望是什么。

根据我的经验：

• 我认为高级开发人员或经理应该能够根据T恤尺寸（XL，L，M，S，XS）估算用户故事（业务需求）。

• 开发人员的工作是将用户故事分解成较小的任务并进行估算。大型任务可能需要您整整一周的时间才能解决，因此高级开发人员可能需要一天才能解决。

• 记录完成任务实际花费的时间非常重要。

• 好的项目经理或高级开发人员会不断收集这些统计信息。当您的生产率提高时，他们将意识到这一点，并且将以您的方式发送更多的工作。

这不仅可以减轻您的生活压力，还可以让部门有效地管理其资源。

与您的团队负责人，项目经理和/或您进行评估的任何人联系；不是我们。人们知道事情并不需要每个人付出相同的努力，他们可以在分配任务时调整估计值，或者至少减轻您对审核期的任何担忧。

在我看来，这就是应该由分配任务的人员来进行估算的原因（需要领导/同伴的投入/合作）。您将获得有关工作实际需要多长时间才能完成的准确估计。

我无法想象放置一个初级开发人员会比设定他们无法保留的期望更糟糕，除非他们当然这样做是为了挑战您。您对不符合估算有任何实际影响吗？

首先我要说的是，您必须学会自己进行估算，这一点很重要。当您接到任务时，立即以您认为需要的方式估算它，然后开始查找两者之间的差异。我几乎可以打赌，在最初的简短估算中牺牲了质量。如果仅仅是因为他们期望您以最快的速度设计和开发产品，则您可能需要与某人聊天以解决问题。

其次，了解质量是利益相关者（您的老板）决定付款的一项功能。您可能必须牺牲一些时间来满足您的需求。

无论哪种方式，消除压力，就像您总是落后于编写不良代码一样，持续不断的感觉并没有什么好玩的。希望这可以帮助。

这很常见。

通常，给出较大的估计值要好于给出较小的估计值（多数情况下总会超过估计值）。我建议您将任务切成尽可能小的子任务，并在每个任务不超过4小时的情况下估算这些任务。

如果一个任务可能需要4个多小时，则将其分解为另一组子任务。还要为您现在无法预见的任务添加一个百分比缓冲区（我的个人偏好是每2个估计的任务中就有1个非预期任务，每个非预期任务需要2-4小时，具体取决于所使用的系统）。

在此之后，您会增加测试，沟通，分析等所需的时间。

首先：如果您每次尝试解决问题都会更快，那么您可能不是一个不好的程序员。因此，让我们摆脱这种想法。

我建议这是您的经理的失败，但管理期望的工作将永远是您的工作。

而不是因为无法按照不切实际的期限而殴打自己，而要衡量一个星期中您实际上可以完成多少天的工作。然后向您的团队负责人说明您是新来的业务和软件开发人员，只能期望您将n天的高级开发人员工作放到标准的一周内。他们至少应该理解这一点，即使他们不喜欢它。

告诉他们您希望不断改进，并告诉他们如何衡量改进。并与他们达成一致，直到一周内可以做5天的高级开发人员工作，您才能期望高级人员的工资。但是同样，当您的薪水不高时，您也不会期望与高级管理者承担相同的责任。

更进一步，这就是为什么我强烈支持使用故事点而不是用几个小时来进行估算的原因。即。每个工作都获得许多分数，团队估计在给定的时间内可以达到多少分数。下一个时期的估算值与上一个时期的实际值相同，并根据假期长假或开发商离职等已知因素进行了调整。

作为经理，当新的开发人员（初级或高级）进来时，我向企业明确表示，我们不会在一开始就增加估算。预计该开发人员会从其他开发人员那里节省尽可能多的时间。新开发人员可能会做得更好，但是承诺不足和交付过多是他们的口头禅。

开发人员将随着时间的推移而改进，高级人员的速度将比初级人员更快，并且团队的“速度”（估计月度）将随之提高。

保持冷静并进行。如果您提出了不符合估计的问题，只需告诉他们您在帖子中写的相同内容，或者如果您感到不安全，请与您的导师/团队负责人单独讨论。

估计只是估计而已。它们可以而且将会关闭，因此，当您学习绳索时，更是如此。作为一名大三学生，很可能是作为特定项目的团队成员，使用正在使用的任何技术的程序员以及公司的员工来学习绳索的情况。而且，如果您与明智的人一起工作，他们会期望您会与预算相抵触。

您可能正在“自下而上”查看要完成的任务。对您来说，您的任务比您正在处理的项目的总体情况更重要-这是可以理解的。您将估算视为对您的限制，当您未满足这些估算时，显然会感到焦虑。

但是，从全局上看，您会发现，对于开发人员/项目经理而言，估计甚至比开发人员的“目标”还重要。将工作分解为任务并进行估计是降低管理和估计整个项目的复杂性的一种方法。跟踪实际完成的工作量与估算值是跟踪项目进展情况的一种手段，但这只是可以应用的指标之一。如果无法定期满足估算值，则向经理发出信号，表明项目存在问题。但是，在任何合理的项目中，团队中都不会有一个初级开发人员无法满足估计的事实。

让我向您介绍我的两个朋友WAG和SWAG

即“野生驴猜”和“科学野生驴猜”

信不信由你，我没有弥补。实际上，它们在业务中很常见。看看这篇文章，看看我的意思。

理想情况下，最好给出一个可靠的估计，但如果不能确定，则最好指出由于数据不完整而造成的估计是粗略的，而不是真实的。

关键是，业务不是计算机编程。管理期望比精度更重要。重要的是要评估您认为需要10％的时间来弥补任何不可预见的问题所需要的时间。

如果您高估了您的时间，他们会很乐意为您准备。如果您低估了他们的话，或者他们在截止日期前不会感到失望，或者在出问题时会感到非常失望。

随着时间的流逝，业务是一个灰色的区域，有些人会获得直观的感觉。他们要求初级开发人员独立做出此类决策的事实说明了一件事。他们要么没有人可以做出这样的决定，要么管理者不想对失败承担责任。

如果您在大型组织中工作，我会把钱花在后者上。当分层业务模型变得足够大时，高层与底层之间的距离就太大了，以至于高层只能根据他们在纸上收到的东西来衡量进度。这是一个糟糕的环境，因为升职通常是为了避免犯错误。但是，获得晋升的人可以通过将责任推给他人（即盲目的无能）并为连锁店中下层人士的成功而赞誉而避免失败。

不幸的是，程序员很容易成为目标，因为不管问题有多大，我们都会设法找到解决方案。关键是，不要花费比实施解决方案更多的时间来确定如何估计问题。

那是一个艰难的地方。听起来您陷入了该管道的“仅需交付”阶段。

多年来，我注意到有关估计的以下内容：估计的质量可以通过回答（使用专有名称）以下三个问题来确定。

• 谁设计的？
• 谁估算的？
• 谁在执行实施？

估计的质量与所命名的不同个体的数量成反比。例如：最好的估计是同一个人完成上述所有三个任务时，最差的估计是一个人进行设计/估计而另一个人将执行实施，而最差的估计是所有三个问题都得到回答的唯一的名称。