13

我是一名 PHP 开发人员，而且我经常不知道工作需要多少天——更不用说时间了——我在工作中需要多长时间。我经常写新东西，把它和旧的废话结合起来。我可以告诉我的老板我可能会在哪周完成某件事——也许是这周的哪一半——但我到底怎么知道具体哪天会完成某件事呢？考虑到错误和其他未知数经常出现并消耗时间，这不是有点不现实吗？我只能尽量减少这些东西......

我正在考虑说以下内容：

“听着，我明白我在说“明天！明天！”没有帮助。在我将要做的许多事情上，我能为你做的最好的事情就是告诉你我可能会在一周内完成它。如果看起来我可以完成它给定一周的星期五，然后我们最好移到下周。”

4

16 回答 16

14

时间估计是困难的。

但是我做得很好的时候都有一些共同点：

1.) 我收到了非常好的和完整的项目要求。这很重要，您应该提出棘手的问题，以确保需求确实尽可能完整。

2.) 我把项目分成几个部分，把每个部分写在白板上，然后分别估算每个部分的完成时间。当我这样做时，我让团队的其他成员做出了贡献，所以我不会忘记任何事情。这看起来很简单，但效果很好。我认为它可以通过减少忽略可能耗时的项目部分的可能性来让您更加现实。如果您可以像这样详细地写下和计划项目，那将有很大帮助。

在整个时间估算过程中，您甚至可以更好地了解项目以及需要做什么。这可以防止错误、编写和重写代码等。这对每个人都有好处。

于 2009-08-11T21:19:38.680 回答
4

跟着你的直觉走，然后增加 50% 的时间。你会在最后期限前完成，不会给自己压力，你的老板会看到高质量的代码而不是快速的代码，而且你可能偶尔会比预期的要快。每个人都赢了:)

于 2009-08-11T21:20:22.080 回答
4

更好的估计来自经验。

您还可以使用功能点分析方法来获得一个好的起点。然后，给你的项目经理定期更新。因此，在周五项目需要滑入下周时，您的项目经理不会感到惊讶。

于 2009-08-11T21:20:48.943 回答
3
  • 被要求在几天内报价是荒谬的，你能做的最好的就是估计。
  • 不惜一切代价避免被迫做出直接的猜测，你几乎肯定会错的。花一些时间来做出更好的估计总是一个更好的主意。
  • 如果您正在处理更改或与一些您以前没有经验的代码交互，那么请尝试估计需要多长时间才能完成您需要做的事情，然后在您了解更多信息时再联系他们正是你需要做的估计多长时间。
  • 做您以前从未做过的事情也是如此，如果您对其他人如何解决类似问题进行一些研究，您可能会更快地交付。
  • 将您的任务分成更小的块（尽可能小）以更准确地估计。这样你就可以说“我认为 A、B 和 C 总共需要大约 6 天，但 D 是我必须看的东西”。这听起来比“我不知道”或“只要它需要”要好得多。
  • 您无法估计找到错误所需的时间。您可以估计修复它需要多长时间。一个棘手的错误很容易需要 2-3 天的时间来追踪和修复。您已经交付的代码中的错误会占用您后续开发的时间。
  • 当你遇到一个让你的截止日期早于截止日期的问题时，一定要让他们知道。这样你的老板在与他的老板/客户交谈时就会得到预先警告。
  • 如果您高估并且幸运地有一些额外的时间，那么要么对其进行更多测试，要么利用这些时间开发其他对您作为开发人员的生产力有用的东西。
  • 如果你不断被欺负而同意任意的截止日期，不断受到骚扰或感觉你的解释被认为是彻头彻尾的谎言，那么在你的健康不可避免地受到影响之前，悄悄地开始在一家了解软件项目管理的公司寻找另一份工作。
于 2009-08-11T21:56:13.957 回答
3

之间也有区别

  • 完成一项任务所需的时间（你应该在获得经验时学会估计）
  • 和延迟：完成该任务的时间，加上做其他更紧急的事情的时间


关于做某事所需时间的估计：

  • 第一次做某事，很难知道完成它需要多长时间
  • 但是，随着时间的推移，你会做越来越多不同的事情；而且，每次，你都会记得你花了多长时间。

过了一会儿，当被问到“你需要多长时间才能做到这一点？”时，你会想：

  • “那个”与我在项目 X 上所做的另一件事非常相似，以及我在项目 Y 上所做的另一件事
  • 我在项目 X 上花了 8 天时间，在项目 Y 上花了 6 天时间；但在 Y 上要容易得多，因为我已经知道如何去做（已经在 X 上做过）
  • 所以，在这个新项目上，它不应该比项目 Y 花费更多的时间
  • 实际上，我现在更好，更有经验……所以应该需要大约 5 天
  • 并且不要给自己太大压力，并保持一定的误差范围，你对你的老板说 6 天或 6 天半。
  • 而且，在他的脑海里，他会再加一天^^ （或者，如果他是那种听到6就数4的人，告诉他8，他就会明白6^^）

随着时间的推移，你会在这方面变得越来越好；最后，您可能会：

  • 估计你应该花多长时间去做你从未做过的事情
  • 估计另一个开发人员需要多长时间来完成它
    • 这对于经验丰富的开发人员来说，
    • 或者对于初学者
    • 或者只针对一个特定的人

何，我忘了：我通常会增加大约 15% 的“开发时间”来测试和纠正错误，顺便说一句——这是我从事的项目的标准费率，而且通常相当准确（当然，对于初学者来说，谁可能会创建更多的错误，你会添加更多；对于有经验的开发人员，少一点）。

是的，当然，有时候，你完全错了；它发生了，就是这样：每个人都会偶尔犯错误:-)


关于延迟：嗯，我通常会告诉我的老板“如果我不需要做其他事情，我应该需要 X 天”；那么，如果我的老板让我在工作中途两天做点别的事情，那就是“他的错”^^

当一个人在一个项目上工作，或者是“我自己的老板”时，我通常知道我需要花多少时间在“其他事情”上。
在我前段时间工作的一个项目中，我曾经告诉客户：“我需要 5 天来做这件事，但考虑到我通常有一半的时间花在没有计划的事情上，让我们考虑一下总共需要 10 天” -- 久而久之，你就会习惯这样算了^^

于 2009-08-11T21:38:14.603 回答
2

墨菲时间管理定律：

要弄清楚某件事需要多长时间，请从它应该需要多长时间开始。

然后，将其乘以 2。

然后，移动到下一个更高的时间单位。

因此，如果一个项目需要一天时间，可能需要两周时间。

于 2010-07-26T02:33:00.240 回答
1

这是史蒂夫·麦康奈尔（又名代码完成先生）的一本好书的链接：http: //www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351/ref=ntt_at_ep_dpt_3 - Software Estimation Demystified

基本步骤是：

  • 将碎片分解为可理解/可行的块（查看工作分解结构）
  • 如果您需要更多信息，请记下并确保尽快通知您的经理
  • 你所拥有的作品应该包括与你之前做过的其他作品一样的项目——这应该可以很容易地提供一个估计。关于这些项目，你对应该花费多长时间有一些“粗略”的想法（加一个 %你的直觉反应时间取决于你的舒适度——比如在 10% 到 30% 之间）以及你只需要大胆猜测的那些项目（在这些项目上添加一个 % 范围，可能在 30% 到 500% 之间）
  • 将您的可交付成果列表放在电子表格中，为每个项目命名，完成的舒适程度（从高到低），您的估计时间 - 可以是一个范围（最少 1 天到最多 5 天）以及任何可能包括的注释问题和假设。
  • 将其呈现给您的经理并讨论

一个包含需要完成的项目、问题、假设和一系列可能的交付日期的文档可以说明您的编程成熟度水平 - 与抛出 # 天/周（或只是一个冷嘲热讽）并且永远不会接近。如果你的经理不明白这一点 - 找一个新的经理。

于 2009-08-12T20:55:29.830 回答
1

帮助您在这方面做得更好的一种方法是跟踪您的原始估计（如果必须首先在黑暗中拍摄），然后跟踪实际花费了您多长时间。您甚至可能想估计做起来有多“难”，以及您认为最初以 1 到 10 的等级说的难度。

这样做一段时间，您可能会开始看到一种模式，甚至开始了解您的估计是好/坏（相对术语）。

随着时间的推移，使用这些来帮助您重新考虑您的估计。例如，最近几次我估计了一个中等难度的 5 天任务（比如 10 天中的 5 天），我平均推迟了 5 天。

有了这个，我将在这个上估计 10 天，看看会发生什么。:)

不断地重做这个练习，你就会开始更好地处理这个问题。

哦，是的，正如已经提到的，估计很难，而且有很多资源，但没有什么比练习或真正好的导师更重要的了。:)

于 2009-08-11T21:37:36.290 回答
1

关于估计的一些想法：

  • 估计不同于承诺。它们是使用有关一组工作可能需要的努力（而不是时间）的可用信息的最佳猜测。
  • 估计值不是一个单一的数字——您应该真正将估计值视为一个范围（下限/上限）或一个值和一个置信度因子。
  • 估计有一定的误差——要减少这个误差，您通常需要花更多的时间进行分析和评估。在某个时刻，产生极其准确估计的努力将开始接近任务本身的努力。
  • 根据定义模糊的工作进行可靠的估计是极具挑战性的。在这种情况下，应该预期会有很高的误差范围。
  • 在评估一项任务时，最好的指南是过去类似任务的经验。
  • 如果历史信息不可用（因为工作努力是独一无二的，或者您没有跟踪此历史） - 您能做的最好的事情就是将任务分解为有意义的最佳工作级别。
  • 尝试询问您组织中可能对系统或代码库有经验的其他人来查看您的估计。
于 2009-08-11T21:39:24.273 回答
1

感谢您的所有回答和反馈。

我问这个问题已经有一段时间了，从那时起，我使用 scrum 和敏捷方法大大提高了我的时间估算技能。我们使用白板和 Scrums，并按时分块交付。

至于整个项目何时交付，取决于项目规模，交付日期仍是未知数。但是，通过将任务分解为故事和子任务，我们可以了解项目的规模。这使我们能够向管理层展示他们的交付预期是否切合实际。

此外，积压的任务使我们能够不断地重新确定每个 sprint 的优先级。这可确保完成最高优先级的问题。最终，积压中的剩余项目微不足道，产品“足够好”可以发布。

到目前为止，它运作良好。

更多详情：http ://www.scrumalliance.org/pages/what_is_scrum，http : //www.goodagile.com/scrumprimer/。

很抱歉将我自己的回复标记为答案，但这对我有用。

于 2011-07-07T18:36:33.873 回答
1

我能给出的最好建议是将任务分解成更小的部分，然后对它们进行估计。也许给每个子任务附加一个“信心”百分比来计算一个乐观和悲观的范围。那样当你的老板说“5-8天？这对我一点帮助都没有，你从哪里得出这些数字！？！？” 你只要向他展示你的崩溃，你就有理由了。一个称职的经理应该把你的屁股放在你承诺的事情上，而不是你离题而被欺负的承诺。

于 2009-08-11T21:22:59.640 回答
1

根据我的经验（曾在经理和助理方面），我知道大多数经理不会将员工给出的估计报告到下一个级别。相反，他们根据自己的直觉+对外部约束的了解。

当经理要求估算时，他/她通常不太关心估算值本身，而是关心员工进行分析并找出子任务、主要差距、依赖关系等。换句话说，要求估算通常是管理层雇用的伎俩让员工继续前进。在这种情况下，估计值只是强制员工进行分析的依赖注入机制。

当然，狡猾的经理也倾向于记住估计值，特别是如果它被低估并用它来控制项目的紧迫程度。

于 2009-09-28T18:13:17.397 回答
0

我会做两件事：

  1. 根据您完成类似复杂性的最后一项任务（“昨天的天气”技术）所花费的时间进行估算。
  2. 在适当的时候给出一个范围估计——“如果事情进展顺利，两天。如果事情真的很糟糕，可能是两个月。” 虽然这是估计的极端范围，但有些任务的准确度与您所能达到的一样。如果您给出一个范围，请务必同时说明该范围存在的原因。
于 2010-07-26T03:14:06.227 回答
0

过去的经验和历史数据通常最适合提供估计。如果您在使用历史数据预测未来任务之前处理过类似的代码/问题。当然，如果您正在处理新事物或完全未知的事物，则更难提供准确的估计。当然，它们是“估计”，这是对何时完成事情的有根据的猜测。

于 2009-08-11T21:33:14.817 回答
0

如果可以的话，再找一份工作。你的老板似乎对项目管理、资源管理和软件开发一无所知。

一般来说，你能给出的只是估计。你的估计会随着经验而变得更好（在大多数情况下，你会估计比现在更多的努力）。而且——正如任何软件开发人员都知道的那样，总是可以选择解决一些愚蠢的问题，这将花费 90% 甚至更多的实际努力（并大大增加开发时间）。

于 2009-08-11T21:23:45.957 回答
0

我通常会说这将比我真正想的要长 3-4 倍。例如，如果我知道我可以在两天内完成一些东西，我会说一周左右。

这样，如果你完成的时间远低于你的估计时间，你就会看起来像个英雄！:P

于 2009-08-11T21:24:57.280 回答