Curta nosso novo canal sobre Rock Progressivo, juntamente com nosso outro blog: http://progressive.cafe. Tudo sobre Progressivo psicodelico, Metal progressivo e outros estilos relacionados, com uma visao pessoal de quem viveu isso desde o inicio.E em breve teremos nossa App Mobile, cujo codigo fonte estara disponivel para voces, aqui, no Bom Programador!Por que Bom Programador gosta de Musica! O Bom Programador apoia o Projeto Kuaray, uma iniciativa para combater o aquecimento global, usando Raspberry, Ubuntu e Node.js.Conheca o Projeto Kuaray e junte-se a nos! Peer review, ou "revisao por pares", e uma pratica de qualidade de software frequentemente negligenciada nas empresas de TI, sigam elas "metodos ageis" ou nao. Porem, esta pratica pode diminuir os custos de desenvolvimento, evitando problemas no momento mais crucial do Projeto: A aceitacao.Devido a minha grande experiencia na area, ja trabalhei com analise e diagnostico de problemas sistemicos, ou seja, aqueles que acontecem quando submetemos um Sistema Aplicativo aos testes de Requisitos Nao Funcionais.Estou muito acostumado a olhar o codigo e levantar possiveis problemas de implementacao, que poderiam ter sido facilmente resolvidos, em momentos anteriores do Projeto. So que apenas recebem atencao, no momento do "vamu ve", ou seja, durante os testes de RNF para aceitacao.Geralmente, este tipo de problema passa despercebido durante todo o desenvolvimento, incluindo os testes unitarios, de integracao e funcionais. Nos, brasileiros, nao atuamos proativamente, entao, 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 e justamente a total NEGLIGENCIA dos Requisitos Nao Funcionais, como: Tempo esperado de resposta e quantidade de usuarios simultaneos. Geralmente, quando coletamos esses requisitos, sequer prestamos atencao neles, durante o desenho da Arquitetura, no Projeto e na Construcao do codigo.Isso nos leva a uma situacao de "Laissez fare" com relacao as capacidades do Sistema, e nos preocupamos apenas com a parte funcional.So que esses "fantasmas" virao nos "assombrar" no pior momento possivel, quando o sistema ja foi aceito e grande parte da Equipe ja foi desmobilizada.E os, assim chamados, "metodos ageis", tendem a piorar a situacao, pois colocam todo o foco na Entrega, criando pressao desmedida por resultados.Peer reviewUma Revisao por pares pode evitar problemas de RNF, ao questionar e, portanto, detectar, possiveis problemas de projeto e implementacao antecipadamente.Para que seja eficaz, uma Review deve ser baseada em criterios, claramente escritos e compreendidos por todos. Deve ficar claro que nao sera avaliada a competencia do Desenvolvedor (ou Arquiteto), mas a eficacia de sua solucao, frente aos requisitos nao funcionais de sua unidade. Sim! E preciso coletar os RNF e extrapolar para cada unidade a ser revista.O Peer review, como o nome diz, e uma revisao de arquitetura, projeto ou implementacao, feito por PARES, ou seja, por Arquitetos, Projetistas ou Desenvolvedores! Nao adianta nada o Analista de Requisitos participar! Alias, os proprios requisitos poderiam ser alvo de Peer reviews especificas.O resultado e uma avaliacao do Produto de trabalho, com recomendacoes de melhorias ou alteracoes, sempre tendo o objetivo de melhorar a Capacidade da Unidade.Para que funcione, o Revisor deve ter experiencia e