Não espere qualidade da sua empresa, seja a qualidade!
De quem é a culpa da má qualidade dos softwares?
Acho que todos já ouvimos falar sobre modelos de maturidade como CMMI ou MPS.BR e processos como o RUP, Scrum ou XP. Quase sempre isso vem acompanhado de comentários críticos e pessimistas de como a nossa empresa está longe de ser maduro e prover produtos de qualidade.
Por outro lado, mesmo empresas que investem em maturidade do processo muitas vezes esquecem que ele não é uma bala de prata. Não existe processo ótimo sem ótimas pessoas. É um mito industrial a possibilidade de criar um processo perfeito que seja independente do nível e da maturidade dos indivíduos envolvidos.
Isso pode ser bem observado na literatura sobre processos. Processos “pesados” ou rígidos são recomendados quando há equipes imaturas, sem experiência e disciplina adequadas. Já com equipes experientes, maduras e disciplinadas quase não existe necessidade de processo.
Por isso é que os processos ágeis, por exemplo, somente são recomendados quando há pessoas muito competentes envolvidas no projeto. Como disse meu orientador: “coloque uma equipe de juniors num processo ágil, eles vão começar a estimar usando planning poker e provavelmente vão continuar jogando poker até o final do projeto”.
O mesmo é aplicável a empresas que disponibilizam salas de entretenimento, por exemplo. Muita gente gostaria de trabalhar no Google e ter uma sala com vídeo-game, mas o que geralmente não se pensa é que qualquer vaga nesse tipo de empresa são preenchidas por pessoas maduras e focadas, que possuem muito compromisso e dedicação.
Resumindo, a culpa pela falta de qualidade e organização em uma empresa é compartilhada por todos os níveis da mesma. Porém, em teoria, todos sabem o que as empresas deveriam fazer.
Mas o que cada um pode contribuir, individualmente ou em equipe?
Após criador o CMM, Watts Humphrey aplicou todos os seus princípios até o nível 5 em projetos individuais durante 3 anos, financiado pelo SEI (Software Engineering Inistitute). Assim surgiu o Personal Software Processos (PSP). Enquanto o CMM ou CMMI é aplicado ao processo de engenharia de software de uma organização, o PSP organiza o trabalho individual de um engenheiro de software.
Antes de pensar numa certificação CMMI, as empresas deveriam focar em melhorar os indivíduos que a compõe através do PSP. Quando as pessoas amadurecem e passam a utilizar um processo pessoal de desenvolvimento por saberem que é algo bom, então adotar um modelo como CMMI é natural, pois elas já absorveram sua filosofia e não é necessário forçar ninguém a usar boas práticas de desenvolvimento que de outro modo não se entenderia a razão.
Mas o que é o PSP, afinal?
É um processo de desenvolvimento de software pessoal, que você e eu podemos adotar como engenheiros de softwares (desenvolvedores), independente do tipo de projeto e de onde trabalhamos.
O PSP é baseado nos seguintes princípios de qualidade e planejamento:
- Todo engenheiro de software é diferente; para serem mais efetivos, os engenheiros precisam planejar o seu trabalho e devem basear os seus planos em seus próprios dados pessoais.
- Para melhorar consistentemente seu desempenho, os engenheiros precisam usar pessoalmente processos bem definidos e com medição.
- Para produzir produtos de qualidade, os engenheiros precisam se sentir pessoalmente responsáveis pela qualidade dos seus produtos. Produtos superiores não são produzidos por acaso; os engenheiros devem batalhar para fazer um trabalho de qualidade.
- Custa menos encontrar e corrigir erros cedo em um projeto do que mais tarde.
- É mais eficiente prevenir defeitos do que encontrá-los e corrigi-los.
- O jeito certo é sempre o mais rápido e o mais barato de fazer o trabalho.
Enfim, os engenheiros de software devem adotar um processo pessoal bem definidos, medir e registrar o tempo que gastaram em cada atividade e a qualidade do produto que entregaram, ajustar o processo através dos dados obtidos para melhorar os próximos projetos e atividades, além de focar na qualidade do trabalho que desempenham.
A estrutura do PSP
A figura acima mostra o fluxo conceitual do PSP. Através dos requisitos, usa-se “scripts” como guia em cada case do processo (planejamento, modelagem, revisão da modelagem, codificação, revisão da codificação, compilação, testes e finalização). Em cada fase, dados de tempo e defeitos são coletados e consolidados com o que foi planejado, permitindo a avaliação do processo atual.
O PSP também provê boas práticas e guias para os diversos aspectos do processo pessoal: planejamento, coletagem de dados, qualidade (medição e prevenção), modelagem, disciplina pessoal, etc. Não entrarei em detalhes sobre cada um desses itens neste artigo, mas vamos a um exemplo.
A fim de prevenir defeitos num software o PSP estabelece o gerenciamento da qualidade através de três práticas:
- Anotar as causas dos erros que já ocorreram e usar esses dados para aperfeiçoar o processo de modo que esse tipo de defeito não ocorra mais, ou seja, que não se cometa os mesmos erros novamente.
- Usar método de modelagem e notação adequados para contruir o modelo completo, pois isso força o desenvolvedor a pensar e entender todo o domínio, o que resulta em menos enganos.
- Uma consequência direta do item 2: com o modelo completo e entendido, gasta-se menos tempo codificando, o que reduz a quantidade de erros. Estudos realizados em 298 projetos demonstraram que os engenheiros introduzem 1,76 erros por hora no design e 4,20 erros por hora na codificação, logo, quanto menos código melhor.
Resultados
A seguir, o gráfico de “Acurácia da Estimação de Esforço” demonstra que na medida em que o indivíduo progride no uso do PSP, ele fornece estimativas mais próximas da realidade. Após 10 programas desenvolvidos as estimativas melhoraram em aproximadamente duas vezes.
Já o gráfico de “Melhoria no Nível de Defeitos” demonstra que, na medida em que se usa o PSP, menos erros são introduzidos nas fases anteriores, ou seja, gasta-se menos tempo corrigindo problemas.
Por último, o gráfico de “Resultados de Produtividade” mostra que não houve mudança significativa no desempenho.
A conclusão do estudo, realizado com 298 projetos pequenos, é que o PSP ajuda a melhorar as estimativas e melhorar a qualidade através da redução de defeitos, embora a produtividade em linhas de código permaneça a mesma. Isso faz muito sentido, já que a melhoria na programação está mais relacionada com o conhecimento da linguagem e a lógica do desenvolvedor, os quais podem ser desenvolvidos através de estudo dirigido.
Fonte: http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm
