Duplicar itens no escopo da medição
Eu acredito que o bom humor seja um elemento fundamental na vida e no processo de assimilação de nova informação e no aprendizado em geral. Mas como isso colabora para que você evite duplicar itens no escopo da medição violando a o esquema de distribuição de riscos estabelecido entre o cliente e o desenvolvedor?
É sobre isso que a dica de uso do MESUR trata hoje.
No passado, eu provocava participantes dos cursos de Análise de Pontos de Função a declamar uma poesia para o colega ao lado. Era mais ou menos assim:
Nunca, jamais, uma mesma função deve se repetir no escopo da medição pela análise de pontos de função.
Quando se trabalha com planilhas eletrônicas, um erro muito comum é a repetição de itens, que ficam duplicados na medição.
Causas para erros de medição
São várias as causas. O tradicional copiar e colar facilita ao analista faltar com a atenção; ou então, por diferentes itens se referirem a uma mesma função, já medida.
Quando se faz a medição em planilhas, cabe ao analista a total atenção para evitar que este tipo de coisa aconteça.
Alinhando a medição à politica de distribuição de riscos entre cliente e desenvolvedores na era da transformação digital
Resolvendo esse problema, o MESUR não permite que uma funcionalidade seja medida mais de uma vez em um mesmo escopo de medição.
O tempo passou e vimos o uso da Análise de Pontos de Função e outras métricas de software afins se expandindo e se adequando.
O seu uso foi para além dos projetos de melhoria ou de desenvolvimento. Para aquele contexto original, o escopo de medição é o software entregue como resultado final do projeto ou como resposta às solicitações de mudança.
Vemos hoje sua aplicação no contexto do desenvolvimento Ágil, onde o escopo da medição tem maior variabilidade de caso para caso. Conforme o caso, o escopo da medição pode ser uma Release ou um Sprint; além do escopo de medição típico de projetos tradicionais.
O modelo de gestão, no qual a medição se insere, pode considerar a medição de uma mesma funcionalidade conforme ela vai sendo refinada dependendo de como se distribuem os riscos de escopo entre desenvolvedor e usuário.
Em termos gerais, eu poderia discordar dessa solução de medição… mas sou eu a pessoa que está naquele contexto específico? Sou eu que conhece as particularidades daquele caso concreto ou das limitações e pressões que limitam as alternativas para outra representação da produção:
A resposta é obviamente: Não.
Implementando a política e reforçando sua aplicação pelo MESUR
Por isso, o MESUR tem um tratamento flexível que permite a você definir a que escopo de medição se refere determinado item e avaliar a sua duplicidade apenas naquele contexto. Tudo isso com o objetivo de que você evite duplicar itens no escopo da medição considerando a sua realidade específica e não algum critério arbitrário.
Qual é esse escopo de medição é por sua conta, por conta da estratégia de medição, por conta das regras de seu contrato. Pode ser um projeto, uma Release, um Sprint e por aí vai. Tudo depende de:
- Como você quer distribuir os riscos;
- Qual a responsabilidade pela definição da solução que você deseja alocar ao desenvolvedor.
Como fazer para que você evite duplicar itens no escopo da medição?
Vamos exemplificar com a medição release 5 do sistema MSR.
Suponha que o Product Owner junto às demais partes no negócio tenham priorizado para o Sprint 1 a criação da funcionalidade de Login e para a Sprint 2 a alteração nessa mesma funcionalidade.
Se tentarmos medir a funcionalidade de Login na Sprint 2 após ela já ter sido medida na Sprint 1 em uma mesma medição, o Mesur acusará como erro, porque ela já existe na medição, conforme figura seguinte.
Como então fazer o Mesur entender que a estratégia de medição permite a medição da função mais de uma vez?
Simples, há um atributo do item de medição, que na figura está rotulado como Iteração. Esse rótulo é personalizável conforme a organização deseje (poderia ser: pacote, sprint, ciclo, etc). Então para que o Mesur permite a medição da função de novo na medição, ela deve referenciar Iterações distintas.
Então, se o analista mediu a função login na medição da Sprint 1 e indicando no campo iteração esse fato, no caso o preenchendo com “Sprint 1“, basta a ele inserir a função login novamente; contudo agora preenchendo o campo de iteração a respectiva Sprint, no caso, “Sprint 2“.
Desta forma o Mesur irá aceitar a inclusão pela segunda vez da função login na mesma medição, conforme ilustrado na figura seguinte.
Importante dizer que, o analista pode informar diferentes atributos a cada vez que medir uma mesma função. Por exemplo, a função de Login na Sprint 1 poderia ser medida com complexidade Baixa e a mesma função medida como de complexidade Média na Sprint 2, dependendo dos requisitos de cada Sprint.
A política de distribuição de riscos entre desenvolvedor e cliente, neste exemplo, aloca ao cliente o ônus com novos refinamentos mesmo dentro do escopo da mesma Release. Portanto, o total da medição deve contemplar o somatório de todas as Sprints ao criar uma medição para a Release.
Caso se queira saber o tamanho de cada Sprint, basta filtrar pela coluna Iteração, e o total do rodapé irá refletir somente o somatório dos itens filtrados.
