Flávio Meira 5º Semestre TADS
Bruno Henrique dos Santos
PROF..: Tânia Ramires
MPS.BR é uma metodologia de melhoria de projeto de software, assim como a CMMI, que trata do mesmo assunto, porém a nível internacional.
Segue alguns mitos e verdades sobre modelos de maturidade de processos.
1. Modelos de maturidade só se preocupam com processos. A competência das pessoas é desconsiderada.
Este é um engano recorrente. Os processos são de fato bastante valorizados nos modelos. Mas há também resultados / práticas / objetivos específicos, tanto no MPS.BR quanto no CMMI, referenciando diretamente a necessidade de competência e conhecimento das pessoas em relação às atividades que executam.
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 muitos problemas.
2. 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 burocrá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 aliados das discussões. Portanto, não há cabimento em se associar este tipo de comportamento ao modelo A, B ou C. Se isto ocorre dentro de alguma empresa, a falha é de quem está conduzindo o projeto de melhoria ou de quem está orientando a sua execução (consultores, implementadores, etc) e não do modelo.
3. Scrum ou XP são preferíveis ao CMMI / MPS.BR porque usam uma abordagem iterativa e não cascata.
Não há a 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, misto, incremental, entrega evolutiva ou qualquer outro. Por exemplo, o método XP pode ser usado em conjunto com o SCRUM, que por sua vez, é empregado como metodologia de planejamento e gerencia de projeto.
5. 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 estas formalizações, em projetos não são mera burocracia. A obtenção de compromissos por parte de clientes e fornecedores, por exemplo, é muito mais segura se for formalizada.
Para mostrar o pragmatismo da melhoria de processos de software via MPS.BR serão citados e comentados alguns resultados esperados de alguns processos do modelo. Ficará fácil de visualizar que não há nada de burocrático ou sobrenatural sendo proposto. Apenas para fins 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).
GPR1. O escopo do trabalho para o projeto é definido
Nas metodologias de maturidade de projeto, o escopo sempre tem de estar definido no inicio do projeto. Mesmo em projetos que defendem um escopo flutuante, é necessário algum nível de definição inicial deste escopo.
GPR 7. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo
O modelo pede que as alocações dos recursos humanos aos projetos não se dêem apenas por disponibilidade, ou seja, que alguém não seja alocado simplesmente porque está livre ou menos atarefado. 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 muitos problemas.
GPR 13. O progresso do projeto é monitorado com relação ao estabelecido no Plano do Projeto e os resultados são documentados
Planejamento e controle são dois lados de uma mesma moeda. Não há muito sentido em se planejar se não houver 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 – ação esta que tanto pode estar ligada à execução quanto à modificação do próprio plano original, desde que haja a concordância dos diversos envolvidos no projeto.
GRE 1. O entendimento dos requisitos é obtido junto aos fornecedores de requisitos
O que se espera é que os requisitos sejam entendidos, definidos e que tal definição tenha a participação de uma pessoa (ou de mais pessoas) chamada fornecedor de requisitos, que nada mais é do que o eleito por outros stakeholders do projeto (normalmente o patrocinador) para ser aquele que diz o que o software deve fazer para quem irá desenvolvê-lo. Alem disso, os requisitos devem ser documentados.
MED2 - Um conjunto adequado de medidas, orientado pelos objetivos de medição, é identificado e/ou definido, priorizado, documentado, revisado e atualizado
“Não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende, não há sucesso no que não se gerencia.”
A frase acima é de William Edwards Deming, um dos papas da qualidade. Sua conclusão é clara: 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 auto-conhecimento. Como saber se a produtividade da minha empresa está baixa ou alta? Ou até antes disto: como saber qual é a produtividade de minha empresa? Como avaliar se medidas tomadas para reduzir o número de defeitos em um produto foram ou não eficazes? Como aumentar a previsibilidade de meus projetos? Medindo, medindo e medindo – e claro, analisando e tirando o melhor proveito destas medições.
O resultado MED2 fala também em objetivos de medição. Estes objetivos são derivados das necessidades de informação da organização. Ou seja, devemos medir aquilo que é importante para a empresa. É importante que o processo operacional de medição esteja completamente alinhado com aquilo que a empresa precisa para melhorar sua gestão.
Conclusão
Qualidade de software não é uma ciência exata. Discussões e divergências sempre ocorrerão. A internet potencializa as discussões e gera um fluxo maior de informações. O problema é que há informações certas e erradas, fundamentadas e levianas, racionais e apaixonadas. É cada vez mais importante saber separar o joio do trigo.
Modelos de maturidade não são garantia de sucesso absoluto para nenhuma empresa. Mas certamente servem muito bem como um guia de referência, um caminho a ser seguido por empresas que desejam melhorar seu desempenho operacional de forma consistente ao longo do tempo.
Material fonte: Artigo da Revista Engenharia de Software edição 2 – Autor: ANDRIELE FERREIRA RIBEIRO.
Nenhum comentário:
Postar um comentário