想象这样一个诱人的世界：所有项目都没有截止日期，一直继续到干系人认为已经交付了足够的价值。
在有些组织里，这就是现实。但在另一些组织中，团队则常常面对这样的困境：
- 固定时间项目：新的或改进的产品必须在指定的截止日期前交付。
- 固定范围项目：一系列的功能必须在产品交付前完成。
- 一切都固定或固定价格项目：产品交付的截止日期以及在此日期前必须完成的功能都已被定义好。
敏捷是依赖于环境的
当关键因素都在掌控之外时，有可能做到敏捷吗？我的观点是：在日期，范围，或两者都固定的情况下，团队可以是敏捷的。
敏捷是依赖于环境的，在车库中开发移动应用的三人团队，有可能比一个庞大的开发医疗相关硬件的分布式团队更加敏捷。
这取决于他们的环境。后者毫无疑问将被要求产出更多的文档，更严格地控制项目，或至少记录变更，以及做一些其他的可能削弱团队敏捷性的工作。
但这都没关系。
敏捷涵盖了非常广泛的活动，这好比维持健康。你可以更健康或更不健康，同样的，团队也可以更敏捷或更不敏捷。
举个例子，我最近进行了年度体检，医生告诉我，我的总胆固醇没有问题，实际上还挺好的。除了其中一个子项——血液中的甘油三酯数量略高了一些。我问医生我能做些什么来改善这个数值？他的首要建议之一是换掉我的父母。
既然我无法做到这一点，我的目标就是在我所在的环境下尽可能的保持健康。同样，敏捷团队也应该努力在所处的环境下，尽可能的保持敏捷。
环境可能是由团队之外决定的
有些团队面临的情况是，老板，客户，或顾客告知他们，必须在一个指定日期前完成一定数量的功能，甚至是以固定的价格。
这些项目当然并不如理想中敏捷，但在这样的条件下，它们依旧可以是敏捷的。
如果没有合同保证交付日期或范围，实施项目的团队是否能更成功，更有可能超越客户的预期？非常可能。但他们所处的环境并非如此，我们无法期望现实的约束消失。
固定价格项目与敏捷宣言
让我们看看固定价格项目如何与敏捷宣言的价值观保持一致。
个体与互动高于流程与工具
首先：个体与互动高于流程与工具。固定项目的范围或交付日期并不意味着不强调敏捷赋予个体与互动的重要性。
伟大的产品依旧能被善于沟通的伟大团队所创造。也许有部分沟通将受制于合同，但并不代表团队不能比合同所要求的更有效或更频繁地进行沟通。
工作的软件高于详尽的文档
工作的软件高于详尽的文档，这是敏捷宣言的第二条。合同式开发项目几乎不可避免地比非合同项目需要产出更多的文档。
然而，在运行良好的固定范围和固定日期项目中，一个共同特征是，团队频繁地向干系人演示并交付可用的软件。
客户合作高于合同谈判
客户合作高于合同谈判，这是敏捷宣言中听起来和固定日期固定范围项目最不相符的一条。但这并不是一定的。即使有合同定义了客户与供应商间的关系，团队始终可以选择与客户良好协作。
即便是最详尽的合同，也会有一定的差距——书面内容的差距，实际需求的差距，对合同解读的差距。寻求用合作的心态去填补这些差距。
响应变化高于遵循计划
敏捷宣言的最后一项价值观，响应变化高于遵循计划，描述了一个合作精神至关重要的场景。
团队和干系人如何应对所发生的变化——或一开始不知道的信息——往往是一个项目被视作成功或是失败的重要因素。我们希望建立和遵循一个变更管理过程，和对于敏捷的重要性一样，对于固定日期和固定范围项目的成功，同样至关重要。
敏捷宣言的原则
本图片来自@虎头锤
敏捷宣言同时包含了十二条原则来支撑四条价值观，我认为这十二条原则的每一条都是对固定日期和固定范围项目的补充。其中有几条值得单独一提。
“我们最重要的目标，是通过及早和持续不断地交付有价值的软件使客户满意。” 这作为敏捷宣言的第一条原则，是有道理的。当在固定日期或固定范围项目中工作时，寻求机会交付足够的价值，使得客户可能不需要他们最初预期的一切。
在我大学刚毕业时，有一份工作是在一家非常大的计算机咨询公司任职。在那里工作几个月后，我记得和我老板，同时也是公司合伙人之一，共进午餐时，他告诉我，我的工作是尽可能的使我所在的项目范围扩大。他说，这始终是我要考虑的第一要务，甚至比成功完成项目还要重要。
不用说，我找到一家对与客户合作更有兴趣的公司后，就立马离开了这家公司。
与其想方设法扩大项目范围，不如把精力放在打造一个功能恰好足够，没有冗余的产品，从而尽早完成项目。
欣然面对需求变化
我认为宣言中最重要的原则之一是，“欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程，掌控变化。”
我们知道，变化时有发生。我们可能需要说服我们的老板，客户，和顾客接受变化的无可避免，但这是做得到的。
敏捷宣言的另外十条原则，包括强调简洁，激发个体的斗志，面对面沟通，稳定的节奏，自组织，反思，相互合作，以及频繁的交付，也都支持固定日期和范围的项目。
固定价格、范围、日期的项目敏捷吗？
所以，这些项目是否敏捷？
是的，它们可以敏捷。
一个团队的目标应当是在所处的工作环境下尽可能地敏捷。所有项目都有一定的约束。一个项目有七名成员，且人数不能增加，那么团队需要在这个条件下敏捷。一个项目被告知需要在某个日期前交付，团队也需要在这个背景下敏捷。
把约束看作是定义了一个解析空间，团队需要在这个空间中运作并找到答案。当然，如果给团队施加了过多的限制，即使敏捷也无法帮助团队找到解决方案。
但若是一些更易于管理的约束，还是给团队留下了敏捷的空间。他们敏捷的程度比不上没有约束的团队，但依旧可以在现有的环境下敏捷。
你的想法如何？
你的观点是什么？固定价格、日期、范围的项目可以敏捷吗？你是否曾在实施这些类型项目的敏捷团队中工作？欢迎分享你的想法。
关于作者:
Mike Cohn : 帮助企业适应和改进敏捷过程及技术，以建立极致高效团队的专家。著有《用户故事与敏捷方法》，《敏捷估算与规划》，《Scrum敏捷软件开发》以及视频课程《更好的用户故事》。Mike是敏捷联盟及Scrum联盟创始人之一，可以通过邮箱 hello@mountaingoatsoftware.com 与他取得联系。如果你想在敏捷方法取得成功，也可以请Mike每周给你一个小建议。
关于译者:
Scrum中文网翻译组：Scrum中文网是全球第一个Scrum中文网站，中国最早的Scrum和敏捷教育及推广机构，也是国际Scrum联盟（ScrumAlliance）官方授权教育机构和大规模敏捷SAFe官方机构SAI在中国的授权合作伙伴。Scrum中文网是中国敏捷教练的摇篮，启蒙和培养了数万名敏捷专业人士，帮助数百家知名企业成功转型敏捷。
原文链接：
https://www.mountaingoatsoftware.com/blog/are-fixed-price-projects-agile
