在计算项目期限时，我们通常会评估中间步骤的持续时间，然后对其进行汇总并为各种事故添加缓冲区。 然后，领导层将我们这段时间削减了一半。 作为本文的一部分，作者将对我们的计算感兴趣，因为即使是一位具有丰富经验的项目经理也常常会理解，计算的周期太短，有时甚至与他的个人专家评估不符。 是的，他将把项目期限和中间步骤的估算值更正到专家评估中，并且在真正精通某些处理的前提下，将在最后期限之前达到15％的准确度，但沉积物仍将保留。
本说明解释了专家估计值与理论计算值之间存在差异的原因。 还考虑了如果不根据类似项目执行情况的统计数据通常高估“高估”专家评估的原因。 最后，揭示了如何正确地计算项目期限，并在项目开始之前或项目进行期间向有关方面解释情况。
错误的根源
当我们评估一项工作的实施时间时，我们确定最可能的数字。 像PERT一样，它可以是对1分或3分的专家评估。 在复杂的项目中，这可以是参数化建模。 在所有情况下，我们都会犯同样的错误。 事实是，在所有经典估计方法中，均假定我们具有估计值的正态分布-根据高斯。 理论家非常喜欢这种分布。
正态分布意味着正确估计工期为6个月的项目同样有可能在9个月或3个月内完成。 在距配送中心相等的距离处，项目完成的概率相等-这是高斯曲线的特征。 另一方面，在实践中，很少有人会看到IT项目的完成速度（在3个月后）快一倍，但是在项目方面（9个月），我们经常看到这些项目被延迟了一半半。 此外，在正常分配的情况下，我们的一半项目将在预计时间之前结束，另一半则在此之后结束。 但这在实践中也没有观察到。 这表明估计期限的正态分布不适用。 就是说，我们没有正态分布，但是有些正态分布在最可能的日期之前和之后具有不同的完成概率。
考虑对数正态分布作为这种分布的一个例子。 它将向我们展示此类分布的特征。 对于对数正态分布，中位数和数学期望值明显超出峰值：
在显示的图表中，峰值显示了项目完成日期的最大可能性，该数字通常包括该数字加上一定的幅度。 中位数表示一个隔离点，在该隔离点上，一半项目将在此期限之前完成，而后一半则在此期限之后。 数学期望值表示项目工期的平均值。 对于工作片段，分布将具有相同的特征：工作片段的实施的最预期时间段（传统上是基于该时间段的计划）与该术语的平均值之间存在较大差异。
为了预测项目的持续时间，我们确定时间最长的链，并加上其片段的持续时间。 如果我们将根据高斯分布的值相加，那么平均而言，应该获得正确的最终项。 实际上，一半的工作片段将提前完成，一半将在以后完成，这些异质性将相互抵消。 碎片越多，不均匀性的补偿就越准确。 另外，我们可以计算错误，并根据最后期限的结果，将最后期限稍微增加一个或两个sigma。
但是我们没有高斯分布。 在我们国家，延长每项工作的执行时间比缩短相同数量的工作更有可能。 结果，如果我们增加每个工作最可能完成的截止日期，则完成方面的异质性不会得到补偿，而是会被放大。 此外，与估算相比，它们在延长项目实际平均期限的方向上有所加强。 我们在现实生活中观察到的情况：如果第一个术语过期，那么所有其他术语都会过期，而延迟只会增加。 只有付出更多的努力，项目滞后才能被消除。
这种计算方法的一个特点是众所周知的事实：评估项目工期的工作分散程度越小，估计的准确性就越低。 尽管从理论上讲应该是完全相反的。 这样做的原因是，我们对整个工作及其组成部分的专家评估是根据经验得出的。 经验是独立地评估每个元素的，而不是基于算术的，根据该评估，工作的持续时间应为其组成部分的持续时间之和。 算术在这里不起作用，因为完成零件的最可能的最后期限之和不能给出完成所有工作的最可能的期限-只有正确的数学期望可以相加。
如果我们尝试将整个项目或其部分的估计项略微增加一个或两个sigma，并考虑分布是正态的，则这无济于事，因为分布的尾部比高斯曲线粗得多。 结果，由于期限估算的这种增加，人们甚至无法达到中位数，更不用说以数学期望的形式表示项目工期的平均值了。
怎么办
一方面，应该增加数学上的期望。 另一方面，我们不是数学家。 我们来自现实生活，即使有时间和一些积累的统计信息，我们也了解计算图形参数的问题。 但是还有其他方法。 最后，评估十几年时间的问题，并随着这种实践而学会了工作。
Brooks方法 ：我们认为程序的实施周期是“直接”（用户是程序员本人），对于软件产品（用户是一个无限的圈子）或复杂软件（在当前情况下，一组微服务）乘以3，对于系统软件产品（乘以3）在当前现实中，是一组相关的基础架构组件）。 这些系数的来源在布鲁克斯的著作“神话的一个月”的第一章中从理论上是合理的，并且对1975年的描述已经很好地转移到了当前的现实中。
Scrum方法 ：我们介绍了实现功能复杂性的抽象中间单元，我们查看了以给定的功能单元衡量的功能实现的统计数据，我们要求团队评估项目任务的复杂性，将这些单元转换为已知长度的Scrum迭代（冲刺），并为该开发团队获取术语的估计值。 由于我们使用的是实际收集的统计数据，并且团队负责估算其复杂性，因此将工期与劳动单位的绑定关系是数学上的期望，因此，一半的冲刺将提前结束，一半结束。 实际上，在Scrum迭代的一半中，团队将不得不承担部分任务，而在一半中添加计划外的任务，以使sprint的长度保持恒定。
将一个团队的Scrum评估转移到另一个团队的任务是一门艺术。 不能通过简单地将一个团队的劳动单位的换算系数引入另一团队的劳动单位来结转它们。 事实是，一个团队的人员组成很好，但是没有好的基础专家，而另一个团队的基础很好，但是前线任务却越来越复杂。 开发人员专业化方面的差异将导致以下事实：就后端任务而言，一个团队在数据库上的任务的复杂性会过高，而另一个团队则在前端。 此外，团队本身确定产品内部质量的必要水平，并且不同的团队以与相邻团队稍有不同的方式来确定产品，这也使重新计算劳动单位变得困难。 也就是说，可以通过比较相似任务的估计将一个团队的中间单元转换为另一个团队的中间单元，但是这些任务应从不同类型的活动中进行，同时要考虑团队的优势和劣势，并要考虑建立Scrum的特殊性。
功能元素方法 ：我们引入劳动输入的中间单元，编制功能元素列表（浏览器中的屏幕，微服务，自定义基础结构元素等），估算中间单元中每个功能元素的工作量。 之后，根据我们与特定开发团队合作的专业经验，我们评估中间单元随时间的转换因子。 就我个人而言，我仍然独立评估各种活动类型的转换因子：分析，设计，编写任务说明，编写代码，布局，测试，集成等。 此后，应考虑操作顺序，上一操作完成与开始新操作之间的特征延迟时间，并应通过关键路径法确定项目的工期。
到目前为止，我们已经处理了项目的内部因素。 但是我们也有外部人员：外部承包商，相关部门，供应商和客户。 它们的问题是完全相同的：它们的响应速度是最可能的值的两倍或更快，或者是响应时间的少于一倍半。 也就是说，也没有正常的时序分布。 还应根据与客户，承包商和相关单位进行的工作统计来确定并考虑到这一点，并在可能的情况下借助罚款加以保护。
时间证明
因此，我们估算了该项目的预计工期。 如何证明收到的条款合理？ 根据所做的计算。 例如，非Scrum项目注释的作者通常在Google表格中制作一个大型的多行可视表，并通过功能元素的方法进行详细计算。 该计算是基于实践的，所有系数和参数都是可视化的，并且即使对于某些人来说这是一段令人不舒服的时期，对有利益相关方的实践通常也是有力的和良好的论据。 特别是这种做法是直观的，并且是在当前公司的框架内获得的。
诸如管理层之类的利益相关者是否同意做得好并且见多识广的时间表？ 即使有兴趣的各方完全理解并意识到评估是正确的，也并非总是如此。 有时由于外部原因，评估是不可接受的，但是这已经使有关方面感到痛苦，导致管理层在时间安排上做出困难的决定。 但是，看到基于经验的计算，管理层和其他有关方面有机会通过分配额外的资源和权力来可预测地影响项目的最后期限。 有时，了解时间安排情况的管理层将继续缩短截止日期，而无需分配额外的资源和权限。 如何忍受这是单独注释的主题。