共计 3642 个字符，预计需要花费 10 分钟才能阅读完成。
作为架构设计人员或技术开发人员，置信你肯定被问到过上面的问题：
- 有个新需要，请帮忙粗略估算下实现这个需要大略须要多少工作量。
- 当初有 100W 估算，请帮忙估算下够不够实现这个需要的开发。
- Story 卡曾经写完了，请帮忙做下具体的估算，看看咱们须要多少开发资源。
- 线上这个问题起因曾经找到了，请帮忙估算下最快多久能修复。
在软件开发的不同阶段，咱们都会因不同的目标须要做估算，比方须要分配资源时、须要排开发计划时、须要评估老本时等等；然而，有些场景下咱们也会察觉一些估算的理由很牵强，甚至是需要自身就不是很正当，感觉单纯是“为了估算而估算”。那么估算都有必要吗？如果有必要这个估算该怎么做呢？
一、为什么要做估算？
首先咱们来答复第一个问题，要想晓得估算是否有必要，就要先弄清楚估算的意义，估算到底帮咱们解决了什么问题，这样能力明确指标，能力设计正当的计划，才能够判断是不是肯定要通过估算来解决这个问题。
Martin Fowler 在他的文章《PurposeOfEstimation》中具体论述了为什么要做估算：
Estimation is valuable when it helps you make a significant decision. 估算是为了帮忙咱们更好的做重要决策
没错，回想起须要做估算的场景，咱们都是须要估算的后果作为输出来帮忙做决策，文章结尾的一些问题也对应着一些典型的须要做估算的场景，比方：做资源布局，老本预计，安顿开发计划，或者评估一个需要的投入产出比等等，在这些场景中，估算能够帮咱们理清做一件事件所须要的人力老本和工夫老本，进而帮忙咱们来做出正当的决策。
明确了估算在决策当中所起到的作用，咱们就能够判段以后这个决策是不是肯定须要估算作为输出，说到这里，当然也有一些软件开发流动并不需要估算也能顺利开展，感兴趣的能够浏览《PurposeOfEstimation》找到一些不须要估算的示例。
二、如何做估算？
明确了估算的意义，那如何做估算能力算是无效的估算，能力帮忙咱们做出正当的决策呢？从估算在软件开发过程中所处的阶段，能够简略的分为两类：
- 开发团队染指前的需要老本估算
- 开发团队在进入开发阶段前的 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 日，深圳站，企业组队参赛 & 集体参赛均可，一年等一回，错过等一年，连忙上车~ 公众号回复“黑马”退出
