从DevOps业务谈敏捷开发、软件工程和新角色最近发表一篇关于DevOps的文章时，我发现了一个很有趣的现象：在国外，很多博主都在批评“DevOps”运动。越是流行，越是厌恶，甚至排斥。简述DevOps讨厌它的原因：1.没有时间专心写代码2.迫使开发者进入一个巨大的知识领域（这里指的是需要成为“全栈”开发者）3.压力大，任务多沉重，不知所措，是真的吗？其实并不是。不管怎样，存在就是合理的。再说了，没有哪个公司傻到让一个只会写代码的开发人员去做QA、系统管理员或者DBA，所以我觉得也不能归为“DevOps”。引用DevOps倡导者JeffRoth的话：“需要在专业知识、协作关系和知识共享之间找到合适的平衡点。只有这样，人们才能充分利用自己的才能和资源。”HowtoHurtaDeveloper》一文有不同的理解，下面综合采访IBMRational中国区技术总监孙鑫，谈谈我对DevOps的一些理解，欢迎评论。敏捷开发初识DevOps时，我很自然地联想到敏捷开发，认为他们是一种集体关系。当他有机会和孙老师聊天时，他并不认为完全是这样。说是不完全准确一个集合关系，但是DevOps可以让敏捷开发更好。怎么理解这句话，我们先说敏捷开发。懂敏捷的都知道Scrum是做的最多的，也是最好的。这是一个流派。当整个团队达到一定的规模，是非常依赖工具的。（因为在实施敏捷的时候，不能完全保证所有的人员都可以在一个地方。在大规模敏捷的情况下，是不可能的把所有人都放在一个小房间里，每天开各种会议。像更强大的scrumsofscrums，我是这么理解的）。这里有一个问题。当Scrum严重依赖工具时，实际上会出现很多问题。大家都知道Scrum是一个迭代的过程，需要很多循环的迭代，不可能一口气搞定（那就不是Scrum）。在这个迭代的过程中，需要沟通、协调、测试、部署、发布等等，那么这些事情是不是只能通过工具来完成呢？我觉得很难。DevOps这个时候能在这里扮演什么角色呢？回到上一点——加速敏捷的进程。因为DevOps可以利用云技术，自动化部署，自动化发布等技术。尤其是测试，当敏捷达到一定规模时，需要跨部门，开发人员可能会非常主动。要是有什么新的功能要加，运维就不干了，估计会说你行不行！其实，这是可以理解的。开发人员抛出一个软件版本给运维人员后，运维人员会使用该产品的版本开始准备部署。这时候，一个问题出来了。他们需要修改配置文件以适应与开发环境有很大不同的真实生产环境。通常他们会重复之前在环境中所做的事情；如果出现问题，它们很可能会引入新的漏洞。这就是他们所担心的。如果没有反复测试，运维人员肯定不会上线。所以，DevOps的概念正好解决了这个问题，但这只是DevOps的一小部分。如果推进Agile，业务管理、生命周期管理、监控管理等，在需要扩展的时候，都会很大程度上依赖于DevOps。两者的关系是DevOps可以带动敏捷加速周期，敏捷在一定意义上也可以促进DevOps。做传统软件工程的大家应该都知道，传统软件工程是从需求-发布-测试这个过程开始的，也就是只停留在研发的工具生产线上，所以我们看到的软件工程链比较短。DevOps的概念出来之后，大家逐渐发现，软件工程的前端部分逐渐变成了一个新的领域，前端+传统软件工程+后端，无形中产生了一个大的产业链，就是我们现在谈论的是什么。全新的软件工程。（PS：据我所知，现在很多公司都在招聘软件工程（DevOps）的职位，很有意思。）软件工程的前端，也可以称为业务端，比如商业计划。那么产业链后端负责什么呢？和孙鑫老师聊天的时候，他特别强调了PRE（全称应该是ProductLineEngineer）产品线工程。孙老师还举了一个例子，“一些大公司像华为，他们不只是做软件，他们所有的嵌入式软件，机械设计，电气设计，软件设计，这些大的产品线本身，其实都是在很好的工程管理下的。”从策划到实施，软件这部分其实占据了很重要的位置，你可以看到PRE中非常强调后端。那么在软件整体框架下如何支撑这些产品线的规划呢？这时候回过头来看，传统的软件工程其实只是其中的一部分。事实上，现在的业务需求越来越往前推。这还包括传统领域的产品管理，也就是常说的项目管理，还有企业架构、信息架构、数据架构、流程集成。当你知道你要做出哪些决定，你投资了哪些大型IT项目，然后将它们推送给你的业务部门和你的最终用户，在规划好这些需求之后，你就可以将它们转化为软件变更的实现。这将是有意义的，这样您就可以捕获支持您的业务目标的需求。孙总在录制视频时提到，中国的食品安全离不开整个大产业链，“我们在做食品管理的时候，都是在抓生产。比如奶粉生产，要看工厂有没有。细菌，其实食品安全管理的范围比原来有了很大的扩大。原材料、运输过程、加工过程等是一个大的产业链。只管理一个部门是不好的。其实，软件工程也是如此。我觉得以后你的软件离不开你的运维，而且频率越快，运维越快就会出问题。”因此，从单纯的软件开发到业务规划、发布部署，以及整个上线的监控，其实是这样的，不管你觉得是不是概念，整个过程都离不开产业链，现在软件工程的前端部分已经逐渐涉及到业务端了，而传统的只是在这个工具的产线上，目前我个人认为新角色的诞生是很难整合的，从上面说的业务线来看，是很难的。如果你想改造一个传统的组织架构，其实是组织变革的问题，这个和DevOps没有关系，不能说我要用DevOps，就必须把两者结合起来部门。这时候可能有人会问了，这不是技术要求吗？如果我解决了技术问题，那么集成应该不是问题。事实上，组织变革与技术关系不大。并不是说技术打通了，两者融合就没有障碍。另一方面，比如一些相对成熟的企业，如银行、电信等，其组织结构包括研发中心、测试中心、运维中心。从研发到运维，技术与技术之间虽然还有很大的差距，但需要时间让他们在这些业务的边界上逐渐更好地融合在一起，形成新的业务线。组织变革往往是对一些新技术的缓慢修正，由此产生的企业文化和工作习惯也会在新的角色定义中发生变化，从而推动组织变革。因此，在这种情况下，也可能会形成新的虚拟人员跨界角色，更容易支撑起整个业务。
