Devops并没有杀死开发人员 -至少不是我所知道的任何开发人员。
但是，Devops正在扼杀开发工作，也就是我们大多数人认为应该如何构建和交付软件的方式。 敏捷装了枪。 Devops正在拉动触发器。
流而不是交付
开发和交付软件的方式正在发生翻天覆地的变化。 大型瀑布式软件开发项目让位于分阶段交付和螺旋方法， 然后由较小的团队使用Scrum或其他迭代敏捷方法在时间范围内交付工作代码 。 现在，人们正在从Scrum到看板 ，再到单件连续流，并立即将代码连续不断地部署到Devops中的生产中。
开发的规模和重点持续缩小，制定决策和完成工作的时间框架也在不断缩小。 阶段和里程碑以及对Sprint的项目审阅和对WIP限制和任务级优化的精益控制的Sprint审阅。 可交付成果的规模：从项目团队一年可以交付的成果到Scrum团队在一个月或一周内可以完成的事情，到单个开发人员可以在几天或几小时内完成生产的工作。
“完成”和“工作软件”的定义已从经过编码和测试并准备演示的东西变为现在正在生产中的东西（“ 已发布的完成手段 ”）。
持续交付和持续部署取代了持续集成。 快速部署到生产中并不会浪费时间进行手动测试或手动测试人员 ，这意味着开发人员有责任在代码投入生产之前自行捕获所有错误-或在生产中进行测试并尝试捕获问题（亦称“ 监控作为测试 ”）。
因为Devops使开发人员更接近生产，所以操作风险比项目风险变得更加重要， 操作指标比项目指标变得更加重要。 系统正常运行时间和生产周期时间取代了挣值或速度。 赶工期的压力已被生产和待命中的消防压力所取代。
Devops与交付项目甚至交付功能无关。 它是关于最大程度地缩短交货时间并最大程度地提高工作流向生产的效率，识别并消除垃圾工作以及延迟和交接，提高系统可靠性并削减运营成本，在从生产到开发的反馈回路中建立尽可能多的标准化和自动化步骤。 它比制造更重要的是制造和过程控制。
Devops也杀死了开发人员的生产力
Devops还破坏了开发人员的生产力。
无论您是尝试通过LOC， 功能点 ， 功能点 ，存储点 ， 速度还是其他方法来衡量开发人员的工作效率 ，还是要通过其他方式来衡量编写多少代码，由于开发人员将更多的时间花在操作工作和处理中断上，因此减少了编码工作量，减少了编写代码的时间。
花时间学习有关基础架构和平台的知识，并了解如何进行设置并确保正确设置。 建立持续交付和持续部署管道并保持其运行。 帮助操作人员调查和解决问题，响应紧急的客户要求和问题，调查性能问题，监视系统以确保其正常运行，帮助进行A / B实验，推动更改和修复…这一切都需要时间远离开发和先发制人的需求，设计，编码和测试（开发人员受过训练并且擅长的工作）的思考。
中断和多任务处理的影响
即使您在严格的WIP限制下使用看板，也不能在Devops中保护开发人员免受其中断和优先级的更改，即使在运行严格的商店中，您也不想这样做。 开发人员需要对运营和客户做出响应，对生产反馈做出反应，解决问题，并帮助尽快发现和解决故障。 这意味着每个人（尤其是您最有才华的开发人员）需要（即使不是一直）大部分时间都可以进行操作。
开发人员在下班后加入电话通话，这意味着在一天的工作完成后要携带传呼机（或被传呼机Duty追赶）。 浪费在支持上的时间导致问题最终不是真正的问题，而漫长的夜晚和周末则是在灭火，跟踪生产问题并帮助从故障中恢复过来，第二天又累了又要花更多的时间进行事故空转测试故障转移，前滚和后滚恢复，并在出现问题且故障转移或前滚或后滚不起作用时参与事后分析和根本原因分析会议。
您无法计划中断和操作问题，也无法计划它们。 这意味着开发人员将更经常错过他们的承诺。 那为什么要做出承诺呢？ 为什么要计划或估算呢？ 而是使用即时优先级来专注于当前操作或客户需要的最重要的事情，并尽快将其交付-除非出现并抢占更重要的事情。
随着开发人员承担更多的操作和支持职责， 多任务和任务切换以及随之而来的中断和效率低下会增加，破坏时间并破坏注意力。 这直接影响了生产力，并长期影响人们思考和解决问题的能力 。
甚至持续部署反馈循环本身也中断了开发人员的流程。
开发人员检入代码后，应该在几秒钟或几分钟内在Continuous Integration中运行单元测试很快，以便他们可以继续进行自己的工作。 但是，要立即部署到生产中，则意味着要在连续交付中运行一套更广泛的集成测试和系统测试以及其他检查（更多测试和更多检查需要更多时间），然后执行步骤进行部署，然后监视生产以进行生产。确保一切正常，如果出现问题请跳入。 即使大多数步骤都是自动化和优化的，所有这些都需要花费额外的时间，并且开发人员的注意力将转移到了编写代码上。
优化进出运营的工作流程意味着牺牲开发人员的流程，并减慢开发工作本身的速度。
期望，衡量标准和激励措施必须改变
在Devops中，开发人员（和操作人员）的工作方式发生了变化，而对他们的管理方式也发生了变化。 更改开发人员的期望，指标和激励措施也很重要。
Devops的成功是通过运营IT指标来衡量的 ，而不是根据是否满足范围，进度和成本的项目交付目标，而不是根据发布目标或冲刺承诺，甚至是产品设计目标来衡量 。
- 团队能够以多快的速度响应重要的更改和问题：将交货时间和周期更改为生产时间，而不是交付里程碑或速度
- 他们多久将更改推送到生产中（这仍然是大多数人最兴奋的指标-每天或每小时或每分钟或每分钟Etsy或Netflix或Amazon部署更改次数）
- 他们多久犯一次错- 变更/失败率
- 系统可靠性和正常运行时间– MTBF， 尤其是MTTD和MTTR
- 变更成本–以及总体运营和支持成本
Devops比Dev更注重Ops
随着越来越多的软件更早地交付到生产环境，开发变成了维护。 项目管理被事件管理和任务管理所取代。 计划的时间变得更短了–或计划被即时队列的优先级和分类所取代。
随着作为Code Ops的基础架构的开发人员的发展，设计和编码基础架构和基础架构的变化，考虑重用和可读性以及复制和重构 ，技术债务和可测试性，并在TDD上构建以实现TDI（ 测试驱动基础架构 ）。 它们变得更加敏捷和敏捷，从而更频繁地进行更小的更改，更多的时间编程和更少的书面工作。
开发人员开始更像ops。 承担运营和支持的责任，将运营风险放在首位，关心基础架构，构建运营工具，找到平衡近期对运营支持的短期需求与长期设计目标的方法。
对于已经从事在线业务一段时间的任何人来说，这都不会让他感到惊讶。 一旦交付了系统并且客户开始使用它，优先级就会改变，有关您的工作和计划方式的所有方面也必须改变。
这种工作方式对开发人员来说不是更好，或更糟。 但这与当今有多少开发人员的想法和工作有根本的不同。 更加疯狂和中断驱动。 同时，更加纪律和精益。 更透明。 更多的责任感和责任感。 与开发无关，而与发布和部署以及运营和支持有关的更多。
开发人员及其经理将需要习惯于运行IT的全局，这远不止于设计应用程序以及编写和交付代码。 这可能是软件开发的未来。 但是并不是所有的开发人员都会喜欢它或擅长于此。
694
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
