CodeGym /Blogue Java /Random-PT /Métricas de Produtividade. O que você precisa saber sobre...
John Squirrels
Nível 41
San Francisco

Métricas de Produtividade. O que você precisa saber sobre medição de desempenho em software?

Publicado no grupo Random-PT
Embora as habilidades práticas e o conhecimento de linguagens de programação, ferramentas e tecnologias específicas sejam a chave para conseguir um emprego em tempo integral como desenvolvedor de software, há outro indicador valioso que, de várias maneiras, pode ser visto como um pressuposto para o sucesso nessa profissão: produtividade. A medição da produtividade é algo que todos os desenvolvedores profissionais de software precisam entender e levar em consideração, pois as métricas de desempenho são inerentemente importantes para qualquer equipe de desenvolvimento de software no ambiente de negócios atual. Métricas de Produtividade.  O que você precisa saber sobre medição de desempenho em software?  - 1

Por que sua produtividade como desenvolvedor é importante?

Na era do desenvolvimento Agile, DevOps e ciclos de lançamento de software reduzidos, quando os desenvolvedores precisam enviar novas versões de produtos o mais rápido possível, as empresas usam várias métricas de produtividade diferentes para avaliar o desempenho de programadores individuais e de uma equipe como um todo. Observando isso do ponto de vista de um desenvolvedor, a medição de desempenho pode servir a vários propósitos valiosos, ajudando você a acompanhar o progresso de suas habilidades de programação, o que permitiria que você alcançasse um crescimento profissional consistente. Programadores altamente produtivos são aqueles que acabam recebendo ofertas salariais de cair o queixo e começam a trabalhar nos projetos mais empolgantes. Mas mesmo se você não for exatamente um grande empreendedor e apenas quiser qualquer emprego em desenvolvimento de software e ser razoavelmente bem-sucedido nele, você ainda precisa ter pelo menos uma compreensão básica dos indicadores de desempenho e como eles são usados ​​para medir a produtividade de sua entrada no trabalho. Que é sobre isso que vamos falar hoje.

Métricas de medição de produtividade de desenvolvimento de software

O que são métricas de produtividade de desenvolvimento de software?

As métricas de desenvolvimento de software são as áreas de trabalho de programação em que medições quantitativas podem ser aplicadas para rastrear o desempenho, a qualidade do trabalho e a produtividade de um desenvolvedor. Cada métrica de produtividade é baseada na coleta de dados do processo de desenvolvimento e em seu uso para medir a produtividade. Como praticamente nada relacionado ao desenvolvimento de software é fácil e direto, pode-se dizer que medir a produtividade da programação também é bastante inconsistente e fragmentado em todo o setor. Ou, simplesmente, várias equipes e empresas podem usar indicadores de desempenho completamente diferentes e abordar essa questão de vários ângulos. Portanto, você não precisa se preocupar em aprender todas as métricas que podem ser usadas pelas equipes de desenvolvimento de software.

Que tipos de métricas de produtividade de desenvolvimento de software existem?

Naturalmente, existem várias métricas de produtividade diferentes que abordam a medição do desempenho em vários níveis e ângulos. Aqui estão os tipos mais comuns de tais métricas de produtividade:

  • Métricas formais com foco no tamanho.

Essas métricas são focadas em medir o tamanho do resultado do trabalho de um programador, como linhas de código (LOC), comprimento das instruções de código, complexidade do código, etc. Essas métricas são cada vez mais consideradas desatualizadas no setor de desenvolvimento de software atual.

  • Métricas de produtividade focadas em tempo e função.

Há uma seleção de métricas de produtividade tradicionais usadas no desenvolvimento de software em cascata, como dias ativos, o escopo da funcionalidade enviada em um determinado período de tempo, taxas de rotatividade de código, número de tarefas atribuídas, etc.

  • Métricas do processo de desenvolvimento ágil.

Métricas do processo de desenvolvimento ágil, como relatório de burndown do sprint, velocidade, lead time, tempo de ciclo e outros, são provavelmente as métricas mais usadas atualmente entre as equipes de desenvolvimento de software. Falaremos sobre métricas ágeis com mais detalhes posteriormente neste artigo.

  • Métricas de análise operacional.

Este conjunto de métricas é focado em medir o desempenho do software em seu ambiente de produção atual. O tempo médio entre falhas (MTBF), o tempo médio de recuperação (MTTR) e a taxa de falhas do aplicativo são as métricas mais usadas aqui.

  • Métricas de teste.

O teste de software tem seu próprio conjunto de métricas para medir a qualidade do teste do sistema, como porcentagem de testes automatizados, cobertura de código etc.

  • Métricas de satisfação do cliente.

Por fim, a métrica final para qualquer peça de software é a experiência do cliente final, e também há todo um conjunto de métricas para isso, como pontuação de esforço do cliente (CES), pontuação de satisfação do cliente (CSAT), pontuação líquida do promotor (NPS) e outros.

Métricas de desenvolvimento de software ágil

Como você pode ver, é muito fácil se perder em todas as complexidades das métricas de produtividade de software. No entanto, os únicos com os quais um desenvolvedor de software regular deve estar bem familiarizado são as métricas Agile, comumente usadas pelas equipes de desenvolvimento de software hoje como padrões de medição de produtividade da equipe em diferentes partes do ciclo de vida do desenvolvimento de software. Vamos listar as principais e mais utilizadas métricas Agile.

1. Sprint Burndown.

Os relatórios Sprint Burndown são uma das principais métricas para equipes de desenvolvimento ágil de scrum. Como no ágil o processo de desenvolvimento é organizado por meio de sprints com limite de tempo, o Sprint Burndown é usado como uma forma de rastrear a conclusão das tarefas durante um sprint. Horas ou pontos de história são usados ​​como uma unidade de medida. O objetivo é alcançar um progresso consistente e entregar o trabalho em linha com as projeções iniciais. O Sprint Burndown ajuda as equipes a medir o ritmo de trabalho e ajustá-lo quando necessário.

2. Velocidade da Equipe.

A velocidade é outro indicador-chave, que também se baseia em horas ou pontos de história como unidade de medida. Ele mede a quantidade média de trabalho que uma equipe conclui durante um sprint e é usado para estimativa e planejamento ao longo de todo o projeto. A velocidade de rastreamento é importante para garantir que a equipe ofereça um desempenho consistente.

3. Pontos de história.

No nível de um membro da equipe de desenvolvimento individual, os pontos de história são uma métrica valiosa, pois o tamanho das histórias que um programador entrega durante cada lançamento é um indicador da produtividade desse codificador.

4. Gráfico de controle do ciclo.

Mede o tempo total desde o momento em que o trabalho em uma tarefa ou outro item do backlog foi iniciado até sua conclusão. Permite rastrear e controlar os tempos de ciclo, entregando resultados mais previsíveis.

5. Rendimento e valor entregue.

Os gerentes de projeto analisam as tarefas atribuídas aos desenvolvedores e atribuem valor a elas. Essa métrica é então usada para medir o rendimento da equipe ou, em outras palavras, a quantidade de trabalho de valor agregado realizado.

6. Alteração de código.

A rotatividade de código é outra métrica que vale a pena mencionar, pois é usada para medir a produtividade de uma equipe como um todo e para acompanhar o desempenho de programadores individuais. A rotatividade de código mede a frequência com que um desenvolvedor remove ou faz alterações em linhas de código adicionadas anteriormente e qual porcentagem do código escrito anteriormente acaba alterado ou jogado fora.

Opiniões de especialistas

Finalmente, para adicionar alguma perspectiva, algumas citações sobre o assunto por profissionais experientes da indústria de desenvolvimento de software. “Espero que você não esteja querendo "comparar" suas métricas com algum tipo de padrão ou mesmo com o desempenho de outra equipe em outra empresa. Todos os lugares em que trabalhei tiveram variações únicas em suas definições de pontos da história, velocidade, estimativas horárias, tarefas etc. que realmente tornariam quase impossível comparar o desempenho de uma equipe de uma empresa diretamente com o de outra equipe em outra empresa”, observou Cliff Gilley, ex-gerente técnico de produtos e Agile Coach.. “Sou um pouco desconfiado de métricas quando se trata de orientar o desempenho da equipe. Depois de prestar atenção a apenas uma ou duas variáveis, torna-se muito fácil cair (intencionalmente ou não) no jogo da métrica e enganar a si mesmo que está melhorando - quando tudo o que você está fazendo é melhorar a métrica. Por exemplo, as métricas baseadas na velocidade podem "melhorar" quando a equipe passa para histórias menores (menos trabalho por história - mais histórias concluídas - então a velocidade aumenta). Isso pode ser bom se as histórias forem histórias de usuários úteis que fornecem incrementos menores de valor comercial. Isso pode ser ruim se as histórias se tornarem tarefas menores e mais "técnicas" que não agregam valor real por si mesmas”, disse Adrian Howard, outro profissional do setor.. “Ao trabalhar em um sistema puxado, valorizo ​​o rendimento e o tempo de ciclo. O primeiro me dá informações gerais sobre a capacidade de nossa equipe e, com o tempo, pode se tornar uma medida preditiva muito poderosa. O segundo é útil como um indicador geral da eficiência de nossos dutos. Se o tempo de ciclo for alto, é hora de começar a olhar para o pipeline, porque há uma restrição que provavelmente podemos trabalhar para facilitar/explorar. Mas as métricas são apenas ferramentas. Não se perca neles e certamente não comece a planejar uma métrica específica. Pense no que você está fazendo como equipe e em como você trabalha naturalmente e, em seguida, construa o sistema em torno das pessoas. As métricas devem ajudá-lo a ver como seu sistema está suportando o trabalho de todos. Ou não”, concluiu Dave Cerra, produtor de desenvolvimento de videogames .
Comentários
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION