Jeff 最近的文章链接到First Fit Decreeasing算法的时间管理示例，其中谈到了时间管理的帕累托原则（或 80/20 规则），即我们在 20% 的工作中产生 80% 的工作我们的时间。
现在我们都听过程序员的名言：
前 90% 的代码占了前 90% 的开发时间。剩下的 10% 的代码占了另外 90% 的开发时间。
但抛开所有的玩笑不谈，通常你的代码中有 20% 是做你想做的事，另外 80% 是处理异常……那么 80/20 规则真的适用于开发人员吗？
有没有人有任何例子说明为什么它适用/不适用于我们？
我认为霍夫施塔特定律适用。
即使考虑到霍夫施塔特定律，它也总是比您预期的要长。
——道格拉斯·霍夫施塔特
更严肃地说，看看关键链项目管理。它建议您为项目中的每个步骤提供两个估计值。一种是乐观估计，如果一切顺利，你有 50% 的把握可以见面。另一个是更现实的估计，它考虑了损失的时间和错误（我的释义，不要责怪作者）。随着时间的推移和几个项目，您将了解哪个估计更准确，以及多少。它因开发人员而异，因此您需要跟踪。
绝对地！我 80% 的时间花在 stackoverflow.com 上，20% 的时间在实际工作。
奇怪的是，我的生产力和以前一样……
……和以前一样！
;-)
提前 2 小时编写单元测试并向您的客户演示功能将为您节省 8 小时的调试和重写时间。
在我看来，Kozyarchuk 是对的：
问题不在于糟糕的时间估计，而是糟糕/不可能的范围估计。
尽早向客户/经理显示结果或结果模型，同时测试代码的有效性，从而更好地理解目标/要求。
请记住：如果项目在完成时“让客户满意”，而不是在项目最初开始时满足分析师已知的需求，那么项目就是成功的。
这自然意味着“移动目标”是规则，不是坏事，也没什么好怕的。这也意味着我，作为项目负责人/架构师，必须确保范围变更的成本能够/将被传达和涵盖。
这是怎么做到的？
这总是有效吗？不
你为什么还要问80/20规则？您正确引用了 90/90 规则。您已经知道 90/90 规则适用于开发人员。
（很抱歉用事实而不是玩笑来回应。）
我花 20% 的时间做我想做的事，80% 的时间在重构它。
所以，是的，如果你认为它在前 20% 中“有效”。但是，最后的 80% 使它可重复使用，值得维护，并且在未来使用是一种乐趣（而不是负担）。
Pereto 原则适用于开发人员。有人说 80% 的工作是由 20% 的开发人员完成的。此外，80% 的错误是由 20% 的开发人员生成的。此外，80% 的功能被 20% 的用户使用。这些是我听说过的例子。
我和蜥蜴比尔在一起。由于非常意外的事情或可能没有考虑到的事情，它总是比预期的要长。
是的，80/20 法则适用于发展，但你必须以不同的方式解释它：