Você está entregando a experiência do desenvolvedor?

Décadas atrás, “The Mythical Man-Month: Essays on Software Engineering” apresentou aos gerentes alguns dos custos e atritos que os desenvolvedores de software enfrentavam e que não eram corretamente encapsulados pelo trabalho e pelo tempo. Isso incluiu tempo de comunicação e coordenação:

“Em algum lugar, neste momento, um desenvolvedor de software está abrindo um ticket da lista de pendências do projeto, entusiasmado com a perspectiva de trabalhar em algo novo. À medida que o desenvolvedor começa a ler a descrição da tarefa, seu laptop é subitamente inundado com alertas do sistema de rastreamento de erros de produção da equipe, interrompendo a capacidade de concentração do desenvolvedor. Eventualmente, voltando à tarefa em questão, o desenvolvedor estuda os requisitos descritos no ticket. Infelizmente, a tarefa carece de contexto e clareza, por isso o desenvolvedor pede ajuda, o que levará dias para ser resolvido. Enquanto isso, o desenvolvedor verifica uma tarefa anterior, que está parada na fila aguardando aprovação há vários dias. Os testes e compilações falham repetidamente, interrompendo o progresso dos revisores cada vez que eles tentam verificar as alterações. À medida que o desenvolvedor salta de tarefa em tarefa, na esperança de finalmente mergulhar em algum trabalho profundo, ele percebe que o experiência não é tão bom quanto deveria ser para permitir seu melhor trabalho.”

Se “The Mythical Man-Month” ilustrou distrações que impediam os desenvolvedores de apenas trabalhar na tarefa em questão, então a pesquisa sobre a experiência do desenvolvedor mostrou que existem barreiras para que os desenvolvedores façam o melhor trabalho possível, dado o tempo de que dispõem.

Um artigo recente no ACM Queue resume problemas que os desenvolvedores modernos enfrentam além daqueles descritos anteriormente.

Os sistemas podem ter atributos que interferem no melhor trabalho possível do software, especificamente aqueles que atrasam e interferem no feedback, interrompem o fluxo e desencorajam a conexão e a colaboração.

Como os problemas no DevEx prejudicam a produtividade do desenvolvedor

Quando as coisas estão funcionando bem para um desenvolvedor, é muito fácil saber: os recursos são entregues, os problemas emergentes são descobertos antes que afetem os usuários e a equipe frequentemente encontra “soluções rápidas” e “frutas fáceis de alcançar” para entregar mais do que o escopo original em um período semelhante. O sucesso geralmente ecoa desde melhores relatórios sobre metas de desenvolvimento alcançadas até uma melhor experiência do usuário, gerando mais vendas.

Mas quando as coisas não funcionam bem, as evidências são muitas vezes muito mais ambíguas. Prazos perdidos acontecem, nem sempre são evidências de um problema e podem ser apenas erros no planejamento original. Mesmo regressões de recursos que chegam até a produção podem ser aceitáveis ​​sob metodologias ágeis. Mas quando todas essas questões são consideradas em conjunto, é fácil perceber, pelo sentimento da equipe, que algo está podre no estado do DevEx.

No artigo do ACM Queue “DevEx em ação”, os autores categorizam algumas das causas imediatas para uma experiência ruim do desenvolvedor (DevEx):

1. Os desenvolvedores raramente entram no ‘Flow’

Tenho um saco de amêndoas na minha mesa agora. Eles são revestidos com um pó sabor descrito como “wasabi com molho de soja” e eu absolutamente os adoro. Isso explica por que os tenho, mas não por que estão na minha mesa do escritório, especialmente porque uma curta caminhada pelo meu jardim me levará à minha linda cozinha, caso eu precise de um lanche. Por que as amêndoas de mesa? A razão é o fluxo. Quando estou trabalhando em algo interessante, estimulante e desafiador, não quero ter que parar a cada 90 minutos para fazer um pequeno lanche. Notei que as últimas duas horas da manhã e o início da tarde eram frequentemente interrompidos não pela necessidade de uma pausa, mas pela simples fome.

Com as amêndoas da minha mesa, posso pegar um punhado rápido e continuar cantarolando até chegar a hora de uma pausa mais longa para passear com o cachorro, cheirar as flores e preparar um almoço adequado.

Não vou insistir na criticidade do fluxo: pode levar horas para voltar a esse estado, uma vez quebrado – mesmo uma conversa de um minuto pode quebrar esse estado – e um desenvolvedor bem focado pode fazer isso em algumas horas de “estado de fluxo”. ”Trabalho que de outra forma poderia levar uma semana.

Como o fluxo é interrompido? Uma resposta óbvia são as repetidas interrupções do dia de um desenvolvedor para responder pequenas perguntas de outras equipes. Espera-se que uma equipe pequena se comunique para colaborar, mas se um desenvolvedor estiver respondendo perguntas de gerentes de projeto, especialistas de suporte e vendas — mesmo que essas solicitações ocupem uma pequena porcentagem do tempo do desenvolvedor — essas breves perguntas espalhadas ao longo do dia podem ser suficientes para garantir que nenhum desenvolvedor tenha duas horas ininterruptas.

Para mencionar um inimigo do fluxo que deveria ser quase evidente: os programadores precisam estar confortáveis, e mais importante do que uma cadeira Aeron é um IDE que o desenvolvedor conhece e adora. Certa vez, trabalhei em uma equipe que, em grande parte por decisão e não por decisão organizada, estava adotando o AWS Lambda para muitas pequenas tarefas de computação. Como ninguém realmente havia tomado a decisão de fazer essa migração no atacado e como a equipe não estava bem versada na integração de CI/CD com a AWS, isso resultou em grande parte do trabalho de codificação real acontecendo na interface da web do AWS Lambda. Nem é preciso dizer, mas ter que escrever código em um site que o desenvolvedor nunca usou antes não é uma receita para o fluxo.

Uma consideração ao considerar o fluxo é a dificuldade de levar uma ideia do IDE do desenvolvedor para um ambiente de teste. Um entrevistado citado em “Uma estrutura acionável para compreender e melhorar a experiência do desenvolvedor” disse:

“A primeira coisa que me veio à mente foi em torno das ferramentas ou de qualquer atrito em torno das ferramentas que torna realmente fácil passar de ‘estou trabalhando em uma ideia’ para ‘estou testando essa ideia’ e produção ou o ferramental torna doloroso ir do ponto A ao ponto B.”

Freqüentemente discutimos a “mudança para a esquerda” dos testes como se fosse uma palavra da moda abstrata de produto ou, pior, um grito de guerra para fazer com que os desenvolvedores que trabalham duro assumam responsabilidades técnicas ainda mais indesejadas. Mas, na verdade, o teste shift-left (colocar mais ferramentas de teste nas mãos dos desenvolvedores que fizeram as alterações) consiste em criar um estado de fluxo onde os desenvolvedores podem tentar coisas novas, experimentar e ver como suas alterações interagem com todo o sistema antes de outro usuário. ou um processo de implantação deve estar envolvido.

2. Sem conexão e colaboração, a criatividade sofre

No exemplo acima de “DevEx in Action”, os autores começam com um desenvolvedor que não consegue identificar claramente os requisitos para seu próximo recurso. Este é o exemplo clássico de colaboração deficiente em software. Sem requisitos claros, o trabalho não pode realmente começar e, se prosseguir, é provável que o trabalho siga na direção errada. Deveríamos pensar mais profundamente sobre o que a verdadeira colaboração pode nos proporcionar e como ela é prejudicada pelo isolamento.

Um efeito secundário da mania de grandes modelos de linguagem é o reconhecimento do valor da criatividade na engenharia de alta qualidade. É verdade há décadas que qualquer pessoa com um modelo de objeto preciso para um banco de dados pode usar uma ferramenta de software para criar uma API para esse banco de dados. Mas a conexão real entre armazenamentos de dados e necessidades de negócios é mais do que publicar mecanicamente cada linha e coluna como um terminal. A criatividade também exige que os desenvolvedores e outras partes interessadas colaborem de maneira significativa.

Em um projeto de serviço business-to-consumer, certa vez passei um trimestre desenvolvendo um sistema telefônico automatizado usando uma versão inicial do Twillio. Implementei filas, retenções, chamadas em conferência, etc. Meses após o início do projeto, eu estava em um piquenique com toda a equipe e perguntei à mesa: “Nossos clientes alguma vez nos ligam?” Foi então que descobri que as chamadas telefônicas recebidas eram o nosso número. 1 fonte de receita. Se eu soubesse disso antes, todo o meu projeto teria um escopo diferente. Eu tinha todos os requisitos para o meu projeto, mas as necessidades básicas do negócio nunca ficaram claras para mim e perdi semanas em ferramentas de chamadas ativas que eram de prioridade extremamente baixa.

Naquele piquenique, quase ri ao ver como não sabia como essa empresa realmente ganhava dinheiro. Com uma colaboração deficiente, nenhum desenvolvedor pode sentir que seu trabalho é realmente valorizado e que está fazendo o melhor que pode.

3. O feedback é de baixa qualidade e o progresso é prejudicado

Quando dizemos “feedback de baixa qualidade”, não queremos dizer feedback que não seja claro ou inútil, mas sim que se refere a encontrar questões que são comunicadas muito lentamente ou de uma forma que requer trabalho extra de interpretação. Vamos começar com o feedback que chega na hora errada.

Um conceito crítico na experiência moderna do desenvolvedor é o “loop interno” de feedback sobre alterações no código. Quando um desenvolvedor tem um sistema rápido e familiar para obter feedback sobre seu código, ele incentiva vários ciclos de teste e experimentação antes que o código seja implantado em um ambiente de teste final ou produção. O “loop externo” de feedback envolve um processo mais formal de propor testes, mesclar alterações, executar a integração e, em seguida, testes de ponta a ponta. Quando são encontrados problemas no loop externo, o resultado são implantações maiores e mais lentas, com os desenvolvedores recebendo feedback horas ou dias depois de escreverem o código.

O teste de loop externo ainda pode ser um teste automatizado e iniciado pelo desenvolvedor original, mas outro problema comum com o feedback que vem posteriormente no ciclo de lançamento é que ele vem de testadores humanos ou de outras pessoas no processo de lançamento. Isso geralmente resulta em feedback sintomático, em vez de identificar as causas raízes.

Quando o feedback não é claro, é tão ruim ou pior do que requisitos pouco claros: os desenvolvedores não conseguem trabalhar rapidamente em problemas que não diagnosticaram e muitas vezes passam para outros projetos no período entre a implantação e a localização de um problema. Essa natureza fora da banda de resolução de problemas encontrada no controle de qualidade também cria pressão para minimizar os problemas; Em vez de trabalhar em uma solução, há uma tendência natural de argumentar que o problema é menor ou não foi causado por mudanças recentes. Por fim, ter outra pessoa informando sobre um problema é naturalmente uma quebra de fluxo, pois o desenvolvedor precisa mudar de contexto.

Nenhuma falha caracteriza um DevEx ruim

Para massacrar a abertura de Ana Karenina: Os bons dias de desenvolvimento são todos iguais; cada dia de baixa produtividade é ruim à sua maneira. Não é possível procurar um obstáculo à produtividade e dizer: “Essa é a única causa da nossa má experiência de desenvolvimento”. Você deve examinar vários fatores contribuintes. Em geral, a confluência de fluxo deficiente, barreiras à colaboração e feedback inoportuno são três barreiras comuns para uma experiência de desenvolvedor e produtividade de alta qualidade.

Para que você não pense que as causas complexas da má experiência do desenvolvedor dificultam a medição, na verdade é um pouco mais fácil ver esse problema do que curá-lo. É bem possível medir uma falha do DevEx. Afinal, DevEx abrange como os desenvolvedores se sentem, pensam e valorizam seu trabalho. Ao pesquisar e medir o sentimento dos desenvolvedores, é fácil ver um problema geral na experiência do desenvolvedor.

Conclusões: Levando a sério a experiência do desenvolvedor

Levar a sério a experiência do desenvolvedor requer uma abordagem que reconheça a complexidade do desenvolvimento de software como uma atividade centrada no ser humano. Não se trata apenas de selecionar as ferramentas certas ou aplicar processos, mas de criar um ambiente onde os desenvolvedores possam prosperar, inovar e entregar seu melhor trabalho. Isto envolve abordar as principais questões identificadas: garantir que os desenvolvedores possam alcançar e manter o fluxo, promover a colaboração e a comunicação eficazes e fornecer feedback oportuno e de alta qualidade.

No seguimento deste artigo, escreverei sobre como compreender e melhorar a experiência do seu desenvolvedor. Para ajudar na mudança de testes e feedback do desenvolvedor, considere o Signadot, que permite que os desenvolvedores executem testes e experimentações em um cluster que contém todos os serviços e recursos necessários. Ao permitir que os desenvolvedores executem testes de integração muito mais cedo do que antes, até mesmo equipes muito grandes podem permitir que um único desenvolvedor obtenha um rápido ciclo interno de feedback sobre suas alterações.

A postagem Você está entregando a experiência do desenvolvedor? apareceu primeiro em The New Stack.