有钱也买不到！企业敏捷性转型的“坑”都在这了

导语
如今敏捷性的实现正越来越受到关注。下面是一些有可能会阻止敏捷性实现的障碍。

文章图片
人们对敏捷性的关注由来已久，关于敏捷性的报道十年前就已经出现在新闻当中。《敏捷宣言》也已经发布了近二十年时间，我们中的许多人早在宣言正式发布之前就开始学习和尝试敏捷技术了。
由于敏捷的成功率和业务满意度都很高，这引起了一些抵制者的恐慌。为此，他们全力阻止企业向敏捷性转型。如果你是他们中的一员，同时也面临着"向敏捷性转型"的压力，那么你现在应该采取行动，不能像因小行星撞击地球而灭亡的恐龙那样坐以待毙。以下这七种方法不仅行之有效，而且还可以帮助你在IT部门中"阻止"敏捷性的实现，同时又不会让你在公司、中名声扫地。
01
曲解敏捷性的含义
当启动下一个项目时，你应坚持让项目经理以"敏捷的方式"运行它们，同时让团队中的所有人每天早上都要弄清楚他们当天能做些什么，以便让项目朝着他们认为的方向发展。
当团队准备测试一个功能时，你可以今天就让产品负责人知道：你明天就需要业务人员来测试这个功能。如果明天没空，没关系。这只意味着该功能将不得不调整至下一个迭代周期。
如果产品负责人抱怨项目没有按时完成，那么，这刚好正中下怀，你可以借机解释一下"敏捷项目"没有时间表。敏捷性就是意味着"没有计划" ，难道不是吗？
02
忽视架构
不要在定义应用程序架构的项目上过早地浪费时间。如果敏捷性意味着需求不断演化，那么应用程序架构不也应该不断演化吗？
因此，不要通过坚持遵从一大堆的抽象原则来限制开发人员的创造力。相反，你要授权开发人员，让他们按照自己想要的方式开发，按照他们自己喜欢的方式构建模块和接口。如果来自不同开发人员的不同模块不能在一起即插即用，或者不同开发人员编写的代码依赖于不同的库，那么你也不用担心。这正是重构的意义所在。
如果不同的开发人员想用不同的语言开发，那么刚好，容器不就是用来解决这个问题的吗？
03
选择Scrum
敏捷性不是一种方法论，而是一系列方法论，每一种都适用于不同类型的项目。 Scrum之所以非常受欢迎，并不是因为它们是"最佳实践" ，而是因为它们是结构严谨的敏捷变体，比其他任何产品更接近舒适区。（注：Scrum是橄榄球运动的专业术语，表示"争球"的动作；把一个开发流程取名为Scrum ，就是让开发团队在开发项目时像打橄榄球一样迅速、富有战斗激情、人人你争我抢地去完成它们。 Scrum就是这样的一个开发流程。）

文章图片
Scrum不太适合COTS（现成的商业软件）和SaaS（软件即服务）的部署，而IT部门所承担的大多数项目都含有COTS和SaaS 。不同的敏捷变体、会议室试点（CRP）或与其密切相关的ATTD（验收测试驱动开发）是更好的选择。
但是谁听说过它们？很可能没人在乎。即使你的最强大的政治对手也不会批评你选择了最流行的敏捷变体，即使他们知道还有其他敏捷变体可供选择，也不会批评你。
因此，当由Scrum驱动的COTS部署出现了问题，即使你清楚这一结果，也不会有人质疑。如果有人质疑，你可以说项目失败了，因为敏捷从一开始就不是一个好主意，而且你可以安全地暗示，任何提出不同意见的人都是在推卸责任。