敏捷继续风靡全球。来自 Standish Group Chaos Study 的最新报告提出了有趣的发现：基于敏捷原则的项目比基于瀑布式方法的传统项目具有显著更高的成功率。
在本文中，我将尝试描述一些促成敏捷团队展现出的这些高性能指标的因素。
敏捷成功率更高的原因是什么？
我参与过的几乎所有瀑布式项目都强烈倾向于规避风险。瀑布式项目通常有宏大的目标，并围绕这些目标进行组织。这意味着，大量的资源（资金和人力）被汇集并投入到严格控制的漏斗中。
一个瀑布式项目通常以以下内容开始：“听着，我们对这个新举措寄予厚望；我们聘请了优秀的专家，投入了大量资金以确保一切顺利进行。不容失败！”
然后，团队以认真的态度开始工作，并渴望展示早期成果，以证明这种潜在的风险投资是合理的。而且，通常情况下，工作从关注我们所说的“精确工作”开始。我们所说的精确工作是指对团队正在构建的软件产品的各个方面做出早期承诺。规范、基础设施、架构、设计，所有这些方面都在项目一开始就得到确定和巩固。一旦经过审查和签字，需求就会被冻结，团队就会匆忙编写代码。最终，代码完成了（通常经过数月的疯狂工作），然后是代码冻结，现在开始测试。
正是在这个阶段，当我们进入测试时，有趣的发现开始涌现。通常情况下，事实证明，早期、急切的承诺巩固了团队和产品基础设施，但最终却将整个项目逼到了一个众所周知的死角。迟来的（且不可避免的）失败付出了高昂的代价。
我刚才描述的过程通常被称为“过早优化”。
敏捷颠覆了上述方法。它拥抱风险，因为它认识到，即使我们尽力而为，风险也是无法避免的。敏捷侧重于早期反馈（使之成为极其早期的反馈）。敏捷摒弃了傲慢的“我们无所不知”的态度，转而采用谦逊的“我们在实践中学习”的方法。
因此，敏捷不是预先确定和巩固需求，而是拒绝冻结范围。恰恰相反，敏捷方法对任何范围蔓延都保持完全开放。换句话说，在敏捷项目中，不存在范围蔓延这种说法。
敏捷中的范围是通过响应反馈来管理的。但是如何征求宝贵的反馈呢？
反馈总是很难获得。每个人都很忙，没有人有时间主动提供反馈。而且，即使有人设法抽出时间提供反馈，通常也是本着“如果你没有什么积极的话要说，至少不要说任何负面的话”的精神提供的。因此，大多数主动提供的反馈最终都变成了不温不火的赞扬。
然而，我们更感兴趣的是找出真相。因此，征求有价值反馈的唯一可靠方法是失败。失败是一个伟大的激励因素。它使所有相关方都以紧迫感做出回应。
在敏捷中，我们重视频繁和早期的失败。我们希望尽早暴露任何重大风险。我们对残酷而诚实的批评持开放态度。
秉持这种态度，敏捷遵循持续集成 (CI) 方法。当我们构建解决方案时，我们必须尝试将组成部分与每次代码转换集成。每一步都伴随着集成测试。
瀑布式方法则恰恰相反。集成被留到最后一步，一旦其他一切都被过早地优化、巩固和测试。正是在最后阶段（集成）发现了重大风险。此时，通常为时已晚，无法成功处理损害。
如何经常且尽早地集成
瀑布式方法不如敏捷成功的原因似乎很清楚。但根本原因不一定归咎于管理软件开发项目的不负责任的方法。瀑布式方法并没有傲慢地拒绝早期和频繁的集成测试。每个人都希望能够尽早发现重大风险。问题在于无法集成尚未准备好进行测试的服务和组件。
随着项目的进展，我们更喜欢使用分而治之的方法。我们自然更喜欢通过并行完成尽可能多的事情来节省时间，而不是按顺序（一次一件）进行开发和构建。因此，我们将团队分成更小的单元，专门执行专门的任务。
然而，当这些专业团队工作时，他们意识到或正在发现各种依赖关系。然而，正如 Michael Nygard 在没有终点的架构中所说：“依赖关系的问题在于你无法依赖它们。”因此，项目开始放缓，因为它被各种无法用于集成测试的依赖关系所困扰。
敏捷方法消除了任何障碍，并允许自治团队继续开发活动，而无需等待任何人。这样，一旦团队开始迭代/冲刺，就可以开始集成测试。从这个意义上说，敏捷是 IT 组织向前迈出的一大步。
6 条评论