软件开发中的日常工作量及其对估算的影响

我坚信，软件开发中的日常工作量（即使应该忽略不计）相对较小，而且应该相对较小，这是软件估算的基本问题。

让我描述一下我如何得出这个结论，并告诉我该论证是否存在严重缺陷：

1. 可以高精度估计的只是例行工作，这意味着以前已经做过。涉及研究和创造力的所有其他类型的工作都无法真正估计，至少不能以+/- 20％的准确度估算。

2. 软件开发就是要避免重复的任务。它的基本原则之一是干燥（不要重复自己）。每当程序员发现自己在做重复的工作时，就该找到避免这种重复的抽象了。这些抽象可能很简单，例如将重复的代码提取到函数中或放入循环中。它们也可能更复杂，例如创建特定领域的语言。无论如何，实施它们都将涉及研究（以前有人做过吗？）或创造力。

从这两点我得出以上结论。

实际上，我已经想了好一阵子了，为什么在其他所有有关软件评估的讨论，博客文章或文章中都没有提到这种关系。太理论了吗？我的假设错了吗？还是太琐碎了-但是，为什么我所知道的大多数开发人员都相信他们可以以+/- 20％或更高的精度进行估算？

在任何给定的项目上，这可能都是正确的。但是，如果您多年来为不同公司从事多个类似项目，则可能会发现自己几乎可以多次解决“基本”相同的问题，而只是稍有不同。

例如，我已经写了很多次数据访问层，现在我更喜欢“长手”，而不是使用当月流行的ORM。对于我来说，用已知的解决方案来处理“常规问题”比在第三方组件中发现和解决新问题更快，更容易。

显然，我可以编写自己的ORM来简化重复代码，而无需在其他人的系统中添加未知的怪癖，但是该代码属于我当时所工作的公司，而其他开发人员会发现它与任何其他第三方ORM。

同样，以我的经验，大多数编程都是业务流程的自动化，尽管每个业务都喜欢认为自己的流程是唯一的。实际上，事实并非如此。

并不是说估算很容易！这比较容易，但是我发现这些天的估计问题是由于需求不足而不是编码所花费的时间。

需求通常分为三类：

1. 模糊，细节留给开发人员。

“让我成为一个网站，它必须很酷并出售我的小部件”

这些往往是最容易估计的，因为当发生严重的意外问题时，您可以简单地将需求更改为功能上等效的东西，并避免出现问题。

2. 非常具体

“使标题背景颜色为＃ff1100”

超级快，而且容易估算。但！需求必然会发生变化。“嗯，别想了，试试其他红色”或“等等！我的意思只是在那一页上！” 因此，“直到我对标题颜色满意为止”的实时范围与编码估计无关

3. 模糊，假设的细节

“给我一个网站，（就像facebook一样）”

这里有许多未阐明的假设，“当然，您将需要一个不同的徽标”，“它应该具有无限滚动”，“必须可扩展到10亿用户！” 有效地控制估计。开发人员要么考虑所有内容，然后将估算值提高到超出预期的“ 1 meeelion工时”，要么他们认为/假定仅需要基本功能，而给出的估算值太低。“哦，一两个星期，我想你只是想把Facebook放在iframe中，对吗？”

有经验的编码非常快，但是设计要求（通常）是硬性要求，并且越来越多地推向非编码器。通过敏捷方法，可以通过将责任转移到“业务”而不是开发人员上来提高编码速度。

为什么我知道的大多数开发人员都相信他们可以以+/- 20％或更高的精度进行估算？

因为我们估计我们对问题的耐心远远超过实际问题。

如果我要为反弹的球设置动画，我可以在上面花一天，一周，一个月或一年的时间，但仍可以播放一个反弹球的动画。希望我花的时间越多，效果会越好，但在某种程度上我很可笑。

我为使球弹起而付出的努力是时间的函数，该时间是合理的。如果我的技能水平不高，我可能会得到一个只是坐在那里的球。但是，当截止日期到来时，我应该让截止日期延长还是至少让屏幕上出现一个球？Waterfall坚持要球弹跳，所以日程表拖延了。敏捷说只要把球传出去。至少我们会发现人们对弹跳有多大的兴趣。因此质量下降。

我试图确保我的球反弹，但是当截止日期临近时，生产一个静态球总比什么都没有要好。因此，在讨论替代方案之前，我根据在问题上花费的合理时间来估算时间。有时球只是不会反弹。有时候没关系。消失一个月不行。