如何避免软件开发中的80/20规则

Question

似乎无论我的项目是什么，我都能相当快地完成80％的工作。用户和管理人员兴奋地认为事情已经提前了，但令人讨厌的20％的工作剩余似乎需要4倍于之前的80％。当我们对项目进行定期检查或站立时，我感觉自己就像一张破纪录的说法“到目前为止，事情已经好了，但还有很多事要做......”

在大多数情况下，我的估计相当准确，但我是人。说服用户最后20％的工作确实占用80％的时间的最佳方法是什么？看起来越来越多的用户和管理层认为IT很容易，而且有些手指就会发生魔术......

总的来说，我们会按照我认为相当低的水平跟踪任务。不一定在创建标签或文本框中，但我们非常详细...我们还跟踪我们对所有任务的估计完成情况，当您处于项目中间时，我认为这是比原始估计更重要的数字

我认为这取决于对用户和管理层的看法。即使他们可能知道完成的估计，他们仍然会对他们所看到的情绪和看法感到失望，并且估计的数字会退居二线。这就是我想弄清楚如何控制或管理期望的方法。

<小时/> 的 修改
转变为社区维基，因为这是相当主观的。应该从一开始就是这样。

Answer 1

完成后不要先显示前80％。滴水喂它们。

Answer 2

也许您需要将正在处理的任务/功能分解为更小的单元，用于安排工作和签入/报告。例如，我的日程表中几乎从未有任何单项，持续时间超过两天。

然后，每天在Scrum工作两周，而不是说“我正在为我们的新布偶制造商工作”，你可以说“我目前正在为布偶制造商的眼睛选择器工作”。

如果您按计划进行工作，并且您的日程安排准确（意味着他们同时考虑了80％和20％），那么管理层确实应该没有问题。如果他们暗示他们可以减少分配的时间，因为你“差不多完成”然后向他们展示那些尚未实施的规范部分。

我假设您使用某种形式的功能规范来详细说明应该做什么，它应该如何表现以及它必须处理的边缘情况。如果是这种情况，那么担心管理层的情绪和看法对我来说似乎很奇怪，他们应该能够将规范与您的工作进行比较，或者阅读您的日程安排以了解剩下的内容。

Answer 3

  

即使考虑到霍夫施塔特定律，它也总是需要比预期更长的时间

但我离题了。

最好的做法是悲伤的体验。 SCRUM methods对某些类型的软件开发非常有用，因为它们会不断将发布日期更新为更准确的日期。 (quick video about scrum)

Answer 4

您如何估算工作量？你说“令人讨厌的20％的工作剩余时间似乎比之前的80％长4倍”，但是你是如何得出“20％”的工作剩余并且“80％”是做了什么？显然估计是错误的 - 实际上只有20％的工作完成了，80％的工作仍然存在。

在软件开发中，很难提前很长时间给出准确的估算。唯一的方法是将工作分成小的可管理部分（每个可能少于10个小时）。您只能准确估计后续步骤。

有助于估算进度的一些实践可以在Scrum中找到。在下一个冲刺期间（一个月或更短时间）将完成的工作范围在冲刺开始时确定，并对每项工作进行粗略估计。然后在冲刺之后，团队可以反思已经完成了多少进展，仍然缺少了多少，估计有多准确，以及什么减慢了团队的速度。在Scrum和其他敏捷方法中，重要的一点是快速反馈已完成的工作以及我们在项目中的进度。我建议您阅读更多相关信息。在The video about Scrum中链接的ÓlafurWaagehis message给出了一个很好的快速介绍。

Answer 5

阅读史蒂夫麦康奈尔的优秀着作Rapid Development，该书对80/20问题和软件估算方面的变幻莫测有很多话要说。

Answer 6

谈到时间估计，这是我的经验：

1. 如果您不能肯定地说任务需要不到4个小时就无法准确估算。将它分解成小块并递归重复。

2. 做出这样的时间估计并不是一件容易的事情，需要时间，您基本上必须以可管理的方式完成整个项目，这意味着对要求的任何更改都将导致更改时间计划（令人惊讶） ，不是吗？）

3. 最大的问题是我们无法预见所有的细节（也许，或许，假设20％？剩下的80％是未经估计的......） - 看看其他人已经指出过的SCRUM。

4. 管理层很少会“接受”如此详细的时间估算，因为实施起来需要“太长时间”。

然而，由于管理层对盈利感兴趣，他们也有兴趣偷工减料。因此，您应根据所涉及的现实生活场景确定可能削减的角落并做出复杂的妥协。在管理层的支持下，你可以通过什么都不做来完成这些最后20％的事情（我猜这种方式很难过，但仍然是真的）。​​

因为代表最终产品的最后20％的最后80％的工作实际上是抛光和熨烫错误并适应变化的要求等。可能有一些有限的第一版等，等等，要有创意。

Answer 7

我认为我不能说Joel对Painless Software Schedules做得更好。

  

如果你的经理让你减少了   估计，这是做什么的。创建一个   调度时间表中的新列   里克的估计（假设你的名字是   瑞克，当然。）把你的估计   那里。让你的经理做任何事   她希望使用Curr Est专栏。   忽略经理的估计。什么时候   项目完成后，看谁是谁   更接近现实。我发现了   只是威胁要这样做   奇迹，特别是当你的经理   意识到他们刚刚进入   比赛看你能慢多少   工作！

Answer 8

据说项目时间的前90％用于90％的工作，其余90％的项目时间用于剩余的10％或工作。 ;）

在项目开始时取得很大进步是很自然的，因为你只需先做最简单的部分。此外，如果前80％的代码中存在任何问题，那么在它们完全结合在一起并且您可以实际测试所有代码之前，它们通常不会很明显。

也许作为一种经验，你应该让人们尝试完成90％的应用程序，以便他们看到最后10％的差异...

Answer 9

我发现了一些对时间估算有很大帮助的事情

1. 熟悉代码库。当你可以听取规范并且可以想到“我需要触摸A，B和C级 - 仅此而已，而不是更少”，那么你就可以得到相当准确的信息。我发现这比知道需要编写哪些特定功能更好，因为你知道你不需要写什么。
2. 记住包括测试，错误修复，部署和最后一刻请求。很容易忘记你需要迁移一堆记录。
3. 在某种程度上，熟悉语言。如果你知道你需要哪些库，那么就更容易知道你不必须做什么。

我已经非常成功地使用了这个近似同事的速度，它只是需要一些经验观察来说明它们能够以多快的速度开发一个特征以及它之前实际测试它有多好

Answer 10

80/20现象的根本原因之一是，任何困难 - 有时甚至是微不足道的 - 任务都会出现意外情况。例如：由于一些过于热心的流程管理人员，您的软件设计流程所要求的文档会突然获得新的模板格式。突然之间，更新新版本的文档不仅仅是一个简单的问题 - 您现在必须重新构建它们，并且所有这些文档都需要更多时间。

我听过处理此类现象的最佳建议之一是始终在项目进度表中构建缓冲区子任务 - 由Richard Whitehead推荐。每项主要任务都会增加20％的时间（或在某处），作为该任务的子任务。每个的目的是为在该任务上“出错”时发生的事情提供一些衡量标准。作者承认（我也发现这是真的）通常管理层会试图删除那些缓冲任务 - 你唯一的办法就是坚持自己的立场，或者像Joel的倡导者那样采取策略（正如@Casey已经提到的那样）。在实践中，我发现很多缓冲子任务通常都会存在，并且在紧迫的时间表中帮助了几次。

Answer 11

  

我认为这取决于对用户和管理层的看法。即使他们可能知道完成的估计，他们仍然会对他们所看到的情绪和看法感到失望，并且估计的数字会退居二线。这就是我想要弄清楚如何控制或管理期望的方法。

首先编写算法......然后编写UI。

Answer 12

如果您一直发现最后20％的工作占前80％的时间的4倍，那么可能是时候与您自己（或与可信赖的同行）进行诚实的讨论，了解您是否放弃技术债务在最初的80％期间累积起来，最终它会咬你。

这可能与您可以考虑改变的工作实践有关。

我所知道的保持技术债务下降的两个最佳实践是编写好的测试（最好是在编写代码之前，但也只是在后面工作之后），并在每个任务之后进行重构。想想在每餐后，而不是在月底，重构为清理厨房。

Answer 13

我认为，如果你能够承诺不足和过度交付，那就最好了。

如果您的估算是正确的，那么您可以解释那个令人讨厌的20％。你显然没有，这就是为什么它是一个问题。

也许你正试图给他们所有他们想要的东西，这是不切实际的。也许你没有完全考虑到墨菲定律，或者没有给出足够的时间进行测试，发现错误，然后重新测试等等。

看起来你应该多做一点风险管理......

Answer 14

说“到目前为止，事情已经好了，但还有很多工作要做......”可能不是最好的方式来解决问题。听说经理或客户可能会认为“是的，还有很多工作要做，但他确实很快就完成了这部分工作，其余的工作很少”。

相反，请务必确定剩余的工作并安排它们。通过这种方式，您可以显示项目剩余20％的位置。如果花费太长时间，您的日程安排将显示项目落后于计划，这应该会引起一些紧迫感。

每周更新您的任务（或定期更新状态报告）。确定有可能落后的区域，尤其是在其他区域依赖它们的情况下。

Answer 15

保持你的时间视野短。与接下来的几个月相比，更容易估计未来几周你将会做些什么。考虑将您的项目分解为简短的里程碑。一个月或者几个月取决于你想要做什么。这基本上就是Scrum所做的。然后，最准确地估计您将要在当前里程碑中完成的工作。当你到达那里时，重新估计下一个里程碑，并有更多的数据来建立估算。最后20％花费这么长时间的部分原因是，当您不了解时，您可能会预先做出估计。

另外，尝试Wideband Delphi估算技术。这将梳理出你可能没有考虑的更多隐藏成本。

Answer 16

尝试并提供最准确的估算值，并尽可能提高项目的透明度。如果您始终接近估计值，那么这应该足以让您的经理满意。请记住，measure productivity非常困难。

Answer 17

在计划时，请将其考虑在内。在估计执行子任务所需的时间时，给出“完成”而不是“基本完成”的估计（根据经验估计“完成”需要多长时间。抵制拒绝集成，文档，整理的诱惑，测试，测试后的错误修复，部署等作为小任务，将被吸收到其他任务中。

你最终会得到一个可怕的大估计。但要问问自己，这是否与之前项目的实际时间不符。

Answer 18

我认为，如果你对80％和20％捆绑在一起的任务进行估算，那么你的开始就会很弱。打破你的估计。使80％和20％两个明确的任务;如果你必须的话，那就是容易的位和硬位。

然后，您可以预先为整个工作提供更实际的时间估算，并使生产更容易跟踪具体细节。

Answer 19

我发现最好的方法是使每个任务的完成百分比保持最新状态。这样，进展就很清楚了。与管理层沟通，他们应该随时了解你的位置。