As Origens do CMMI e dos Métodos Ágeis

A ideia de incompatibilidade entre os métodos Ágeis e as melhores práticas do CMMI pode ser atribuída em grande parte às diferentes origens das duas abordagens. Os métodos Ágeis tiveram a sua origem em mercados caracterizados por mudanças rápidas e pequenas organizações. Pelo contrário, o CMMI provém de mercados caracterizados por grandes organizações e alguma estabilidade contratual. Evidentemente, estas ideias são generalizações, mas se analisarmos com maior detalhe a forma como cada uma das abordagens foi criada - como veremos a seguir - apercebemo-nos claramente porque razão abordam o desenvolvimento de software com base em diferentes perspectivas.

As origens dos métodos Ágeis

A base dos métodos Ágeis é o IIDD (desenho e desenvolvimento iterativo e incremental), um método adoptado há cerca de 75 anos. Entre os primeiros a adoptar o IIDD esteve o departamento de defesa (DoD) americano. Por sua vez, um dos progenitores do IIDD foi W. Edwards Deming, que começou a promover o Plan-Do-Study-Act (PDSA) como componente vital da engenharia empírica. Mais uma vez, entre os primeiros adeptos dos ensinamentos de Deming estiveram nomes sonantes como a NASA (National Aeronautics and Space Administration) e a força aérea dos Estados Unidos.

Em meados da década de 1950, o IIDD era utilizado no desenvolvimento de software, apregoando as vantagens de "evitar o desencorajamento da gestão" e "aumentar a satisfação do cliente". No entanto, num mundo de sistemas dominado pelos mainframes, pela linguagem COBOL (Common Business-Oriented Language) e pela procura de processamento de grandes quantidades de dados complexos, a regra eram os métodos de desenvolvimento e de desenho top-down, considerados inclusivamente por muita gente como sendo o standard a seguir.

Esta situação foi influenciada pela natureza dos standards do DoD e pela proliferação de contratos com preço fixo celebrados com os fornecedores de sistemas complexos. Recorde-se que nessa altura, os consumidores de software eram sobretudo as grandes organizações.

Em 1976, Tom Gilb, no seu livro Software Metrics, referiu que o desenvolvimento evolutivo resultava na disponibilização de software superior, lançando um movimento que tinha em vista iterações ágeis e leves, capaz de fornecer resultados rápidos e benefícios de negócio visíveis com maior frequência.

À medida que aumentava o grau de maturidade da engenharia de software, foram disponibilizadas mais aplicações formais do IIDD, como no The Spiral Model of Software Development and Enhancement de Barry Boehm (1985). Na década de 1990, o IIDD conseguiu uma aceitação bastante alargada na comunidade de software. E isso aconteceu de várias formas, incluindo a prototipagem rápida, o RAD (rapid application development) e o RUP (rational unified process). As sementes da maior parte dos modernos métodos Ágeis foram lançadas na década de 1990.

Apesar de muitas pessoas poderem não ter consciência disso, os métodos Ágeis e inovadores começaram nos departamentos de TI (tecnologias de informação) de várias grandes empresas, incluindo um fabricante de automóveis e um banco. Por exemplo, o XP (eXtreme Programming) teve as suas origens na Chrysler Corporation em 1996, enquanto o FDD (feature driven development) deu os primeiros passos no United Overseas Bank, em Singapura.

O método XP tornou-se um dos mais reconhecidos da família Ágil, mas também proliferaram outros métodos, com nomes como Scrum, Crystal, ou FDD. Com todos estes métodos IIDD surgiu a necessidade de os coordenar e comparar para permitir o seu crescimento e suporte. Deu-se então uma reunião entre os principais responsáveis pela teoria e aplicação de cada método. Entre os nomes mais sonantes, marcaram presença Kent Beck, Ron Jeffries, Alistair Cockburn, Jim Highsmith, Bob Martin, Mike Beedle, Ken Schwaber, ou Jeff Sutherland.

Destes encontros acabaria por sair o célebre Manifesto para o Desenvolvimento de Software Ágil ou a Agile Alliance, uma organização sem fins lucrativos destinada a promover a adopção dos métodos Ágeis. O Manifesto documentou os princípios orientadores para o desenvolvimento Ágil e definiu uma filosofia em torno de um conjunto de metodologias existentes.

Enquanto o primeiro Manifesto para o Desenvolvimento de Software colocava o enfoque na programação, três anos depois nasceu um conjunto de seis princípios de gestão conhecido como Project Management Declaration of Interdependence (DoI). Os autores do DoI formaram posteriormente a Agile Project Leadership Network (APLN), uma organização sem fins lucrativos destinada a encorajar uma melhor liderança e gestão no sector das TI e na profissão de engenharia de software.

Toda esta actividade teve como resultado um crescimento rápido e uma adopção alargada dos métodos Ágeis no mundo da engenharia de software. Inclusivamente, alguns métodos, sobretudo o Scrum, continuaram a crescer para além da indústria de software, alargando o seu campo de acção a áreas que pretendem obter os benefícios proporcionados pelos conceitos básicos do IIDD.

As origens do CMMI

Antes de receber o nome CMM, a primeira framework Capability Maturity Model foi publicada em 1989 por Watts Humphrey no livro Managing the Software Process. Alguns anos antes, o DoD tinha efectuado um pedido de propostas para responder à soma excessiva de dinheiro que gastava em software que nunca era disponibilizado ou que era disponibilizado demasiado tarde e com pouca da funcionalidade esperada. A ideia deste pedido de propostas era criar o que conhecemos actualmente como Software Engineering Institute (SEI) na Carnegie Mellon University.

O SEI juntou representantes do mundo universitário, da investigação e da indústria para identificar e promover práticas que tenham dado provas práticas de sucesso nos esforços do DoD em termos de aquisição de software. A framework de boas práticas da Carnegie Mellon para responder aos problemas do DoD foi designada por CMM. Se tivermos em conta o espaço temporal em que tudo isto aconteceu, vemos que foi antes da Internet e de praticamente tudo o que está associado às tecnologias Internet.

Aprendemos muito nos últimos 20 anos. Na realidade, quando o DoD se propôs resolver o seu dilema de software, esta indústria era muito diferente do que é actualmente. Para contextualizarmos melhor esta questão, podemos dizer que todos aqueles que trabalharam no desenvolvimento do CMM inicial estavam à procura da solução para o problema do software, partindo do princípio que o software é um componente de um sistema maior e que se ele falhar, poderão perder-se vidas (por exemplo, em aviões, navios, armamento, equipamentos médicos).

Os sistemas eram criados utilizando passos de desenvolvimento cuidados e deliberados, de acordo com relações contratuais entre o cliente e quem efectuava o desenvolvimento. Os utilizadores não contribuíam normalmente de forma directa para o desenvolvimento do produto final antes da fase de teste em ambiente de utilização prática. Tudo se baseava na relação contratual, nos requisitos e nos standards para disponibilizar o produto.

Estes comentários poderão ser uma generalização algo exagerada, mas a ideia é resumir o ambiente de aquisição de software por parte do DoD que existia na altura. Além disso, pretende-se explicar porque razão as práticas do CMMI ainda podem apresentar algumas características de cerimónia e baixa confiança encontradas no ambiente de contratação governamental caracterizado por um risco elevado do software, podendo envolver a perda de vidas em caso de falha.

Por outro lado, neste tipo de ambientes de alto risco era extremamente importante que o software saísse bom à primeira. As entregas eram monolíticas e pouco frequentes, o que contribuía para custos elevados de implementação, actualização e substituição. Por exemplo, o software existente num avião de combate da década de 1980 não podia ser actualizado com base em ligações Internet e/ou sem fio. Para agravar ainda mais esta situação, a maior parte das organizações envolvidas neste ambiente contratual era de grande dimensão, trabalhando em projectos também de grande dimensão e grande complexidade.

Outro dos elementos importantes em jogo era a utilização de dinheiros públicos nos contratos governamentais, onde a grande visibilidade exigia níveis elevados de responsabilidade por parte das partes envolvidas, dando assim origem a ambientes avessos ao risco, onde era mais importante proteger os próprios interesses do que encontrar a solução mais eficiente para ambas as partes.

No espaço de poucos anos, o CMM deu origem a vários outros modelos, desenvolvidos para responder às necessidades de projectos que não tinham nada a ver com o desenvolvimento de software. O CMM e as suas variantes também passaram a ser cada vez mais utilizados a nível internacional e pela indústria comercial. Como as organizações que tentavam adoptar mais de um modelo num dado projecto rapidamente se aperceberam dos desafios inerentes a esse propósito, pediram ao SEI que consolidasse os vários CMMs num só modelo. Foi assim que surgiu o CMMI em 1998, criado por uma equipa constituída por representantes da indústria, governo e SEI.

Entretanto, como seria de esperar, têm surgido novas contribuições de boas práticas de gestão e de desenvolvimento propostas por uma grande variedade de indústrias e de utilizadores de todo o mundo. Consequentemente, têm sido incorporados continuamente no CMMI novas ideias, standards e práticas.

Baseado num texto da autoria de Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad e Sandy Shrum, com o título "CMMI or Agile: Why Not Embrace Both!"