Ultimamente modelos de maturidade de software, como o MPS.BR (a denominação correta do modelo é MR_MPS, mas o nome do programa que lhe deu origem – MPS.BR – tem sido mais comumente utilizado para designá-lo) e o CMMI (Capability Maturity Model Integration) estão sendo questionados e criticados. Infelizmente, muitas dessas críticas são absolutamente equivocadas. Abaixo, alguns mitos sobre modelos de maturidade de software:
1º Mito – Modelos de Maturidade só se preocupam com processos. A competência das pessoas é desconsiderada.
Os modelos de maturidade de software valorizam bastante os processos. Mas esse fato, porém, não implica dizer que a competência das pessoas envolvidas nos processos é dispensada. Tanto no MPS.BR quanto no CMMI, há também resultados, práticas e objetos específicos que, para o sucesso do software, necessitam, sim, da competência e do conhecimento das pessoas que executarão as atividades.
2º Mito – Modelos de maturidade estão ressuscitando o taylorismo. Um grupo de pessoas completamente alheias à realidade de quem “põe a mão na massa” cria um bando de processos democráticos.
Qualquer iniciativa de melhoria de processo de software está condenada ao fracasso se os executores das atividades que estão sendo descritas no processo são alijados das discussões. Portanto, não há cabimento em se associar este tipo de comportamento ao modelo A, B ou C.
3º Mito – Scrum ou XP são preferíveis ao CMMI/MPS.BR porque usam uma abordagem iterativa e não cascata.
Não há definição de uso de um ciclo de vida de projeto específico nos modelos de maturidade. O que é necessário para que haja aderência aos modelos é a definição de qual ciclo de vida será utilizado para cada um dos projetos. Pode ser cascata, iterativo ou qualquer outro.
4º Mito – Dezoito meses é o tempo necessário para se avaliar com um sucesso uma empresa no nível G do MPS.BR.
Não há um tempo determinado para se implementar os processos de um nível. Esse tempo varia muito de empresa para empresa, pois depende de alguns fatores como, por exemplo, investimento direto no projeto de melhoria de processos. A instituição mantenedora do modelo, a Softex, tem apoiado financeiramente empresas que apresentem certos requisitos a cobrirem parte dos seus custos de consultoria. Entre eles está o compromisso de se realizar uma avaliação após 12 meses e não 18. Mas isto não quer dizer que o tempo seja este ou aquele. Este compromisso existe apenas para empresas que participam de algum grupo que recebe este apoio financeiro.
5º Mito – O MPS.BR é burocrático demais. Se eu for gerar todos os documentos que são solicitados pelo modelo, não tenho tempo para fazer o mais importante: software de qualidade.
O MPS.BR não obriga a geração de nenhum documento específico. O modelo apenas exige que algumas formalizações sejam realizadas. E isso não é mera burocracia. É importante, pois a obtenção de compromissos por parte de clientes e fornecedores, por exemplo, é muito mais segura se for formalizada. Seria muito difícil as pessoas lembrarem todas as mudanças feitas no projeto e que foram acordadas apenas oralmente.
O MPS.BR e o CMMI, apesar de este último ter mais reconhecimento internacional, estão sendo tratados de forma indistinta porque eles são completamente compatíveis. Há apenas algumas diferenças: Há alguns processos e, portanto, requisitos adicionais ao MPS.BR ligados às áreas de gestão do conhecimento e gerência de reuso; O MPS.BR apresenta maior flexibilidade na exclusão de processos a serem considerados na avaliação.
Agora serão citados e comentados alguns resultados esperados de alguns processos do modelo. A nível de esclarecimento, as siglas no início de cada resultado são abreviações dos nomes dos processos aos quais eles pertencem e o número representa a posição do resultado dentro do processo. Nos exemplos abaixo são citados resultados dos processos Gerência de Projetos (GPR), Gerência de Requisitos (GRE) e Medição (MED).
GPR 1. O escopo do trabalho para o projeto é definido;
É interessante se definir o escopo de um projeto. Mesmo que ele venha a mudar necessário algum nível de definição inicial deste escopo: para que a mudança seja possível é preciso saber o que se quer mudar.
GPR 6. Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados;
Como em um projeto sempre há um grau de novidade é fundamental que ocorra, em algum nível, o gerenciamento dos riscos, já que se os mesmos não forem devidamente tratados, a probabilidade de que algum deles ocorra e prejudique algum aspecto do projeto é muito grande. O MPS.BR deve identificar esses riscos, classificá-los em relação à sua probabilidade e impacto e priorizá-los em função destas características. A priorização é importante para que aquilo que é mais importante tenha um cuidado maior do que aquilo que potencialmente pode trazer menos danos ao projeto.
GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo;
É neste ponto em que as pessoas envolvidas no modelo são mais valorizadas. É de extrema importância que a alocação dos recursos humanos aos projetos não se dê por questões como disponibilidade, por exemplo. Cada papel ou função dentro de um projeto requer uma série de conhecimentos e habilidades e o não-atendimento destes “pré-requisitos” normalmente traz consigo uma série de problemas. Se um funcionário irá desempenhar determinada função, mas não tem capacitação para isso, deve-se pelo menos oferecer-lhe um treinamento. O que o modelo quer evitar é que uma pessoa com um déficit de conhecimento importante vá adquirindo este conhecimento de qualquer forma, o que prejudicaria a qualidade do software.
GPR 13. O progresso do projeto é monitorado com relação ao estabelecido no Plano de Projeto e os resultados são documentados;
Fazer um planejamento para o projeto é altamente recomendável. É necessário, porém, que seja exercido certo controle sobre esse planejamento, um monitoramento constante que avalie se o plano está de fato sendo concretizado ou se necessita de alguma ação de correção de rota. Muito dificilmente um plano não sofrerá mudanças, mas ele, junto ao monitoramento é importante para que essas mudanças não sejam feitas de forma desordenada. É interessante planejar de forma progressiva, isto é, detalhar o que está próximo do momento atual e planejar as etapas mais avançadas de forma mais genérica dado que é impossível detalhar o que não se conhece. A parte da documentação é importante, pois ajuda a orientar o que deve ser feito naquele projeto e, futuramente, poderá servirá como base para, por exemplo, se estimar um tempo de construção de um conjunto de requisitos de outros projetos semelhantes.
GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos;
Espera-se que os requisitos do projeto sejam entendidos, definidos e que tal definição tenha a participação de uma pessoa (ou mais pessoas) chamada fornecedor de requisitos, que foi eleita por outros stakeholders do projeto para ser aquele que diz o que o software deve fazer para quem irá desenvolvê-lo. Esses requisitos devem ser documentados para que seja possível entender o que se deve ser feito e se manter um monitoramento sobre eles, até mesmo quando eles sofrerão mudanças, já que é preciso saber e se ter um controle do que está sendo mudado.
MED 2. Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e/ou definido, priorizado, documentado, revisado e atualizado.
A empresa precisa se conhecer objetivamente para alcançar o sucesso. E medidas, bem entendidas, definidas, coletadas e analisadas são a base para este autoconhecimento. Devemos medir aquilo que é melhor para a empresa e tirar o melhor proveito destas medições. É importante que o processo operacional de medição esteja completamente alinhado com aquilo que a empresa precisa para melhorar sua gestão.
Enfim, modelos de maturidade não são garantia de sucesso absoluto para nenhuma empresa. São um guia de referência para a aplicação de boas práticas dentro das empresas que desenvolvem software, um caminho a ser seguido por empresas que desejam melhorar seu desempenho operacional de forma consistente ao longo do tempo.
Nenhum comentário:
Postar um comentário