“敏捷的弱点是什么？”，一个刚接触敏捷的朋友如是问。
敏捷方法是一种适应性方法，换句话说，由于它本身的适应性，他可以去适应各种情况，并且可以根据实际的效果来调整自身，从而改善它的适应程度。因此，首先我们说，敏捷的弱点或者优点这样的问法是不妥的，应该问，在什么情况下敏捷适用性不好？
敏捷的产生主要是来自于开发团队，开发团队发现他们在进度、质量等方面的能力无法满足业务需求，于是提出要加强交流，增进反馈，避免各种内部浪费。于是开发团队在实践上采用测试、迭代、提高交流效果等等，最终在效率上得到了很大提升。
但是，很快的，这个团队意识到，光提高开发的质量还不行 。开发测试之外的很多东西也需要敏捷才可以，尤其是在发布一个新版本的时候，旧有的发布方法没法满足开发的速度要求。他们于是提出了敏捷的需求管理，要求和业务部门之间建立专门的业务分析来进行沟通；数据库重构技术，要以往DBA所负责的部分也能够变得敏捷，适应开发的需要；部署和发布方面也需要一套高效的方法来适应快速发布，快速反馈的需要。于是，整个IT部门变得更敏捷，从需求到发布的整个软件生命周期都得到了很大的改善。
然而，这个部门很快又遇到了问题。虽然IT部门的开发很高效，但他们和其他的业务部门之间总遇到难以解决的问题。或者是业务变化跟不上，或者是售后支持没法及时反映。于是，由CIO带领，公司开始了整个的组织转型，将一个组织敏捷/精益化，建立敏捷业务和精益企业。让IT部门的价值得到最大的提升，由新的IT系统来促进业务的发展。
不过，问题又来了。由于业务的发展，公司需要和其他的公司之间进行数据交换，共同开发通讯接口。合作公司的反应速度和开发效率极低，大大的降低了合作的效果。于是，公司派出咨询师，帮助合作公司进行过程的改进。最终达到共赢。
这一整套过程下来，敏捷/精益的思想得到了贯彻，开发效率和业务效率得到很大提升，公司获得了很大的企业价值。然而，如果这一切都无法顺利的完成呢？
在某些公司，由于各种原因，一个团队的敏捷程度完全取决和他们合作的部门或公司的敏捷程度。在一个项目中，我的一个同事所在的团队需要和数据库部门以及另一个开发部门协作，从而完成一个系统集成应用，然而，他们没有数据库的操作权限，同时另一个部门的API尚未就绪。他们很快就开发完毕自己所分配的部分功能，在等待中不断的催促和协调另外的部分。一个几周的工作，硬生生的被拖到了三个月。
综上， 敏捷什么情况下适用性不好呢？答案是，当你没有办法改变你周边的人、部门、公司做事方式的时候。
不过，我认为，改变一个人虽然困难，但我们可以去影响他们。只要从基本的实践处做起，逐渐的，周边的人会被带动，从而可以推动整个部门的改变。一个部门改变了，公司领导会很快意识到这种变化，变化也有可能影响到其他部门。只要我们坚持去做
此文由scrum中文网整理，转载请注明
