80/20时间管理规则是否适用于开发人员？

Question

Jeff's recent article与time management example算法的First Fit Decreasing相关联，该算法讨论了时间管理的Pareto principle（或80/20规则），即我们80％的工作是在20％的时间内完成的。

现在我们都听过程序员quote：

  

前90％的代码占了   前90％的开发时间。   其余10％的代码帐户   对于其他90％的开发   时间。

但是除了所有的笑话之外，通常好像20％的代码要做你想要的，而另外80％是处理异常...... 80/20规则真的适用于开发人员吗？ / p>

有没有人有任何关于它为什么/不适用于我们的例子？

Answer 1

我认为霍夫施塔特定律适用。

  

即使考虑到霍夫施塔特定律，它也总是比你预期的要长。

     

- Douglas Hofstadter

更严重的是，请查看Critical Chain Project Management。它建议您为项目中的每个步骤提供两个估计值。一个是乐观的估计，如果一切正常，你大约有50％肯定会遇到。另一种是更现实的估计，将错误的时间和错误考虑在内（我的解释，不要责怪作者）。随着时间的推移和几个项目，您将了解哪些估计更准确，以及多少。它因开发人员而异，因此您需要跟踪。

Answer 2

绝对！我80％的时间花在stackoverflow.com上，20％的时间用于实际工作。

奇怪的是，我的生产力与以往一样......

......和以前一样！

- ）

Answer 3

为您的客户提前2小时编写单元测试和演示功能将为您节省8小时的调试和重写时间。

Answer 4

在我看来，Kozyarchuk做对了：

问题不在于时间估计不佳，因为范围估计很差/不可能。

在测试代码有效性的同时，尽早向客户/经理显示结果或模型结果，从而更好地理解目标/要求。

请记住：如果项目在完成时“让客户满意”，而不是在项目最初启动时满足分析师已知的要求时，项目就会成功。

当然，这意味着“移动目标”是规则，而不是坏事，没有什么可担心的。这也意味着，作为项目负责人/架构师，我必须确保范围变更的成本能够/将被传达和覆盖。

这是怎么做到的？

• 早期演示，经常演示（对同一房间内的用户及其经理）
• 更改请求心态。 （因此客户知道这些变化是什么以及这些变化的成本是多少，因此客户可以使用它们来重新规划他的项目）
• 说实话，与客户和开发人员交谈......并确保他们也互相交谈。

这总是有效吗？ 否

Answer 5

为什么你甚至会问80/20规则？您正确引用了90/90规则。您已经知道90/90规则适用于开发人员。

（很抱歉回复事实而非笑话。）

Answer 6

我花了20％的时间做我想做的事，80％重构它。

所以，是的，如果你认为它在前20％“起作用”。但是，最后的80％使其可以重复使用，值得维护，并且将来可以使用（而不是负担）。

Answer 7

Pereto原则适用于开发人员。有人说，80％的工作是由20％的开发人员完成的。此外，80％的错误是由20％的开发人员产生的。此外，20％的用户使用了80％的功能。这些是我听说过的例子。

Answer 8

我和比尔蜥蜴在一起。由于非常意外的事情或者可能没有考虑到的事情，它总是花费比预期更长的时间。

Answer 9

是的，80/20法律适用于开发，但你必须以不同的方式解释它：

• 前80％的代码在20％的时间内完成。
• 其余80％的时间不足以完成其余20％的代码。