O DevOps não está matando os desenvolvedores – pelo menos não todos os desenvolvedores que conheço. Mas está matando o desenvolvimento, ou a maneira como a maioria de nós pensa em como devemos construir e entregar software. O Agile carregou a arma. O DevOps está puxando o gatilho.

Fluxo em vez de entrega

A mudança radical está acontecendo na maneira como o software é desenvolvido e entregue. Os projetos de desenvolvimento de software em cascata de grande escala deram lugar à entrega em fases e abordagens em espiral, e depois a equipes menores que entregam código de trabalho em caixas de tempo utilizando Scrum ou outros métodos Agile iterativos. Agora as pessoas estão passando de Scrum para Kanban, e um fluxo contínuo de entrega de uma peça por vez, com implementação imediata e contínua de código para produção em DevOps.

A escala e o foco do desenvolvimento continuam diminuindo e o mesmo acontece com o prazo para a tomada de decisões e para executar o trabalho. Fases, marcos e revisões de projeto para sprints e reviews de Sprint para controles Lean além de limites WIP e a otimização de nível de tarefa. O tamanho das entregas: do que uma equipe de projeto pode entregar em um ano para o que uma equipe Scrum pode fazer em um mês ou uma semana, para como um desenvolvedor individual pode começar a trabalhar na produção em alguns dias ou algumas horas.

A definição de “Feito” e “Software Funcionando” muda de algo que é codificado, testado e pronto para demonstração, para algo que está trabalhando na produção – agora (“Concluído Significa Lançado“).

A entrega contínua e a implementação contínua substituem a integração contínua. A implementação rápida para produção não deixa tempo para testes ou para testadores manuais, o que significa que os desenvolvedores são responsáveis pela captura de todos os próprios erros antes que o código alcance a produção – ou fazer testes na produção e tentar detectar os problemas quando eles acontecem (também conhecido como “Monitoring as Testing“).

Porque o DevOps aproxima muito mais os desenvolvedores da produção, riscos operacionais tornam-se mais importantes do que os riscos do projeto, e as métricas operacionais tornam-se mais importantes do que as métricas do projeto. O funcionamento do sistema e o tempo de ciclo para produção substituem o valor agregado ou a velocidade. O estresse de alcançar os prazos é substituído pelo estresse de combater incêndios na produção e estar de plantão.

DevOps não é sobre a entrega de um projeto ou mesmo fornecer recursos. Trata-se de minimizar o tempo necessário e maximizar o fluxo do trabalho para a produção, reconhecer e eliminar o trabalho sucata e os atrasos e transferir, aumentar a confiabilidade do sistema e reduzir os custos operacionais, a construção de loops de feedback da produção para etapas do desenvolvimento, da padronização e automatização o máximo possível. É mais sobre o controle de fabricação do que processo de engenharia.

DevOps também mata produtividade do desenvolvedor

DevOps também mata a produtividade do desenvolvedor.

Se você tentar medir a produtividade do desenvolvedor por LOC, pontos de função, pontos de recurso, Story Points, velocidade ou alguma outra medida do quanto de código é escrito, menos codificação é feita, porque os desenvolvedores estão gastando mais tempo em trabalhos ops e lidando com interrupções, e menos tempo escrevendo código.

Tempo de aprendizado sobre a infraestrutura e plataforma e compreensão sobre sua configuração, certificando-se de que é a configuração correta. Construir pipelines de distribuição contínua e implementação contínua e mantê-los em funcionamento. Ajudar ops a investigar e a resolver problemas, respondendo às solicitações urgentes de clientes e às perguntas, olhando para problemas de desempenho, monitorando o sistema para certificar-se de que ele está funcionando corretamente, ajudando a realizar experiências A/B, forçando alterações e correções… tudo rouba tempo do desenvolvimento e impede que eles pensem sobre requisitos, design, codificação e testes (o trabalho para o qual os desenvolvedores são treinados e são bons em fazer).

O impacto de interrupções e multitarefas

Você não pode proteger os desenvolvedores de interrupções e alterações nas prioridades em DevOps, mesmo que utilize Kanban com limites WIP estritos, e você não quer. Os desenvolvedores precisam ser responsivos às operações e aos clientes, reagir aos comentários de produção, mergulhar nos problemas e ajudar a detectar e a resolver falhas o mais rápido possível. Isso significa que todos, especialmente os seus colaboradores mais talentosos, precisam estar disponíveis para ops na maioria do tempo, se não o tempo todo.

Os desenvolvedores se juntam aos ops de plantão após o horário, o que significa carregar um pager após o dia de trabalho. E o tempo desperdiçado em ligações de suporte para problemas que acabam não sendo problemas reais, longas noites e fins de semana no combate a incêndios e rastreamento de problemas de produção e ajudando a recuperar de falhas, chegando cansado no dia seguinte para passar mais tempo esgotado em incidente e testes de falhas e recuperação de avanço e roll-back e participando de pós-mortem e sessões de análise de causa raiz quando algo dá errado e a falha ou roll-forward ou roll-back não funciona.

Você não pode planejar as interrupções e os problemas operacionais, o que significa que os desenvolvedores vão perder seus compromissos com mais frequência. Então, por que assumir compromissos? Por que se preocupar com planejamento ou estimativa? Use a priorização just-in-time, em vez de se concentrar na coisa mais importante que os ops ou o cliente precisam no momento, e entregue o mais rápido possível – a não ser que algo mais importante venha à tona e se antecipe a isso.

À medida que os desenvolvedores aceitam mais tarefas e responsabilidades de suporte, multitarefas e alternância de tarefas – e as interrupções e as ineficiência que vêm com eles – aumenta-se a fragmentação do tempo destruindo a concentração. Isso tem um impacto imediato na produtividade e um de longo prazo sobre a capacidade das pessoas para pensar e resolver problemas.

Até mesmo o próprio loop de feedback da implementação contínua é uma interrupção no fluxo de um desenvolvedor.

Depois que um desenvolvedor verifica o código, executar os testes unitários em funcionamento na integração contínua deveria ser rápido, levando alguns segundos ou minutos para que eles possam seguir em frente com o seu trabalho. Mas para implementar imediatamente na produção significa executar por meio de um conjunto mais amplo de testes de integração e de sistemas e outras verificações na distribuição contínua (mais testes e mais verificações levam mais tempo), então execute as etapas até a implementação, e então faça o monitoramento da produção para se certificar de que tudo funcionou corretamente, e vá fundo se alguma coisa der errado. Mesmo que a maioria das etapas seja automatizada e otimizada, tudo isso tira tempo e atenção do desenvolvedor para trabalhar no código.

Otimizar o fluxo de trabalho dentro e fora das operações significa sacrificar o fluxo do desenvolvedor, e retardar o trabalho de desenvolvimento.

Expectativas, métricas e incentivos têm que mudar

No DevOps, a maneira como os desenvolvedores (e ops) trabalham e a maneira como eles precisam ser gerenciados mudam. Também é fundamental mudar as expectativas, as métricas e os incentivos para os desenvolvedores.

O sucesso de DevOps é medido por métricas operacionais de TI, e não pelo cumprimento das metas de entrega escopo do projeto, cronograma e custo, nem pelo cumprimento das metas de lançamento ou compromissos Sprint, ou até mesmo o cumprimento das metas de design de produtos.

• Quão rápido o time pode responder às mudanças e aos problemas importantes: alterar tempo de entrega e tempo de ciclo para produção em vez de entregar milestones ou velocidade
• Quantas vezes eles forçam as alterações para a produção (que ainda é a métrica com a qual a maioria das pessoas está mais animada – quantas vezes por dia, hora ou minuto Etsy, Netflix ou Amazon implementam mudanças)
• Quantas vezes eles cometem erros – Taxa de mudança/erro
• A confiabilidade do sistema e o tempo de atividade – MTBF e especialmente MTTD e MTTR
• Custo da mudança – Operações gerais e os custos de suporte

DevOps é mais sobre Ops do que Dev

À medida que mais softwares são entregues mais cedo e com mais frequência para a produção, o desenvolvimento se transforma em manutenção. O gerenciamento de projetos é substituído pelo gerenciamento de incidentes e de tarefas. O planejamento de horizontes fica muito mais curto – ou o planejamento é substituído por priorização da fila e triagem just-in-time.

Com a infraestrutura como código, Ops se tornam desenvolvedores, projetando e codificando infraestrutura e mudanças de infraestrutura, pensando pensando sobre a reutilização e a facilidade de leitura, duplicação e refatoração, a dívida técnica, a capacidade de teste e a construção em TDD para implementar TDI (Test Driven Infrastructure). Eles se tornam mais e mais Agile, fazendo pequenas mudanças com mais frequência, mais tempo de programação e menos em trabalho burocrático.

E os desenvolvedores começam a trabalhar mais como ops, assumindo responsabilidades de operações e suporte, colocando riscos operacionais em primeiro lugar, preocupando-se com a infraestrutura, construindo ferramentas de operações, encontrando formas de equilibrar as demandas imediatas de curto prazo para apoio operacional com objetivos de projeto de longo prazo.

Nada disso será uma surpresa para quem já vem trabalhando em um negócio online há algum tempo. Uma vez que você oferece um sistema e os clientes começam a usá-lo, as prioridades mudam, tudo sobre a maneira como você trabalha e plano têm que mudar também.

Essa forma de trabalhar não é, necessariamente, melhor ou pior para os desenvolvedores. Mas é fundamentalmente diferente de como muitos desenvolvedores pensam e trabalham hoje. É mais frenético e baseado em interrupções. Ao mesmo tempo, é mais disciplinado e mais improdutivo. Mais transparente. Exige mais responsabilidade e prestação de contas. É menos sobre desenvolvimento e mais sobre o lançamento, a implementação, as operações e o apoio.

Os desenvolvedores – e seus gestores – precisarão se acostumar a fazer parte do panorama geral de executá-lo, o que é muito mais do que projetar aplicativos, escrever e entregar o código. Esse pode ser o futuro do desenvolvimento de software. Mas nem todos os desenvolvedores vão gostar, ou ser bom no que fazem.

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2014/07/develops-isnt-killing-developers-but-it.html