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