Resolução de divergências
A contestação em medições de software e a resolução de divergências estão presentes em todo tipo de medição. Ou seja, medições de uma perspectiva interna, por exemplo, a contagem de linhas de código; ou externa, por exemplo, a análise de pontos de função, estão sujeitas a isso.
A análise estática de código fonte e outros itens de configuração são a base das métricas internas. Ferramentas como o SonarQube, por exemplo, as derivam automaticamente. Portanto, permitem medições com pouca margem para divergências ou contestação. Afinal, os objetos considerados na medição são concretos e exigem zero interpretação. Quando há divergências, são problemas quanto à interpretação das regras de contagem ou do escopo em que se aplicam, que as motivam.
As medições em uma visão externa de negócio, em especial a medição de pontos de função, se baseiam em representações imperfeitas e com maior nível de abstração. Portanto, é natural surgirem divergências entre medições. E, o monitoramento de sua frequência e natureza permite identificar oportunidades e problemas.
Corrigir práticas equivocadas de medição
São vários os casos de má aplicação das regras de medição. Dessa forma, sua presença promove divergências de medição; e as partes devem as resolver. Por exemplo, o desenvolvedor medir cada tabela do banco de dados como um arquivo lógico; ou então, medir cada elemento da arquitetura como uma função do usuário; ou ainda, incluir no escopo da medição funcionalidades já existentes no produto e cujos requisitos funcionais não foram alterados naquela Release.
Melhor alinhar a análise e gestão dos requisitos aos objetivos
Os requisitos, em suas diferentes representações são um dos principais insumos para medição. Problemas na entrada, promovem problemas na saída. Por exemplo, as histórias do usuário no Jira são mal elaboradas.
Subdividir uma história, inicialmente próxima a uma funcionalidade do usuário não é em si um problema; tem até nome: Story-splitting. Passa a ser um problema quando deixa de preservar a propriedade de que cada história do usuário deve ter, separadamente, valor de negócio mensurável. A medição acaba promovendo a identificação de problemas dessa natureza, por exemplo.
Se a análise e gestão de requisitos são importantes no desenvolvimento ágil e transformação digital, então eles são fundamentais no desenvolvimento tradicional. Ele privilegia a previsibilidade e os requisitos são chave para esse fim. Ou seja, esse papel da divergência como instrumento de diagnóstico de problemas subjacentes de análise e gestão de requisitos é mais crítico ainda.
Melhor alinhar os objetivos da medição a partir de casos concreto
Diferentes são os níveis de evolução do software em que a medição ou a aproximação do tamanho se insere conforme os objetivos associados.
Por exemplo, a gestão de um contrato avalia o desempenho do desenvolvedor com base na aproximação do tamanho derivado da documentação em estágios iniciais do desenvolvimento de uma Release. Nesse caso, deve-se considerar como insumos as histórias do usuário usadas como entrada no desenvolvimento para medição ou aproximação do tamanho. Em outro caso, a gestão do contrato avalia o desempenho com base na medição do produto final entregue e usa como insumos os refinamentos derivados daquelas histórias originalmente incluídas na Release.
Considerar a medição de um cenário em outro promoverá divergências e o problema está na falta de alinhamento sobre qual tipo de insumos considerar na medição naquele contexto em especial. Observe que em todos os casos podem ser histórias de usuário… No entanto, em que nível de refinamento?
A resolução de divergências e melhores produtos
As divergências em medições a partir de uma visão externa não a tornam pior do que as medições em uma visão interna. Isso seria como culpar o termômetro pela febre. A gestão de software deveria considerar ambas em seus processos e não uma como alternativa à outra. Cada uma cumpre um propósito diferente; aborda diferentes eixos na medição.
Os melhores produtos de software são desenvolvidos por aqueles que entendem o seu propósito e o processo de negócio no qual se inserem. Para esse fim, alinhar o fluxo operacional em que a solução de software se insere entre todos os envolvidos é um importante passo. Se a medição se insere no desenvolvimento ágil ou no contexto da transformação digital, então a resolução de divergências é uma ótima oportunidade para isso.
A resolução de divergências está longe de necessariamente indicar um problema em si. Além de promover objetivos de eficiência operacional e transparência, ela potencializa a entrega de melhores produtos.
Uma visão geral da resolução de divergências no MESUR
Um dos objetivos do Mesur© é de substituir as planilhas nas medições. Consequentemente, isso inclui o processo de validação, aferição ou resolução de divergências nas medições de pontos de função.
Primeiro, é recomendado ter uma visão geral sobre o papel do aferidor e como o Mesur suporte à sua atuação na evolução da validação e resolução de divergências de uma medição no vídeo a seguir.
Em seguida, apresentamos quatro casos de uso do Aferidor na resoluções de divergência com o MESUR:
- O aferidor concorda integralmente com um item de medição e quer registrá-lo como convergido na validação e resolução de divergências
- O aferidor discorda e justifica da avaliação de um item na medição pelo analista; no entanto, o aferidor concorda com a presença daquele item no escopo da medição.
- O aferidor discorda da presença de um item no escopo da medição; ou seja, o analista inclui uma funcionalidade a mais do que o necessário.
- O aferidor indica a ausência de um item no escopo da medição; ou seja, o analista deixou de incluir uma funcionalidade necessária.
