敏捷|有钱也买不到！企业敏捷性转型的“坑”都在这了( 二 ) 来源：计算机世界如今敏捷性

04 玩蛙跳游戏
敏捷性的魅力和最大的优点在于它的简单性，最大的缺点是缺乏良好的扩展性。
明智的业务部门会让敏捷性保持敏捷，为此他们会拓展敏捷的原则，将软件部署和所有业务变化都包含进去。从这个角度看，大规模战略计划本质上是瀑布式的，其失败的原因与瀑布式项目失败的原因相同：它们是线性的，有很多相互依赖性和潜在的单点故障。另外，它们建立在对未来的假设之上，当未来到来时，这些假设至少会改变两次。
但是你不要在意这些。 CIO的工作不是让业务更加灵活，而是为了支持商业战略，不管战略是否有任何实际运作的机会。由于敏捷性不能扩展到战略级计划，因此IT部门需要采用一种听起来像敏捷性但是扩展起来像瀑布一样的方法。
这时你可以用到SAFe ，即所谓的Scaled Agile Framework（可扩展的敏捷框架）。尽管敏捷性的成功是因为其本身方法简单，但是SAFe却异常复杂，有着大量移动部件、潜在的故障点以及对未来的假设。另外还有一个额外的好处就是没有人熟悉SAFe 。
SAFe 本身没有问题，但是需要有经验的从业者和相当多的程序基础设施。如果业务部门需要SAFe，那么IT部门就要部署SAFe 。从瀑布式转向SAFe本身就存在鸿沟和风险。
尽管程序必然会失败，但是你却可以全身而退，不用承担责任，因为你已经警告过敏捷性不能扩展。
05 坚持让开发伙伴使用敏捷性，同时坚持让他们同意固定价格的投标
当然，他们必须使用敏捷。非常好，不是吗？此外，你还需要教会业务部门中的每名经理如何以敏捷方式与IT部门协同工作。
文章插图
供应商的出价必须要有一个固定的价格。这是保持供应商诚实的唯一方法。否则他们就会用一种"不当激励"来拖延项目预算和进度。
如果有供应商提出，从一个固定的范围开始，并通过严格的变更控制来调整价格，那么管理可以限制敏捷性。这不失为一件好事情，因为在签署工作说明之前，你就可以知道与该供应商合作的难度。
06 离岸敏捷
从理论上讲，业务规划师会为收入、成本、风险和业务成绩设定目标。但是实际上，在大多数业务部门中，批准实际执行的项目都是降低成本的项目。
从为开发者工作支付的费用开始设置障碍，与此相比，还有什么会更合适呢？因此，当与开发合作伙伴合作时，你要确保其大多数团队成员在11个时区之外生活和工作。
敏捷原则的第6条强调了开发人员之间以及开发人员和业务用户之间面对面交谈的重要性。有了时差，海外开发者自然不会参与。没关系。你也不用理会这条。这只是理论。在节约资金和抽象原则之间做出选择，那些想节约资金的人自然会站在你这边。
当敏捷"团队"交付模块时，也没关系，即便他们击中靶子，也是击中了位于错误目标中心的靶子。这些模块的成本确实是大大降低了，同时IT部门也可以甩锅给业务部门，指责业务部门不清楚他们自己的需求。因为面对面交流太少，所以要求不明确。
07 让一切都围绕流程
是的，我们都知道敏捷宣言鼓励"个人和交互胜过流程和工具" 。但如果说管理层在过去几十年里学到了一件事的话，那就是业务的成功取决于建立定义良好的可重复流程。成功不是来自人际关系，也不是通过员工合作找出更好的解决方案。成功来自于员工遵循流程，按照规定按部就班的一步一步来。