nossa experiência de usar métricas ágeis mais comuns

nossa experiência de usar métricas ágeis mais comuns

usar métricas ágeis para medir a produtividade da equipe é a parte fundamental da filosofia da Agile. Os gerentes de equipe e todos os membros devem ver as consequências de seu trabalho e usar esses dados para melhorar o fluxo de trabalho e aumentar a eficiência.

usuários finais e clientes também podem se beneficiar do uso de métricas de projeto ágeis que se concentram na avaliação do resultado do produto. As métricas permitem que Scrum masters, desenvolvedores, designers e testadores Medam o desempenho do aplicativo e rastreiem se as tarefas atuais e anteriores tornam o produto melhor. Neste artigo, revisaremos métricas ágeis que importam e compartilharemos nossa experiência de aplicar esse painel de métricas ágeis a um projeto da vida real. Acontece que, para liderar uma equipe com sucesso e entregar resultados, você não só precisa saber quais métricas aplicar, mas como fazê — lo-compartilharemos como descobrimos isso.

tipos de métricas ágeis comuns

a classificação de métricas ágeis não está definida em pedra — está sempre mudando e reestruturando. Ainda assim, ao longo dos anos, vimos o aumento de três tipos principais de métricas ágeis em várias estruturas ágeis.

1. métricas Kanban – essas métricas são baseadas na medição do tempo investido (tempos de ciclo) e resultados entregues (taxa de transferência) e sua proporção.
2. Scrum métricas métricas, que são voltadas para o planejamento e a compreensão do fluxo de trabalho e demonstrando o quanto o trabalho foi realizado em um determinado período;
3. métricas Lean — medição contínua da eficiência de produção e qualidade do produto com a avaliação técnica, funções de testes, verificando possíveis erros, e prevendo efeitos negativos.

Podemos usar todos os três tipos de métricas para avaliar os principais aspectos do processo de desenvolvimento de software e resultados: qualidade do produto, produtividade da equipe e saúde.

métricas ágeis de qualidade

Antes de começar a medir a velocidade e a eficiência da equipe, você precisa saber se geralmente está se movendo na direção certa. Qual é o uso na entrega imediata de todas as tarefas de desenvolvimento, se as tarefas em si forem formadas da maneira errada? A prioridade para cada equipe e gerente de desenvolvimento de software é garantir que todas as atividades estejam relacionadas à melhoria do produto — isso é feito medindo sua qualidade e detectando tendências negativas.

defeitos escapados

cada projeto ágil tem sprints ou ciclos de trabalho, no final dos quais uma determinada tarefa é entregue. Depois que o trabalho foi concluído, o Gerente da equipe deve avaliar a qualidade dos resultados transformados. Todas as alterações, edições e bugs não corrigidos são defeitos escapados — problemas que os desenvolvedores poderiam ter corrigido, mas não. registre seu número e natureza precisos para saber quais erros geralmente escapam aos olhos dos desenvolvedores.

depois de fazer um relatório sobre defeitos escapados e coletar estatísticas tangíveis, você precisa discutir os resultados com sua equipe. Certifique-se de que cada membro da equipe saiba que tipos de erros a equipe normalmente perde. Se você tiver sugestões individuais, discuta-as com os membros da equipe individualmente.

implantações com falha

se o produto foi implantado, mas não foi lançado ou não conseguiu atrair usuários, isso é registrado como uma implantação com falha. Às vezes, uma implantação com falha acontece com as decisões de uma das partes interessadas, ou o modelo de negócios não é confiável. Seja qual for a causa do problema, você precisa registrar todas as implantações com falha, juntamente com os motivos de sua falha.

Antes de lançar uma nova implantação, a equipe sempre pode dar uma olhada na lista de implantações com falha anterior e examinar se esta não pode passar pelo mesmo processo. Analisar os motivos do fracasso das versões anteriores permite evitar problemas futuros.

Lançamento Net Promoter Score (NPS)

O Net Promoter Score é a métrica que envolve a avaliação dos usuários reações em termos quantitativos (números, estatísticas, classificações médias) e qualitativa feedback (comentários, feedback direto, mensagens, e-mails, chamadas). Depois que a equipe coletou e analisou o feedback, cada membro da equipe sugere uma pontuação que avalia o quanto o usuário provavelmente recomendará o produto (normalmente, as pontuações são definidas em limites de 1 a 10).

métricas ágeis de gerenciamento de projetos

depois de ter um histórico completo de falhas e sucessos anteriores, você pode analisar a direção tomada para todos os projetos incompletos atuais e distribuir tarefas relevantes, contando com experiências anteriores. Depois de estabelecer a direção do desenvolvimento — o” o que fazer” do produto”, você precisa avaliar a eficiência da equipe-é o fator” como estamos indo”. Você pode usar métricas de projeto ágeis para saber se os membros da equipe atendem às suas expectativas, entendem suas tarefas, gerenciam prazos e se todos os processos são coordenados e sincronizados.

Lead time

Lead time é uma métrica que permite que as equipes verifiquem quanto demorou para que a entrada do backlog do produto chegasse ao final do sprint. Ele pode ser usado para rastrear produtos em qualquer estágio de desenvolvimento, tarefa por tarefa ou avaliar as despesas gerais de tempo, da ideação à liberação. É uma métrica de longo prazo que os desenvolvedores podem usar enquanto planejam seu trabalho futuro e estimam os preços.

certifique-se de registrar o lead time para cada um de seus projetos. É melhor manter estatísticas de imagem maior que cubram todo o projeto e organizaram métricas de sprint — para que você possa examinar cada estágio separadamente.

tempo de ciclo

se o Lead Time estiver entre as métricas de desempenho de equipe de longo prazo, o tempo de ciclo se concentra em tarefas individuais. Essa métrica avalia a duração de um único ciclo, em que um ciclo é realizado por uma tarefa, calcula o número de ciclos por projeto e mede os resultados alcançados para o usuário final se o produto já estiver beta-testado ou liberado.

com o tempo de ciclo, as equipes podem ver imediatamente se uma tarefa leva muito tempo ou se alguns membros da equipe não estão entregando em suas extremidades. Essa métrica de curto prazo torna o gerenciamento de projetos muito mais fácil e ajuda a identificar rapidamente os problemas à medida que surgem.

Sprint burndown

esta métrica é aplicada a curto e longo prazo. Os gerentes podem criar relatórios sprint burndown Scrum em tempo real para acompanhar o progresso de sua equipe no projeto atual-para isso, eles precisam estimar o número total de sprints e prever despesas prováveis de tempo. Também pode ser usado a longo prazo-os gerentes podem analisar relatórios sobre projetos anteriores, identificar estágios que falharam nos prazos esperados e analisar as causas dos atrasos.

o mais importante, o sprint burndown permite rastrear a dinâmica do fluxo de trabalho das equipes. Alguns membros tendem a trabalhar mais devagar nos primeiros estágios, enquanto outros se esgotam no final do projeto. Com o sprint burndowns, os líderes de equipe podem detectar essas tendências, determinar suas causas e ajudar os membros com distribuição de trabalho e gerenciamento de tempo.

Épico & Release burndown

Esta métrica é semelhante ao Sprint Burndown — a única diferença é que ele se concentra na produtividade da equipe, antes e após o lançamento. Os gerentes podem adicionar novos requisitos e incorporar tarefas baseadas no feedback dos usuários finais. É uma versão melhorada do sprint burndown, pois também incorpora tarefas dadas após o lançamento do projeto.

Velocity

esta métrica avalia o número de pontos de história concluídos em um determinado período. Com base em seu histórico, você pode prever despesas de tempo para futuros pontos da história. A diminuição da velocidade da equipe em sprints específicos pode apontar para mal-entendidos entre os membros da equipe ou tarefas indicadas que são mais difíceis do que o previsto anteriormente.

métricas ágeis adicionais

métricas ágeis ajudam a equipe a conhecer melhor seu projeto e acompanhar muitos aspectos significativos do desenvolvimento de produtos. Existem também métricas ágeis para executivos seniores que permitem ver a imagem maior do desenvolvimento e o bem-estar da equipe. De acordo com nossa experiência, essas métricas adicionais ajudam a medir qualquer aspecto do seu trabalho. No entanto, definimos as principais características que mais informam sobre o produto final e ajudam a fornecer um resultado totalmente completo.

fluxo cumulativo

o nome da métrica comunica claramente sua finalidade-acumular todos os fluxos do projeto e avaliá-los em um único diagrama. Ter esse gráfico fornecerá uma visão em grande escala — ela pode ser enviada às partes interessadas do projeto que não têm tempo para analisar relatórios ágeis mais detalhados.

o diagrama geralmente descreve os seguintes processos:

• tarefas no backlog: quantas tarefas os membros da equipe do backlog têm ao longo do prazo;
• Trabalho aprovado: quantas tarefas entre planejadas foram concluídas — o gerente de equipe imediatamente vê diferenças entre o planejado e finalizado atividades;
• Buffer de tarefas: todo o trabalho que está aguardando aprovação é definido para estar em uma zona tampão;
• Em andamento: você precisa avaliar a carga de trabalho atual.

rotatividade de código

esta métrica mostra as tendências das alterações da base de código antes do lançamento. Os diagramas de rotatividade mostram quanto código foi adicionado, removido ou alterado uma vez por vez. Nos primeiros sprints, haverá muitos picos e quedas no gráfico, porque o código ainda é instável, mas à medida que o projeto avança, o gráfico de rotatividade de código deve se tornar estável, sem altos e baixos drásticos.

antes do lançamento, o churn deve obter um código de adição ou edição de declínio antes que o próprio lançamento signifique que ele não será submetido a testes suficientes. No geral, sempre que houver uma irregularidade nos gráficos ágeis, investigue os motivos.

Gráfico de controle

um gráfico de controle é um gráfico onde a equipe pode ver informações sobre a duração de seus tempos de ciclo. O resultado ideal teria a linha no gráfico diminuindo constantemente com o tempo — isso significaria o aumento da velocidade da equipe — menos tempo é necessário por ciclo único. Outro aspecto importante é a consistência-os tempos de ciclo precisam permanecer mesmo independentemente do tipo de tarefa — isso significa que você tem a distribuição correta do trabalho.

métricas de saúde

as equipes de desenvolvimento de Software precisam se concentrar em prioridades de longo prazo, como manter a comunicação entre os membros tranquila e verificar se todos estão satisfeitos. O Agile é uma metodologia flexível, o que significa que pode se adaptar aos interesses de diferentes membros, assim que os gerentes souberem a que prestar atenção. Veja como descobrimos se todos os membros da nossa equipe estão satisfeitos com o fluxo de trabalho.

felicidade

se você confiou em relacionamentos informais em sua equipe, é mais fácil começar com um diálogo aberto com cada membro. Peça a todos que avaliem sua experiência na empresa de 1 a 5. Você pode fazer perguntas de assistência – quais são os melhores e piores aspectos de seu trabalho, o que poderia ser melhorado e o que poderia aumentar a felicidade? Se a equipe não tiver hábitos de comunicação amigáveis, o uso de pesquisas anônimas pode levar a resultados mais objetivos.

moral da equipe

moral e felicidade da equipe não são as mesmas coisas. A felicidade tem mais a ver com conforto, enquanto o moral da equipe Está ligado à produtividade, auto-estima, avaliação de qualidades profissionais próprias. Novamente, você pode pedir aos funcionários que avaliem seu moral de 1 a 5 e façam as seguintes perguntas;

• trabalhar na empresa ajudou a melhorar suas habilidades?
• quanto é o seu potencial total explorado com a carga de trabalho atual?
• você gosta do seu trabalho?
• você vê os resultados claros do seu trabalho?
• você está entusiasmado com novos projetos?

o objetivo aqui é entender que a corrente de desenvolvimento da equipe vai na direção certa. Às vezes, o Gerente da equipe de desenvolvimento de software assume tarefas lucrativas, mas chatas, ignorando os interesses dos membros. Esta pesquisa ajudará você a ver se os funcionários estão animados e desafiados por seu trabalho.

rotatividade de membros da equipe

se os gerentes de equipe substituem frequentemente os membros da equipe, isso significa que o ambiente de trabalho provavelmente não é saudável. Uma certa taxa de rotatividade ao longo do tempo é saudável — na verdade, você não quer ter nenhum acréscimo de pessoas por anos, pois isso significaria estagnação. No entanto, você deve estar atento a picos repentinos de atividade — meses em que várias pessoas deixaram a equipe ou muitas pessoas se juntaram. Se você tiver uma adição repentina de muitos novos participantes, você precisa prestar atenção ao processo de integração antes de ir diretamente para o trabalho relacionado ao projeto.

medir benefícios para usuários finais

as equipes ágeis devem saber o quão bem o produto atende às necessidades de um usuário final e proprietário de uma empresa. Isso é feito com uma análise abrangente de código que determina a qualidade do código e sua usabilidade para um usuário final, bem como possíveis complicações de manutenção.

análise de código estático

é o tipo simples de análise de código quando o software está inativo. Apenas monitorando o código automaticamente com ferramentas de código aberto, você pode identificar problemas de segurança, detectar dívidas técnicas e bugs e enviar fragmentos de código problemáticos para o coletor de lixo.

análise dinâmica de código

a análise dinâmica de código requer que sua equipe execute software para avaliar a experiência recebida pelos usuários finais. Incentivamos nossos desenvolvedores e testadores a sempre se colocarem no lugar dos usuários, explorando os cenários mais comuns. Por exemplo, eles podem apresentar seus colegas e familiares à solução, solicitando feedback — a menos que não seja proibido pelo Acordo. Mais importante ainda, temos uma equipe de profissionais de QA que são totalmente responsáveis pela análise dinâmica de código — embora acreditemos que quanto mais pessoas contribuírem para testar métricas em Agile, melhor será a qualidade final do produto.

como aplicar as melhores métricas ágeis

de toda a variedade de métricas ágeis disponíveis, você precisa selecionar as que serão relevantes para sua equipe e projetos a longo prazo. Manter o controle dessas características-chave deve ser um hábito, enquanto não deve distraí-lo de um trabalho mais urgente. Veja como incorporamos métricas ágeis em nosso fluxo de trabalho.

concentre-se no desempenho, orçamento e qualidade

você precisa ter certeza de que, depois de selecionar todas as métricas, poderá ter uma imagem clara da qualidade, carga, despesas de tempo e orçamento do seu trabalho. Em primeiro lugar, criamos métricas de curto prazo relacionadas aos nossos projetos ativos: tempo de ciclo e velocidade para avaliação de desempenho ágil, análise de código para avaliação de qualidade de código e fluxo cumulativo para acompanhar todos os processos de desenvolvimento e seus custos.

durante o primeiro sprint, certifique – se de fazer o seguinte:

• Definir quantos sprints e ciclos de projeto;
• Estimar o tempo de despesas para todo o projeto, levando em conta as necessidades do cliente;
• Avaliação de soluções competitivas para entender o nível de complexidade do produto final;
• Recolher o feedback de nossos membros da equipe sobre suas expectativas sobre o projecto mais emocionante, desafiadora e difícil aspectos.

Desta forma, podemos saber quanto tempo vamos gastar para concluir o projeto, com padrões de qualidade definidos com base em soluções semelhantes, e se a nossa equipa está motivada para trabalhar com as tarefas ou não (ele tem um enorme impacto na produtividade).

métricas após o primeiro sprint

aqui, nos concentramos em obter feedback do cliente e de todos os membros da equipe. Após o primeiro sprint, queremos saber que todas as partes envolvidas no fluxo de trabalho entendem o processo e se sentem confortáveis. Além disso, enfatizamos a avaliação da qualidade do Código — até planejamos a análise de código e a avaliação da dívida tecnológica como parte de cada um de nossos próximos sprints. Assim que as primeiras linhas de código foram escritas, manter sua qualidade é nossa prioridade.

Velocity vem depois

Velocity é uma das métricas mais importantes em nossos projetos, mas não a chave. Nos abstemos de basear nosso julgamento nos números de velocidade nos estágios iniciais. A estratégia de passar rapidamente pelos primeiros passos é um desastre esperando para acontecer – a equipe pode pular o planejamento ou esquecer de fazer a um cliente várias perguntas cruciais. Não apressamos os primeiros estágios do produto, permitindo que clientes e membros da equipe encontrem seu ritmo. Aumentar a velocidade de nossa equipe se torna uma de nossas prioridades quando estamos no ponto de execução. Assim que todos os recursos e design são definidos, nos esforçamos para minimizar as despesas de tempo e concluir todas as tarefas o mais rápido possível.

métricas individuais

cada uma das métricas usadas deve estar disponível para toda a equipe e membros individuais. Desenvolvedores, testadores, designers devem ser capazes de ver o ritmo e os resultados de seu trabalho, não apenas uma equipe como um todo. Para que isso aconteça, usamos ferramentas de produtividade e rastreadores de tempo, como Jira e Hubstaff. Todos os relatórios gerais são sincronizados com os individuais-os membros podem ver qual porcentagem do tempo produtivo geral de suas horas.

Perguntas frequentes

o que é KPI no Agile?

os principais indicadores de desempenho no Agile são valores mensuráveis que mostram a eficiência da equipe na consecução dos objetivos de negócios. Os KPIs de alto nível se concentram em resultados de longo prazo que dependem de muitos fatores-quantos usuários foram atraídos pelo produto final, taxas de conversão, qualidade de feedback. KPIs de baixo nível são valores de curto prazo que não são influenciados por muitos fatores conectados — tempo gasto no projeto (geralmente calculado em horas), orçamento do projeto (investimento por tarefa), etc.

Agile é uma metodologia de desenvolvimento baseada na melhoria contínua — o desenvolvimento de software analisa dados e se adapta a ele. A equipe analisa KPIs ágeis em seu desempenho e qualidade de trabalho, e implementa mudanças imediatamente, no próximo sprint.

o que são métricas de Sprint?

as métricas da Sprint são métricas que avaliam as entregas da equipe de desenvolvimento de software, verificando quanto valor foi entregue ao cliente final até o final de cada sprint . Esse valor pode ser medido com um novo recurso, melhorias de design ou exclusão de bugs.

o próximo objetivo da sprint metrics é medir a eficácia da equipe em termos de negócios — a rapidez com que a solução foi entregue ao mercado, Qual é o feedback do cliente e os níveis de conversão. Por fim, as métricas precisam mostrar a satisfação dos desenvolvedores com seu projeto e com a direção que a equipe está tomando em geral. Por que as métricas são importantes para projetos ágeis?

o ponto principal da Metodologia Ágil é que os desenvolvedores sempre podem fazer correções no processo após cada sprint. Ter dados, estatísticas e gráficos tangíveis permite que os desenvolvedores entendam quais mudanças fazer para o próximo sprint e permite avaliar a qualidade do produto final — caso contrário, seria fácil ser pego em detalhes técnicos e de organização.

o que é um sprint no Agile?

um sprint é um período claramente definido com a data de início e término em que a equipe está preparada para concluir um determinado número de Tarefas. Sprints são a base do Scrum, Agile e DevOps — as equipes dividem sua carga de trabalho em pedaços gerenciáveis menores e rastreiam os resultados de cada sprint. Cada um desses períodos é tratado como um mini-Projeto com um planejamento prévio, avaliação de risco, atribuições de responsabilidade e análise pós-sprint.

cada projeto é composto por uma série de sprints. Como cada sprint é avaliado, é fácil identificar problemas no início e removê — los no próximo sprint-para que o fluxo de trabalho seja constantemente otimizado.

quais são as métricas para o desenvolvimento de software?As métricas de desenvolvimento de Software são valores quantitativos que permitem medir a qualidade, o desempenho e a saúde do projeto de desenvolvimento de software. Eles ajudam a melhorar o processo de desenvolvimento à medida que o projeto avança e podem ser usados para o trabalho futuro da equipe para melhorar a organização e o planejamento.

existem seis tipos principais de métricas de desenvolvimento de software:

• métricas formais de código – são valores qualitativos objetivos que calculam quanto trabalho foi realizado determinando o número das linhas de código (LOC), Comprimento do caminho de instrução e outros.
• métricas de eficiência do desenvolvedor-a equipe pode calcular o código de atribuição, os dias ativos e o tempo gasto na tarefa.
• processo Ágil métricas — quando o projeto é dividido em sprints, a equipe pode medir a eficiência das menores partes do projeto – levar tempo (quanto tempo foi gasto para uma determinada fase de desenvolvimento, que pode conter vários sprints), o tempo de ciclo (um sprint geralmente cai em um único ciclo) e de velocidade (quantas tarefas foram realizadas em um determinado período).
• métricas operacionais – essas métricas verificam as características de execução do software e determinam a eficácia da equipe da empresa em manter a ferramenta sem ajuda de terceiros. Tempo médio entre falhas e tempo médio para recuperar (MTTR) verifique como o software será executado em circunstâncias naturais e quão equipada é a equipe interna no manuseio da carga.
• métricas de teste – essas métricas avaliam a cobertura do Código-quanto código foi testado, o número de bugs e a porcentagem de dívida tecnológica.
• satisfação do cliente-a equipe obtém insights sobre as reações dos usuários finais ao produto, medindo o Net Promoter Score, o Customer Satisfaction Score e o Customer Effort Score. Essas métricas avaliam, respectivamente, se os usuários recomendariam o produto e se estão satisfeitos com o resultado.

as métricas ágeis fazem parte das redes de software e podem incluir outras categorias, como você pode observar em nosso guia.

o que são métricas SDLC? SDLC é um ciclo de vida de desenvolvimento de software — um conjunto de estágios que uma tecnologia típica sofre durante sua concepção, execução e finalização. Uma SDLC média consiste nas seguintes etapas:

• avaliando sistemas existentes e definindo suas características, vantagens, problemas;
• definindo requisitos para a nova funcionalidade do projeto, design, público-alvo, etc.;
• projetando o sistema e delineando um caminho típico do Usuário;
• desenvolvendo o software, o que significa escrever código, preparar hardware e criar recursos;
• teste de desempenho do software, funcionalidade, segurança, interface, etc.;
• implantando o software em seu ambiente natural, onde a tecnologia será executada a longo prazo;
• mantendo o sistema atualizando o código, substituindo ou editando certos fragmentos e removendo bugs.

cada estágio do SLDC pode ser medido pelas seguintes características.

• Requisitos: a equipe deve coletar todos os requisitos para o projeto e avaliar a implementação de cada um deles em termos de tempo e dinheiro;
• qualidade de Software: todos Ágil métricas de qualidade pode ser usado na fase de desenvolvimento de um SDLC;
• casos de Teste: a equipe tem que se calcular o número de realizado o teste de actividades, a sua velocidade, e final de cobertura de código;
• Defeitos: para medir a eficiência de seu trabalho, desenvolvedores e testadores precisa estar ciente do exato número de problemas que surgem durante o desenvolvimento;
• Tarefas: a medição do tempo gasto e o dinheiro ganho por tarefa permite avaliar se todos os membros da equipe são produtivas ou não.

todas as métricas, descritas em nosso guia, podem ser usadas em diferentes estágios do ciclo de vida de desenvolvimento de Software. O projeto está na maior necessidade de monitoramento mais próximo do lançamento, porque os problemas podem se acumular e é fácil perder um defeito crítico no produto.

o que é throughput em métricas ágeis?

é a métrica que calcula o número de histórias concluídas por sprint. No Scrum, uma métrica semelhante é chamada de Velocidade de Sprint.

conclusão

métricas ágeis configuram uma base sólida para tomar decisões informadas ao longo de um projeto de desenvolvimento de software. Os desenvolvedores podem usar esses insights para aumentar sua eficiência nos próximos sprints e melhorar constantemente a qualidade de seu produto. No entanto, vale a pena notar que as métricas de desenvolvimento não devem se tornar uma prioridade absoluta no projeto de desenvolvimento de software. Os desenvolvedores devem confiar, em primeiro lugar, nas necessidades do projeto e nas preferências do público.

na Jelvix, usamos uma abordagem personalizada para aplicar métricas ao projeto. Primeiro, discutimos o MVP do projeto com o cliente, pesquisamos o público-alvo, analisamos soluções competitivas e só então escolhemos as métricas que melhor se encaixam no projeto. Não nos esforçamos para aplicar todos os KPI – em vez disso, selecionamos aqueles que refletem mais as necessidades do projeto.