栏目介绍

本栏目为 EXIN Agile Club 的子栏目。栏目目的是翻译 Mike Cohn 的高质量博客，让大师的智慧可以影响更多的人。翻译已经得到 Mike Cohn 的授权。

如果您有相关意见、建议，可以在评论区给我们留言，我们将会认真对待每一条留言消息。

译者有话说

人人都希望自己的项目没有约束，然而没有约束的项目就好像天马——每个人都听过，但没有人见过。即使是雷神山、火神山医院这种举国皆知的项目，依然会受限于时间的约束。当敏捷作为一种项目管理方法存在时，必然也要受限于项目的三重约束。那么当敏捷项目面临此类约束时，我们还能愉快的敏捷么？

想象一下这样一个令人神往的情景：开发中的项目没有规定截止日期，并且这种状态居然可以一直持续到干系人认为已经交付了足够的价值为止。

这种做法在某些组织中是真实存在的；但在更普遍的其他组织中，团队却不得不面临着以下的现实情形：

固定日期项目，新产品或改进的产品都必须在指定的截止日期前交付。

固定范围项目，一系列的功能都必须在产品交付前完成。

一切都固定（日期、范围）或固定价格的项目，产品交付的截止日期以及在此日期前所必须完成的功能都已被定义好。

1 敏捷依赖于场景

当项目开发中的关键要素不受团队掌控时，还可以实施敏捷么？在我看来是可以的：当日期、范围，或两者都被固定时，团队依旧可以保持敏捷。

能否实施敏捷取决于场景。在车库里开发移动APP的三人团队，会比一个正在构建医疗监管设施的大型分布式开发团队更容易实施敏捷。

由于他们的场景不同，后一个项目无疑需要编写更多的项目文档；还被设置了更严格的开发控制流程，或者至少需要记录下来所有的变更事件；除此之外还有其他一些会削弱团队敏捷性的事情。

但这些都无所谓。

实施敏捷就像养生保健一样，是一个覆盖面十分广泛的行为。如同你的身体可以保持健康或不健康，同理团队也可以保持敏捷或不敏捷。

举个例子，我最近刚做完年度体检。医生说，我的总胆固醇指数很正常。事实上对我来说这确实是一个好消息，除了一个子项——我血液中甘油三酯有点高。我咨询我的医生我需要注意什么才能改善这个指数，他首要建议之一就是重新选一次父母吧。

时光倒转重新投胎，肯定做不到啊。于是我的目标就是在所处的环境中尽可能的让我的身体保持健康，敏捷团队也一样，尽一切可能在当前场景中保持敏捷吧。

2 场景是由团队之外的人所定义

有些团队面临的情形是，老板，客户，或顾客要求他们，必须在指定日期前完成确定数量的功能，甚至是在固定价格的前提下。

这些项目当然并不如理想中敏捷，但即使在这样的条件下，它们依旧是可以敏捷的。

如果没有合同用以约束交付日期、范围，实施项目的团队是否能更成功，更有可能超越客户的预期？非常有可能。但他们所处的环境并非如此，我们无法寄希望于现实的约束会嗖的一声自己消失。

3 固定成本项目与敏捷宣言

让我们看看固定价格项目如何才能跟敏捷宣言的价值观保持一致。

个体和互动高于流程和工具

首先：个体和互动高于流程和工具。固定项目的开发规模或交付日期，并不意味着不强调敏捷赋予的个体和互动的重要性。

优质的产品仍然能够被善于沟通的卓越团队所创造。也许合同中描述了应采用的交流方式，但团队同样可以采用比合同所规定的更有效或更频繁地进行沟通。

工作的软件高于详尽的文档

工作的软件高于详尽的文档，这是敏捷宣言的第二条。合同式开发项目几乎不可避免地比非合同项目需要产出更多的文档。

然而，在运行良好的固定范围和固定日期项目中，一个共同特征是，团队频繁地向利益相关者演示并交付可用的软件。

客户合作高于合同谈判

客户合作高于合同谈判，这是敏捷宣言中听起来跟固定日期或固定范围的项目最不协调的一条。但这并不尽然。即使有合同定义了客户与供应商间的关系，团队也始终可以选择与客户友好协作。

此外，即便是最详尽的合同，也会有一定的差距——书面内容的差距，实际需求的差距，对合同解读的差距。团队要寻求用合作的心态去弥补这些差距。

响应变化高于遵循计划

敏捷宣言的最后一项价值观，响应变化高于遵循计划，描述了合作关系中的一个至关重要的场景。

团队和利益相关者如何应对所发生的变化——或者是一开始不清楚的信息——往往是决定项目成败的重要因素。我们希望建立和遵循一个变更管理过程，向对敏捷的重要性一样，用来推动固定日期和固定范围项目的成功。

4 敏捷宣言的原则

敏捷宣言同时包含了十二项原则来作为四条价值观的有力支撑，我认为这十二项原则的每一条都是对固定日期和固定规模项目的补充。其中有几条值得单独拿出来说一说。

“我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。”这作为敏捷宣言的第一条原则，是有理由的。当在固定日期或固定范围的项目中，寻找时机向客户交付足够多的价值，这时客户有可能会意识到，他们可能并不需要最初预期的待交付内容。

在我大学刚毕业时，有一份工作是在一家非常大的计算机咨询公司任职。在那里工作几个月后，我记得和我老板，也是公司合伙人之一，共进午餐时，他告诉我，我的工作是尽可能的使我所在的项目扩大规模。他说这是他最关系的事情，甚至比成功完成项目还要重要。

道不同不相为谋，于是乎当我找到一家更重视客户合作的公司后，就立马炒了这家公司。

与其想方设法扩大项目规模，莫不如把精力更多放在打造一个功能恰好，没有冗余的产品，从而尽早完成项目。

欣然面对需求变化

我认为宣言中最重要的原则之一是，“欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程，掌控变化。”

我们知道，变化时有发生。我们需要让我们的老板，客户，和顾客相信，变化无可避免，我们需要坦然面对，欣然接受变化。

敏捷宣言的另外十条原则，包括强调简洁，激发个体的斗志，面对面沟通，稳定的节奏，自组织，反思，相互合作，以及频繁的交付，也都可对固定日期和范围项目启到支持作用。

5 固定成本、范围和期限的项目

是否可以敏捷？

那么，这些类型的项目能实施敏捷吗？

是的，答案是可以。

所有的项目都有约束，团队的目标是在有约束的环境下工作也尽可能敏捷。团队只有七个人并且团队无法增员的项目需要在那个场景中保持敏捷。一个被告知必须在指定日期之前交付项目的团队需要在这个环境中保持敏捷。

可以将约束视为这么一种定义，约束就是团队在其中运行解决方案的道场。当然，有一点，如果你对一个团队施加了过多的限制，即使是敏捷也无力帮助团队成员找到解决方案。

但是，一组易于管理的约束仍然为团队的敏捷性留下了足够的空间。如果没有这些限制，他们不会像理想中的团队那么敏捷，但他们仍然可以在这种背景下保持敏捷。

元芳，你怎么看？

你认为固定成本、期限和范围的项目可以敏捷么？你是否有过作为敏捷团队的一员来交付这种类型的项目经验？请在下面的评论区分享你的想法。

以上文章，来自【敏捷传习录】