概述

唯有通过改变，才能保留价值。
— 理查德·洛文塔尔

在探讨大型项目中的敏捷原则之前，我们先回顾一下敏捷流程的基本原理，并识别那些伪装成敏捷流程的实际做法。

敏捷流程的主要特征之一是能够根据项目需求进行调整。最佳实践是通过开放而真诚的沟通，明确项目的需求以及团队成员的需求。

当人们初次接触敏捷流程时，最初的反应往往是对其适用性的怀疑。通常我们会发现，人们倾向于引用相同的原因来说明为什么认为敏捷流程无法奏效。

敏捷方法的目标

敏捷流程承诺能够灵活应对不断变化的需求，从而在任何时刻为客户提供最高的业务价值。因此，执行流程的人始终处于核心位置。当《敏捷宣言》中提到“个体与互动高于流程与工具”时，其本质是在为人的福祉而质疑和优化流程。由此引发的问题是：如果团队人数不是十几个，而是接近一百人，人是否还能保持在流程的中心？

敏捷方法的目标是确保在软件开发过程中尽早发现并消除风险。将系统划分为多个部分，并对这些部分进行迭代开发，可以降低系统的复杂性。这种演进式的方法能够在早期就产生可交付成果，提供反馈，使我们能够立即采取必要的纠正措施。

采用这种迭代且增量式的开发方式，是所有敏捷流程的基础，使我们能够对开发过程中可能出现的各种风险获得早期反馈。只有通过这种早期反馈，我们才能及时应对这些风险。

短周期且时间盒化的开发过程能带来频繁的反馈。时间盒意味着每个开发周期的时间范围是固定的。如果周期不够短，相应的反馈就会延迟过久；如果开发周期没有时间盒限制，则很可能超出预期时间，导致反馈再次被推迟。然而，真正关键的并非时间盒本身，而是开发周期对变化的响应能力，而时间盒化的方式恰好简化了这一响应机制。

敏捷开发周期中的项目参数

规划敏捷开发周期时，始终假设以下项目参数是固定的：

• 时间
• 资源
• 质量

因此，只剩下唯一一个可变的参数：范围。这意味着范围是可以变化的——在一个开发周期结束时，发布的内容可能比原计划包含更多或更少的功能。但周期会在预定时间结束，所需资源提前确定，最终产品也必须满足既定的质量标准。

众所周知的阶段——分析、设计、实现和测试——在迭代、增量式流程中依然存在。但在敏捷开发中，这些阶段并非按顺序执行，而是并行进行。因此，测试不能脱离实现独立进行，设计也不能与实现割裂，因为在编码或测试过程中，我们可能会发现新的信息，直接影响系统的设计。这使得整个开发过程具备持续的灵活性，能够在全过程中不断优化设计。

正如#key# 詹姆斯·海史密斯 #key# 所言（《敏捷宣言》签署人之一，多本软件开发书籍作者）：

虽然工作流模式适用于某些场景——例如处理汽车保险理赔——但它并不适用于产品开发。许多产品开发活动是并发进行的，部分完成后再逐步完善，这才是常态。

尽管敏捷开发具有快速变化和高度灵活性的特点，但协调各项活动仍然至关重要。例如，绝不要在实现新功能的同时试图改进现有系统的设计。

适应性的重要性

尽管敏捷流程在很多情况下被视为万能良方，但它们往往需要根据项目的具体需求进行调整。一个定义好的敏捷流程应被视为起点，之后必须加以调整。因此，流程的适应性是成功实施敏捷的关键。项目成员无需去适应流程，相反，流程应当服务于人。因此，重要的是不应“采纳”流程，而应“适应”流程。

适应基于对流程的定期反思。这类反思（或称回顾）通常包含两个层面：

• 第一层面是回顾项目当前状态，帮助识别阻碍进展的障碍；
• 第二层面，即元层面，是对当前流程支持效果的反思。

在元层面，团队中的每个人共同参与塑造流程，使其尽可能更好地服务于团队。当然，团队越大，流程的调整就越困难，因为人数越多，关于流程的意见越多，提出的要求也就越多。然而，目前对于如何为大型团队建立和调整敏捷流程，仍缺乏足够的指导。