用于软件开发的敏捷方法可以对 IT 行业产生积极影响。 可以通过多种方式衡量采用敏捷方法的结果。 更快的软件变更请求周转、更少的错误、团队绩效和瓶颈的量化测量都是成功实施敏捷的反映。 为了成功衡量敏捷的影响，组织需要比较与敏捷前和敏捷后开发相关的各种指标。 敏捷的真正影响不能仅通过收入的增加或修复的错误数量的增加来衡量。 需要考虑几个内部参数以了解真正的影响。 （有关敏捷开发的更多信息，请参阅敏捷软件开发 101。）
为什么选择敏捷 IT？
IT 行业一直倾向于敏捷实践，主要是因为软件开发的瀑布模型的限制。 通常，据观察，IT 公司无法响应不断变化的客户需求或市场情况，也无法通过软件开发的瀑布模型来降低成本。 即使我们抵消了这种对敏捷方法的压倒性倾向，并认为一些兴奋只是炒作，但仍有很多经验反馈反对瀑布模型。
简而言之，瀑布模型是一种软件开发模型，其中工作以顺序方式完成——一个阶段接一个阶段。 该模型有五个阶段：需求、设计、实施、验证和维护。 通常，在一个阶段完成后，即使不是不可能，也很难对较早的阶段进行更改。 因此，假设要求几乎是固定的。 与敏捷模型的主要区别在于假设需求不会发生变化。 敏捷假设业务情况会发生变化，需求也会发生变化。 因此，软件在冲刺中以较小的块交付，而在瀑布模型中，第一次交付或发布是在很长一段时间后进行的。 （有关开发的更多信息，请参阅 Apache Spark 如何帮助快速应用程序开发。）
对瀑布模型最显着的批评是它假定需求不会发生变化。 这个假设是有缺陷的，也是不现实的。 例如，2001 年，对英国 1,027 个 IT 项目的研究表明，这种假设是 IT 项目失败的最大单一原因。
在另一个例子中，《敏捷和迭代开发：经理指南》一书的作者 Craig Larman 指出美国国防部 (DoD) 使用瀑布模型执行的许多项目如何未能成功 实现他们的目标。 在整个 1980 年代和 90 年代，根据 DoD STD 2167 中发布的标准，DoD 被要求为其软件开发项目使用瀑布模型。令人震惊的统计数据显示，这些软件项目中有 75% 从未使用过。 继这份报告之后，著名软件工程专家 Frederick Brooks 博士发起了一个工作组。 工作组发表了一份报告，评论道“DoD STD 2167 同样需要彻底改革以反映现代最佳实践。 进化发展在技术上是最好的，它可以节省时间和金钱。”
瀑布模型的以下四个假设在现实场景中失败了：
给出的要求定义合理，因此不会发生重大变化。
即使需求在开发阶段发生变化，它们也足够小以适应开发周期。
软件交付后发生的系统集成将按计划进行。
软件创新和创新所需的努力将按照计划和可预测的时间表进行。
敏捷方法论如何解决瀑布模型的问题？
敏捷方法从根本上不同于瀑布模型，从它的假设中可以清楚地看出这一点：
没有人，即使是客户，也不能完全了解或理解这些要求。 不能保证要求不会改变。
需求变更可能不小且易于管理。 事实上，它们会以各种尺寸出现，并且会不断出现。 因此，软件将以小增量交付以跟踪更改。
敏捷如何影响 IT 行业？
很多地方都在采用敏捷，而很多公司都在制定采用敏捷的计划。 尽管敏捷确实对 IT 行业进行了根本性的改变，但事实和数据仍然有点难以获得。 但是可以通过下面给出的英国电信 (BT) 的案例研究来理解敏捷的影响。
BT 转向敏捷实践的原因
早在 2004 年，BT 就开始在其软件开发实践中遇到一些问题。BT 开发了许多软件项目，既有简单的也有复杂的。 许多软件项目无法在约定的时间范围内开发出高质量的产品。 英国电信发现问题的根源在于瀑布模型。 因此，加强瀑布模型并没有帮助。 问题的主要原因如下：
需求管理不善
提出的要求太多，无法在有限的时间内完成。
许多需求与业务需求无关。
几乎所有（如果不是所有）需求都被分配了高优先级状态。
这些需求代表了当前的业务需求，没有着眼于未来的场景。 这留下了未来软件更改的可能性。
糟糕的软件设计
鉴于需求数量巨大，设计师花费了太多时间试图弄清楚需求的含义。 留给实际设计的时间不多了。
需求分析师转移到其他任务，带着不成文的隐性知识。
以上两个因素导致设计不佳。 设计师仍然必须按照最初的时间表交付。
发展限制
由于软件设计有缺陷，编码仓促且质量差。 开发人员会意识到糟糕的软件设计会导致糟糕的代码，但仍然必须按约定的时间表交付。 由于没有运行单元测试和回归测试，在集成过程中会报告很多错误。
到部署软件时，客户注意到需求已经发生变化，业务场景也发生了变化。 该软件也有很多问题。 实际上，软件开发的全部努力现在都被认为是浪费。
针对上述问题，BT做了什么？
BT 意识到加强瀑布模型并不是解决问题的方法。 它需要一种新方法。 因此，它决定实施敏捷方法。 根据新方法，决定了以下事项：
BT 现在可以在 90 天的周期内交付可用的软件，而不是 12 个月的开发周期。 当时的想法是专注于一两个业务问题，并以在 90 天内交付软件解决方案为目标。 这个周期的开始以不同利益相关者之间的激烈讨论为标志，以便清楚地识别、分析和优先考虑需求。
目标是提供清晰、有形的商业价值。 内部客户承受着提供明确要求的压力。 因此，用户故事不是模糊的目标，而是具有明确的验收标准。
将交付的软件将经过全面测试和记录。 该软件将经过频繁的集成测试以预先发现问题。
借助敏捷方法，BT 可以更轻松地适应不断变化的需求或业务情况。 代码质量得到改善，最后一刻的基本错误得到解决。
结论
敏捷尽管具有所有优势和围绕它的炒作，但仍处于其潜力未被充分发挥的阶段。 这是因为许多组织正在定制方法以修改其原始原则。 因此，瀑布模型在某些情况下卷土重来。 虽然定制将继续，但重要的是要保留敏捷的基本原则。 许多组织声称完全敏捷，但要成为真正的敏捷公司，他们还有一段路要走。
