为什么软件时间表很难定义？

以我的经验来看，让我们的工程师准确地估计和确定要完成的任务就像拔牙一样。不仅仅是给出2到3周或3到6个月的估计时间...定义软件计划的最简单方法是什么，这样就不必费心定义？例如，客户A希望在2011年2月1日之前获得功能。知道在此过程中可能需要其他错误修复并占用额外的工程时间，您如何安排时间实施此功能？

如果使用熟悉的工具和熟悉的团队来启动与已完成的其他项目几乎相同的项目，并且给出了明确的书面要求，那么应该可以做出正确的估算。

这些是画家，地毯安装工，园丁等经常遇到的条件。但这并不适合许多（或大多数）软件项目。

我们经常被要求评估使用新工具，新技术，需求不断变化等的项目。与根据过去的经验进行插值相比，这更多的是对未知数的插值。因此，自然而然地，估计会更加困难。

根据我的亲身经历，这与Pemdas所说的恰恰相反：通过实践，我刚刚了解到完全不可能估计一项任务需要多少时间。在软件开发职业生涯的开始，我经常给出“ 45天”，“五个星期”等估算值，然后非常努力地及时完成。几年后，我开始给出不太准确的估算值，例如“大约一个月”，“五到七个星期”等。实际上，我尝试不给出任何估算值，或者要求客户给出自己的估算值或截止日期，或者我给出一个尽可能粗略的估计。

为什么这么难估算？因为几乎不可能在实际编写整个源代码之前就知道如何编写整个源代码，并且因为您的工作依赖于他人工作中的随机事物，动机等等，所以这里是可能原因的更详细列表：

1. 要知道确切地需要什么来制造产品，尤其是如何去做，并不容易。经过数天的工作之后，我经常启动应用程序的某些部分，然后才明白我的第一种方法是错误的，并且有一种更好，更聪明的处理方法。

2. 可能会出现一些问题。例如，如果要开始工作，必须在计算机上安装精美的SQL Server，并且安装失败并且不存在支持，则可能需要花费数周的时间来解决此问题。

3. 需求通常不够清晰，但是在开始阅读它们之后，您认为它们已经足够了。有时您会理解平均值为“ A”，并且在开始实施它们后，会注意到它们的含义可能为“ B”。

4. 客户喜欢在您刚刚完成相关部分时准确地更改他们的要求，而他们真的不明白您为什么还要再花两周时间和2000美元来进行微小的更改，因为他们看不到这个微小的更改需要改变其他事物，这需要改变其他事物，等等。

5. 你无法估计自己的动机。有时候，您可以工作几个小时并取得成功。在写了十行代码之后，有几周的时间，您切换到Programmers StackExchange，并花费数小时阅读回答问题的答案。

6. 当您的估计取决于其他人时，事情真的变得很糟糕。例如，在一个2个月的项目中，我不得不等待设计师完成他自己的工作。这位设计师花了3个月的时间才提交了一份无法使用的废话。当然，这个项目很晚。

7. 您的估计还取决于您的客户。我的客户花了数周的时间才回信。当您必须等待他们的答案时（例如，如果您要他们明确要求），这确实会影响您的日程安排。

你能做什么？

1. 给出更大的时间表。如果您认为您可以在两周内完成工作，则说您将在一个月内交付。

2. 要清楚。如果您依赖设计师，其他开发人员等，请说出来。与其说“我将在三个月内交付产品”，不如说“我将在设计人员给我PSD文件后两个月内交付产品”。

3. 说明如果需求每天都在变化，那么该项目将很难及时交付。

4. 削减您的时间表。准时交付大型项目的各个部分更加容易。

5. 当您使用不熟悉的产品时，或者尤其是您将要使用他人的源代码时，永远不要做出估计：您永远无法预测源代码的糟糕程度和花费的时间了解并将其复制粘贴到The Daily WTF。

一个非常相似的问题是“解决这个填字游戏需要花费多长时间？”

您必须先看一下才能看到很多类似的东西，然后才能回答：

• 用熟悉的语言吗？（西班牙文，英文，中文）
• 这是我们之前解决过的一种类型吗？（例如，在杂志中刊登的系列文章之一）
• 在我们甚至不了解它们之前，是否有任何线索需要其他知识？
• 就您所知，难题中是否有任何地方需要额外的工作？

由于项目中通常有几个新事物（否则就不是一个项目），您必须仔细研究一下才能知道它们将花费多长时间解决。也许甚至或多或少地解决了它们，然后您仍然不确定没有想到没有一两个惊喜。

还有一个巨大的压力，那就是要尽可能便宜地做到这一点，因此要尽快完成，而过低的估算责任不归咎于项目经理，而是由开发商提供估算。开发人员无需花费很多迭代即可掌握这一点，并且学会了非常厌倦给出任何绝对数字。

您的工程师无法提供准确估计的最明显原因是，这是不可能的。

当然，您可以估计从家里上班需要多少时间+ -2分钟。您知道如何驾驶汽车，可以评估流量以及其他一些外部因素。

告诉我从伦敦开车到巴塞罗那需要多少时间。当然没有任何高级GPS规划工具。像我们在软件评估中一样，使用良好的旧方法。实证估计和预测。

在软件中，情况更糟：

1. 估计常常成为一种承诺，因此我们的判断被修改了。
2. 对于同一任务，鲍伯和卡尔的估计之间可能会有巨大差异。
3. 不确定性很常见，我们有多少人陷在愚蠢的错误或硬盘崩溃中，从而破坏了任何明显的正确估计。
4. 除编程外，我们通常会忘记所有其他任务，包括会议，电话，帮助同事等。
5. 人脑有限。它尚未设计用于估计长期运行的任务。

这就是为什么无法告诉您的客户您将能够以高准确度为02/01/2011发货的原因，而忘记了03/01/2011。

为了解决所有这些问题，我建议您使用高级估算技术，例如Planning Poker（免责声明：这是我的网站之一）和带有速度计算的迭代开发。

• 前两个问题是使用Planning Poker解决的。估算是集体的，团队拥有它们，而不是个人。
• 最后的第三个问题是使用速度和迭代开发解决的。通过了解速度（基于历史记录应用于估算的因素），您可以更加放心地计划发布。如果做得好，迭代式开发会将最重要的功能带到顶部，并帮助您及早为用户带来价值。

根据定义，软件开发是发现和发明的行为。它必须始终涉及未知的事物。

唯一与软件开发有关的知识都是在软件完成时才知道的。

唯一未知的技术或业务功能是唯一完整的打包解决方案可供下载。

我们编写新软件的原因是因为我们拥有新功能或新技术，或两者兼有。新意味着新的-未知的-不可预测的。

由于软件开发必须涉及新颖性，因此无法预测开发工作。

老实说，我认为这只是需要练习。如果您编写了足够的代码，那么最终您应该“相当”准确。我的第一任老板认为这项技能非常重要，以至于他要求我在我实施的每个功能/项目中非正式地进行练习。在每个项目之后，我们都对估算进行了评估，并试图找出我哪里出错了。最终，您掌握了窍门。

从来都不容易。您只是尝试变得更好。

将可交付的代码分成更小的部分的一个优点是，客户可以了解期望的内容和期望的时间。现在，您有了一些基准，可以将它们用作参考。

如果他们在定义的时间严格定义了所需的功能，则他们需要知道必须为该请求分配其他资源。他们冒着严重漏洞的风险以及在不修复漏洞的情况下可以走多久的风险。当出现重大问题时，您会返回客户并强迫他们做出决定。我是否要修复错误或在新功能上规定期限？给他们足够的信息以做出明智的决定。

希望您有足够的合作历史，并已建立起足以值得信赖的自己。您不能期望他们完全理解开发过程，但是可以使他们感到自己正在诚实地努力，而不是利用他们缺乏的知识。

因为我们制定时间表太早了。请参阅Construx的有关进行初步粗略的文章，然后再进行更好的粗略文章。另外，如果您不跟踪先前的估算结果，则很难获得更好的结果。FogBugz做到了这一点[他们免费的客户，没有其他利益冲突]。

我从这本书中学到了很多东西：

软件估算：揭开妖术的神秘面纱

简而言之，为了获得更好的估算结果，我们这样做：

1. 除琐碎的任务外，其他所有任务的估计都超过一个人（在我们的示例中为两个人）
2. 我们将任务分为较小的任务。您拥有的任务越多，您的估计就越可能是好的-如果我从嘘声中正确记起，则是大数定律
3. 我们估计了最坏，最好和最可能发生的情况。有时我们每个人对那些树的情景的估计都完全不同。这意味着我们必须交谈，通常结果是我们中的一个人不了解任务。如果一个人单独估计任务，那将被认为是错误的。
4. 我们将上述点的3个数代入方程式并接收估计值（excell）k

工作任务完成后，我们的估计是错误的，我们尝试找出原因。并且我们将这些知识整合到下一个估算过程中。到目前为止，这是我用于估计较大任务的最佳过程。当我说任务时，我指的是大约需要50-500小时的工作。

注意：这实际上仅适用于按小时计费而不是固定费率/固定费率的项目。

我通常会尝试计划时间表，以使其实质上包含一堆SCRUM Sprint（无论是否使用SCRUM）。在制定进度表时，首先要确定每个冲刺的长度以及项目的功能。通常，首先必须完成一些功能，因此我尝试为这些功能提供最佳估计（不要与乐观相混淆），并且在项目即将结束时的所有功能都应具有广义估计。将要素映射到sprint之后，我尝试在项目的末尾添加1-2个sprint，以说明向右滑动的要素以及在原始需求收集中被忽略的要素。

这样做的关键是，我使所有这些对客户端都是透明的，以便他们理解为什么最后两个sprint是空的或稀疏地填充的。至少到目前为止，我与之合作的客户都喜欢这一点，因为他们知道进度/财务方面有一定的缓冲，因为他们中的大多数人都知道，SW的估算往往不那么具体。他们还意识到，如果我们不需要上次冲刺，那么这些时间就是我们不收费的。透明的进度表构建方式以及项目执行过程中进度进展的定期反馈使我与之合作的每个客户都非常满意。

除了命名的所有事物之外，我还将这两件事视为最大的问题。首先，您要根据每周5天每天整整8个小时可用的每个开发者来估计最终日期。这是不正确的，几乎可以100％确保在任何不重要的项目上都错过了结束日期。人们请假，参加公司（或非基于项目的）会议，与人力资源部门就健康保险索赔，休息等问题进行斗争。每个开发人员每天的可用时间不得超过6小时。

众所周知，下一个开发人员忘记估计所有非开发任务，例如与项目，部署，QA支持，UAT支持，编写单元测试，研究，文档等有关的会议和电子邮件。将这些类型的任务添加到估计电子表格后，估计变得更好。

当涉及到可能需要花费几个小时才能完成的任务的时间估算时，我会尽力使用以下规则：

1. 如果您碰巧依赖别人，永远不要试图预测别人何时才能完成工作。只为自己说话。
2. 首先分析任务，然后估算。通过分析，我的意思是至少写下（而不是试图让所有事情都掌握在自己的脑海里！）一系列子任务，并对每个任务进行估算。
3. 如果任务足够复杂，请估计进行此类分析的时间。让估计是一个单独的过程。您还可以确保老板知道这一点。
4. 不要在压力下估计。明确指出，进行合理的估算需要时间，只需告诉他们“我将在明天11:00结束分析任务时命名日期”之类的内容即可。我知道有些客户/经理可以努力，但是他们不会通过。戴上忙碌的面孔，尽情享受您的时间！
5. 要求的时间比您想象的要多一些，因为您可能忘了在估算中增加休息时间（以及其他时间）。
6. 对于大任务，甚至要求更多-可能会不止一次喝咖啡。
7. 如果您确实无法估计（任务太难/不熟悉）或不确定，请咨询能够帮助您进行分析的人员。

可能有更多的规则，但实际上我的墙上没有张贴带有此规则的海报。我现在只是制定它们，但是它们来自我的经验（因此它可能对您不起作用）。

我能想到的唯一可靠的计划软件开发的方式（但我还没有实际尝试过）是基于证据的计划，它基本上是蒙特卡洛方法，用于基于有关您任务的历史记录来计算发货日期的概率我已经完成了。感觉不错，因为它除了估计时间和实际时间外不尝试使用其他任何指标。但是，将大型任务事先分解为较小的任务需要大量的经验，并且您必须拥有大量的历史数据才能使其足够精确地工作。

有“未知未知数”和“未知未知数”。:-)

1. 估算通常会成为截止日期。

   • 没有人愿意错过最后期限并成为头条新闻！

2. 需求改变（通常是合理的），程序员无法否决它。

3. 程序员不能控制以下因素：

   • 她所依赖的代码的可用性
   • 她所依赖的代码质量
   • 系统的总体架构和设计
   • 用于访问系统其他部分的API