Métricas de processo de software podem produzir benefícios significativos, quando uma organização trabalha para melhorar seu nível geral de maturidade de processo. No entanto, assim como todas as métricas, elas podem ser mal-utilizadas, criando mais problemas do que podem resolver. Grady (1992) sugere uma “etiqueta de métricas de software” apropriada para os gerentes e para os profissionais quando instituem um programa de métricas de processo. Sobre o que os gerentes e profissionais devem fazer quando instituem um programa de métricas de processo, assinale a afirmativa correta.
- A)Utilizar métricas para avaliar indivíduos.
Errada, porque métricas de processo não devem ser usadas para avaliar indivíduos, e sim para entender e melhorar o processo.
- B)Excluir métricas importantes, se uma única métrica atende os requisitos.
Errada, pois a coleta de métricas deve considerar informações relevantes e complementares, não eliminar dados úteis sem justificativa.
- C)Considerar como negativos dados de métricas que indicam uma área com problema.
Errada, porque dados que apontam problema não são negativos em si; eles são valiosos justamente por revelar onde melhorar.
- D)Fornecer feedback regularmente para os indivíduos e equipes que coletam medidas e métricas.
Certa, porque a boa prática é dar retorno frequente às pessoas e equipes que medem, mantendo o programa útil e transparente.
Gabarito: D
Métricas de processo de software servem para enxergar como o processo está funcionando e onde ele pode melhorar. A ideia não é transformar a medição em caça às bruxas, nem usar número como se fosse martelo para resolver tudo. Quando bem usadas, elas ajudam a identificar gargalos, acompanhar evolução e apoiar decisões de melhoria contínua. Grady, ao tratar da “etiqueta” das métricas, defende justamente um uso responsável: medir com propósito, comunicar os resultados e devolver informação a quem participou da coleta. Isso evita desmotivação e faz com que a equipe veja valor no esforço de medir. Em processo de software, a métrica deve orientar melhoria, e não punição. Por isso, o item D está correto: é essencial fornecer feedback regularmente para os indivíduos e equipes que coletam medidas e métricas. Sem retorno, a coleta vira burocracia; com retorno, vira aprendizado. É aquele clássico caso de “se você mede e não devolve nada, a equipe só vai sentir que está preenchendo planilha por esporte”. As demais alternativas contrariam boas práticas: não se usa métrica para punir pessoas, não se elimina informação útil só porque uma métrica parece suficiente, e dado ruim não deve ser tratado como algo negativo, mas como um sinal importante de problema a ser investigado. A lógica é de melhoria de processo, bem alinhada com a visão de qualidade e maturidade de processo presente na engenharia de software.