Ao gerenciar projetos de desenvolvimento de software, muitas atividades levam à necessidade de quantificar o que será desenvolvido. O tamanho do software é a base para outras medidas e valores importantes, como custo, prazo, desempenho e qualidade. Utilizar métricas é uma prática essencial para uma boa gestão. Uma boa métrica é aquela que permite a construção de indicadores que facilitam a tomada de decisão sem que sua confiabilidade seja questionada.
Quando falamos de métricas para qualidade e desenvolvimento de software, tudo se complica devido à natureza das tarefas de desenvolvimento e do leque de técnicas de metrificação que são utilizadas no mercado. Também existem muitas falácias e enganos conceituais devido à falta de conhecimento teórico e prático no assunto. E para complicar ainda mais, o projeto de software sempre vive sob a ameaça do scope creep (requisitos que só aumentam sem controle) e de datas de entregas irreais atribuídas ao paradoxo da urgência do negócio versus a complexidade do software a ser desenvolvido.
Depois que o software está entregue e operando, sem métricas, o esforço e a qualidade das manutenções são geralmente à base do famoso “chutômetro”, gerando manutenções imediatistas e paliativas que comprometem a capacidade do software em evoluir e aceleram sua aposentadoria antecipada. Portanto, desmistificar esse mundo de métricas é fundamental para trazer esse tema à tona e dar a devida importância que o tema exige.
A métrica e o mito
Como disse Peter Druker, “Se você não pode medir, você não pode gerenciar”, isso quer dizer, se você não tem visibilidade do que está acontecendo, você não sabe como atuar. Basear o julgamento do estado de um projeto de software, por exemplo, em opiniões e feedbacks enviesados é um erro muito básico. Para fugir do viés e do “sentimento” e poder se apoiar em informação, precisamos de dados e estatísticas oriundos de valores quantitativos e matemáticos. Além disso, também é necessário ter um grau maior de precisão na hora de passar uma previsão do que vai acontecer, caso contrário não conseguimos nem iniciar um projeto sem saber o mínimo de esforço, custo e prazo necessário para concluí-lo.
A métrica puramente pode não prover respostas imediatas, mas os indicadores provindos de métricas sólidas podem dar um indício do que está acontecendo e, comparando com informações e experiências anteriores, dar uma visão do que pode vir a ocorrer no futuro. Mesmo que uma previsão tenha uma certa margem de erro, ela limita um conjunto de possibilidades infinitas em um conjunto de resultados menor, e isso é o que se deseja ter para que se possa atuar dentro de um projeto. Ou seja, se tenho dois ou três resultados possíveis ainda é melhor do que dezenas ou centenas.
Porém, para se ter as métricas e os indicadores, é importante ter os seguintes itens, que permitem uma gestão baseada em métricas confiáveis:
- Um processo que garanta a coleta, armazenamentos e recuperação apropriada dos dados de maneira segura e íntegra;
- A geração de indicadores que respondam questões objetivas da gestão: Como e onde estamos? Aonde queremos chegar? Chegaremos lá no prazo, custo, qualidade planejados?;
- A aplicação de técnicas corretas das métricas de software para cada assunto necessário para a gestão: estimativa, acompanhamento e visibilidade;
-
Métricas que sejam:
- Íntegras: não podem ser manipuladas indevidamente;
- Objetivas: não podem dar margem para interpretação;
-
Precisas: quantificadas em valores numéricos precisos e não em escala nominal ou subjetiva. Citando Tracy
O’Rourke, CEO da Allen-Bradley, “Sem a informação correta, você é apenas mais uma pessoa com uma opinião”;
o Confiáveis: o método para obter as métricas deve ser repetido sem gerar resultados diferentes cada vez que é executado; - Padrão: Possuir uma unidade de medida padronizada.
Imagine uma unidade de medida comum no dia a dia de cada pessoa: peso, altura, velocidade, volume, etc. Imagine, se essas medidas não possuíssem as características citadas, como seria confuso o nosso mundo e quantos problemas teríamos nas atividades cotidianas. Imagine tentar comprar leite sem saber como especificar quantos litros você precisa e qual seria o resultado do seu bolo caso você utilize a quantidade errada?
Com as métricas de software acontece o mesmo. Como entregar um projeto sem saber quantas pessoas são necessárias? Qual o tamanho do software que será produzido? Qual o custo para produzir? Quanto de testes deve ser executado?
E quando precisamos estimar a quantidade de pessoas necessárias ainda nos deparamos com o “Mito do Homem/Mês” ou homem/hora. Essa métrica utilizada geralmente para medir esforço possui vários problemas como já citado no The Mythical Man-Month de Frederick P. Brooks. Segundo Brooks, os projetos de software falham na maior parte do tempo por ultrapassarem o prazo. Os enganos mais comuns são:
- Assumir que tudo vai dar certo;
- Fazer estimativas pobres;
- Confundir esforço (o quanto precisamos para executar) com progresso (o quanto estamos executando);
- O progresso do projeto é mal monitorado;
- Adicionar mais pessoas quando o prazo do projeto está quase estourando.
Ainda citando Brooks “custo de fato varia conforme o produto do número de homens e o número de meses. Progresso não. Por isso, o homem/mês como uma unidade para medir o tamanho de um trabalho é um mito perigoso e enganador. Isso implica que os homens e os meses são intercambiáveis. Quando uma tarefa não pode ser partilhada por causa de limitações sequenciais, a aplicação de um maior esforço não tem nenhum efeito sobre a programação. ”.
Essa relação existe devido a problemas da natureza da tarefa da programação, que requer muita intercomunicação e
aprendizagem do escopo e do plano do projeto. Sendo assim, ao adicionar mais homens, ou seja, mais esforço, aumenta
também consideravelmente o tempo necessário para que se produza algo (F ...
