后端开发教程 - Java、Spring Boot 实战 - msg200.com
如何准确估算项目/任务的时间
步骤 1. 了解客户需求
第 2 步：安排这些活动
步骤3.风险管理步骤
步骤 4. 进行估算
大多数人不知道如何充分评估任务的时间安排。唉，这有时会让他们紧张……“截止日期悄悄来临，却浑然不知”。他们甚至买了超过500%的再保险以防万一（但仍然不够）。经理们试图压缩“故意夸大的截止日期”，以便他们能承诺一些更容易接受的东西（常见的管理弊病）。他们总是含糊其辞，而不是给出具体的数字（这更像是开发人员的问题）。
我个人，以及我确信几乎所有人，都讨厌诸如“什么时候可以准备好？”这样的问题，但在一个被认为处于控制之下的项目中，这些问题在任何时候都是必不可少的。
因此，为了实际估计您或您的团队的某些工作所需的时间，您需要做一些准备。
步骤 1. 了解客户需求
如果您不知道船的目的地，您怎么知道旅程需要多长时间。
首先确定项目内需要完成的所有工作。例如，包括功能性需求和非功能性需求（有时很难一次性完成，可能需要反复进行）。为此，请确保预留时间用于会议、报告、沟通、测试以及其他对项目成功至关重要的活动。
第 2 步：安排这些活动
现在，按照需要发生的顺序列出您确定的所有活动。
在此阶段，您无需添加您认为活动需要多长时间。但是，您可能需要记录任何重要的截止日期。例如，您可能需要在开始集成之前获取系统其他组件的文档。
步骤3.风险管理步骤
列出所有相关的假设、排除和限制。
在项目初期，需要集思广益，识别风险。假设你的项目没有任何风险是错误的——每个项目都有风险，如果你没有意识到这些风险，那么你的方向就错了。如果风险没有被识别和衡量，就意味着你不再能够控制项目及其完成所需的时间。你只能依靠运气——这些你没想到的风险可能会发生，从而增加项目的实施时间，甚至毁掉项目。
步骤 4. 进行估算
有几种估算时间的方法：
专家判断
实际上，这是在相关领域专家的参与下形成的评估。专家可能是一位专家，也可能是一群拥有丰富专业知识的人员。
专家会对评估结果做出假设（时间或金钱）。之后，你可以对所有方案进行平均，并在讨论中尝试达成统一的解决方案。当然，让专家参与讨论各种方案会更有效，也能得出更准确、更合理、更可靠的评估结果。
三点估计
最常见、最简单的方法之一。在此框架内，首先确定乐观估计值（O = 乐观）、悲观估计值（P = 悲观）和现实平均估计值（M = 中间）。
P、M 和 O 的值由专家确定（以小时、天、美元为单位），例如在项目团队内部讨论时。为此，专家会提出以下问题：“如果一切顺利，项目需要多长时间？不会有任何风险和问题吗？”，“最糟糕的情况是什么？需要花费多少时间/精力？”等等。然后将获得的 P、M 和 O 值代入公式：(O + 4 M + P) / 6
计算结果给出了平均估值。该公式一方面可以考虑可能出现的正面和负面情景，另一方面可以“平滑”其影响，从而获得更切合实际的评估值。
质量成本
这是一个相当有趣的技巧。起初，我们只估算功能开发所需的时间或预算，而不考虑错误和问题，仿佛我们立刻就能得到完美无缺的软件（从未见过如此神奇的软件）。此外，我们还会进一步估算，为了使软件更接近“理想”状态，实际需要多少额外的时间和预算来处理错误和问题。
在评估软件质量保证成本时，可以分析和考虑以下方面：
- 缺陷预防活动费用
- 测试成本
- 纠正内部错误
- 修复外部集成问题
- 根据实际环境和数据安装和配置软件的成本
类比估计
在这种方法的框架下，我们可以借鉴过去解决此类问题或项目的经验。这里的主要步骤是找到可能的类比，并突出类似的任务。
寻找与以前经历相似的朋友或任务，可以做分解。
参数模型
这是最准确、最灵活的评估方法之一。其本质是基于过去的经验、现有数据以及指标和统计数据，建立某种参数化的模型预测。
事实上，我们建立了一个特殊的数学模型，可以追踪最终成绩如何随初始参数的变化。这种依赖关系甚至可以可视化。这将有助于分析预估成绩与平均值的偏差范围，并了解哪些因素会对其产生影响。
自下而上的估计
这种方法类似于专家评估，只是在这种情况下，预测不是针对整个项目，而是针对其各个组成部分的任务进行单独预测。它是将项目分解为不同阶段的过程。具体做法是：我们收集专家意见，例如来自分析、开发、测试、软件支持等领域的专家的意见。我们将他们的评估汇总在一起，加上互动时间，最终形成一个总体预测。
换句话说，我们分部分收集评估，了解软件开发过程中每个参与者需要多少时间，并将所有信息汇总在一起，同时考虑到额外的风险。
结论
我认为为了获得更准确的结果，最好混合使用几种技术，例如自下而上的估算和三点估算来估算项目的各个部分。
我们需要教会人们做估算，尤其是在IT领域。这对于项目的成功、参与人员的成功以及客户的满意度都至关重要。
我们并不总是能够正确地理解客户的需求，总是期望他会提出新的东西或修改规范中现有的某些内容。当一个人不想或没有时间去理解需求或将项目分解成几个部分时，你总是可以听到不同的乘法因子，要么是 pi(3.14..)，要么是 e(2.71..)。乘数并不小，它们的差值可能很大。但所有这一切——都是对小事的疏忽或懒于理解以上所有内容的问题。显然，评估需要资源，有时甚至是严肃的，但对细节越关注，对执行时间的预测就越准确，特别是如果我们有一个已经制定并执行过此类项目的团队。
遗憾的是，教会一个人留意细微之处既困难又费时。但即使遇到阻力，这仍然是必要的。
推荐书籍
感谢您的阅读！
有任何问题吗？请在下方留言，开启精彩讨论！
看看我的博客，或者在推特上跟我打个招呼👋 ，或者订阅我的电报频道。
制定你的最佳计划！