为使开发人员估算更准确，需要考虑的 11 件事

如果您之前曾被要求做过估算，您会同意这说起来容易做起来难。

范围越大（要做多少），就越难估计，因为复杂性增加，因此模糊性和未知性也会增加，出现错误、失误和沟通不畅的可能性也就越大。

估算类型

1. 高层级。此时，我们的业务合作伙伴/客户只想了解他们正在考虑做的事情所需的总投入。他们想要一个直觉的估算，只需几秒钟就能估算出来。他们不想花费太多时间，哪怕只是估算一下，因为他们还不确定是否值得投入。

2. 详细估算。详细估算是指项目已经过审核，我们的业务合作伙伴/客户希望获得更准确的估算。这样，我们就可以花时间进一步分析，最终得出更明确的任务和时间表。

根据我的经验，高级估算的使用更为广泛，因为它们适用于很多方面，而不仅仅是估算项目工作量。它们还用于快速估算功能和错误，以便更轻松地确定需要关注的优先级。

我还发现，我只在刚刚审查过的项目开始时做详细的估算，以帮助确定整个项目的各个部分以及预计的时间表和工作量。

由于高级估算比详细估算进行的次数要多得多，因此这篇文章将重点介绍我在进行高级估算时通常考虑的事项。

需要考虑的事项概述

在提供高阶估算时，我会在给出答案之前考虑以下所有因素。我们将在下文中逐一详细介绍。

1. 识别各个部分。

2. 我和我的开发团队熟悉所有内容。

3. 对现有功能的影响。

4. 有时间与我的开发团队以及我们的业务合作伙伴/客户沟通和组织日常任务进度并进行协调。

5. 是时候编写单元测试了。

6. 是时候编写集成测试了。

7. 需要手动测试。

8. 是时候记录错误、对其进行分类、确定其优先级并重新测试它们了。

9. 是时候记录我们所做的事情了，特别是如果这是一项重大的努力。

10. 是时候记录错误、对其进行分类、确定优先级并在上线后重新测试它们了。

11. 是时候培训支持操作人员来支持新功能了。

根据我们估计的内容（项目、功能或错误），上述内容可能并不全部适用，但无论我估计什么，我都会在脑海中浏览此列表。

1 - 识别各个部分

即使在高层次的估算中，我们也会先在脑海中形成一个关于各个部分如何协同工作的基本设计。将这个设计分解成多个部分，有助于我们识别复杂性。

• 要做的工作涉及哪些各个部分？

• 我们接触了多少系统和代码库？

• 我们要调用多少个 API？

• 如果有的话，我们要连接哪些数据库？

• 我们需要使用和/或应用哪些框架/插件/架构/包/模式？

由于这是一个高层设计，我们只能运用我们对系统的了解。因此，熟悉有助于提供更准确的估算。这也引出了我的下一个观点。

2 - 熟悉所有部件

对于我们能够识别的所有碎片，我们对所有碎片的熟悉程度如何？

我通常与一个开发团队一起工作，因此为了更安全地估计，我通常假设他们中的大多数人（包括我自己）不会熟悉所有内容。

我通常会考虑以下方面的熟悉程度：

• 代码库和结构

• 数据库模式

• 架构模式

• API（这是我们将要使用的新 API 吗）

• 供应商解决方案

然后，我会留出学习的时间——阅读文档、进行研究，甚至与经验丰富的资源协调。很多时候，我们会有多个经验丰富的资源，每个资源都对应着我们不熟悉的部分。

3 - 识别功能影响

我们正在评估的这个功能是新功能吗？还是在更新现有功能？如果是，那么它是否是一个核心功能，更新后会影响其他多个功能？

知道这个问题的答案将有助于我们评估整体测试工作量。受影响的现有功能越多，我们需要进行的测试就越多（例如回归测试）。

如果受影响的功能已经存在单元测试和集成测试，那么我们还需要考虑根据需要更新现有的单元测试和集成测试。现有的单元测试和集成测试无疑有助于减少整体测试工作量，因为它们将涵盖部分回归测试。

4 - 沟通和组织开销

我们还需要考虑沟通时间和组织时间来整理和执行我们的日常任务。

• 整理我们需要完成的任务需要多少时间？

• 我们需要花多长时间来向团队汇报我们已经完成的工作、正在进行的工作以及下一步要做什么？

• 我们需要花多少时间去协调知识资源来获取完成任务所需的信息？

• 与我的开发团队协调并回答他们的澄清问题需要多长时间？

• 我们需要花多少时间来协调我们的业务合作伙伴/客户以明确需求并确定功能/错误的优先级？

执行一个项目需要我、我的开发团队、我们的业务合作伙伴/客户以及利益相关者之间进行大量的沟通。如果我们想确保与合作伙伴建立信任关系，沟通是工作的一部分。

5 - 编写单元测试

如果我们正在编写新功能，并且我们已经确定它们值得编写单元测试，那么我们需要留出编写它们的时间来。

同样，如果您使用 TDD（测试驱动开发）进行开发，那么您的工作努力将包括这一点以及解决方案的开发。

6 - 编写集成测试

如果您的团队投资了集成测试，那么可能也需要编写这些测试。

7 - 手动测试

尽管存在单元测试和集成测试，但仍然需要进行手动测试。

单元测试和集成测试越少，需要进行的手动测试就越多。

这包括开发完成后进行的初始手动测试。此外，我还会将每次修复错误或由于需求变化而引入代码变更时所需的手动测试也纳入其中。

8 - 漏洞百出

我们已经编写了自动化测试，并完成了手动测试。在最初的手动测试阶段，我们很可能会发现一些错误。

根据发现的错误数量，需要对它们进行分类、鉴别、确定优先级、修复、测试并与团队协调其状态。

更糟糕的是，错误修复可能会引入更多错误，因此通常情况下，错误修复还包括回归测试，以确保没有其他问题出现。

9 - 更新文档

如果您的团队投入精力创建/维护文档，这也是额外的努力。

考虑解决方案的规模和复杂性以及需要更新/创建的文档量。

10 - 上线后稳定

尽管我们付出了巨大的测试努力，但我们自己能够测试的场景有限。我们依靠真实的用户和真实的数据来检验我们的解决方案。

在此期间，我们再次处于错误和更多错误的阶段，但不受控制并且掌握在用户手中。

11 - 移交给运营支持

对于某些团队来说，运营支持（当出现故障/无法正常工作时发生的事件、修复生产错误、升级依赖项（如服务器、数据库、插件等））由不同的团队处理。

如果适用，那么还需要付出额外的努力将其交给运营支持团队，并且可能会出现二元性，其中会有一段时间您和/或您的开发团队会在运营支持团队学习解决方案的过程中为他们提供一些支持，直到他们能够处理大多数（如果不是全部）出现的问题/支持问题。

总结

开发解决方案不仅包括开发时间，还包括分析、沟通、测试和稳定。

变化幅度越大，复杂度越高，估算也越困难。模糊性和未知因素也会增加估算值，因为它们也会增加复杂性。

我们在进行估算时越详细，估算就会越好。