你既不应抱怨，
也不应谴责，
而应努力，
去改善你所看到的不足。
—— 列夫·托尔斯泰

大团队中的敏捷流程

敏捷流程最初是为小型团队设计的。为了使其适用于大型团队，必须对其进行调整。我们需要放大或制度化流程中的一些特性，以确保“敏捷宣言”所倡导的价值观和基本原则依然得到尊重。在大型团队中，某些原则需要特别支持，因为它们不像在小型团队中那样自然地发挥作用。例如，我们必须格外注意，即使团队成员分布在不同的子团队中，仍要保持互动与沟通。

让我们探讨一下为大型团队建立和实施敏捷流程的关键特征。我们不会关注每个子团队将采用的具体流程细节，因为每个子团队都是一个小团队，因此可以灵活运用各种敏捷方法。例如，一些子团队可能遵循极限编程（XP），而另一些则可能更倾向于使用Scrum。相反，我们将重点放在那些确保所有不同子团队协同一致、持续保持敏捷性的特殊流程上。

明确目标

我们可以尝试通过访谈大型团队成员来了解他们如何判断工作是否完成。可能会惊讶地发现，很少有人能给出一个基于实现项目目标的答案，而更多人只提到截止日期。这是因为软件团队成员总是非常关注截止时间，却往往忽视项目的使命。

为什么人们对自己目标如此模糊？因为团队规模太大，开发人员觉得不必关心整体目标，认为高层管理者会清楚。然而，令人意外的是，高层管理者也常常对目标缺乏清晰且一致的理解。他们只是专注于完成自己负责的小部分工作，而并不关心整个项目全局。

因此，我们必须确保所有项目成员都清楚地了解由使命声明定义的共同目标。否则，项目成员很可能无法团结协作，反而像在各自独立的项目中工作，而不是朝着同一个目标前进。

在试图激励所有人朝着共同目标努力时，我们可能会遇到类似作者曾经历的问题：

被任命为项目经理的人仅为此项目担任该职位。大家都知道，项目结束后，他将回到原来的岗位，那个岗位在组织层级中略低一些。因此，项目经理没有特别强烈的动力去完成项目也就不足为奇了。在这种情况下，我们能做的有限，只能忽略层级关系，直接与项目经理的上级进行沟通。

提供反馈

互动与沟通是所有敏捷流程的核心，但转向敏捷方法还需要在其他方面做出改变。其中之一是从线性（瀑布式）开发转向迭代、增量式开发。这会对常规开发实践产生巨大影响。例如，迭代增量的方法不允许软件在黑暗中开发，这是线性开发中有时会出现的情况：在明确需求后，项目团队就进入开发区域，与外界完全断开联系（尤其是客户）。只有到了截止日期，才被要求展示应用成果。在此之前，没有人期望系统已经可用。

在敏捷流程中，从开发团队到客户，所有人都被邀请对系统提供反馈，以帮助不断改进。但这并非早期频繁反馈的唯一好处。它还能进一步带来以下益处：

• 增强客户与项目之间的可靠性与信任；
• 提升团队对自己工作的信心，从而激发动力和工作满意度；
• 建立开发、集成，甚至生产与维护的稳定节奏；
• 评估架构设计；
• 更深入理解领域知识和需求；
• 通过尽早交付可用系统，防止客户最终收到一个完全失败的产品。

因此，让我们尽早让系统运行起来，以便能够持续获得反馈并从中受益。