Peer review, ou "revisão por pares", é uma prática de qualidade de software frequentemente negligenciada nas empresas de TI, sigam elas "métodos ágeis" ou não. Porém, esta prática pode diminuir os custos de desenvolvimento, evitando problemas no momento mais crucial do Projeto: A aceitação.
Devido à minha grande experiência na área, já trabalhei com análise e diagnóstico de problemas sistêmicos, ou seja, aqueles que acontecem quando submetemos um Sistema Aplicativo aos testes de Requisitos Não Funcionais.
Estou muito acostumado a olhar o código e levantar possíveis problemas de implementação, que poderiam ter sido facilmente resolvidos, em momentos anteriores do Projeto. Só que apenas recebem atenção, no momento do "vamu vê", ou seja, durante os testes de RNF para aceitação.
Geralmente, este tipo de problema passa despercebido durante todo o desenvolvimento, incluindo os testes unitários, de integração e funcionais. Nós, brasileiros, não atuamos proativamente, então, deixamos os testes de RNF apenas para o final de tudo e, quase sempre, realizados manualmente.
Don't get me started in that!
Uma das causas dos problemas de desempenho é justamente a total NEGLIGÊNCIA dos Requisitos Não Funcionais, como: Tempo esperado de resposta e quantidade de usuários simultâneos. Geralmente, quando coletamos esses requisitos, sequer prestamos atenção neles, durante o desenho da Arquitetura, no Projeto e na Construção do código.
Isso nos leva a uma situação de "Laissez fare" com relação às capacidades do Sistema, e nos preocupamos apenas com a parte funcional.
Só que esses "fantasmas" virão nos "assombrar" no pior momento possível, quando o sistema já foi aceito e grande parte da Equipe já foi desmobilizada.
E os, assim chamados, "métodos ágeis", tendem a piorar a situação, pois colocam todo o foco na Entrega, criando pressão desmedida por resultados.
Peer review
Uma Revisão por pares pode evitar problemas de RNF, ao questionar e, portanto, detectar, possíveis problemas de projeto e implementação antecipadamente.
Para que seja eficaz, uma Review deve ser baseada em critérios, claramente escritos e compreendidos por todos. Deve ficar claro que não será avaliada a competência do Desenvolvedor (ou Arquiteto), mas a eficácia de sua solução, frente aos requisitos não funcionais de sua unidade. Sim! É preciso coletar os RNF e extrapolar para cada unidade a ser revista.
O Peer review, como o nome diz, é uma revisão de arquitetura, projeto ou implementação, feito por PARES, ou seja, por Arquitetos, Projetistas ou Desenvolvedores! Não adianta nada o Analista de Requisitos participar! Aliás, os próprios requisitos poderiam ser alvo de Peer reviews específicas.
O resultado é uma avaliação do Produto de trabalho, com recomendações de melhorias ou alterações, sempre tendo o objetivo de melhorar a Capacidade da Unidade.
Para que funcione, o Revisor deve ter experiência e independência, logo, é melhor que não pertença ao mesmo Projeto, mas deve ter a experiência necessária para fazer a revisão. O(s) revisor(es) deve receber antecipadamente a lista de critérios, os RNFs e o Produto de trabalho a ser revisto, e deve trabalhar sem a presença do Autor do trabalho. É claro que ele pode e deve tirar dúvidas, mas dece evitar ser influenciado em sua análise.
Ao final, uma breve sessão de esclarecimentos permitirá ao Autor conhecer e justificar os resultados, e ambos podem chegar a uma solução satisfatória.
O princípio é: Toda boa ideia deve resistir a um debate franco. Assim como toda boa implementação.
Nenhum comentário:
Postar um comentário