人们对敏捷性的关注由来已久，关于敏捷性的报道十年前就已经出现在新闻当中。《敏捷宣言》也已经发布了近二十年时间，我们中的许多人早在宣言正式发布之前就开始学习和尝试敏捷技术了。

由于敏捷的成功率和业务满意度都很高，这引起了一些抵制者的恐慌。为此，他们全力阻止企业向敏捷性转型。如果你是他们中的一员，同时也面临着"向敏捷性转型"的压力，那么你现在应该采取行动，不能像因小行星撞击地球而灭亡的恐龙那样坐以待毙。以下这七种方法不仅行之有效，而且还可以帮助你在IT部门中"阻止"敏捷性的实现，同时又不会让你在公司、中名声扫地。

1. 曲解敏捷性的含义

当启动下一个项目时，你应坚持让项目经理以"敏捷的方式"运行它们，同时让团队中的所有人每天早上都要弄清楚他们当天能做些什么，以便让项目朝着他们认为的方向发展。

当团队准备测试一个功能时，你可以今天就让产品负责人知道：你明天就需要业务人员来测试这个功能。如果明天没空，没关系。这只意味着该功能将不得不调整至下一个迭代周期。

如果产品负责人抱怨项目没有按时完成，那么，这刚好正中下怀，你可以借机解释一下"敏捷项目"没有时间表。敏捷性就是意味着"没有计划"，难道不是吗?

2. 忽视架构

不要在定义应用程序架构的项目上过早地浪费时间。如果敏捷性意味着需求不断演化，那么应用程序架构不也应该不断演化吗?

因此，不要通过坚持遵从一大堆的抽象原则来限制开发人员的创造力。相反，你要授权开发人员，让他们按照自己想要的方式开发，按照他们自己喜欢的方式构建模块和接口。如果来自不同开发人员的不同模块不能在一起即插即用，或者不同开发人员编写的代码依赖于不同的库，那么你也不用担心。这正是重构的意义所在。

如果不同的开发人员想用不同的语言开发，那么刚好，容器不就是用来解决这个问题的吗?

3. 选择Scrum

敏捷性不是一种方法论，而是一系列方法论，每一种都适用于不同类型的项目。Scrum之所以非常受欢迎，并不是因为它们是"最佳实践"，而是因为它们是结构严谨的敏捷变体，比其他任何产品更接近舒适区。(注：Scrum是橄榄球运动的专业术语，表示"争球"的动作;把一个开发流程取名为Scrum，就是让开发团队在开发项目时像打橄榄球一样迅速、富有战斗激情、人人你争我抢地去完成它们。Scrum就是这样的一个开发流程。)

Scrum不太适合COTS(现成的商业软件)和SaaS(软件即服务)的部署，而IT部门所承担的大多数项目都含有COTS和SaaS。不同的敏捷变体、会议室试点(CRP)或与其密切相关的ATTD(验收测试驱动开发)是更好的选择。

但是谁听说过它们?很可能没人在乎。即使你的最强大的政治对手也不会批评你选择了最流行的敏捷变体，即使他们知道还有其他敏捷变体可供选择，也不会批评你。

因此，当由Scrum驱动的COTS部署出现了问题，即使你清楚这一结果，也不会有人质疑。如果有人质疑，你可以说项目失败了，因为敏捷从一开始就不是一个好主意，而且你可以安全地暗示，任何提出不同意见的人都是在推卸责任。

4. 玩蛙跳游戏

敏捷性的魅力和最大的优点在于它的简单性，最大的缺点是缺乏良好的扩展性。

明智的业务部门会让敏捷性保持敏捷，为此他们会拓展敏捷的原则，将软件部署和所有业务变化都包含进去。从这个角度看，大规模战略计划本质上是瀑布式的，其失败的原因与瀑布式项目失败的原因相同：它们是线性的，有很多相互依赖性和潜在的单点故障。另外，它们建立在对未来的假设之上，当未来到来时，这些假设至少会改变两次。

但是你不要在意这些。CIO的工作不是让业务更加灵活，而是为了支持商业战略，不管战略是否有任何实际运作的机会。由于敏捷性不能扩展到战略级计划，因此IT部门需要采用一种听起来像敏捷性但是扩展起来像瀑布一样的方法。

这时你可以用到SAFe，即所谓的Scaled Agile Framework(可扩展的敏捷框架)。尽管敏捷性的成功是因为其本身方法简单，但是SAFe却异常复杂，有着大量移动部件、潜在的故障点以及对未来的假设。另外还有一个额外的好处就是没有人熟悉SAFe。

SAFe 本身没有问题，但是需要有经验的从业者和相当多的程序基础设施。如果业务部门需要SAFe ，那么IT部门就要部署SAFe。从瀑布式转向SAFe本身就存在鸿沟和风险。

尽管程序必然会失败，但是你却可以全身而退，不用承担责任，因为你已经警告过敏捷性不能扩展。

5. 坚持让开发伙伴使用敏捷性，同时坚持让他们同意固定价格的投标

当然，他们必须使用敏捷。非常好，不是吗?此外，你还需要教会业务部门中的每名经理如何以敏捷方式与IT部门协同工作。

供应商的出价必须要有一个固定的价格。这是保持供应商诚实的唯一方法。否则他们就会用一种"不当激励"来拖延项目预算和进度。

如果有供应商提出，从一个固定的范围开始，并通过严格的变更控制来调整价格，那么管理可以限制敏捷性。这不失为一件好事情，因为在签署工作说明之前，你就可以知道与该供应商合作的难度。

6. 离岸敏捷

从理论上讲，业务规划师会为收入、成本、风险和业务成绩设定目标。但是实际上，在大多数业务部门中，批准实际执行的项目都是降低成本的项目。

从为开发者工作支付的费用开始设置障碍，与此相比，还有什么会更合适呢?因此，当与开发合作伙伴合作时，你要确保其大多数团队成员在11个时区之外生活和工作。

敏捷原则的第6条强调了开发人员之间以及开发人员和业务用户之间面对面交谈的重要性。有了时差，海外开发者自然不会参与。没关系。你也不用理会这条。这只是理论。在节约资金和抽象原则之间做出选择，那些想节约资金的人自然会站在你这边。

当敏捷"团队"交付模块时，也没关系，即便他们击中靶子，也是击中了位于错误目标中心的靶子。这些模块的成本确实是大大降低了，同时IT部门也可以甩锅给业务部门，指责业务部门不清楚他们自己的需求。因为面对面交流太少，所以要求不明确。

7. 让一切都围绕流程

是的，我们都知道敏捷宣言鼓励"个人和交互胜过流程和工具"。但如果说管理层在过去几十年里学到了一件事的话，那就是业务的成功取决于建立定义良好的可重复流程。成功不是来自人际关系，也不是通过员工合作找出更好的解决方案。成功来自于员工遵循流程，按照规定按部就班的一步一步来。

每个流程设计师都知道，一个好的流程不应该有漏洞。由你来决定你的敏捷流程，就像所有其他优秀流程一样，描述了流程是如何从一个环节到另一个环节，每个决策点都被描述为一个过程分支，而每个参与者都将他们的输入转化为输出，成为下一个员工的输入。

为敏捷流程添加足够的复杂性，最终IT部门可以扩展EPMO的项目管理流程执行的范围，以便他们能够密切关注敏捷教练，就像他们一直让你的瀑布式项目经理保持一致一样。

如果你觉得这里列出的七个策略没有吸引力，那么你还有一个选择。

你可以向不可避免的事情屈服。你可以承认敏捷确实比瀑布式开发更有效，并且真心尝试一下。这可能会很痛，但是你可以这样想：膝关节置换手术也会痛。但从长远来看，回避比让它发生的伤害性更大。