Qualidade de Software Ltda

É sabido que programas de certificação como o CMMI e o seu primo brasileiro MPS.BR tem colocado os olofotes sobre os processos de desenvolvimento. Muitas empresas denvolvedoras de software fizeram o seu trabalho de casa no que tange a definir, documentar, e divulgar seu processo de desenvolvimento. Feito isso o próximo passo e obter um nível de certificação. Obtida a certificação (nível 2, ou nível 3 ou…) aí e só alegria! Almoços de comemoração e muita publicidade, afinal de contas deu um bocado dc trabalho para conseguir a certificação. Mas e a qualidade do produto de software?

Bem, este é o ponto. Certificação do processo, não significa certificação do produto! É aí que mora o perigo! Deitado em berço esplêndido de uma certificação muitas empresas se esquecem da qualidade do produto.

Para garantir que um processo certificado produza um produto de software de qualidade será necessário uma boa equipe de qualidade assegurada, que não só execute checklists, mas faça inspeções em cada etapa do processo de desenvolvimento para se verificar a conformidade entre o que foi especificado e o que foi construído. Um produto de software pode ser produzido e até funcionar e mesmo assim não estar em conformidade com a especificação. Por exemplo, a especificação descreve uma arquitetura lógica de três camadas e o programador implementa em uma camada única. A especificacao descreve um determinado método de acesso e o programador implementa um método diferente, e assim vai sendo comprometida a qualidade do produto mesmo de uma empresa certificada.

E você o que pensa sobre a qualidade do produto de empresas certificadas? Dá para confiar cegamente?

Você conhece algum desenvolvedor de software que gosta de metodologia para desenvolvimento?  Desenvolvedor gosta de exercer sua criatividade, gosta de imprimir seu estilo de codificar, gosta de liberdade e geralmente não gosta de regras!

E do ponto de vista da empresa? Adotar uma metodologia rígida, uma metodologia flexível ou nenhuma metodologia ?

Independentemente do tamanho da empresa e do seguimento de sua atuação toda empresa precisa de alguma metodologia para o desenvolvimemto de software, pois os funcionários tiram férias, ficam doentes e pedem as contas e nesses casos haverá alguma documentação do software que permitirá uma manutenção emergencial ou mesmo evolutiva sem sobressaltos.

Duas abordagens que eu não acredito são:

1- Metodologia rígida -São boas para desenvolvimento de software de missão critica (principalmente aqueles que podem fazer com que haja perda de vidas) Fora desse domínio a metodologia rígida vira favas contadas, peça de museu, piada em “happy hour”

2 – Bom senso – Deixe por conta do bom senso dos desenvolvedores que eles produzirão um com junto mínimo de documentos, além do próprio código do software.

Então qual abordagem adotar?

Pense em uma metodologia flexível, adaptativa adequada a natureza de cada projeto. Estabeleça processos de entregas, por exemplo, um para novos desenvolvimentos, outro para manutenção evolutiva. Cada processo de entrega define uma raia que orienta o desenvolvedor nas suas atividades.

Não delegue o cumprimento dos processos de entrega para o bom senso. Estabeleça um indicador de conformidade ao processo e defina uma meta a ser atingida a cada nova entrega.

Esse indicador pode ser baseado em artefatos e cada artefato pode ter um peso diferente, por exemplo, um documento de visão do sistema, pode ter um peso maior para um processo de entrega de novo desenvolvimento do que numa manutenção corretiva.

E para garantir que o processo de entrega seja realmente adotado pela organização e necessário o patrocínio da alta gerência, o que irá demonstrar o comprometimento da organização com a metodologia proposta.

Penso que metodologia flexível seja melhor do que nenhuma metodologia. E você o que acha?