你的估算作得对吗？ | IDCF

做为架构设计人员或技术开发人员，相信你必定被问到过下面的问题：

• 有个新需求，请帮忙粗略估算下完成这个需求大概须要多少工做量。
• 如今有100W预算，请帮忙估算下够不够完成这个需求的开发。
• Story卡已经写完了，请帮忙作下详细的估算，看看咱们须要多少开发资源。
• 线上这个问题缘由已经找到了，请帮忙估算下最快多久能修复。

在软件开发的不一样阶段，咱们都会因不一样的目的须要作估算，好比须要分配资源时、须要排开发计划时、须要评估成本时等等；然而，有些场景下咱们也会发觉一些估算的理由很牵强，甚至是需求自己就不是很合理，感受单纯是“为了估算而估算”。那么估算都有必要吗？若是有必要这个估算该怎么作呢？

1、为何要作估算？

首先咱们来回答第一个问题，要想知道估算是否有必要，就要先弄清楚估算的意义，估算到底帮咱们解决了什么问题，这样才能明确目标，才能设计合理的方案，才能够判断是否是必定要经过估算来解决这个问题。

Martin Fowler在他的文章《PurposeOfEstimation》中详细阐述了为何要作估算：

Estimation is valuable when it helps you make a significant decision.估算是为了帮助咱们更好的作重要决策

没错，回想起须要作估算的场景，咱们都是须要估算的结果做为输入来帮助作决策，文章开头的一些问题也对应着一些典型的须要作估算的场景，好比：作资源规划，成本估计，安排开发计划，或者评估一个需求的投入产出比等等，在这些场景中，估算能够帮咱们理清作一件事情所须要的人力成本和时间成本，进而帮助咱们来作出合理的决策。

明确了估算在决策当中所起到的做用，咱们就能够判段当前这个决策是否是必定须要估算做为输入，说到这里，固然也有一些软件开发活动并不须要估算也能顺利开展，感兴趣的能够阅读《PurposeOfEstimation》找到一些不须要估算的示例。

2、如何作估算？

明确了估算的意义，那如何作估算才能算是有效的估算，才能帮助咱们作出合理的决策呢？从估算在软件开发过程当中所处的阶段，能够简单的分为两类：

• 开发团队介入前的需求成本估算
• 开发团队在进入开发阶段前的Story估算

然而无论是哪一种估算，正常的流程应该至少包括以下的步骤：

• 理清业务需求
• 肯定技术解决方案
• 将要作的事情拆分红任务
• 针对每一个任务作出评估

2.1 有效的估算应该关注什么？

上面的流程很简单，但不一样的人遵守这个流程获得的估算结果可能会是不一样的，一方面不一样的人给出的解决方案多是不同的，另外一方面不一样的我的经验也会致使任务拆分结果的差别，进而致使估算结果的差别；

估算结果的差别并不表明估算是有问题的，由于作估算基于的前提条件是有差异的，那么怎样才能保证估算的结果能够知足帮助咱们作决策的要求呢？在整个估算过程当中，咱们要重点关注如下几点：

1）明确估算粒度

估算粒度决定咱们的设计要作到多细致，估算的解决方案要作到多细致。一般开发团队介入前的需求成本估算，目的是用来判断完成这个需求大概须要多少成本，粒度会比较粗；而开发团队进入开发阶段前的估算，目的是为了作详细的开发计划，粒度会比较细。

估算粒度的大小能够指导整个估算过程的进行，避免你们陷入无休止的细节讨论之中，当遇到问题争论不休时，咱们能够马上问一个问题：这个争论的结果会影响咱们的估算吗？若是不影响，能够在后面有了更多输入的时候再进行讨论；若是有影响，那就要尽快找到能够作决定的人来进行决策。

2）需求理解一致

在流程的第一步一般是业务分析人员对业务需求进行讲解，阐明需求设计的业务价值，当前的业务现状，须要作的改动，以及交互设计的一些细节；

在这个过程当中参与估算的架构设计人员或开发团队须要理解需求的所有内容，并结合本身对当前系统的理解评估新的设计和改动是否和既有的实现有冲突，及时给予反馈，对设计上不理解的地方及时提问，保证你们对业务需求的理解在同一个层次上，这样才能保证后续解决方案的合理性以及估算的合理性

3）估算应该是协做的结果

为了确保估算的相对准确性，在敏捷开发中当Story卡准备好以后，一般整个开发团队都要参与到估算当中，估算较高或较低的同窗要给出理由，尽可能避免由于上下文不一致致使估算的误差。

而对于粒度较粗的估算每每会忽略这点，一方面粒度较粗，不须要特别细致，准确性每每会被忽略；另外一方面在软件开发初期可以作估算的人力资源有限；然而，这个粒度的估算对决策的影响每每更大，估算误差较大对软件开发项目的影响是巨大的，能够试想一个场景：在最初的成本估计过程当中，若是低估了项目的复杂性，给出了较小的估算，一方面在开发过程当中不断涌现的复杂性，对开发团队来讲是不可预期的，会影响开发团队对总体开发进度的控制程度，另外一方面没有足够的预算，颇有可能致使项目开发到一半由于资金不足而失败。

所以，在作较大决策相关的估算时，建议尝试创建解决方案Review小组，估算的结果在小组内进行评估，确保不会产生较大的误差。

4）明确估算基于的假设

从估算的基本流程能够看出，估算是基于一个假定的解决方案，不一样的解决方案的估算可能会有很大的差别，好比：

如今要把一个文件里的内容导入到生产环境的数据库中：解决方案能够有两种：

• 人工解析文件内容，转化为SQL，将数据写入到生产环境的数据库中
• 开发一个功能，操做人员能够经过Web端选择文件上传到生产环境的数据库中

两个方案均可以解决问题，但不一样的方案的优缺点也是明显不一样的，影响也是不一样的，所以在估算给出的同时，要明确指出估算基于的假设，一旦假设不成立，咱们就须要进行从新估算。

2.2 估算须要考虑哪些因素？

前文提到不一样的人对同一个需求作估算，结果多是不一样的，由于解决方案多是不一样的，估算的假设前提也多是不一样的。从团队的视角出发，无论是解决方案小组来Review估算，仍是开发团队一块儿来作估算，咱们能够认为解决方案是一致的，假设前提也是相同的，在这种状况下怎么能保证不一样的人给出的估算是基本一致的，是符合团队预期的呢？

本质上来讲是要消除人的经验对估算产生的影响，所以咱们要尽量多的找出影响估算结果的因素，在每次估算过程当中，你们都要经过各类问题来澄清这些因素是否会对估算结果产生影响，以及会产生多大的影响。

通过大量估算的分析，咱们认为如下因素会对估算结果产生较大影响：

• 技术难度，新的技术/框架的引入
• 业务逻辑的复杂程度
• 交互设计的复杂程度
• 第三方的系统集成难易程度
• 数据量级，数据迁移的复杂度
• 是否破坏已有功能
• 跨功能性需求，好比性能、数据安全等等

以前项目上的同事为了保证不一样的人在估算过程当中可以尽可能给出符合团队预期的结果，设计了不少问题帮助你们在估算时理清须要考虑的因素，我整理了一下，供你们参考：

类别	问题
前端	是否须要引入新的前端组件/框架？
	是否须要修改/复用现有组件？这些组件在哪些场景使用？
	是否包括较多的样式细节调整？
	是否有特殊的异常处理逻辑？
	是否涉及较多的业务场景（组合状况）？
	是否有复杂的交互逻辑和校验逻辑？
	与后端服务的集成逻辑是否复杂？
后端	是否须要新建/修改API？
	是否会大量改动现有代码/测试？
	是否有大量的跨服务交互？
	是否有比较复杂的业务流程控制？
	是否有新技术的引入，须要作进一步的调研？
	是否有性能风险？涉及数据量级有多大？
	是否须要写大量的测试代码（单元测试、契约测试）？
数据	功能验收的数据准备是否复杂？
	是否须要新建数据表结构？
	是否须要作数据迁移？数据迁移的数据量和复杂度有多大？
	当前数据结构的修改是否会影响到其余功能，好比报表、ETL任务等？
系统集成	是否包含系统集成？
	是否须要在集成中考虑失败重试的场景？
	是否须要考虑集成接口的幂等性？
	系统集成逻辑和场景是否比较复杂？是否有不少异常场景须要处理？
	集成对端系统是既有功能仍是新开发的？
	是否须要在系统集成过程当中作大量的沟通工做？
	系统集成测试环境的搭建是否困难？
	系统集成的联调工做是否容易开展？

结语

估算在整个软件开发周期当中起着很是重要的做用，往大了说，它可能决定了整个项目的开发资源配置，它也可能决定了整个项目的开发周期和交付节奏，它甚至可能决定了一个项目还未开始就不会继续下去。所以，在作估算以前，咱们要明确此次估算在接下来的决策中到底起到什么做用，能够帮咱们解决什么问题。

然而，在整个世界都在高速发展的大环境下，惟一不变的就是变化，敏捷软件开发也因其能应对需求的快速变化而成为主流的开发模式。估算是基于必定的假设前提，在必定的上下文下才成立的，一旦假设发生变化，估算就失效了，咱们须要从新作决策，必要时估算也须要重头来过。

来源：码猿外

做者：麻广广

声明：文章得到做者受权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原做者有其余考虑请联系小编删除，致谢。

IDCF DevOps黑客马拉松👉 9月11-12日，上海站，11月20-21日，深圳站，企业组队参赛&我的参赛都可，一年等一回，错过等一年，赶忙上车~公众号回复“黑马”加入