您如何处理较小的编程可交付成果中的时间滑点？

Question

我问这个关于小型工作的问题：我认为，对于较大的工作，你有各种合同问题需要处理。对于较大的工作，如果你没有考虑到时间表的滑点，你基本上就会被甩掉。

使用较小的可交付成果（10小时或更短时间）：如果您正在做以前做过的事情，那么很容易估计工作时间（并且可能需要更少，因为您已经学会了做到“最好”）。但是有了新的东西，你如何处理初步估计中可能的时间滑点？为了以防万一，随意增加20％的时间？给出一个范围，然后在前进时提供更高的精度？一些HelloWorlds计费几个小时，并试图找出未知数？

对于这个问题，我假设你为灵活的客户工作，他们需要尽可能最好的信息来完成他们的工作，并且需要早点完成所有工作。

Answer 1

在任何新的和不同的开头，任何精确到优于+/- 50％的估计要么是填充的，要么是猜测，或者具有良好的灵活范围。

也就是说，优先事项和时间表通常是灵活的，并且除了开发团队或客户之外还有很多其他事情。

重要的是，有明显的进展，对客户需求的响应（与请求相对 - 灵活的客户端会看到差异），以及一种迭代方法，如果有必要，可以让您早日使用少于100％的功能（在第1天不需要所有），前提是修复和功能发布频繁并提供切实的额外好处。

让客户摆脱“完整，准备好约会X”的思维模式，并进入“足够，一直在改进”的思维模式，这是关键。

否则，你必须回到历史悠久的传统......你要求四位值得信赖，经验丰富，可靠的同事作出估计......

...然后将它们加在一起。

Answer 2

学习需要反馈，因此我建议您跟踪自己的准确性。

记录日志，其中包含每项估算任务的简要说明，原始估算值和所需的实际时间。因此，例如，如果您发现您的估算值短25％，则开始向上进行相应的调整。如果您发现没有模式超过或短，请查看任务本身的特征，以查看是否存在某些种类的任务， -estimate。

Answer 3

这是一个有点开放的问题所以答案可能也是如此。

尽量提供尽可能接近所询问内容的内容，尽量让它在没有明显错误的情况下运行（例如，崩溃）。永远不要试图再次猜测要求，如果没有被要求，即使你知道它是必要的也不要这样做 - 当你需要更多时间来“正确”时，这会给你带来影响 - 这不一定问了什么，但是在你交付之后你的客户真正想要什么。如果你可以早点，但不要超过10％ - 否则你会被认为是无法估计的人。