企业什么时候不应该采用敏捷开发(Agile)？

敏捷开发作为最近的时髦词汇，已经迅速席卷了IT界，以前Agile的使用仅仅适用于网站和手机APP的开发范围，而今传统企业IT也想引进Agile模式，来打造新的企业IT服务模式。Agile的好处我此处就不再描述了（本人目前主要的工作就是负责在公司内部内部普及Agile和DevOps），我在此主要是说说Agile本身的局限性或者说是她的适用情况，给那些想做Agile转型的公司做一个参考。

1，当你不能用迭代法开发你的产品时，不要使用Agile。

不是所有的产品都是可以先推出一个简单的有着很多bug的版本，而后按着用户反馈逐步的更新和改进的。企业用户和普通用户的需求特点十分的不同，如果企业用户的产品指向生产，销售和CRM环节，产品的高质量往往是第一位的，高质量往往意味着长时间，目前流行的Scrum方式其实很难打造高质量的产品。

2，当你的客户不能保证全身心的投入的开发工作时，不要采用Agile。

敏捷的模式不仅仅是针对IT的开发和管理人员，同时也是对客户或用户的，还是以Scrum为例，业务部门需要有专门并且全职的人员和开发人员在一起完成工作，不断做需求更新和排位，不断收集业务部门的反馈来调整开发目标。业务人员的参与程度的高低直接决定了Scrum方式的成败。 但是传统企业中的业务部门是否做好了这个准备，是否有相应的资源来匹配新的交付模式，都值得事先花更多的时间开准备。

3. 当整个团队的规模太大，并且跨越了不同的时区，不要采用Agile。

俗话说，“船小好掉头”，只有规模够小才能敏捷灵活，但是传统大型企业IT有一个致命的问题，就是IT服务资源的全球化。以前这是一个引以为豪的地方，但是现在却成为一个绊脚石。大部分的企业会把IT系统架构/方案设计放在欧美国家，把IT运维放在中国或印度，软件开发和测试也会放在中印等国家，业务关系管理（BRM）则可能紧挨着有业务部门的地点。这种分散的模式很难把Agile模式所需要的资源集中在某一个物理位置，所以企业IT只能采取虚拟团队的模式来应付这种情况，或者从长远上来看准备进行大的组织结构调整。

虚拟团队的工作效率其实无法满足agile的模式，如果是短期还可以，但是长期来说（以Scrum为例）天天的会议对于跨时区的团队实际上是挺痛苦的，更不要说当前企业合作服务（比如，电话会议+文件实时共享）和面对面的沟通还是有不少的差距的。我相信经常使用这些服务的人明白我的意思，电话会议作为信息共享还可以，但是用来支持开发项目，效率就要打个大折扣。

原文转自：https://zhuanlan.zhihu.com/p/24565037