CMMI® ou Agile?

Há tempos venho alimentando a minha curiosidade em buscas de materiais que esclarecessem a polêmica que existe por trás de dois grandes paradigmas da Engenharia de Software: CMMI e Metodologias Ágeis. Foi então que me deparei com um excelente artigo escrito por profissionais do SEI (Software Engineering Institute) da Carnegie Mellon University. O nome do artigo? "CMMI® or Agile: Why Not Embrace Both!", numa tradução livre: "CMMI ou Ágil: por que não adotar ambos!(?)". Este post então é resultado de um pequeno resumo do artigo que, na minha opinião, contribue em muito para uma visão mais madura, no sentido profisisonal, sobre o entendimento de ambos os paradigmas, livrando-nos muitas vezes, de certo "achismos" e preconceitos. O artigo original é referenciado em um link no final deste post.

O artigo propoe desmistificar a confusão em que se tem ao adotar, em um mesmo ambiente de desenvolvimento de software, as metodologias CMMI e métodos ágeis. O autor afirma que o correto é se aproveitar ao máximo as melhores vantagens de ambos, já que as duas abordagens aplicam as melhores práticas da Engenharia de Software. Não sendo, portanto, saudável à profissão, se adotar uma postura favorável ou contra a qualquer um dos paradigmas. 

O autor ainda afirma que o mal uso de ambos os métodos por mais de 20 anos, causado pelo mal entendimento e o uso exacerbado de suas técnicas, é o que tem resultado o desentendimento e a conclusão errônea de que, as suas aplicabilidades atrapalham o sucesso de um projeto de desenvolvimento de software. 

O desentendimento muitas vezes ocorre mesmo em ambos os lados. Na comunidade CMMI existe a escassez de conhecimento profundo em torno dos métodos ágeis. Por outro lado, existe um conhecimento também superficial da comunidade ágil em relação ao CMMI. 

A falta de conhecimento muitas vezes se deve ao fato da definição de diversas terminologias específicas de seus contextos, como por exemplo, Garantia da Qualidade e Previsibilidade no CMMI e Integração Contínua e Código Coletivo em metodologias ágeis, conforme citado pelo autor. 

Outro fator de insucesso na aplicação conjunta desses dois conceitos está na diferença das duas abordagens, sendo uma bottom-up contra a outra, top-down, o que negligencia a visão de negócios, que deveria ser o que mais importa ao sucesso de um projeto de software. 

Algumas curiosidades foram encontradas no artigo. O autor reconhece que a maneira como o CMMI foi criado causou o desentendimento e a sua má aplicabilidade. Um outro ponto é que as pessoas na comunidade ágil reconhecem o fato de conhecerem muitos aspectos relacionados ao CMM mas desconhecem tudo o que envolve o CMMI. O CMM não é atualizado desde 1993, o que evidencia que encontra-se descontinuado devido à criação do CMMI. 

Uma outra cultura problemática nos tempos de hoje é que usuários do CMMI que usavam o CMM se atualizaram mas ainda continuam usando conceitos do modelo antigo. 

• A origem dos dois extremos:

O segundo capítulo se dedica a descrever as origens de cada abordagem. As metodologias ágeis foram inspiradas no IIDD (Desenvolvimento e Projeto Iterativo e Incremental), adotado há 75 anos na área de engenharia e posteriormente proposto ao desenvolvimento de software por Edward Deming. Na década de 90, após a adoção official de alguns métodos ágeis, como o XP, introduzido na Chrysler, o manifesto ágil foi escrito e, em poucos anos esta filosofica IIDD foi disseminada rapidamente pelo mundo devido à quantidade de adeptos de renome que obtiveram sucesso em seus projetos. 

Já o CMMI teve sua origem em abordagens top-down em projetos de contratos fechados principalmente desenvolvidos na linguagem COBOL. Uma primeira solicitação de sua criação e formalização foi feita pelo DoD (Departamento de Defesa dos E.U.A) ao que hoje chamamos de SEI (Software Engineering Institute) para melhorar a qualidade de seus projetos de software, pois, chegaram à conclusão de que a maioria deles eram muito custosos e não eram entregues ou eram entregues com atraso com poucas funcionalidades como o esperado. Os sistemas desenvolvidos nesse contexto eram comumente considerados críticos, ou seja, vidas poderiam ser perdidas em decorrência das falhas de software. 

Além desses fatores, os sistemas desenvolvidos para o DoD muitas vezes tinham um alto custo de deploy e testes, e não poderiam ser mais admitidas as entregas monolíticas e inconstantes. Um sistema embarcado em um avião caça em 1980, por exemplo, não poderia ser atualizado durante o voo ao se perceber uma falha. Logo, fazer o software corretamente da primeira vez era criticamente importante. 

• Fatores que afetam nossa percepção:

De acordo com o relatado pelo autor sobre o uso do CMMI nas organizações, o mesmo constata uma questão um tanto quanto curiosa: a perseguição pelos níveis de maturidade, através do conjunto de processos adotados, a empresa perde um pouco o foco no valores do ponto de vista do cliente, do produto, em torno dos projetos, e objetivos de negócios dos profissionais. 

Os profissionais que implementam o CMMI nas organizações muitas vezes falham em garantir que os processos adotados são totalmente implantados com sucesso nos novos projetos. Muitas vezes também não revisam os processos de acordo com as lições aprendidas e, os mesmos acabam se tornando incompatíveis com as práticas individuais e do time de desenvolvimento, além de se tornarem inflexíveis à adaptação de acordo com a necessidade do projeto. Um último ponto de falha na implantação é que, muitas vezes, os processos são descritos com um nível de formalismo que se torna de difícil entendimento pelos profissioniais, fator este que causa a sua rejeição. 

Para a implantação do CMMI com sucesso, deve-se considerar o equilíbrio exato adotado pela organização, avaliando prerrogativas do projeto e individuais, analisando as responsabilidades estabelecidas às pessoas, confiança, negócios e considerações também culturais. Se esse equilíbrio é afetado em favor da organização, os projetos e os profissionais podem perder a flexibilidade necessária que eles precisam para atingir o sucesso profissional e a motivação desejada. Por outro lado, muita flexibilidade pode expor a organização a um grande risco e podem perder a oportunidade do aprendizado organizacional, o que pode levar a uma maior qualidade dos projetos ao longo prazo. É difícil, portanto, se atingir o equilíbrio ideal. 

Um grande e comum engano que ocorre pelas pessoas que utilizam o CMMI é a de encará-lo como um padrão, quando na verdade ele é um modelo de processos. As suas práticas propostas não são um conjunto ordenado de atividades a se seguir dentro de um processo específico. Quando se usa o termo “modelo”, a intenção é dizer que o método pode ser customizado de acordo com a necessidade, ou seja, as práticas são utilizadas conforme a necessidade da organização em qualquer momento de sua realidade. O CMMI também encoraja o experimento de outros modelos, práticas, frameworks e abordagens para a melhoria dos processos conforme a necessidade. 

Em suma, o CMMI formou ao longo de muitos anos de pesquisa, uma base sólida de conhecimentos necessários aos projetos de software e metodologias atuais. CMMI não foi concebido para ser um substituto ou uma definição de qualquer coisa no mundo real, e isto é que é um modelo. Portanto, é apenas um ideal construído para se definir boas práticas de situações no mundo real. 

O que acontece é que muitas vezes, justamente por encará-lo como um padrão, ao invés de um modelo, o CMMI acaba sendo aplicado, quando deveria, na verdade, ser implementado. Isto faz com que se perca o foco no produto e ganhe foco mais na avaliação da organização, algo puramente comercial em muitos casos. 

A implementação então, no mais correto conceito, se dá em utilizar o modelo da mesma maneira em que arquitetos e engenheiros da construção civil usam seus modelos: como uma ferramenta de aprendizado, comunicação, e principalmente, como um meio de organizar seus pensamentos. Já a aplicação é a corrida desenfreada em tentar se tornar exequível todas as práticas por ele propostas.

• A verdade por trás do CMMI:

Um fato que muitas vezes é contrariado principalmente pela ocorrência da desinformação é que, analisando holísticamente os últimos objetivos do CMMI, os seus propósitos são os de tornar os processos de desenvolvimento de software menos pesados, eliminando tudo o que causa a improdutividade, assim como é proposto nas metodologias ágeis. Além disso, diferentemente dos métodos ágeis, o CMMI oferece toda a infra-estrutura de aprendizado organizacional e benefícios de melhorias passadas para os projetos que ainda nem começaram. 

Para se reforçar a idéia de que o CMMI é um modelo, o autor exemplifica dentro de alguns objetivos e suas práticas-chave, o único ponto que deve ser obrigatório a se seguir são os objetivos, já as práticas são opcionais, ou seja, é possível se escolher apenas algumas, desde que se atenda ao objetivo do modelo para a melhoria de uma área de processo que traga mais valor ao negócio da empresa. 

De acordo com essa preocupação de se utilizar o CMMI corretamente, foram criadas as avaliação SCAMPI, a qual é utilizada para analisar se a empresa está utilizando o CMMI como um modelo mesmo e não um padrão. Esta análise é feita através de estórias, ou temas, que sugerem visões para dar base a um analisador ou uma equipe de análise de processos. 

• A verdade por trás das metodologias ágeis:

Na intenção de relatar as verdades que ocorrem também em torno dos manifestos ágeis o autor nos revela também pontos problemáticos na sua abordagem. Existem muitos depreciadores da mesmas que fazem um mau uso, ganhando a fama de “lacaios indisciplinados”, pois, ao analisar o Manifesto Ágil, os mesmos acabam julgando que as práticas por ele propostas são a verdade absoluta ao sucesso de um projeto, sendo que na verdade, o que o manifesto diz é que devemos buscar mais as suas práticas ao invés das sugeridas por métodos tradicionais, mas não que devemos evitá-las. Muitas vezes essas pessoas apenas usam desses argumentos para se ter a total liberdade em seus processos, o que na verdade, os torna caóticos e não caracterizam qualquer metodologia. 

Um ponto marcante das metodologias ágeis é que as mesmas privilegiam o conhecimento tácito das pessoas (como no manifesto ágil: iterações entre os indivíduos ao invés de processos e ferramentas). Este fator pode beneficiar diretamente a organização baixando o custo de seus processos de Engenharia de Software. 

Os riscos de processos centrados no conhecimento tácito são mitigados pelos seguintes fatores: 

- A duração do projeto e do ciclo de vida esperado (feito em “Time-Boxes” previsíveis); 

- A natureza moderna de auto-documentação dos códigos-fonte; 

- O uso de ferramentas de engenharia reversa para documentar o projeto e ferramentas que integram pequenos pedaços do código continuamente; 

- Equipes pequenas (o que traz baixa rotatividade de pessoal). 

O grande risco é quando há ausência de processos, disciplina e regras para planos ou planejamento do projeto. 

Cada palavra utilizada no manifesto ágil foi escrita cuidadosamente para denotar que se deve, portanto, dar prioridade aos conceitos estabelecidos e, no entanto, não devem ser interpretados como sendo a verdade absoluta. Algo semelhante ao engano que se comete no CMMI ao se aplicar todas as práticas rigidamente ao invés de se propor um modelo que atenda aos objetivos gerais. Algo que a abordagem SCAMPI vem tentando mudar. 

• Conclusão: Há valor em ambos os paradigmas!

O que se prentende demostrar através de todos esses conceitos e fatos é que, há valor em ambos os paradigmas. CMMI e práticas ágeis são compatíveis pois, diferentemente do que se pensa, elas tratam de níveis diferentes de abstração, pois o CMMI trata dos processos visando a maturidade da organização, enquanto que as metodologias ágeis focam nos artefatos a nível de projeto. No entanto, quando se traz o CMMI também ao nível de projetos, é comprovado que ambos são realmente compatíveis, já que o CMMI diz o que o projeto deve fazer, e não em qual metodologia deve-se aplicar, podendo então se utilizar qualquer uma que tenha um alto nível de maturidade, como é o caso dos métodos ágeis. 

A sinergia proveniente do uso dos dois paradigmas podem trazer inúmeros benefícios. Os métodos ágeis podem fornecer o “how-to” (como fazer) para as melhores práticas do CMMI que funcionam bem ao contexto do projeto. Por outro lado, o CMMI fornece toda a engenharia para se sustentar as práticas ágeis em grandes corporações. Além disso, o CMMI pode fornecer todo o gerenciamento dos processos que ajudarão a manter e melhorar continuamente a implantação de uma abordagem ágil em uma organização. 

Um dos maiores desafios dos projetos que utilizam as metodologias ágeis nos dias de hoje, é a obtenção de escala para grandes projetos e até mesmo de manter o alinhamento quando se tem diversos projetos em uma mesma empresa. Quando não há a preocupação neste patamar organizacional, os riscos não são devidamente controlados e os requisitos não-funcionais ou arquiteturais acabam sendo deixados de lado. Para tanto, o CMMI oferece uma abordagem eficiente para gerir em grande escala. Uma outra tendência neste tipo de gerenciamento está em um novo modelo organizacional, também ágil, baseado em Scrum de Scrums. 

Já no CMMI o grande desafio está no que já havia sido comentado: flexibilizar o projeto e assim aplicar o tailoring correto às necessidades da empresa, priorizar os objetivos de negócio ao invés de focar na corrida da obtenção de certificação. As práticas, ao se atingir um determinado nível de maturidade, pode trazer valores imediatos. No entanto, a longo prazo, essa maturidade pode ser perdida devido à sobrecarga de processos rumo a um novo nível. 

O autor julga que muitas literaturas recentes para o CMMI são meras anedotas ao criticar as metodologias ágeis. O mesmo acontece no lado oposto. Há também um julgamento precoce em torno da adoção de um paradigma ou outro ao se tentar aplicá-los em um projeto piloto e o mesmo falhar. Logo, o paradigma é tachado de falho e em seguida abandonado. 

Em suma não existe um paradigma melhor que o outro, o que há são melhores abordagens para cada situação ou necessidade, variáveis instrínsecas ao perfil da organização. Em acréscimo a essa idéia, o autor afirma que, em grandes organizações, obtem-se uma melhor maturidade nos processos utilizando-se da sinergia resultando da junção dessas duas abordagens. O benefício colhido a longo prazo, sengundo pesquisas, se torna extremamente satisfatório. 

Quando o CMMI é implementado de forma adequada, pode fornecer a infra-estrutura necessária para dimensionar com êxito a gestão e as entregas de sistemas complexos, mantendo as vantagens do desenvolvimento iterativo e incremental que as metodologias ágeis oferecem. 

Segundo citações do autor, é recorrente vermos em discussões sobre o assunto pela comunidade ágil que, CMMI e metodologias mais tradicionais como o processo em cascata são colocados como sinônimos, o que é de fato errôneamente interpretado! O CMMI transcende tais definições, pois, este paradigma não se enquadra no conceito de métodos ágeis e muito menos à métodos tradicionalistas. 

A tendência em se formar campos distintos, tais como os que separam CMMI e Agile, é inerente à característica humana, mesmo quando falamos em desenvolvimento de software. O autor então defende que devemos ter um único objetivo em mente: unir as comunidades em uma só. Assim, ganhariamos em discussões com o intuito de se comparar resultados, facilitando também a experimentação e aprendizado.

• A referência: 

Link original do artigo: http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm

Finalizo por aqui pessoal deixando a seguinte pergunta: 

Você concorda com as afirmações deste autor? O que você mudaria ou acrescentaria a essas idéias?

Um grande abraço e até o próximo post!  :-)

.