Total de visualizações de página

terça-feira, 20 de abril de 2010

Visão Ágil e Visão estruturada-Parte-2-CMMI

CMMI:

Um dos pontos mais importantes para se entender as diferenças e ajustar os encaixes, quando falamos de CMMI(MPS.BR) e métodos ágeis, é compreender a origem de cada abordagem.
O CMMI surgiu para se desenvolver projetos grandes, de gerência altamente complexa, torneados com escopo imutável e custo definido, além de altíssima aversão a riscos. Os primeiros projetos CMM surgiram para a fabricação de softwares que visavam controlar naves espaciais, satélites inovadores e armamentos de tecnologia inédita. O modelo foi publicado em 1989, por Watts Humphrey, no seu livro "Managing the Software Process". O Departamento de Defesa(DoD), responsável por esses projetos estratégicos não tinha outra saída, naquele momento, senão sugerir métodos altamente estruturados, com forte gerência de requisitos e um estrito controle das partes envolvidas.Um ambiente onde o escopo era(ou tinha que ser) definido rigorosamente, pois o software era tido como um componente de algo maior, cuja infalibilidade era a premissa primeira, até porque naves espaciais, satélites,equipamentos médicos,etc, implicavam aspectos de segurança de vida. Os usuários não eram stakeholders colaborativos, como agora percebemos, entrando no circuito do processo somente para os testes e com pouca intervenção durante o trajeto. Esse conceito era chamado de "low trust". O sistema era desenvolvido por processos cuidadosamente definidos centrados no menor risco, na fortíssima padronização e em relacionamentos amplamente costurados por contratos entre clientes e desenvolvedores. Isso acabou moldando a personalidade do modelo CMMI para ambientes que os americanos chamavam de " high ceremony" e "low trust" , ou seja com alto nível de controle de risco e aplicação de gerência e com baixa interveniência dos usuários. As entregas, por sua vez, também obedeciam a uma receita da época: os "deliveries" eram monolíticos e infrequentes. Porquê? Por que a parada de um caça de guerra para troca de possível componente(software incluído), ou a suspensão da funcionalidade de um aparelho médico podia custar muitas horas de logística. Na época, claro,não se baixava um software pela internet. Além disso, entregar o componente funcionando na sua plenitude, no primeiro "delivery" era premissa de primeira ordem. Tudo isso, num projeto gigantesco, com envolvimento de múltiplas empresas com inúmeras equipes e entrelaçados por contratos governamentais exigentes em termos de baixo risco. Com o tempo, o CMM ganhou variantes para outros projetos(não somente de software) e não demorou o pleito para que todas essas fossem empacotadas num único modelo, quando nasceu o CMMI, em 1998. O CMMI foi evoluindo e hoje forma o framework com um conjunto melhorado de padrões, práticas e idéias.Mas a sua gênese trouxe marcas que definiram o método e que se observa no seu genoma:
1)Aplicado para projetos grandes e de alta complexidade;
2)Aplicado em projetos com múltiplas equipes, oriundas de empresas diferentes e até competidoras entre si, onde a competitividade influia e o alto protocolo definido substituia a confiança(trust) e a coesão das equipes, definindo um ambiente com traços de "low trust". Ou seja, a confiança entre os times não se dava por coesão, integração e interação constante das equipes(valor do relacionamento do capital humano), mas pelo nivel de cerimônia, rigor e protocolo que o processo impunha;
3)Projetos onde os "deliveries" eram monolíticos e infrequentes, pois a logística de parada dos seus receptores de software (aviões,satélites e devices médicos) implicava sérios riscos. A idéia era entregar o " todo" com "quase tudo" funcionando na primeira vez( a velha e volumosa cascata);
4)Os projetos tinham que ter baixos riscos(aversão intensa a riscos) devido às suas características técnicas especiais e ao alto investimento de recursos públicos, dada as características dos projetos.
Assim nasceu um modelo CMMI, fortemente estruturado, revestido pelo rigor das regras e com baixa interação do capital humano(entre equipes),porém aplicado para projetos gigantes e de alta complexidade operacional e gerencial.Isso, entretanto, não significa que o Modelo, tal como definido hoje, não pode ou não deve ser aplicado em projetos que possuem estilo e ciclos de vidas diferentes. Um modelo, qualquer que seja, deve ser visto como um guia e não como uma regra ortodoxa calcada sobre preceitos imutáveis, conforme veremos na parte 4.

Um comentário:

  1. Muito interessante, não sabia desta "sisudez" toda do CMMI, isso começa a explicar muitas coisas, mas como você mesmo disse "Um modelo, qualquer que seja, deve ser visto como um guia e não como uma regra ortodoxa calcada sobre preceitos imutáveis.." então vamos em frente...

    ResponderExcluir