上下文与利益相关者

我们相信我们创造了体验，
但正是这些体验塑造了我们。
——尤金·伊翁尼斯科

为了更清晰地说明本课程中讨论的各类议题，本章将介绍一个大型项目在决定采用敏捷流程方面的实际案例。这实际上是一份经验总结报告，整合了此前所描述的各项实践。

项目历程

该项目最初约有200名成员，已持续开发两年之久。然而，客户突然意识到：根本没有可用的可运行软件，甚至无法预估何时能交付。因此，客户决定终止该项目。

负责开发的大型公司试图说服客户给予项目第二次机会。开发方承诺此次将彻底改变做法。这种承诺极具说服力，最终客户同意（主要原因是客户同时也是该公司的联合所有者），但附加了严格的监管条件。尽管大多数人对这一决定感到高兴，但开发团队仍缺乏动力，因为他们刚刚目睹了两年的努力付诸东流。然而，在这次重启之后，项目对开发公司而言变得至关重要。

由于已有数百万美元投入，客户对这次尝试能否成功持高度怀疑态度。因此，他们决定不承诺全程资金支持，而是每三个月根据项目进展评估一次是否继续提供财务支持。项目重启之初，所有人都认为只要第一个周期（即前三个月）取得成功，客户就会承诺后续资金。但客户却因前次失败的经历，坚持维持为期三个月的试用期。是否继续资助，将完全取决于每个发布周期的结果。幸运的是，团队持续每三个月交付一项新功能。随着系统逐步成型，客户的信心也重新建立起来。

敏捷适用性

在本次尝试中，建立敏捷流程相对容易，因为经历过一次失败后，没有人愿意再看到同样的结局。之前的失败使公司在财务和生产力方面已达到极限，这种压力反而促使所有人必须快速决策。整个公司都迫切希望这次能够成功，因此每当有人提出潜在的重大障碍时，解决问题或消除风险比第一次尝试时更加高效。即便是公司内部的官僚规则，也往往能以务实方式灵活处理，无需严格遵循层级流程，因为项目被明确标记为“使命级”。

客户

客户本身具有挑战性，因为它并非单一个体，而是一个由多个成员组成的群体。更复杂的是，这群客户之间存在竞争关系，始终无法达成统一意见。例如，客户A几乎从不认同客户B的建议。尽管如此，这个客户群体仍需合作，因为他们最近刚刚合并，现在同属一家控股公司。而这家控股公司，恰好也是开发公司的所有者。

因此，开发公司本质上是客户群体的一个子公司——典型的软件外包团队，主要任务是为公司其他部门开发软件。但显然，母公司并不局限于向自己的软件团队下达指令，还必须与其他软件团队展开竞争。更糟糕的是，部分客户原本就不看好这个项目，因为在合并之前，他们已利用自身开发能力启动了一个类似方向的项目。

客户与最终用户之间的矛盾

客户群体指定了正式代表，但这些代表时间有限，难以胜任工作。此外，由于缺乏共同文化背景，他们常常无法准确把握每位客户的真实需求。

更重要的是，这些代表距离最终用户的日常使用场景太远，无法真正理解客户的核心诉求（这是客户代表与最终用户之间典型差异的体现）。这一问题一直持续到第二次发布后，部分最终用户有机会亲自体验并操作系统为止。他们对系统的反应极为积极，于是主动（也应我们的请求）在我们办公地点设立了客户办公室，确保有人随时可以回答问题、测试系统并提供反馈。当这种情况发生后，最终用户才真正成为推动项目前进的关键力量。然而，多次出现的情况是，最终用户与代表之间在需求上存在分歧。大多数情况下，问题在于：最终用户并未提出代表所声称的那些复杂需求。这也进一步凸显了最终用户反馈的价值。

团队

项目高峰期，整个团队共170人，其中110人为软件开发人员。在这110人中，有35位是外部顾问，受合同约束。幸运的是，核心知识仍然掌握在内部员工手中。

内部团队构成

项目中不乏技术娴熟的人才，但他们对第一次尝试所用的技术更为熟悉，而对第二次尝试所采用的技术则相对陌生。此外，团队中几乎没有具备丰富项目经验的成员。许多开发人员刚从大学毕业，仅有一次项目经历——即最初的那次尝试。

外部团队构成

部分软件开发工作外包给了外部团队，其中一个团队与主项目团队同地办公，几乎看不出其外包身份。其余大部分外包团队也接受了敏捷开发模式的转变，因此与内部团队保持一致的交付节奏。在谈判初期，曾就外包合同的修改进行过多次讨论。但最终，通过双方的共识而非合同条款，确保了对外包团队的敏捷参与。