此前，研发频道曾发表过一篇文章《DevOps正在扼杀程序员？ 》该文引发了CSDN网友们的激烈探讨。有人认为，DevOps的流行让越来越多的程序员身兼多职，而这种流行趋势正在扼杀真正的程序员。而在这篇文章中原文作者Jim Bird则认为DevOps扼杀的不是开发者，而是开发本身和开发生产力。

所幸到目前为止，暂时还没有看到哪个开发者受到了如此重大的打击。真正受到Devops影响的是开发本身和开发生产力。敏捷开发如上了膛的枪支，而Devops正扣在扳机上。

交付被工作流取代

开发的规模和重心持续收缩，因此花在决策上的时间相应减少。从前需项目团队花一年才能完成的交付演变为只给开发团队一个月，甚至是要求开发者独立在几周内就完成。现在，完成的意思是已发布完毕而不仅仅是完成代码工作。

持续交付和持续开发取代了持续集成。如此快速的产品上线节奏，测试用时越发变得稀缺，这也意味着开发者不得不演变为“超人”，既要搞代码，又要兼顾测试，既要对内，又要对外。

Devops活生生就是多快好省的代名词，最终目的就是推动产品上线，不断加快工作流的速度。再三强调的标准化自动化，开发周期的一再压缩，软件开发仿佛一下子就从工程的范畴蜕变成制造和生产控制的领域。

Devops在消磨开发生产力

不论是采用LOC(Lines Of Code)还是别的计量方法，开发者的代码量输出都在持续萎缩，因为他们要把时间分配到运营工作中。但时间恰恰是个可恶的零和游戏，这边多的恰是那边少的。帮助运营团队查找和解决问题，回复客户的咨询和疑问，监控系统，帮助执行A/B测试……面对如此繁重的任务清单，还能要求开发人员写出原来一样的代码吗？

亟需改变的期望值、度量方法以及激励措施

在Devops中，不论Dev还是Ops，他们的工作已经发生了改变，因此需要采取应对措施来顺势而为。期望值、度量方法以及激励措施应成为应对措施中的关键组成。

Devops的成败需要由运营相关的度量来判别，无关乎项目交付目标或者产品设计目标。比方说：

• 对于重大变更或问题能否快速响应：把筹备周期开发周期的重心从交付里程碑上转移到实际产品；
• 能否快速把变更应用到实际产品中，以天/小时/分钟来衡量；
• 错误的频率，变更次数/错误次数的比率；
• 系统可靠性的考量，例如用MTBF，特别是MTTD和MTTR；
• 变更的成本，总体营运成本和支持成本的分析。

Devops更着重于Ops

由于越来越来的软件被更迅速和频繁地推出，开发转变成维护。项目管理被突发事件管理和任务管理取代。计划制定的范围变得越来越窄，或者说是受到高优先度事件编排的制约。

Dev在慢慢转变成Ops。电商行业尤甚，购物平台一旦推出，客户开始使用后，如果作出变更，所有前期制定的工作和计划都不得不跟着改变，可谓牵一发而动全身。对于开发者来说，目前的大环境充耳皆闻的是有关精简和培训的理论，强调更多的责任和义务，更为关注发布和部署环节，对开发本身的冷淡程度每况愈下。

开发者和他们的管理者们需要适应这种转变，这或许就是将来软件产业的真实写照。但这不是所有人都喜欢看到的，或者说能很好地完成角色转换的。