敏捷这个概念已经提出很多年了。它针对开发团队的角色做了划分，并且对各个角色的能力要求还很高，另外对工作流程，迭代周期都提出了理想定义，这实际上是对组织架构的一个颠覆。对于国内的很多互联网大企业确实已经取得了不错的应用效果，但很多传统行业转型过程中的企业并没有很好地去应用。
那么我们看一下在传统企业内部推进敏捷转型落地的过程中，都存在哪些问题和阻力？
首先在企业内部，无论做任何变革，都需要有一个过程。不同的人，针对同样一件事，由于个人立场不同，得出的结论也是不一样的。在敏捷导入过程中，也存在这样的问题。当团队初始使用敏捷的阶段，最大的问题就是团队成员的抵触情绪。抵触可以有多种形式，主动的或被动的，公开的或隐蔽的。
主动抵抗可能仅限于少数脾气暴躁但与世隔绝的人，或者它可以蔓延到那些煽动不满和鼓动以阻止参与的人。“积极抵制的人可能会试图破坏这个过程，所以他们会四处乱说敏捷开发，试图说服人们放弃它。” 随着不满的蔓延，它会削弱士气，因此隔离抗议者并让他们加入是很重要的。
但是实际上公开抵制并不常见，至少在决定采用敏捷之后不会。更多遇到的情况其实是被动抵抗。“被动的抵抗者假装顺从这个过程，站起来并口头上表达想法，但他们的态度是，'谁在乎？'”。
因此在敏捷的导入过程中，如何引导团队成员去接受，去积极地实践敏捷是关键所在。
同时我们应应当意识到，软件开发效能的整体提升，并不是敏捷完全能解决的问题。团队效能的提升，涉及到管理流程、技术架构、工具自动化等方方面面的因素，而敏捷只关注于需求与开发之间的管理流程的问题。基于团队不同的现状，敏捷也有不同的表现形式，这里就不作赘述
但总体来说，企业做敏捷转型，仍然有一定的流程可以遵循。
如果企业完全是从原来瀑布开发模式做转型，那么首先在团队层面需要引入看板方式，让团队能够很好的可视化现有流程。只有可视化现有流程，才能识别并优化团队的瓶颈问题。
其次，当团队能够熟练使用看板以后，就可以把团队的组织流程转变成Scrum。Scrum比Kanban模式的优点在于对团队的动作做了更多的规范化，这样更有利于团队建立统一的开发节奏。
第三，当团队的组织流程运行顺畅以后，就可以在技术架构层面引入更多的实践，例如：优化团队的开发框架、修复以前的技术债等。
最后，当团队级别的效能提升到一定阶段以后，就可以把敏捷相关实践拓展到整个IT部门，并且推进业务部门一起来做尝试。这块就涉及到规模化敏捷推广和业务敏捷的相关内容了，后续我再详细展开谈谈。
另外我们嘉为蓝鲸的DevOps平台完全可以实现敏捷开发，感兴趣的朋友也可以私我了解。
