Benchmarking de Software

Benchmarks de software para previsibilidade de projetos

Você deseja comparar seu desempenho com outros, internamente ou com equipes de outras organizações. Para comparações entre equipes internas, você pode estabelecer seus próprios benchmarks internos, enquanto para comparar com outros na indústria de software, você procurará benchmarks de software da indústria. Este artigo se concentra em benchmarking apropriado do trabalho de software para que você possa comparar o desempenho de suas equipes com o de outras. 

N.º. Este artigo não é sobre benchmarking de desempenho (velocidade) de software.

O Benchmarking de Software pode ajudar as organizações a compreender o seu desempenho e onde podem melhorar. Também com benchmarks, os gestores podem responder às questões vitais sobre um projeto de software de "Quanto tempo vai demorar?" e "Quanto vai custar?"   Os benchmarks também podem ser usados para ajudar a tomar decisões de negócios valiosas sobre em que trabalho de software focar.

Fundo

O software está se tornando um diferencial importante entre empresas bem-sucedidas e malsucedidas na maioria dos setores. A capacidade de produzir capacidades de software inovadoras e diferenciadas de alta qualidade mais rapidamente do que os concorrentes é uma chave para uma empresa vencer os seus concorrentes. Eventualmente, poderá tornar-se um factor líder na sobrevivência empresarial, como já o é para as empresas de base tecnológica.

Saber como sua empresa está se saindo em relação a outras na capacidade de fornecer recursos de software está se tornando cada vez mais importante. É aqui que entra o benchmarking.

Comparativo de produtividade do desenvolvedor

O foco tende a ser produtividade do desenvolvedor, antes por três razões:

1. Variável. A produtividade do desenvolvedor varia significativamente – os mais qualificados são 100 vezes mais produtivos que os menos qualificados.
2. Significativo. O custo do desenvolvedor é geralmente o maior componente de custo da entrega de software.
3. De valor. As empresas dependem do fornecimento de software para se manterem competitivas, por isso a taxa a que este pode ser entregue é importante para uma organização.

A medida básica da produção é o tamanho funcional, mas não ignore a qualidade.

A medida básica de produção mais útil é a quantidade de funcionalidade reconhecível pelo usuário que pode ser entregue com alta qualidade por um desenvolvedor ou por uma equipe de desenvolvimento. A melhor maneira de determinar isso não é contando linhas de código, mas sim pelo tamanho funcional do software entregue. O tamanho funcional é medido usando o padrão ISO COSMIC Function Point (CFP). O CFP é a medida padrão mais moderna e universal para tamanho de software. É uma medida independente da tecnologia do tamanho reconhecível pelo usuário. A produtividade dos desenvolvedores e das equipes de desenvolvimento pode ser comparada em CFP médio por mês ou CFP médio por sprint.

Benchmarks de produtividade do desenvolvedor

Cada desenvolvedor ou equipe pode ser avaliado em PCP por sprint.

Aviso: As métricas de produtividade devem exigir que a qualidade seja verificada.

Estes são valores observados pelo autor em dezenas de projetos de dimensão modesta (250-1500 CFP). Você deve estabelecer e manter seus próprios benchmarks. Muitas vezes também são expressos como o inverso, CFP entregue por unidade de tempo. Por exemplo. 20 CFP por mês.

Regra prática: 10-20 CFP por desenvolvedor por mês é uma regra geral. A faixa de produtividade observada do desenvolvedor é de 2 a 200 CFP por desenvolvedor por mês, dependendo das circunstâncias, domínio, ferramentas e competência.

Benchmarks de produtividade da equipe

Um guia geral é que em uma equipe de sete, 4 desenvolvedores, 2 testadores e um analista de negócios produzirão em média 4 horas por CFP, ou seja. 80 CFP por sprint de 2 semanas. Isso pode ser reduzido se houver um acúmulo de bugs a serem corrigidos de sprints anteriores.

Regra prática: 70 CFP por sprint é uma primeira estimativa razoável, mas você deve estabelecer seus próprios benchmarks.

A maioria dos gerentes deseja saber como sua equipe e empresa se comparam a outras em:

• Produtividade no desenvolvimento de software
• Qualidade de software
• Gastos com software
• Valor do software pelo dinheiro

O benchmarking interno de software compara diferentes equipes ou projetos dentro de uma organização. O benchmarking de software externo ou da indústria compara essas características com normas externas.

Este artigo explora quais métricas de software podem ser avaliadas e quais métricas usar para não estimular consequências indesejadas.

Os valores de referência reais apresentados são apenas para orientação e não devem ser considerados valores de referência definitivos. Em todos os casos, os benchmarks internos são os melhores, compilados a partir de trabalhos anteriores dentro da sua organização.

AI não foi usada para escrever este post.

Benchmarks de recursos de software

Para o planejamento da equipe, os líderes precisam saber qual é o quantidade ideal de trabalho que alguém pode realizar. Software é trabalho de conhecimento e as restrições cognitivas dos desenvolvedores são tais que eles só conseguem lidar razoavelmente com uma certa quantidade de funcionalidade. Nossas observações são de que isso gira em torno de 150 CFP. O que significa que independentemente do tamanho do seu projeto, você provavelmente precisará de mais de um desenvolvedor se o seu escopo total for superior a 180 CFP. A tabela abaixo é uma diretriz para a capacidade típica por função.

Por exemplo, um projeto de 1.000 CFP precisará de 1 Gerente de Projeto, 2 Analistas de Negócios, 3 testadores e 5 desenvolvedores. Esses números dependem da competência e do conhecimento do domínio dos envolvidos. Sempre que possível, é melhor lutar por equipes menores de indivíduos altamente competentes.

Observe que, para trabalhos de manutenção de software, um único desenvolvedor geralmente pode lidar com mais de 180 CFP. Geralmente requer 1 desenvolvedor em tempo integral por 1.500-2.500 CFP para manutenção.

Referências de qualidade de software

A qualidade do software é uma questão de vantagem comercial. A organização que fornece consistentemente software de qualidade útil aos clientes provavelmente superará seus rivais. O benchmarking de métricas de qualidade de software torna-se, portanto, um importante comparador corporativo.

Potenciais de defeito

O número de defeitos em um software pode ser antecipado. Os defeitos podem ser previstos com base no tamanho do software. É lógico que um software maior tem o potencial de apresentar mais bugs do que um software pequeno. O potencial de defeito é o conceito do número de defeitos que provavelmente ocorrerão em um software antes de iniciarmos qualquer medida de detecção/evitação/remoção de defeitos.

Os potenciais de defeitos típicos são de 4 a 5 defeitos por CFP. Esses defeitos variam em gravidade e em sua origem. Normalmente da seguinte forma:

Fonte: Capers Jones, A Economia da Qualidade de Software, 2011.

O que isto significa é que provavelmente haverá 5 defeitos por CFP, a menos que executemos medidas de melhoria de qualidade para encontrar e corrigir defeitos de cada uma destas áreas.

A consciência do potencial de defeito ajuda a responder a estas perguntas:

• Quantos defeitos precisamos encontrar para alcançar uma qualidade razoável?
• Quantos defeitos provavelmente serão pendentes?
• Quantos testes mais precisamos executar?
• Estamos prontos para entrar ao vivo?

Eficiência na remoção de defeitos

A qualidade de um produto de software é geralmente observada como o número de defeitos expostos na produção. O número de “novos” defeitos diminui ao longo dos primeiros 3 meses, por isso podemos dizer que o a eficiência de remoção de defeitos é determinada pelo número de defeitos encontrados nos primeiros 3 meses de uso como uma porcentagem dos potenciais defeitos, que se baseia na quantidade de funcionalidade fornecida.

Benchmarking de software – Cronogramas

O cronograma, ou tempo necessário para entregar o software, é uma consequência direta da produtividade da(s) equipe(s) que trabalha(m) no software. Analisamos a produtividade do desenvolvedor em termos de produção da equipe por sprint em cerca de 70 CFP por sprint de duas semanas, ou 140 por mês. Isso nos dá um guia claro para responder à pergunta. "Quando isto estará pronto?"

Regra prática: Para pequenos projetos com menos de 1.000 CFP: uma equipe normalmente entregará 140 CFP por mês.

Regra prática: Para grandes projetos acima de 1.000 CFP+, a produtividade diminui com o tamanho: o número de meses para entrega = CFP ^ 0,4

Observe que entregar funcionalidade com baixa qualidade atrasará o projeto em geral. Somente com alta qualidade os cronogramas mais rápidos podem ser alcançados.

Dica: Se um CFP tiver sido entregue, mas um defeito for descoberto em um sprint subsequente, você não o contará como entregue.

Comparativo de valor entregue

Se uma empresa gasta $1000 na entrega de 1 CFP de novas funcionalidades. Espera-se que o valor comercial geral dessa funcionalidade exceda o custo de $1000 no curto e no longo prazo. O valor por CFP irá variar, mas as empresas devem pensar num retorno de valor de 1 a 3 anos em termos de muitas vezes o custo por CFP. O benefício comercial de 3 anos por CFP é uma métrica útil para acompanhar e pode ser comparada.

Custo total de propriedade

Além do custo inicial de construção do $1000 de um CFP, as empresas devem levar em consideração o custo total de propriedade ao longo da vida útil desse software. Por exemplo, nos primeiros dois anos após a construção inicial, é provável que sejam feitas melhorias consideráveis, cerca de 20% no primeiro ano e mais 15% no segundo, normalmente 8% por ano. Você pode estabelecer seus próprios benchmarks internamente para o TCO dos aplicativos de software em seu portfólio. Esses dados ajudarão nas decisões sobre planos de substituição de sistemas.

Regra prática: o TCO total de 5 anos é normalmente 2-3x o custo inicial.

Mudança de escopo de benchmarking

Durante um projeto, novos requisitos surgirão ou se tornarão aparentes. Embora algumas dessas coisas possam ser conhecidas antecipadamente, outras não. As organizações que gastam adequadamente no trabalho de requisitos (15% ou mais para desenvolvimento personalizado, mais alto para implementações de pacotes como ERPs) não apenas alcançarão prazos mais curtos, mas também experimentarão menos mudanças de escopo durante o projeto. Alcaparras Jones

Regra prática: 1-2% alteração de escopo por mês durante um projeto.

Regra prática: 8% por ano de mudança de escopo após a implementação.

 

Benchmarking da dívida técnica

A dívida técnica é o retrabalho que surge de requisitos emergentes que não eram conhecidos quando o código foi escrito pela primeira vez. Para quantificar e avaliar a dívida técnica, é preciso primeiro classificar cuidadosamente o retrabalho causado por:

• Erros no código (não dívida técnica)
• Atalhos criados para implantação rápida (não uma dívida técnica no conceito original, mas comumente considerada assim)
• Retrabalho porque foi realizado trabalho de requisitos insuficiente (incógnitas conhecidas surgindo posteriormente). Esta é uma dívida técnica evitável.
• Retrabalho porque surgiram requisitos posteriores que não eram conhecidos anteriormente. (Esta é a inevitável dívida técnica genuína.)

A maioria das organizações é inconsistente com as classificações acima e, portanto, terá dificuldade em avaliar a dívida técnica.

 

Custo total de propriedade

Além do custo inicial de construção do $1000, as empresas devem levar em consideração o custo total de propriedade ao longo da vida útil desse software. Nos primeiros dois anos após a construção inicial, é provável que sejam feitas melhorias consideráveis, cerca de 20% no primeiro ano e mais 15% no segundo e 8% por ano a partir de então. Além disso, há a manutenção do software anualmente, seja para mantê-lo funcionando em uma infraestrutura em constante mudança ou para corrigir bugs que apareçam. Alcaparras Jones

Regra prática: o custo de 5 anos é normalmente 3x o custo inicial.

Outros benchmarks para trabalho de software

Engenheiros por cliente/usuário

Esse número é frequentemente citado por produtos Saas de consumo, como Facebook e Twitter. Mais frequentemente é expresso como milhares de usuários por engenheiro. Esta é uma métrica útil para essas organizações.

Receita por engenheiro DevOps

Em empresas com uso intensivo de software, onde a equipe técnica é o principal custo do negócio, acompanhar a receita geral por engenheiro de DevOps é um amplo indicador de eficiência técnica.

Métricas DORA

Frequência de implantação

É uma medida do número de vezes que um novo código (de qualquer quantidade) é lançado para produção. É um indicador útil e único da repetibilidade do ciclo de desenvolvimento/teste. A frequência de implantação deve ser medida em horas ou dias, não em semanas.

Tempo médio para restaurar

O Mean Time to Restore rastreia o tempo decorrido para restaurar o serviço após uma falha na produção. Este é um indicador da capacidade de uma equipe se recuperar de um erro. Deve ser medido em minutos ou horas, não em dias.

Prazo de entrega para mudanças

O Lead Time for Changes rastreia o tempo que o código leva para ir do commit até a execução bem-sucedida na produção. Isto não leva em consideração a magnitude, o valor nem a complexidade da mudança. É mais uma questão de eficiência de implantação do que de eficiência de desenvolvimento.

Alterar taxa de falhas

A taxa de falha de alteração é um indicador da qualidade do código implantado.

Vantagens das métricas DORA

Eles são fáceis de rastrear

Eles estão focados em atividades DevOps.

Desvantagens das métricas DORA

Eles se concentram nas taxas de alteração, independentemente do tamanho ou do valor do cliente.

Eles são em sua maioria inadequados para planejamento, dimensionamento e rastreamento de projetos

Eles são adequados apenas para benchmarking de atividades DevOps ou DevSecOps,

Benchmarks prejudiciais para trabalho de software

As organizações podem muitas vezes capturar erroneamente métricas que podem levar a consequências não intencionais; estas devem ser utilizadas com grande cautela ou totalmente evitadas e, além disso, não devem ser utilizadas como base para benchmarking.

Linhas de códigos produzidas por engenheiro

Isso pode fazer com que os desenvolvedores escrevam código detalhado, em vez de código eficiente ou reutilizado. Em vez disso, use CFP produzido por engenheiro

• Defeitos produzidos por mês por engenheiro
  • O número de defeitos produzidos deve ser considerado no contexto da saída. Um desenvolvedor que produz 1 defeito por mês e apenas 1 CFP é menos capaz do que aquele que produz 2 defeitos por mês em 10 CFP. Em vez disso, use defeitos por CFP produzido por engenheiro.
• Custo para detectar um defeito
  • Quanto maior a qualidade do software, mais caro será encontrar um defeito. Um alto custo por descoberta de defeito pode significar que o software já tem um alto valor.

Dicas de benchmarking interno

1. Divulgar os nomes dos projetos em benchmarks comparativos internos
2. Mostre as métricas dos componentes e não apenas os valores gerais.
3. Inclui atividades sem codificação.
4. Inclui aspectos humanos.
5. Use métricas de tamanho funcional.
6. Não use os dados para definir metas abstratas.

Resumido de Capers Jones apresentação em Benchmarking