{"id":3138,"date":"2015-01-29T09:20:15","date_gmt":"2015-01-29T12:20:15","guid":{"rendered":"http:\/\/blog.dialhost.com.br\/?p=3138"},"modified":"2015-01-29T09:20:15","modified_gmt":"2015-01-29T12:20:15","slug":"devops-nao-esta-matando-os-desenvolvedores-mas-sim-produtividade-deles","status":"publish","type":"post","link":"https:\/\/www.dialhost.com.br\/blog\/devops-nao-esta-matando-os-desenvolvedores-mas-sim-produtividade-deles\/","title":{"rendered":"DevOps n\u00e3o est\u00e1 matando os desenvolvedores, mas sim a produtividade deles"},"content":{"rendered":"
\"computacao<\/a>
Imagem ilustrativa<\/figcaption><\/figure>\n

O DevOps n\u00e3o est\u00e1 matando os desenvolvedores<\/a> \u2013 pelo menos n\u00e3o todos os desenvolvedores que conhe\u00e7o. Mas est\u00e1 matando o desenvolvimento, ou a maneira como a maioria de n\u00f3s pensa em como devemos construir e entregar software. O Agile carregou a arma. O DevOps est\u00e1 puxando o gatilho.<\/p>\n

Fluxo em vez de entrega<\/strong>
\nA mudan\u00e7a radical est\u00e1 acontecendo na maneira como o software \u00e9 desenvolvido e entregue. Os projetos de desenvolvimento de software em cascata de grande escala deram lugar \u00e0 entrega em fases e abordagens em espiral<\/a>, e depois a equipes menores que entregam c\u00f3digo de trabalho em caixas de tempo<\/a> utilizando Scrum ou outros m\u00e9todos Agile iterativos. Agora as pessoas est\u00e3o passando de Scrum para Kanban<\/a>, e um fluxo cont\u00ednuo de entrega<\/a> de uma pe\u00e7a por vez, com implementa\u00e7\u00e3o imediata e cont\u00ednua de c\u00f3digo<\/a> para produ\u00e7\u00e3o em DevOps.<\/p>\n

A escala e o foco do desenvolvimento continuam diminuindo e o mesmo acontece com o prazo para a tomada de decis\u00f5es e para executar o trabalho. Fases, marcos e revis\u00f5es de projeto para sprints e reviews de Sprint para controles Lean al\u00e9m de limites WIP e a otimiza\u00e7\u00e3o de n\u00edvel 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\u00eas ou uma semana, para como um desenvolvedor individual pode come\u00e7ar a trabalhar na produ\u00e7\u00e3o em alguns dias ou algumas horas.<\/p>\n

A defini\u00e7\u00e3o de \u201cFeito\u201d<\/a> e \u201cSoftware Funcionando\u201d muda de algo que \u00e9 codificado, testado e pronto para demonstra\u00e7\u00e3o, para algo que est\u00e1 trabalhando na produ\u00e7\u00e3o \u2013 agora (\u201cConclu\u00eddo Significa Lan\u00e7ado\u201c<\/a>).<\/p>\n

A entrega cont\u00ednua<\/a> e a implementa\u00e7\u00e3o cont\u00ednua substituem a integra\u00e7\u00e3o cont\u00ednua. A implementa\u00e7\u00e3o r\u00e1pida para produ\u00e7\u00e3o n\u00e3o deixa tempo para testes ou para testadores manuais<\/a>, o que significa que os desenvolvedores s\u00e3o respons\u00e1veis pela captura de todos os pr\u00f3prios erros antes que o c\u00f3digo alcance a produ\u00e7\u00e3o<\/a> \u2013 ou fazer testes na produ\u00e7\u00e3o e tentar detectar os problemas quando eles acontecem (tamb\u00e9m conhecido como \u201cMonitoring as Testing<\/a>\u201c).<\/p>\n

Porque o DevOps aproxima muito mais os desenvolvedores da produ\u00e7\u00e3o, riscos operacionais tornam-se mais importantes do que os riscos do projeto, e as m\u00e9tricas operacionais<\/a> tornam-se mais importantes do que as m\u00e9tricas do projeto. O funcionamento do sistema e o tempo de ciclo para produ\u00e7\u00e3o substituem o valor agregado ou a velocidade. O estresse de alcan\u00e7ar os prazos \u00e9 substitu\u00eddo pelo estresse de combater inc\u00eandios na produ\u00e7\u00e3o e estar de plant\u00e3o.<\/p>\n

DevOps n\u00e3o \u00e9 sobre a entrega de um projeto ou mesmo fornecer recursos. Trata-se de minimizar o tempo necess\u00e1rio e maximizar o fluxo do trabalho para a produ\u00e7\u00e3o, reconhecer e eliminar o trabalho sucata e os atrasos e transferir, aumentar a confiabilidade do sistema e reduzir os custos operacionais, a constru\u00e7\u00e3o de loops de feedback da produ\u00e7\u00e3o para etapas do desenvolvimento, da padroniza\u00e7\u00e3o e automatiza\u00e7\u00e3o o m\u00e1ximo poss\u00edvel. \u00c9 mais sobre o controle de fabrica\u00e7\u00e3o<\/a> do que processo de engenharia.<\/p>\n

DevOps tamb\u00e9m mata produtividade do desenvolvedor<\/strong><\/p>\n

DevOps tamb\u00e9m mata a produtividade do desenvolvedor.<\/p>\n

Se voc\u00ea tentar medir a produtividade do desenvolvedor <\/a>por LOC, pontos de fun\u00e7\u00e3o<\/a>, pontos de recurso, Story Points<\/a>, velocidade <\/a>ou alguma outra medida do quanto de c\u00f3digo \u00e9 escrito, menos codifica\u00e7\u00e3o \u00e9 feita, porque os desenvolvedores est\u00e3o gastando mais tempo em trabalhos ops e lidando com interrup\u00e7\u00f5es, e menos tempo escrevendo c\u00f3digo.<\/p>\n

Tempo de aprendizado sobre a infraestrutura e plataforma e compreens\u00e3o sobre sua configura\u00e7\u00e3o, certificando-se de que \u00e9 a configura\u00e7\u00e3o correta. Construir pipelines de distribui\u00e7\u00e3o cont\u00ednua e implementa\u00e7\u00e3o cont\u00ednua e mant\u00ea-los em funcionamento. Ajudar ops a investigar e a resolver problemas, respondendo \u00e0s solicita\u00e7\u00f5es urgentes de clientes e \u00e0s perguntas, olhando para problemas de desempenho, monitorando o sistema para certificar-se de que ele est\u00e1 funcionando corretamente, ajudando a realizar experi\u00eancias A\/B, for\u00e7ando altera\u00e7\u00f5es e corre\u00e7\u00f5es\u2026 tudo rouba tempo do desenvolvimento e impede que eles pensem sobre requisitos, design, codifica\u00e7\u00e3o e testes (o trabalho para o qual os desenvolvedores s\u00e3o treinados e s\u00e3o bons em fazer).<\/p>\n

O impacto de interrup\u00e7\u00f5es e multitarefas<\/strong>
\nVoc\u00ea n\u00e3o pode proteger os desenvolvedores de interrup\u00e7\u00f5es e altera\u00e7\u00f5es nas prioridades em DevOps, mesmo que utilize Kanban com limites WIP estritos, e voc\u00ea n\u00e3o quer. Os desenvolvedores precisam ser responsivos \u00e0s opera\u00e7\u00f5es e aos clientes, reagir aos coment\u00e1rios de produ\u00e7\u00e3o, mergulhar nos problemas e ajudar a detectar e a resolver falhas o mais r\u00e1pido poss\u00edvel. Isso significa que todos, especialmente os seus colaboradores mais talentosos, precisam estar dispon\u00edveis para ops na maioria do tempo, se n\u00e3o o tempo todo.<\/p>\n

Os desenvolvedores se juntam aos ops de plant\u00e3o ap\u00f3s o hor\u00e1rio, o que significa carregar um pager ap\u00f3s o dia de trabalho. E o tempo desperdi\u00e7ado em liga\u00e7\u00f5es de suporte para problemas que acabam n\u00e3o sendo problemas reais, longas noites e fins de semana no combate a inc\u00eandios e rastreamento de problemas de produ\u00e7\u00e3o e ajudando a recuperar de falhas, chegando cansado no dia seguinte para passar mais tempo esgotado em incidente e testes de falhas e recupera\u00e7\u00e3o de avan\u00e7o e roll-back e participando de p\u00f3s-mortem e sess\u00f5es de an\u00e1lise de causa raiz quando algo d\u00e1 errado e a falha ou roll-forward ou roll-back n\u00e3o funciona.<\/p>\n

Voc\u00ea n\u00e3o pode planejar as interrup\u00e7\u00f5es e os problemas operacionais, o que significa que os desenvolvedores v\u00e3o perder seus compromissos com mais frequ\u00eancia. Ent\u00e3o, por que assumir compromissos? Por que se preocupar com planejamento ou estimativa<\/a>? Use a prioriza\u00e7\u00e3o 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\u00e1pido poss\u00edvel \u2013 a n\u00e3o ser que algo mais importante venha \u00e0 tona e se antecipe a isso.<\/p>\n

\u00c0 medida que os desenvolvedores aceitam mais tarefas e responsabilidades de suporte, multitarefas <\/a>e altern\u00e2ncia de tarefas \u2013 e as interrup\u00e7\u00f5es e as inefici\u00eancia que v\u00eam com eles <\/a>\u2013 aumenta-se a fragmenta\u00e7\u00e3o do tempo destruindo a concentra\u00e7\u00e3o. Isso tem um impacto imediato na produtividade e um de longo prazo sobre a capacidade das pessoas para pensar e resolver problemas<\/a>.<\/p>\n

At\u00e9 mesmo o pr\u00f3prio loop de feedback da implementa\u00e7\u00e3o cont\u00ednua \u00e9 uma interrup\u00e7\u00e3o no fluxo de um desenvolvedor.<\/p>\n

Depois que um desenvolvedor verifica o c\u00f3digo, executar os testes unit\u00e1rios em funcionamento na integra\u00e7\u00e3o cont\u00ednua deveria ser r\u00e1pido, levando alguns segundos ou minutos para que eles possam seguir em frente com o seu trabalho. Mas para implementar imediatamente na produ\u00e7\u00e3o significa executar por meio de um conjunto mais amplo de testes de integra\u00e7\u00e3o e de sistemas e outras verifica\u00e7\u00f5es na distribui\u00e7\u00e3o cont\u00ednua (mais testes e mais verifica\u00e7\u00f5es levam mais tempo), ent\u00e3o execute as etapas at\u00e9 a implementa\u00e7\u00e3o, e ent\u00e3o fa\u00e7a o monitoramento da produ\u00e7\u00e3o para se certificar de que tudo funcionou corretamente, e v\u00e1 fundo se alguma coisa der errado. Mesmo que a maioria das etapas seja automatizada e otimizada, tudo isso tira tempo e aten\u00e7\u00e3o do desenvolvedor para trabalhar no c\u00f3digo.<\/p>\n

Otimizar o fluxo de trabalho dentro e fora das opera\u00e7\u00f5es significa sacrificar o fluxo do desenvolvedor, e retardar o trabalho de desenvolvimento.<\/p>\n

Expectativas, m\u00e9tricas e incentivos t\u00eam que mudar<\/strong>
\nNo DevOps, a maneira como os desenvolvedores (e ops) trabalham e a maneira como eles precisam ser gerenciados mudam. Tamb\u00e9m \u00e9 fundamental mudar as expectativas, as m\u00e9tricas e os incentivos para os desenvolvedores.<\/p>\n

O sucesso de DevOps<\/a> \u00e9 medido por m\u00e9tricas operacionais de TI<\/a>, e n\u00e3o pelo cumprimento das metas de entrega escopo do projeto, cronograma e custo, nem pelo cumprimento das metas de lan\u00e7amento ou compromissos Sprint, ou at\u00e9 mesmo o cumprimento das metas de design de produtos.<\/p>\n