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