软件变更成本
一旦设计，编码，测试和实施软件，更改或修复软件的成本可能很高，这有两个截然相反的立场（常常被误解）。 有人认为，将更改留到很晚是非常昂贵的，更改的成本成倍增加。 另一个立场是，更改应尽可能晚地进行，因为更改软件的成本基本上（或至少可以是）基本持平（这就是为什么我们将其称为“软件”软件）。
哪个位置正确？ 我们为什么要关心呢？ 那我们该怎么办？
指数变化成本
早在1980年代初期，Barry Boehm发布了一些统计数据（ 软件工程经济学，1981年 ），该统计表明，随着时间的推移，进行软件更改或修复的成本显着增加-您可以看到他在此处发表的原始曲线。
Boehm查看了1970年代从TRW和IBM的基于Waterfall的项目中收集的数据，发现随着从需求分析到架构，设计，编码，测试和部署的阶段，进行更改的成本增加。 在您仍在定义需求时发现并纠正了需求错误几乎不花任何代价。 但是，如果等到完成系统的设计，编码和测试并将其交付给客户之后，它的成本可能高达100倍。
这里有一些警告。 首先，大型项目的成本曲线要高得多（在小型项目中，成本曲线更像是1：4而不是1：100）。 在Boehm称之为Architecture-Breakers的情况下，变更成本上升到100倍的情况很少见，在这种情况下，团队得出了基本的架构假设错误（缩放，性能，可靠性），并且直到客户已经使用了系统并遇到严重的操作问题。 而且，所有分析都是在30年前的一个小数据样本上完成的，当时开发代码的成本更高，更耗时且需要书面工作，并且使用的工具不胜枚举。
从那以后，还进行了其他一些研究，这些研究大部分都支持了Boehm的发现-至少有一个基本的思想，即发现错误的时间越长，纠正错误的成本就越高。 这些研究已在史蒂夫·麦康奈尔（Steve McConnell）的Code Complete等书中得到广泛引用，并被用来证明早期审查和测试的重要性 ：
过去25年的研究已明确证明，第一次做正确的事是值得的。 不必要的更改很昂贵。 惠普（Hewlett-Packard），IBM，休斯飞机（Hughes Aircraft），TRW和其他组织的研究人员发现，在开始建造时清除错误可以使返工的成本比流程的最后部分便宜10到100倍，在系统测试期间或释放之后（Fagan 1976; Humphrey，Snyder和Willis 1991; Leffingwell 1997; Willis等1998; Grady 1999; Shull等2002; Boehm和Turner 2004）。
通常，原理是找到尽可能接近引入错误的错误。 缺陷在软件食物链中保留的时间越长，则对链条的影响越大。 由于需求是首先完成的，因此需求缺陷可能会在系统中存在更长的时间，并且价格更高。 插入上游软件的缺陷也比插入下游的缺陷具有更广泛的影响。 这也使早期缺陷更加昂贵。
当我们拥有更好的开发工具并且许多团队已经从重量级顺序瀑布式开发转向轻量级迭代，增量式开发方法时，有关此数据的准确性和完整性 ， 我们可以依赖它的程度以及今天的相关性存在争议。 。
扁平化代码更改的成本
游戏规则应随着迭代和增量开发而改变-因为它们必须如此。
Boehm早在1980年代就意识到，如果我们提前考虑风险并使用他所谓的Spiral Model （ 螺旋模型 ）而不是试图定义，逐步设计和构建软件，就可以及早发现更多错误（从而降低开发成本）。按照瀑布顺序设计和构建软件。
在更现代，更轻松的敏捷开发方法背后也有同样的想法。 肯特·贝克（Kent Beck）在《 极限编程说明》 （第1版，而不是第2版）中指出，将变更成本降至最低是“极限编程”的目标之一，而扁平化的变更成本曲线是“ XP的技术前提”：
在某些情况下，随着时间的推移，软件更改成本的指数级增长可以被抵消。 如果我们能使曲线变平，关于最佳软件开发方法的旧假设将不再成立……
您将在流程中尽可能晚地做出重大决定，以减少做出决定的成本，并最大可能地做出正确的决定。 您只会实现您必须执行的操作，以希望您对明天的期望不会实现。 您只会在设计元素简化现有代码或使编写下一部分代码更加简单时才将它们引入设计中。
重要的是要了解Beck并不是说XP的变化曲线是平坦的 。 他说，如果团队为此努力，并利用XP中的关键实践和原则，则可以降低这些成本，例如：
- 简单设计，执行最简单的工作 ，并尽可能推迟设计决策（ YAGNI ），以使设计易于理解和更改
- 连续，规范的重构，以使代码易于理解和更改
- 测试优先开发 –预先编写自动化测试以立即捕获编码错误，并建立测试安全网以在将来捕获错误
- 开发人员与客户密切不断地合作，以确认他们对构建和配对所需的理解，以设计解决方案并解决问题，并尽早发现错误和误解
- 依赖于工作软件而不是文档，以最大程度地减少每次更改所需的文书工作量（编写代码，而不是规范）
- 团队不断迭代地工作的经验–人们以这种方式工作和思考的次数越多，他们就会越好。
尽管没有任何研究支持这些论断，但所有这些都说得通，听起来很正确，这就是为什么贝克放弃了XP版本第二版中有关变化曲线的讨论的原因 。 但是到那时，变更可能与敏捷开发保持一致的想法已经为许多人所接受。
反馈的重要性
Scott Amber同意可以在敏捷开发中使成本曲线趋于平坦 ，这不是因为简单设计，而是因为对于迭代式增量开发至关重要的反馈回路 。 敏捷方法优化了团队内部的反馈，开发人员之间以及与客户紧密合作，并依靠持续的面对面交流。 遵循测试优先开发，结对编程和持续集成等技术实践，使这些反馈循环更加紧密。
但是真正重要的是从使用该系统的人员那里获得反馈–只有这样，您才能知道自己是否正确或错过了什么。 设计和构建某些东西并从真实用户那里获得反馈所需的时间越长，将工作软件交付真正的客户手中所需的时间和工作就越多，那么您的变更成本实际上就越高。
优化和简化此反馈循环是推动精益创业方法发展的动力：定义最小可行产品 （几乎无法完成工作），尽快将其发布给客户，然后通过以下方式响应用户反馈持续部署和A / B测试技术，直到您找到客户真正想要的。
即使是零钱仍然很昂贵
即使您竭尽所能来优化这些反馈循环并最大程度地减少开销，但这仍然并不意味着更改会变得便宜。 如果您在此过程中犯了太多错误，那么快就不够好。
邮政卫生专员以粉刷房屋为例 ：假设您每次粉刷房屋的成本为1,000美元，而不论粉刷为蓝色，红色还是白色。 变更成本是固定的。 但是，如果您必须先将其涂成蓝色，然后再涂成红色，然后再涂成白色，然后每个人都感到高兴，那您就是在浪费时间和金钱。
“无论改变的成本有多昂贵或有多少变化，所做的更改越少，结果将变得越便宜，越快……规划不是一个四个字母的词。” [但是，我想指出的是“计划”是]。
在规划和设计上花太多时间是浪费。 但是，如果没有花足够的时间在创建它之前先弄清楚您应该构建什么以及应该如何构建它，并且不小心谨慎地构建它，那也是一种浪费。
随着时间的推移，变更变得越来越昂贵
您还必须接受变更的增量成本将在系统的整个生命周期内增加，尤其是在使用系统之后。 这不仅是技术债务问题 。 使用该系统的人越多，如果您弄错了变更，可能会受到变更影响的人越多，您就必须越谨慎，这意味着您需要花费更多的时间来计划和沟通变更，构建和测试流程。 -back功能，并使用Canary Releases和Dark Launching缓慢推出变更-这增加了成本并延迟了获得反馈的时间。
您还需要了解和处理更多的操作依赖性，还需要更改或修正更多的数据，从而使更改更加困难和昂贵。 如果您做正确的事，组建一个好的团队并负责任地管理技术债务，那么这些费用应该在系统的整个生命周期中缓慢增加–如果您不这样做，则指数变化曲线将会开始。
真正的变更成本是多少？
变更的实际成本是成指数的还是平坦的？ 真相介于两者之间。
没有理由进行软件更改的成本必须与30年前一样高。 今天，我们可以用更好的工具和更好，更便宜的软件开发方式来做得更好。 最小化变更成本的关键似乎是：
- 尽快将软件交付客户。 我不相信任何组织确实需要每天进行10-50至100倍的软件更改 ，但是您也不想等待数月或数年的反馈。 减少交付，但增加交付频率 。 而且，由于您将更频繁地交付，因此有必要建立一个持续交付管道，以便您可以高效，自信地推出变更。 使用Lean Software Development和看板的思想来识别和消除浪费，并最大程度地缩短周期时间 。
- 我们知道，即使有很多前期规划和设计思想，我们也无法将所有事情都做好前期准备–这就是瀑布式谬误。 但是，重要的是不要在不需要时浪费时间和金钱。 在第一时间花足够的时间来了解需求和设计 ，以便至少在第一时间获得正确的解决方案，以后可以节省很多。
- 无论您是逐步进行迭代工作，还是按顺序进行工作，都应尽早发现错误，无论您是通过Test First Development和Pairing进行此操作，还是通过需求研讨会和代码复审来进行操作，这都适合您。
翻译自: https://www.javacodegeeks.com/2013/09/the-real-cost-of-change-in-software-development.html
软件变更成本