投资回报率（ROI）已成为在企业中引进工具、方法或者策略时必须考虑的关键指标。
尽管如此，在某些情况下，ROI 很容易衡量，而在其他情况下，则往往只衡量结果——金钱。这种评估角度是有效且必要的，但也经常会忽略总价值的其他关键组成部分。例如 Incredibuild 这样的平台，它提供开发加速的解决方案，这是一种具有显著利益和价值的功能，虽然听起来有些抽象，但理解这些平台提供的价值是非常简单的。
让我们探讨一下加速对两个关键价值：开发时间和迭代频率。
可量化价值
让我们从一个基本前提开始：时间=金钱
这并不新鲜，但让我们再加上一个新层面：时间=速度+质量
在深入探讨之前，让我们来分解一下。如果时间就是价值，是速度和工作质量的结果，那么价值就来源于在开发过程中节省的时间。
以此为基础，我们先建立一些今后将使用的关键概念：
- 本地和集中式构建，在开发过程中运行测试并了解代码如何工作需要进行构建。它们可以在开发人员的设备上本地发生，允许立即进行更改，或者集中在中央（CI）进行，将多个开发人员和团队的更改和更新合并。
- 构建等待时间，简单地说，这是构建需要完成的时间。构建意味着在等待其编译和合并新更改的过程中无法对代码进行操作，而更长的构建时间会导致上下文切换和时间浪费。
- 增量和完整构建，增量构建通常在本地运行，并且比完整构建所需的时间更短。然而，像新分支这样的事件会触发代码库的完整构建。同样，大型团队可能会要求成员每天进行“get latest”，这可能会触发增量构建，可能与完整构建所需的时间一样长。
构建速度对频率的影响
构建时间以及构建频率是影响上市时间的最大因素之一。好的软件是在迭代中构建的，而较慢的周期意味着完成的任务更少，修复需要更长时间，发布时间变得更加紧张。
大多数组织更喜欢实现完整的“每次提交构建”，即每当在分支上有新的提交时触发新构建的能力，但低构建频率使这种期待变得不切实际。
尽管有很多理由努力提高构建频率，但有两个原因突出：
- 在流程的早期为开发人员提供反馈；
- 更快速的解决“谁破坏了构建”的问题。
较低的构建频率还伴随着更大代码质量风险，每个项目的构建次数较少意味着每次构建中包含更多的代码添加。这也意味着更多的潜在错误，以及更难通过数十个代码添加来确定故障的位置，每次提交构建意味着只检查单个代码更改。因此，更快的构建和更高的构建频率减少了搜索错误和修复代码所花费的时间，使开发更好的软件成为可能。
总之，开发时间和迭代频率加速的价值不容小觑。它直接影响着软件开发过程的效率和效果，最终影响了组织在当今快节奏的市场环境中的竞争力和成功。
随着技术的不断发展，像 Incredibuild 这样的工具的重要性变得更加突出。那些接受并利用这种平台的企业通过简化其开发流程、缩短上市时间并更有效地交付高质量软件，从而获得显著的竞争优势。尽管投资回报率仍然是评估投资的关键指标，但必须考虑到的不仅是有形的财务回报，还有为企业的开发流程和整体成功带来的更广泛、长期的价值的方面，例如像 Incredibuild 这样的工具。
量化构建时间缩短的价值
为了说明问题，让我们分解一下 Incredibuild 加速的一个示例，测量使用 Incredibuild 时增量构建和完整构建的差异。
这仅是一个概览，让我们给示例添加一些更多的细节。
假设您拥有以下情况：
- 30位开发人员；
- 每个月22个工作日；
- 每分钟开发成本为 $ 0.75 (基于年度开发人员成本为$100K计算 ，按照12个月、22个工作日、8.5小时每天，60分钟每小时分解)。
现在，可以开始计算我们节省的资金。
首先，每位开发人员每天节省的时间计算如下：
（每次增量构建节省的时间 x 迭代次数）+（完整构建节省的时间 x 迭代次数）= 总节省时间
（3 分钟 x 4）+（30 分钟 x 1）= 42 分钟节省
接下来，我们可以通过将上述结果乘以开发人员的总数来计算每天节省的总时间：
42 分钟 x 30 名开发人员 = 1,260 分钟（大约 21 小时）
然后将其推广到一个完整的月份：
1,260 分钟 x 22 天 = 27,720 分钟（约 3 周）
现在我们可以了解节省的货币价值：
27,720 分钟 x $0.75 = 每月节省的 $20,790 直接开发人员生产力
并且在整整一年内：
$20,790 x 12 = 每年节省的 $249,480 直接开发人员生产力
上述估计假设构建频率与使用 Incredibuild 之前相同。如果考虑到迭代频率的提高（增量构建从 4 次提高到 8 次，完整构建从 1 次提高到 2 次），可以假设我们上面展示的节省额可能轻松翻倍，达到几乎每年$500,000！
考虑 CI/CD 构建
以上内容的计算集中在个人开发人员在本地运行构建上。然而，当今的开发并不是孤立进行的。例如，构建服务器集群完成构建的频率要高得多并且会贯穿几个月，因为开发团队正在寻求持续构建的实践。
当考虑到 Incredibuild 对 CI/CD Pipeline 和构建的影响时，我们可以看到更大的提升。
对于这个示例，我们假设大约 33% 的构建会影响开发人员的生产力，因为它们发生在工作时间内，并且阻止开发人员在构建完成之前继续工作。使用上面使用的相同公式，但增加平均集中构建时间。
首先，计算每个开发人员每天的节省时间：
集中构建节省的时间 x 迭代次数 x 影响开发人员生产力的构建百分比 = 每个开发人员每天的总节省时间
80 分钟 x 3 次迭代 x 33% = 节省的 80 分钟
然后将其推广到每天的总节省：
80 分钟 x 30 开发人员 = 节省的 2,400 分钟
然后每月节省：
2,400 分钟 x 22 天 = 节省的 52,800 分钟（约 1 个月 6 天）
现在让我们来探讨一下财务方面：
52,800 分钟 x $0.75 = 每月节省的 $39,600 直接开发人员生产力
最后，让我们将其推广到每年的节省：
$39,600 x 12 = 每年节省的 $475,200 直接开发人员生产力
与第一个示例一样，我们的计算没有考虑构建频率的增加。这意味着从实际意义上讲，比较节省可能每年接近 100 万美元。
开发者加速的真正影响
在这两种情况下，在构建频率增加之前的节省已经非常显著。通过减少构建时间来改善频率，这样规模的团队可以实现每年节省75万美元至150万美元！值得注意的是，随着代码库规模和项目复杂性随时间增加，这些数字将会增加。
我们已经广泛关注了构建加速的实际利益，但值得注意的是，这些直接影响也会产生重要的无形利益，包括：
- 由于构建速度更快而增加的频率
- 更快的上市时间和每年发布数量的增加
- 集中、满意度更高的开发人员
- 更多时间进行创造性工作和提高代码质量。
在找到此类解决方案时，它的价值不需要是某种抽象概念。加速不仅仅意味着变得更快，它帮助开发团队实现更好的软件质量和更短的上市时间。
立即查看 Incredibuild 如何通过在线投资回报率计算器提高投资回报率，并获取试用 License！
