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