DevOps扼杀的不是开发者,而是开发生产力!

更新时间:2014-08-11 09:57:15点击次数:681次

摘要:有人认为,DevOps的流行让程序员身兼多职,而这种流行趋势正在扼杀真正的程序员。在这篇文章中作者Jim Bird的观点与之相反,他认为DevOps扼杀的不是开发者,而是开发本身和开发生产力。

此前,研发频道曾发表过一篇文章《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。电商行业尤甚,购物平台一旦推出,客户开始使用后,如果作出变更,所有前期制定的工作和计划都不得不跟着改变,可谓牵一发而动全身。对于开发者来说,目前的大环境充耳皆闻的是有关精简和培训的理论,强调更多的责任和义务,更为关注发布和部署环节,对开发本身的冷淡程度每况愈下。


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


英文出自: Dzone

  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息