Kodus

Estamos colaborando com a BossaBox na elaboração de um relatório sobre liderança e gestão para CTOs, CPOs, Diretores e Heads de Produto e Tech. No estudo, eles mapearão quais técnicas de gestão que estão sendo mais eficientes em Estratégia, Pessoas e Processos. Pedimos para os líderes de tecnologia que quiserem ajudar, respondam neste link: https://lnkd.in/dMKRMrhi Leva apenas 4 minutos para completar! Como agradecimento, os respondentes terão acesso exclusivo ao relatório antecipadamente. Bora ajudar?

Provavelmente, você já ouviu falar de Lead Time. Apesar de ser muito utilizado pelas equipes de engenharia, o Lead Time frequentemente não é aproveitado ao máximo, pois as informações que ele fornece nem sempre são óbvias. Antes de explicar o que o Lead Time pode revelar, vamos fazer uma breve recapitulação do que ele é: ⌛️ Lead Time é o tempo total desde o início de uma solicitação até a sua entrega final. É uma medida crucial que ajuda a entender a eficiência e a capacidade de resposta da equipe. 🗡️ Você também pode analisar diferentes aspectos do Lead Time para entender melhor algumas informações sobre sua equipe. Por exemplo: • Lead Time em WIP: pode mostrar quanto tempo uma tarefa leva para ser concluída depois de ser iniciada pela equipe; • Lead Time por tipo de item: pode revelar anomalias no lead time de diferentes tipos de itens. Por exemplo, você sabia que os bugs podem ser os principais responsáveis pelo aumento do seu lead time? • Lead Time por coluna: permite identificar outliers e entender rapidamente onde estão os gargalos no processo. 📋 Aqui estão algumas informações que você pode obter ao analisar o Lead Time: • Quanto tempo a equipe tem levado para desenvolver um item de trabalho. • A saúde do processo de desenvolvimento, identificando gargalos ou aumento no tempo de passagem em alguma etapa do fluxo de desenvolvimento. • Casos extremos e o que pode ser aprendido com eles. • Se a equipe tem entregue os itens de trabalho dentro de um padrão de dias ou semanas. • Os efeitos que as incertezas e complexidades não mapeadas podem ter no tempo necessário para a conclusão dos itens de trabalho de uma equipe de desenvolvimento de software. • O lead time pode ser um excelente indicador de custo, pois quanto mais tempo algo leva para ser concluído, maior é o seu custo.

Quer entender melhor como está o desempenho do seu time de engenharia? As métricas DORA podem ser um bom caminho para isso. Essas métricas foram criadas por uma equipe no Google Cloud com o objetivo de avaliar o desempenho de DevOps e impulsionar a performance. Ela é dividida em 2 categorias (Velocidade e Estabilidade) e composta por 4 principais métricas: • Deployment Frequency • Lead Time for Changes • Mean Time to recovery • Change Failure Rate O que significa cada uma dessas métricas? 🤔 → Velocidade 🚀 Deployment Frequency Quantas vezes seu time coloca código em produção? Com base na pesquisa realizada pelo Google, equipes de elite fazem deploys em produção com muito mais frequência, algumas até várias vezes por dia. ⏰ Lead Time for Changes Quanto tempo leva desde que seu time faz o primeiro commit até estar em produção? Equipes de elite são capazes de recuperar de uma falha em menos de uma hora, enquanto equipes de alto desempenho conseguem recuperar em menos de um dia. → Estabilidade 🛠 Mean Time to Recovery Quando algo dá errado (e sempre dá), quanto tempo seu time leva para consertar? Segundo o último relatório Stat of DevOps 2023, times de elite levam menos de 1h, já times com um nível de desempenho médio leva entre um dia e uma semana. 🚧 Change Failure Rate Qual a porcentagem de deploys que resultam em falhas? Equipes de elite apresentam uma taxa de falha nas mudanças de aproximadamente 5% e equipes de baixo desempenho podem ter taxas de até 64%. Alguns benefícios que você pode colher ao acompanhar as métricas DORA: • Entender como está o desempenho do time • Entender como está a qualidade de entrega • Capacidade do time em lidar com incidentes. • Melhores estimativas

A gente adora fechar a semana com novidade! 🦊 🚀 Agora o cockpit tá disponível para mais membros do time! O que antes era restrito apenas ao owner da organização agora está acessível para todos os membros do time. Basta adicionar os membros nos times, e eles receberão um convite automaticamente. Isso facilita ainda mais a colaboração e a visibilidade para todos! 🚀 🤓 Implementação de fila nas automações Esta é uma atualização mais técnica, mas não podemos deixar de compartilhar! Migramos todas as automações e rotinas mais complexas para um sistema robusto de mensageria. Isso significa muito mais estabilidade e qualidade para nossa aplicação. 🔧✨ Acesse o changelog para saber mais sobre as novidades: https://lnkd.in/dGfNrNAJ

Como o Google está usando Machine Learning para automatizar a resolução de comentários em code reviews? Estudos indicam que desenvolvedores podem gastar até 35% do seu tempo em code reviews, um processo essencial, mas que consome muito tempo e pode ser uma fonte de frustração devido à repetitividade de algumas tarefas. O Google está usando Machine Learning para automatizar a resolução de comentários em code reviews. Isso significa que, ao invés de o desenvolvedor precisar interpretar e corrigir manualmente cada comentário, a IA sugere edições de código precisas e contextuais em tempo real durante a revisão. 📈 Impacto na produtividade: • Em média, 7.5% dos comentários de revisão de código são resolvidos aplicando edições sugeridas pela IA. • Isso se traduz em uma economia de centenas de milhares de horas de engenheiros anualmente! • Feedbacks extremamente positivos indicam um aumento significativo na produtividade e permitem que os desenvolvedores foquem em tarefas mais criativas e complexas. 🎯 O que isso significa para a engenharia de software? Esta abordagem não só melhora a velocidade e eficiência do processo de revisão de código, mas também ajuda na disseminação de conhecimento e boas práticas entre os desenvolvedores.

Seu time é de Produto ou de Feature? Em 2019, Marty Cagan, renomado autor do Vale do Silício, fez um post sobre times de produto vs times de features. Ele enfatizou a importância de termos um time focado em resolver problemas, um time de produto, e não um time de features. Após conversar com centenas de empresas no Brasil, observamos que a maioria dos times é, na realidade, de features. Mas, por quê? Antes de explicar os motivos que identificamos, vamos entender as principais diferenças: 🎯 Times de produto: Seu foco está em resolver problemas. Geralmente, uma métrica é priorizada para ser melhorada e o time deve encontrar a melhor maneira de fazer isso acontecer. O sucesso é alcançar essa métrica/resultado. Times de produto e engenharia trabalham em conjunto. 🏭 Times de feature: Seu foco está em entregar funcionalidades de um roadmap já priorizado. Um time externo, que pode ser chamado de produto ou negócio, prioriza um roadmap e o passa para o time de engenharia entregar. Seus processos são desenhados como uma fábrica de software. O sucesso é entregar a iniciativa no prazo. Como mencionamos, a maioria dos times está estruturada como times de Feature. Mas, por quê? 💜 Times de Feature também têm seu valor Ben Erez, em um excelente artigo da Newsletter do Lenny, traz ótimos pontos em defesa dos times de features. Em cenários com menor incerteza de produto, faz sentido priorizar a velocidade de entrega, visto que o maior risco é não entregar, e não a descoberta. 🚨 Falta de cultura e conhecimento do contexto Os times frequentemente não têm conhecimento do contexto para opinar e confrontar as decisões que vêm "de cima". Junto com a falta de uma cultura de resolução de problemas (os devs querem codar, não falar com o cliente), cria-se o ambiente perfeito para um time de features. ⌛️ Falta de maturidade da área Falando especificamente do Brasil, nossa área de produto e engenharia é muito recente. Para obtermos esse nível de "empoderamento" de time, precisamos cada vez mais de pessoas com experiências diversas para resolver problemas.

Finalizando a primeira semana de Julho com novos updates na Kody 🦊 Nessa semana, focamos bastante em criar novos alertas para o time, como o alerta de “Pull Request muito grande”. PRs grandes podem dificultar a revisão e atrasar todo o processo. Agora vamos notificar quando um PR exceder o tamanho ideal para garantir revisões mais eficientes. Além do alerta de PR, também lançamos mais dois alertas: ⏱ Tempo de Code Review 😰 Possível alta carga de trabalho individual Quer saber como esses alertas funcionam e conhecer outras atualizações da Kody? É só acessar o nosso changelog 👉 https://lnkd.in/dtR9NMfK

Estimar ou não? Eis a questão. Por um lado, temos stakeholders e lideranças que precisam de prazos para gerenciar entregas e a estratégia da empresa. Por outro lado, temos a equipe, que não dispõe de todas as informações necessárias e enfrenta mudanças de escopo a todo momento. A prática de estimar prazos e recursos é amplamente adotada, mas também amplamente debatida. Vamos explorar os dois lados dessa moeda? 🤔 Incerteza das Estimativas Iniciais Estimativas feitas no início de um projeto são frequentemente imprecisas devido ao conhecimento limitado sobre o escopo completo e os desafios que surgirão. Como Ron Jeffries argumenta em seu artigo "Estimation is Evil", essa incerteza inicial pode levar a prazos irrealistas. 😩 Impacto na Moral e Eficiência da Equipe Prazos irreais podem gerar pressão e estresse nas equipes, afetando a moral e a eficiência. Quando a prioridade é cumprir as estimativas ao invés de entregar valor real, a qualidade do trabalho pode sofrer. 🐌 Ineficiências no Processo Focar em cumprir estimativas pode levar ao desperdício de esforço em tarefas que não agregam valor real ao produto final. A prioridade deve ser resolver problemas à medida que surgem, não apenas cumprir um cronograma. 💰Necessidade para Planejamento e Orçamento As empresas precisam de estimativas para planejar recursos e orçamentos de maneira eficaz. As estimativas ajudam na comunicação com stakeholders e no estabelecimento de expectativas claras. Como achar um equilíbrio? 📊 Foque em estimativas utilizando métricas e não em chute de pessoas: Você por exemplo usar o Lead Time P75 para entender quanto tempo leva de uma tarefa ser concluída. Assim você consegue entender minimamente quando aquela tarefa PODE ficar pronta. 🎯 Não trate estimativas como assertivas: Estimativas, como o próprio nome diz, são uma referência estimada de quando algo pode ser finalizado. Não trate como certeza, é puramente estatística. 🏆 Foco no Valor em vez dos Prazos: Mudar a mentalidade de cumprimento de prazos para entrega de valor incentiva as equipes a resolverem problemas conforme surgem e a priorizarem as necessidades dos usuários. O debate sobre a utilidade das estimativas em projetos continua. É claro que há argumentos válidos em ambos os lados. No entanto, a chave pode estar em encontrar um equilíbrio: usar estimativas como uma ferramenta de planejamento flexível, enquanto se mantém o foco na entrega contínua de valor.

Se você quer seu time mais produtivo, você deveria focar em medir e melhorar a Developer Experience (DX). Segundo o Github, a Developer Experience é uma junção de 3 forças no time de engenharia: 📊 Produtividade + ⚡️Impacto + 😄 Satisfação = 💜 Developer Experience (DX) Vamos entender um pouco mais afundo cada uma delas. 📊 Produtividade: Reflete a eficiência dos desenvolvedores em concluir suas tarefas. Uma forma eficaz de medir isso é através das métricas de Fluxo, como "Lead Time for Changes", "Deployment Frequency" ou “Throughput” que indicam a rapidez e a frequência das entregas de software. ⚡️Impacto: Mede a relevância das contribuições dos desenvolvedores para os objetivos estratégicos da empresa. A "Change Failure Rate" é uma métrica DORA útil aqui, uma análise de tipos de itens trabalhados também pode ajudar. 😄 Satisfação: Esse aspecto se foca no bem-estar e no engajamento dos desenvolvedores com seu trabalho. Pesquisas de satisfação, como formulários customizados ou ferramentas de bem estar, podem fornecer insights valiosos sobre a moral e a motivação da equipe. Mas porque é importante? Bem simples, aumenta a produtividade e os resultados do time de engenharia. Alguns resultados de empresas que aplicam DX no dia dia: • Melhora de tempo de flow dos devs e consequentemente melhora na produtividade; • Redução no Time To Market • Maior retenção de pessoas

E ai, vamos de update? Neste mês, nosso time trabalhou bastante para trazer novas funcionalidades e melhorias para a Kody. 🦊 Como parte da nossa missão de proporcionar mais visibilidade e autonomia para os times, estamos animados em anunciar a introdução das Dora Metrics em nossa engine de métricas. 🌟 Além das novas métricas, realizamos várias melhorias visuais no cockpit. Agora, além da visualização de artefatos em nível de sistema, você pode visualizar artefatos específicos de cada time. Quer ver essas e outras novidades que rolou na Kody em junho? Dá uma olhada no nosso vídeo. 😉 https://lnkd.in/dJ_59mEa