固定价格项目能否敏捷？

关注

发布于: 3 小时前

我们知道敏捷项目和传统项目管理不同的地方是，传统项目的项目管理铁三角是固定的：成本，项目时间，项目范围。而敏捷项目只有团队成本是固定的，范围和时间都是可以调整的，调整的依据是是否交付了高质量的用户的价值。越是参与实际的项目越能感觉到传统项目管理方式在软件开发这种知识型工作中的阻力.甲方希望能够在项目前期固定一切，这样才有一切尽在掌握的安全感。而这种 Control 却让本应该充满创意的开发工作变得僵化，大部分项目以“不是客户想要的”结局落幕。作为参与项目中的我们每个人其实是很失落的。最近看了一篇 Mike Cohn 的关于固定价格项目的如何敏捷的文章，有一些感触，今天总结一下，希望对小伙伴们有帮助。文末可以找到原文链接。

有约束就无法敏捷了吗？

很多时候我自己也会在想，实施敏捷有很多条件，这些条件构建出了一个理想环境。很多成功的敏捷案例都是恰好在这么一个合理的环境下孕育出来的。现实是残酷的。很难达到敏捷宣言所描述的那个乌托邦。不过这篇文章却告诉我们，其实任何有约束的环境中依然有机会敏捷，敏捷也是对环境有依赖的。作者举了一个自己的例子：作者最近做了年度体检。他的医生告诉他他的总胆固醇没问题。事实上，这很好。除了胆固醇中的一种成分外，他血液中的甘油三酯含量过高。他问医生能做些什么来改善这个值。医生最重要的建议之一就是改变作者的父母。哈哈，这显然做不到，看来是遗传因素。所以作者的目标就是在他所处的环境中尽可能地保持健康。

从上面的例子可以看出，生活中我们有很多无法选择的约束条件，我们依然有自己的选择。所以就算在一个固定时间固定范围的项目中，如果一个团队觉得应该用敏捷方式工作，那么一样可以努力在环境允许的范围内保持敏捷。

固定总价合同和敏捷宣言的关系

作者用固定总价合同项目和敏捷宣言做了比较。之前我默认的认知觉得他们是水火不相容的存在。不过通过作者的对比其实一些“不可能”可能只是我们自己的思想在作怪罢了。尝试把 No 说成 Yes And，并找到可能的阻碍消除他，真的会带来不同的视角哦。

“个体与交互高于合同和谈判”：就算项目范围和交付日期是固定的，沟通依然是重要的，为什么我们会默认觉得传统项目就不重视沟通，因为有了合同约束在前吗？合同可能规定了沟通方式和时间，但并没有说不让用更频繁地和合理地沟通形式。客户也不都是黑脸吝啬不好沟通是不？

“可工作的软件高于详尽的文档”：固定范围和日期的项目肯定需要更多的文档。这可能是合同或者项目合规需要。不过这不影响频繁的演示 demo 给客户。

“客户合作高于合同谈判”：这句话感觉和实际项目最不相符，我们印象中的项目乙方永远都是孙子的感觉，甲方不顾你的死活尽情的压榨。作者提出真的没有改变的机会吗？合同里面会有很多事无巨细的描述，用来保护甲方利益，不过真的天衣无缝吗？通常还是会有很多空白。这些空白包括需求空白，风险空白，业务理解的空白等等。客户合作能填补这些空白，让客户知道我们都是为了最终的目标，一个能够解决他们实际需要的有价值的产品，而不是一场你死我活的交易。

“响应变化高于遵循计划”：传统项目管理中对变更管理是恐惧的，因为有变更就会带来成本的变化，项目管理要控制变更次数和规模来减少风险。而敏捷却是要拥抱变化。因为我们要面对很多未知，而敏捷项目和传统项目的目标都是一样的，项目最后的成功——一个有价值的产品。

敏捷原则是固定日期时间项目的补充

作者提到敏捷宣言还包含了作为四大价值基础的十几个原则。其中的每一条都是对固定日期和范围的项目的补充。例如：

“我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。”这条是宣言的首要原则。当在固定日期或固定范围的项目中工作时，寻找机会交付足够的价值，告诉客户可能不需要他们最初预期的所有东西。 Mike 是有情怀的工程师，他不希望来扩大项目范围来为公司增加收入，从客户手里获得更多利益。而现实中很多时候客户自己在不断的扩大范围，因为他们恐惧做少了无法实现他们的需求。其实找到方法让客户知道我们是在和他们合作为了更精准高效的实现他们的需求，解决他们的实际困难，而不是为了尽快快弄完项目。相信客户是会理解的。
“欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。”面对未知我们要认识到变化是不可避免的，而不是想办法控制它不变。所以让老板、客户、用户相信这一点。并让他们知道我们会和他们一起来面对。

写在最后

固定价格、范围和日期的项目是可以敏捷的吗? 答案是：可以的。有时候我们总是觉得身处的环境有太多不可能限制我们团队的敏捷性。转型困难重重。可是换一个角度想想，我们生活的世界就是不理想的，存在种种约束。只要约束是留有空间的，那么团队就可以在约束的空间中寻找解决方案。我最近在做的一个项目就是固定总价的传统项目，但是依然和客户合作按照 Scrum 的模式在运行。客户相信我们，愿意用迭代中发现的新需求来替换之前合同中功能。所以这也让我看到了希望。不过前提一定要和客户构建起一个信任的环境，之后在这个环境和约束中进行合作。