MOVIMENTO ÁGIL, CMMI e o MIDDLE-GROUND?

Vamos entender e contextualizar o gênesis dos modelos de maturidade e das metodologias ágeis

PRÓLOGO

Houve um tempo em que estar no meio de algo, de uma posição, de um lugar ou mesmo de uma opinião não era um lugar ruim. Se você estava no ranking médio de sua classe ou se você estava no meio de uma fila de pessoas já era melhor do que estar no final, apesar de não ser tão bom como estar em primeiro.

Em uma grande maioria de situações, estar no meio não é necessariamente uma coisa ruim, todavia, atualmente nós parecemos viver em um mundo orientado à beira das coisas; nosso contexto global expõe uma realidade que nos empurra a acreditar que os extremos são os únicos caminhos disponíveis para alcançar o sucesso, seja pessoal, profissional, técnico ou principalmente político.

Mas, então, o que isto tudo tem a ver com o título deste artigo? Bom, a dualidade presente no título acima por si só já contém o antagonismo implícito para, naturalmente, despertar opiniões polarizadas de muitos interessados no tema. Não que o tema seja tão polêmico assim, mas, quando leio as diversas matérias ou participo de argumentações acerca do assunto, por vezes me sinto como o sujeito no centro a charge abaixo.

 

Créditos da Imagem “Finding the Middle Ground” RIOS 2002

 

Sinto-me desta forma não por falta de opinião, mas porque vejo que ambas as abordagens possuem valores que devem ser reconhecidos em face de situações diferentes.

Mas, antes de tudo vamos entender e contextualizar o gênesis dos modelos de maturidade e das metodologias ágeis; com certeza, entender de onde vieram irá nos ajudar a melhor compreendê-los e, por fim, quem sabe compreender o seu “middle-ground”.

 

 

O CMMI

O CMMI surgiu na década de 80,em plena guerra fria e durante o período de reativação da Iniciativa Estratégica de Defesa Americana (também conhecido como Star Wars). A ideia do CMMI foi resolver o grande problema gerado pela utilização de diferentes Modelos de Maturidades em Capacitação (CMMs) de forma concomitante.

A principal motivação era prover ao departamento de defesa norte-americano (DOD) a capacidade de prever a qualidade, os custos e os prazos nos projetos contratados e licitados. Desta forma, visando o desenvolvimento do projeto CMMI o DOD fundou (em 14 de novembro de 1984) em conjunto com a Carnegie-MellonUniversity, o Instituto de Engenharia de Software (SEI).

Originalmente o SEI era o instituto responsável pelo CMMI, hoje em dia é o CMMI Institute que mantém e desenvolve o modelo. De uma forma sucinta a evolução do modelo pode ser sintetizada pela figura abaixo.

 

Imagem: EVOLUÇÃO DOS CMMS. Fonte (CHRISSIS; KONRAD; SHRUM, 2011)

 

No Brasil, com o objetivo de fomentar, facilitar e popularizar o uso de modelos de maturidade compatíveis com o CMMI por empresas nacionais, a iniciativa MPS.BR foi criada em dezembro de 2003 e coordenada pela SOFTEX (com o apoio do MCTI, FINEP, SEBRAE e o BID).

Vale ressaltar que, apesar de não ser um processo e sim um modelo de maturidade o CMMI está diretamente ligado a sua premissa de quea qualidade é influenciada pelo processo e que seu foco é a melhoria contínua deste processo.

A base da constelação de variações do CMMI é formada atualmente pelos modelos: CMMI-DEV - Voltado ao processo de desenvolvimento de produtos e serviços; CMMI-ACQ - Voltado aos processos de aquisição e terceirização de bens e serviços; CMMI-SVC - Voltado aos processos de empresas prestadoras de serviços.

Até a data deste artigo a versão 1.3 do CMMI-DEV é a mais recente, sendo dividida em cinco níveis de maturidade:

- Nível 1 - Realização;
- Nível 2 - Gerenciado;
- Nível 3 - Definido;
- Nível 4 - Quantitativamente;
- Nível 5 - Otimização.

Cada um dos níveis de maturidade é definido por um conjunto de áreas de processos (PA) próprios juntamente com as áreas de processo pertencentes aos níveis anteriores, com exceção do nível um que não possui nenhuma área de processos

 

 

O MOVIMIENTO ÁGIL

Na década de 90, um engenheiro aeroespacial chamado Jon Kern, muito frustrado com os longos prazos de entrega dos sistemas desenvolvidos e principalmente com o resultado das decisões tomadas nos estágios iniciais do projeto e que dificilmente poderiam ser alteradas posteriormente, juntou-se a outros 16 líderes de software que iniciaram uma série de encontros informais para buscar e analisar maneiras de desenvolver software de maneira mais simples, sem as rígidas etapas de processos imputadas por técnicas comuns na época (e até hoje) como, por exemplo, o processo CASCATA (WATERFALL).

Com rápida adesão à ótica dos 17 líderes da comunidade ágil encontravam-se empresas tradicionais que sofriam com a rápida ascensão de pequenas companhias capazes de criar produtos melhores de forma a abocanharem fatias importantes de seus mercados em um curto espaço de tempo.

Adicionalmente, a expectativa por inovações e a necessidade de atendimento de demandas de mercados consumidores cada vez maiores criou um alinhamento perfeito para o nascimento da metodologia ágil.

 

Manifesto para Desenvolvimento Ágil de Software

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas

Software em funcionamento mais que documentação abrangente

Colaboração com o cliente mais que negociação de contratos

Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Signatários:
1.    Kent Beck
2.    Mike Beedle
3.    Arie van Bennekum
4.    Alistair Cockburn
5.    Ward Cunningham 
6.    Martin Fowler
7.    James Grenning
8.    Jim Highsmith
9.    Andrew Hunt 
10.    Ron Jeffries
11.    Jon Kern
12.    Brian Marick
13.    Robert C. Martin
14.    Steve Mellor
15.    Ken Schwaber
16.    Jeff Sutherland 
17.    Dave Thomas

 

Princípios por trás do Manifesto Ágil

Nós seguimos estes princípios:

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.

Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.

O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.

Software funcionando é a medida primária de progresso.

Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

Contínua atenção à excelência técnica e bom design aumenta a agilidade.

Simplicidade--a arte de maximizar a quantidade de trabalho não realizado--é essencial.

As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Imagem: Manifesto para Desenvolvimento Ágil de Software. Fonte http://agilemanifesto.org/iso/ptbr/manifesto.html

 

O MIDDLE GROUND

Uma vez contextualizado a origem do CMMI e do movimento Ágil e suas bases tão antagônicas, vamos avançar um pouco no tempo e jogar uma luz sobre o contexto de uso atual de ambos.

Se por um lado o desenvolvimento ágil se conecta como uma luva aos profissionais que desenvolvem a solução e ao cliente que irá utiliza-la, o CMMI se conecta aos gerentes de projetos e colaboradores intermediários que supervisionam e acompanham os trabalhos sendo executados. Esses últimos, quase sempre responsáveis por responder e fornecer indicadores sobre a saúde da operação de desenvolvimento para a alta direção das empresas.

Ainda, na mesma medida que a adoção contínua ao movimento ágil se expande como um dilúvio sobre o mercado privado, também cresce a dificuldade de contratação por parte de setores governamentais e grandes instituições, uma vez que estão cada vez mais presos a regras de conformidade e legislações que os remetem a estimativas fiéis de custo, prazos, uso de recursos e quantificação/qualificação de entregas de contratos.

Ambos cenários supracitados são bem diferentes, mas o objetivo final permanece o mesmo, entregar um produto de qualidade, com custo e prazo aceitáveis e que resolva o problema do cliente.

Então, se observarmos com objetividade a dinâmica de funcionamento da gestão empresarial e governamental, e também aplicarmos uma dose de bom senso podemos chegar à conclusão que os antagônicos precisam coexistir de alguma forma, sendo este fato muito mais comum do que se imagina.

Segundo dados recentes do CMMI Institute, mais de 70% das organizações avaliadas em 2015 no modelo CMMI, usavam uma ou mais abordagens ágeis acompanhadas de processos de gestão. Esta realidade tem se tornado cada vez mais frequente.

Tão frequente que atualmente o site do CMMI Institute disponibiliza um guia para adequação da metodologia Scrum ao CMMI e seguindo esta tendência estão sendo preparados guias para adequação para outras metodologias ágeis.

É inegável a ampla contribuição que o movimento ágil trouxe para o universo de desenvolvimento de software, porém (mais uma vez me sentindo como o sujeito no centro da charge), aplico esforços para balancear a liberdade e a autonomia adquirida nas metodologias ágeis aos benefícios efetivos e à necessidade da aplicação das boas práticas de projeto.

Por fim, acredito ser imprescindível, em um contexto tão heterogêneo como o atual, investir em flexibilidade corporativa e abrangência técnica para alcançar o middle-ground entre os dois universos, pensando sempre na melhor abordagem para cada situação. Pois como mencionado no próprio manifesto ágil:

“... mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.” (EOF)

 

Autor: Gustavo Castro

 

Para outras informações fale conosco