Métodos Ágeis ou MPS.BR/CMMI ? Por que não os dois?

Recentemente, com Isabella Fonseca, da Powerlogic, participei do seminário Maré de Agilidade, onde se discutiu, dentre outras coisas, a aplicação de modelos ágeis. Fui com o estrito objetivo de trincar alguns tabus extremistas que sugeriam a incompatibilidade dos dois modelos.
Tecnologia e metodologia não devem ter torcida, não devem inspirar rivalidade, mas sim serem usadas como ferramentas que nos ajudem a alcançar objetivos nobres. Paixão indiscutível não é compatível com métodos e ferramentas. Isso se ajusta mais com política, futebol e religião. Quando expressa nos domínios da engenharia de software, a paixão denota muito mais imaturidade do que habilidade e mais estilo ginasiano do que conduta profissional. A MPB nos dá exemplo de junções de coisas aparentemente inconciliáveis. Os irreverentes do J.Quest e Skank criam colorações ágeis e modernas com as velhas e belas baladas rítmicas de Roberto e Erasmo Carlos.
Algumas percepções desenvolvidas pelos agilistas a respeito dos modelos CMMI /MPS.BR acabaram definindo uma meia verdade sobre a impropriedade da proposta para o desenvolvimento de sistemas nos dias de hoje. Embora ainda retenham uma parte desse teor mais tradicional, cada versão lançada tem procurado evoluções a fim de oferecer novos arcos de opções. Processos iterativos têm sido aplicados no MPS.BR em muitas das mais de 200 empresas certificadas. Assim, embora a genética inicial fosse para sistemas com estilo cascata, não há rigorosamente nada hoje que impeça, via modelo, a aplicação de ciclos de vida mais iterativos na construção de produtos incrementais a bordo do MPS ou CMMI. Se fizermos uma tomografia da "anti-empatia" mútua entre agilistas e estruturados, perceberemos que a falta de informação tem sido um dos grandes fatores de ruído nessa arena. Os exageros acontecem de ambos os lados: a percepção errada dos estruturados de que os métodos ágeis não são controlados é uma delas. Embora seja uma abordagem mais libertária, o Scrum não prescinde da disciplina. A idéia de que o "daily scrum" perde em efetividade é abobrinha pura. Tenho 40 anos de estrada em TI e isso, rigorosamente, não me faz melhor do que os que estão por aí. Sou só uma testemunha mais atenta de decisões simplistas sobre o melhor das tecnologias e metodologias. Pura perda de oxigênio. Esses exageros de agilistas e estruturados, gerados por distorções, ruídos e paixões em nada contribuem para uma visão possível de perfeita e pacífica coexistência entre as propostas. Colocações pejorativas encontradas em listas de discussões, empobrecem a discussão das idéias: os “cascateiros” (para aqueles que usam o modelo cascata, com uma mensagem subliminar de enganadores), ou "prestidigitadores" (para aqueles que usam a "agilidade" de camelô para criar ilusões rápidas e passageiras) são de uma imaturidade infanto-juvenil que inibe uma convivência possível, que existe e não é de hoje. Desde 2005, existem relatos de iniciativas de aproximação. A experiência da Powerlogic, empresa referência em modelos ágeis, na implementação do nível C (CMMI-N3) é eloquente. O MPS.BR, planeja para 2010 o Guia MPS voltado para modelos ágeis.
A questão é de se buscar um ponto de equilíbrio existente entre as propostas, de forma a preservar seus atributos seminais e desenvolver soluções que permitam uma empresa buscar um modelo de maturidade sem abandonar por completo, preceitos culturais estabelecidos. E isso é plenamente possível na aproximação MPS.BR + Métodos Ágeis. Sem cascateiros e prestidigitadores!

Visão Ágil e Visão estruturada-Parte 6-Desafios

Desafios

Os projetos e as empresa que aderiram ao uso de ambos os paradigmas, percebem que existem valores reais nos dois lados.No nível de projetos, os modelos estruturados focam mais no "o quê" fazer enquanto os métodos ágeis focam no "como" os projetos desenvolvem seus produtos. Isso define que ambos tem uma boa faixa de convivência. Hoje muitas organizações certificadas em CMMI/MPS.BR usam equipes "ágeis" de desenvolvimento. Da mesma forma, uma empresa ágil, pode usar MPS.BR/CMMI para projetos iterativos, time-boxed, o que é perfeitamente compatível com os seus preceitos de hoje. Os métodos ágeis podem prover o "como" em projetos CMMI, especialmente em projetos de menor porte com equipe co-alocada. As abordagens CMMMI/MPS.BR, por seu lado oferecem as práticas de engenharia de software para projetos de maior porte.
O grande desafio dos modelos ágeis está na aplicação de grandes projetos, onde diversas e pequenas equipes devem ser mantidas alinhadas e coordenadas durante a sua execução, mantendo as premissas ágeis aplicáveis. A manutenção do alinhamento em projetos distribuídos requer um papel ou mecanismo para a preservação da coerência, lógica e unicidade de:
a)Arquitetura do sistema;
b)Escopo,qualidade, cronograma, custo e risco;
c)Funcionalidades gerais do sistema a serem desenvolvidas, incluindo requisitos não técnicos.
Algumas técnicas que evoluem bem em ambientes ágeis controlados, como a refatoração, não escalam bem quando se tem múltiplas equipes cooperando no mesmo produto.
O modelo ágil pode escalar bem para grandes projetos desde que adote os conceitos regulares de Release Planning,Sprint Planning,Test Planning, Integração contínua e defina equipes para desenvolvimento no estilo FDD(orientado a features) ao invés do desenvolvimento orientado a componentes.
Do ponto de vista de engenharia de software, as atividades abaixo são desafiadoras para projetos grandes,complexos,distribuídos e em várias equipes e se potencializam quando em modelos ágeis:
a)Estabelecer os objetivos gerais do produto e ter uma visão do projeto;
b)Gerenciar a alocação de requisitos para as equipes;
c)Definir e manter as interfaces e restrições entre equipes, tanto para o produto quanto para o processo;
d)Manter integração efetiva dos produtos, com verificação e validação;
e)Coordenar a gerência de riscos por todo o projeto.
Esses processos necessários para a condução de grandes projetos estão presentes nos níveis D e C do MPS.BR(N3 do CMMI).
Algumas abordagens Scrum estão evoluindo de forma a permitir a efetiva gerência de grandes projetos. O "Scrum of Scrum" é uma delas, que seria uma espécie de gerente sênior alinhavando vários projetos. O MPS.BR possui processos e resultados que orientam na gerência integrada(GPR-II e GPP-Portfólio) e o CMMI tem um processo(IPM) voltado para isso.
Os métodos ágeis também deverão buscar melhorias dentro do escopo organizacional que suportem definição de processo, medições,treinamento, reutilização, etc, e formem um arco gerencial mais amplo do que os limites do "scrum team", principalmente para projetos com tais características. Nas empresas de MG, que estão envolvidas com MPS.BR e Scrum, percebe-se alguns sintomas semelhantes. A Powerlogic, que fará sua apresentação, uma empresa, cuja UO(Unidade organizacional) avaliada é focada em produtos, tem nível C(CMMI-N3), e adota Scrum com extrema capacidade, sendo inclusive referência no Brasil.Uma empresa pequena, focada em projetos, localizada no interior, prestes a tirar nível G, em junho/julho adota Scrum/Ágil com bastante eficiência e muito provavelmente logrará êxito na sua avaliação. Uma empresa maior, também com ênfase em projetos, localizada em BH, nível F e indo para C, divide o seu universo de projetos, deixando aqueles que demandam maiores controles para o método mais estruturado, no qual se certificaram F(2 do CMMI) e para os projetos menores, incentiva a aplicação do Scrum. Mas é importante observar que isso tudo pode ser relativo: depende da empresa, do seu amadurecimento em métodos ágeis, do seu tipo de contrato com clientes, etc. Ou seja, cada empresa pode ter a sua verdade momentânea.

Visão Ágil e Visão estruturada-Parte 5-Analisando o Manifesto Ágil

A interpretação do Manifesto Ágil, por vezes pode trazer impropriedades à sua aplicação e os erros de sua interpretação podem ser danosos até para os agilistas.
O Manifesto diz algo assim:
---------
1)Estamos apresentando melhores formas de desenvolvimento de software, fazendo e ajudando os outros a fazerem. Através desse trabalho, estamos valorizando(come to value) :
1)Indivíduos e interações com relação(over) a processos e ferramentas;
2)Software funcionando com relação(over) a documentação abrangente(aqui um erro de interpretação de inglês que alguns cometem, quando traduzem a palavra -comprehensive- como compreensiva);
3)Colaborações com o cliente com relação a negociações contratuais;
4)Resposta a mudanças com relação a acompanhamento(following) de um plano.
---------

Os pontos fundamentais na análise do manifesto são dois:
a)Entendimento do verbo valorizar(to value) e
b)Os conceitos colocados à direita das premissas do manifesto, após a palavra com relação ou (sobre)(over).
Justamente esses dois pontos tem contribuído para a adoção equivocada de alguns preceitos dentro dos métodos ágeis. O conceito de "to value"(valorizar) está dizendo que o Manifesto dará maior valor, considerará mais os itens à esquerda da frase do que os à direita. Isso, entretanto não significa que os da direita devem ser banidos definitivamente, o que foi assumido por interpretações equivocadas de que os modelos ágeis não devem ter processos, ferramentas, documentação,negociação contratual e planos. O que o Manifesto explicita é que os itens à esquerda devem ser mais valorizados. De novo, as fragilidades na interpretação levam as duas bandas(agilistas e estruturados) a terem posicionamentos incorretos sobre o significado real do manifesto.Tanto para o lado dos agilistas, que justificam a ausência desses artefatos como uma imposição pétrea do manifesto, como pelo lado dos estruturados que criticam um ambiente caracterizado como indisciplinado e anárquico.A interpretação equilibrada do Manifesto ajuda tanto na adoção exata e ajustada do modelo, quanto na diminuição de críticas originadas pelos erros de sua interpretação.

Visão Ágil e Visão estruturada-Parte 4-Entendendo o conceito de modelo

Entendendo o conceito de modelo:
Uma dos pontos mais importantes para se diminuir as lacunas conceituais entre os dois modelos é perceber que o CMMI e o MPS.BR são " modelos" e não "padrões". A distinção, vai muito além da semântica e nos remete a observação de algo simples como o capim. Um "modelo" define o "quê" e não o "como". Isso faz muita diferença quando pensamos em implementar um modelo e analisarmos os riscos da sua interpretação, inclusive para a preparação da avaliação. Quando você trabalha com o balizamento pelo "o quê" a implementação torna-se mais liberta de procedimentos, templates rigorosos e de processos pré-cozidos. Até porque a empresa, dentro da sua visão, cultura e estilo é que irá definir certamente isso. O modelo será o guia, a orientação e o apontamento de caminhos. O cuidado que se deve ter sempre é garantir que aquilo que você definiu produza os resultados esperados que o modelo exige. Já o "padrão" é muito mais rigoroso e impõe formas específicas de se fazer algo. No modelo ágil, por exemplo, se a empresa apresenta o Release Plan, identifica o P.O(Product Owner), que representa os fornecedores de requisitos da área do Produto e na reunião de Sprint Planning 1 seleciona os itens do Product Backlog, estaria caracterizando o resultado GRE1-Os requisitos são entendidos, avaliados e aceitos, junto aos fornecedores de requisitos,utilizando critérios objetivos  e o SP1.1-Obtain an understanding of requirements, do processo RM(requirements management) do CMMI. Isso, por si só, mostra que modelos como MPS.BR e CMMI incentivam as empresas a buscar alternativas de solução, através de práticas, frameworks, e de outros conceitos correlatos, sem estabelecer amarras rígidas a pontos pré-definidos. É claro, entretanto, que algumas evidências são necessárias em uma avaliação, para que se possa perceber o alcance da implementação. O exemplo, que sempre cito, a respeito de um agilista entusiasmado que conheci e que dizia ser ele(em carne e osso) a própria documentação do Plano de Projeto, implicará reprovação naquele resultado específico. É importante entender que MPS.BR e CMMI são coleções de idéias e de boas práticas registradas ao longo de décadas e que devem ser usadas como guias para implementação na empresa, sempre de acordo com a cultura dela. Aqui cabe a diferenciação entre "aplicar" e "implementar". "Aplicar" MPS.BR ou CMMI, sugere muito mais um decalque justaposto sobre os processos existentes da empresa a fim de produzir os produtos que o modelo espera. "Implementar" MPS.BR /CMMI, por sua vez, sugere você usar o modelo como uma ferramenta de aprendizado, de comunicação e de organização de idéias, claro, dentro de um universo delimitado. Também significa parar para analisar o que se faz, da forma com que a empresa e sua cultura adotam a prática, e "ajustar" de maneira a melhorar, se e onde cabível. Onde não for pertinente, deveremos olhar para verificar se o que é feito e como está feito atende às exigências do modelo, podendo até permanecer como tal. Essa caracterização do MPS.BR/CMMI, como um "modelo" guia de melhorias de processo, por vezes não é observada nem pelos seus implementadores e as vezes não entendida nem por seus avaliadores, ajudando a criar, dessa forma, mitos de dificuldade, que na realidade não deveriam existir, caso os conceitos de "modelo" e de "implementação" fossem plenamente entendidos.

Visão Ágil e Visão estruturada-Parte 3-Métodos Ágeis

Métodos Ágeis:

O surgimento dos métodos ágeis se deu, para surpresa de muitos, bem antes da Internet e dos processos colaborativos. A pedra fundamental dos métodos ágeis foi o desenvolvimento de projeto com estilo iterativo e incremental, aplicado à engenharia desde a metade dos anos 30. IIDD, como era chamado "Interative and Incremental Design and Development", já era muito usada em projetos de engenharia de hardware(não software). O grande precursosr dos métodos iterativos e incrementais foi Dr Edward Deming, um estatístico, professor que promoveu o conceito de PDCA(originalmente PDSA), com o -S- de Study ao invés de -C- de Check. A Nasa,a Força Aérea Americana e a indústria japonesa usaram intensivamente o método de Deming em projetos "time box", iterativos e com ciclo de desenvolvimento incremental de produtos. Na metade dos anos 50, diversos projetos de software usaram o método de IIDD, empregando muitos dos conceitos hoje aplicados nas metodologias ágeis. Entretanto num mundo dominado pelo Cobol, com demandas por projetos complexos, grandes arquivos, abordagem top-down estruturada, isso acabou não sendo percebido como um possível padrão emergente. Em 1976, Tom Guilby apontou no seu livro "Software Metrics", que um método superior para desenvolvimento de software existia e lançou a idéia de algo mais leve, mais ágil, mais adaptativo, com ciclos e iterações que mostravam mais rapidamente os produtos ao cliente. Essas idéias foram gradativamente amadurecidas e em 1985, Barry Boehm lançou o seu método Espiral, no seu "The Spiral Model of Software Deevelopment and Enhancement". Durante os anos 90, aumentou a aceitação dessa nova abordagem e o IIDD ganhou variantes como RAD(Rapid Application Development) e RUP(Rational Unified Process). Embora soando estranho, algumas técnicas inovadoras de métodos ágeis surgiram em grandes empresas: XP(eXtreme Programming) surgiu na Chrysler Corp em 1996, num projeto pilotado pelos ainda não gurus Ron Jeffries e Kent Beck. Já no final da década, ficou claro que um método que privilegiava a forte interação entre equipes, usava a comunicação "tête-à-tête",aplicava uma rigorosa interação com o cliente, empregando times pequenos e rápidos,e com as entregas frequentes de software, se tornaria uma forte abordagem para se fazer software de forma superior àquela vigente. Vários métodos foram derivados dessas idéia originais como Scrum, Crystal, FDD, etc. Com a proliferação de métodos se deu um fenômeno parecido com o que aconteceu quando do surgimento da UML. Havia a necessidade de se definir algo em comum e os grandes gurus de cada linha se uniram para escrever o famoso "Manifesto Ágil", nascido nas montanhas geladas do estado de Utah. Os líderes foram: Kent Beck,Ron Jeffries,Alistair Cockburn, Jim Highsmith,Bob Martin,Mike Beedle,Ken Schwaber e Jeff Sutherland. Um subconjunto desses autores se juntou à Mary Poppendick para formar a Agile Alliance, organização não lucrativa voltada para encorajar o uso de métodos ágeis. Enquanto o primeiro manifesto foi focado para programação, 2 gurus originais(Cockburn e Highsmith) se juntaram com outros luminares como David Anderson, Mike Cohn, Todd Little, etc para definir os seis princípios de gerenciamento, conhecido pelo estranho nome de "Project Management Declaration of Interdependence(DoI)". Os 15 autores do DoI formaram o Agile Project Leadership Network(APLN), de novo, um organismo sem fins lucrativos que encorajava a prática de métodos ágeis, agora em domínios de liderança e gerenciamento. Esses manifestos, somados ao crescimento de desenvolvimento de software para a internet alavancou o método, sendo que o mais conhecido (Scrum) continua a crescer além do software, alcançando domínios que objetivam os mesmos ganhos definidos por Deming e equipe, com o seu IIDD. Assim surgiu um método caracterizado por premissas frontalmente opostas àquelas existentes :
1)Equipe pequena,coesa e trabalhando com forte interação;
2)Forte participação do cliente;
3)Entregas pequenas e em maior frequência;
4)Comunicação "tête-à-tête", com experiência fortemente focada em projetos menores, sem os rigores do custo fixo, com aceitação de riscos, que segundo o método, serão mitigados pelas suas próprias características de fluidez,rapidez e de entregas menores.
Da mesma maneira, o modelo ágil proposto deverá ser observado, segundo seus valores e princípios de uma forma aberta, atentando para o fato de que o Manifesto ágil define preferências e não alternativas excludentes e encoraja o foco sobre certas áreas mas não elimina outras.

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.

Visão Ágil e Visão estruturada-Parte-1-Introdução

Quando um dinossauro como eu, cheio de movimentos letárgicos e pré-reumáticos, é convidado a falar sobre MPS.BR num evento chamado -Maré de Agilidade- , há que se preparar. Como sou um "sem-prancha", e da praia só gosto da paisagem, detesto a areia e me incomodo com o sol, senti a necessidade de buscar um pouco da história para preencher o vazio que tal combinação insólita proporcionaria(um dinossauro sem prancha, numa praia cheia de jovens surfistas, brilhantes e ágeis). Fui estudar um pouco acerca dos dois pólos aparentemente antagônicos e distantes dentro do campo da Engenharia de Software: O métodos ágeis e os métodos , que chamei de estruturados, envolvendo CMMI e MPS.BR. Esse artigo, claro, não objetiva nem evangelizar os seus pouquíssimos leitores de forma a cooptá-los a uma genuflexão definitiva diante do altar de uma das alternativas, nem acender uma tocha provocativa, buscando detonar uma linha e colorir de méritos a remanescente. Muito pelo contrário, a missão é de paz.
Se pudesse definir um objetivo sintético para essas reflexões, diria que, como já falei por cerca de 4 horas e pouco no podcast do Vinicius Manhães Teles, estamos falando de métodos convergentes e não de extremos que nunca se tocarão.
Esse trabalho foi centrado no melhor "paper" que detalhou os dois métodos. Publicado pelo SEI, em Novembro de 2008, sob o título de CMMI or Agile: Why not embrace both, esse artigo, escrito por pessoas ligadas profundamente à engenharia de software, mostra com equilíbrio e vislumbre as trilhas de convergências entre as duas propostas. Dentre seus autores (Hillel Glazer, da Entinex,Inc; Jeff Dalton, da Broadsword Solutions Corp;Mike Konrad do SEI; e Sandy Shrum do SEI), também se encontra David Anderson, da David Anderson Associates, um dos signatários do Manifesto Ágil, em uma das suas vertentes. Ele foi escrito em várias partes, para que um leitor incauto possa desistir dele, sem grandes perdas de oxigênio e comprometimentos de suas sinapses. A estrutura, segue uma estrutura próxima do artigo original:
1)Essa introdução
2)Visão do CMMI e métodos estruturados(MPS.BR)
3)Visão dos métodos ágeis
4)Entendendo o conceito de modelo
5)Analisando o Manifesto Ágil
6)Desafios
7)Conclusão
8)Adendos-extensões sobre o assunto

Sucesso ou fracasso do CMM/CMMI/MPS.BR

O Sucesso ou fracasso do CMM
Carlos Barbieri


Publicado no CW em 2004, como referência somente ao CMM. Hoje os conceitos valem para CMMI e MPS.BR

O sucesso da implantação de processos de melhorias de software, via CMM ou através de qualquer outro caminho depende de muitos fatores , que variam do técnico ao cultural. As empresas que já alcançaram algum nível de maturidade (vinte e poucas no Brasil em nível 2 e menos de 4 em nível 3, até final de 2003) provavelmente têm receitas diferentes nos seus mecanismos próprios de implantação. O primeiro fator a se considerar é que um processo dessa natureza não é suave, o seu caminho é difícil e o seu retorno, nem sempre certo. Sem um esforço perfeitamente orquestrado entre equipes e dirigentes as chances de sucesso diminuem. A presença marcante de uma gerência envolvida com os ônus do processo é um dos fatores determinantes e que caracterizam as bem sucedidas em CMM.Caberá a eles, gerentes de níveis variados, o delicado senso de flexibilizar no momento certo e intransigir no tempo oportuno, buscando o equilíbrio capaz de fazer com que o processo siga adiante sem rupturas. Outro fator passa pelos aspectos culturais da equipe. Lembre-se que o processo de CMM não diz como fazer, e muito certamente as empresas envolvidas num processo como esse terão que rever as suas práticas de forma profunda. O “peopleware”, representado pelo conjunto de pessoas (gerentes, analistas, programadores, etc) com o perfil de trabalho modificado pelas novas práticas, responderá de maneira diferente. Variará de manifestações de euforia pela modernização de processos e de ferramentas, até o ceticismo explícito ou camuflado daqueles que já fazem bem sob as condições presentes, sem admitir concessões às mudanças. A escolha cuidadosa de pessoas com maior possibilidade de comprometimento com o processo, para ocupar pontos chaves(equipe SEPG, que coordena os trabalhos internamente, por exemplo) é ponto fundamental. Não é a toa que a primeira empresa a alcançar o nível 5 de CMM foi a Motorola, da Índia. A Índia é hoje reconhecidamente o pais onde melhor se aplica os conceitos CMM fora dos EUA. Na década de 70, por quatro anos, tive oportunidade de trabalhar com indianos, durante meu tempo de pós-graduação e mestrado no INPE em São José dos Campos. Desenvolvi diversos trabalhos, projetos e treinamento em conjunto com muitos deles. É um povo diferenciado. Além de uma consistente formação analítica, dedicação e concentração, são de uma retidão profissional e ética acima da média. Não é a toa que dominam o mercado off-shore de desenvolvimento de sistemas. Nós brasileiros temos a nosso favor a capacidade de improvisação, o tino correto para as decisões difíceis e o “timig” mais preciso, sobre o “quando” das coisas. Somos muito intuitivos, mas não gostamos de muita disciplina, de cronogramas, modelos, templates, etc. É um desafio especial ajustar o nosso perfil aos preceitos do CMM. Daí a necessidade de se equilibrar bem o rigor dos métodos com a nossa capacidade de realizar coisas, com o nosso famoso “brasilian little style”.Aos implementadores (consultores externos e equipe da empresa responsável pelo projeto CMM ) caberá a busca do ponto de equilíbrio entre a aplicação do academicismo solicitado e a permissão da informalidade não desagregadora. A simples aplicação de receitas pré-cozidas experimentadas em outras empresas não garante sucesso algum. Deverão receber o tempero de cada empresa. Há que se considerar os seus objetivos(selo CMM, melhoria de processos ou ambos), o entendimento dos seus aspectos culturais e a sua história de fracassos e sucessos recentes. Ciclos de treinamento e palestras de conscientização sobre as melhorias que se busca deverão ser planejados e aplicados com freqüência e intensidade. Em algum ponto desses diversos caminhos, cada empresa encontrará a sua receita de sucesso ou de fracasso do CMM.

MG e a vocação pela qualidade de software

As montanhas de Minas são emblemáticas no seu silêncio e na forma contemplativa com que nos observam a todos. Esse Estado das alterosas, circundado por elas, aprendeu com as forças das montanhas, que obstáculos são elementos que vivemos para ultrapassar. Isso sempre nos fez bem. Aprendemos também, por influência delas, que devemos nos comportar praticando o seu silêncio. Isso nem sempre nos fez bem. É nessa combinação de força e silêncio que, por certo tempo, a nossa informática se colocou numa discreta posição de sétimo ou oitavo lugar, enquanto o nosso PIB se posicionava em segundo ou terceiro. Simples: temos uma competência em Informática espessa, porém difusa e silenciosa. Ha vinte e poucos anos, a Índia, resolveu incluir na sua história, algo mais do que os palácios suntuosos e a sua miséria obscena. Resolveu que seria uma das melhores alternativas, se não a melhor opção de engenharia de sistemas do planeta. Está a caminho, quase chegando lá. Pelos quatro cantos do planeta já se ouve a sua voz e já se fala da sua competência. Antes da novela das oito, a Índia já era conhecida pela sua força na construção de software. Em Minas, estamos iniciando um movimento bem mais modesto, mas à altura das nossas montanhas. Com as suas forças, mas sem a sua mudez. Estamos nos preparando para fazer desse estado um participante ativo e notado no campo da informática, principalmente na esfera da qualidade de software. Em 2005, os números estimados de certificações CMM e CMMI, apontavam que SP tinha aproximadamente entre 22 a 24 certificações. O RJ possuia em torno de 4 a 6 , o RS possuia entre 4 a 6 , o DF possuia em torno de 2 ou 3 , PE possuia 3 e a Bahia 1 , ES 1, CE 1 e Minas Gerais possuía uma única certificação. A certificação solitária de Minas Gerais, pertencia a um conceituado Instituto de ensino, pesquisa e desenvolvimento em Telecomunicações, localizado em Santa Rita do Sapucaí (INATEL). A partir daquele instante , uma engenharia de software mais aplicada, começou a mudar os números por aqui nas Alterosas. As empresas começaram a buscar melhor qualidade nos seus processos e a investir em métodos formais de qualificação. Começamos com a Spress Informática(N2), depois veio a MSA-Infor, hoje Spread(N2), depois a Unisys-BH(N5) e depois novamente a Spress(N3), a MSA-Infor(N3), e a Squadra(N2) . Naquele mesmo momento, começava a nascer o MPS.BR, o modelo brasileiro equivalente ao CMMI, desenvolvido e apoiado pela Softex-Associação para Promoção da Excelência do Software Brasileiro, que oferece programas de apoio ás empresas interessadas em melhoria de processos. Por iniciativa da SECTES e FAPEMIG, a Fumsoft criou o CCOMP.MG, célula dedicada ao desenvolvimento de conhecimentos na área de Engenharia de Software, com foco em MPS.BR e CMMI. Hoje, temos em MG, em números de setembro de 2009, 29 certificações, num total de 150 no Brasil. O estado de MG ocupa a segunda posição, logo atrás de SP, que tem 35 certificações. A primeira empresa com certificação dupla CMMI e MPS.BR, a Synos Technologies é também de Minas Gerais. A primeira empresa que mescla MPS.BR com metodologias ágeis, em níveis mais elevados de maturidade, deverá ser daqui também(Powerlogic). E outras tantas, cujos nomes não caberiam nestas linhas. Esse alcance vai muito além de um trabalho competente das empresas , de suas diretorias e de seus empregados. Ela mostra que MG está se preparando para mudanças definitivas. A Fumsoft-Sociedade Mineira de Software, através do CCOMP.MG tem desenvolvido , com apoio da Governo do Estado e Softex , um trabalho que se materializa nesses números. No próximo dia 8/10, no Inovatec, lançaremos o G7(sétimo grupo de empresas, em busca de patamares de excelência em software). Já realizamos a implementação em 3 grupos já terminados(apoiados diretamente pela Sociedade Softex), e mais 2 estão em fase final de avaliação. O G6, iniciado em Maio de 2006, e o G7, a ser lançado em outubro, terão o apoio direto do Governo de Minas Gerais, via o APL de Software. O Governo de Minas Gerais trouxe, para dentro de seu projeto estruturador, o conceito de qualidade de software. Temos agora em BH, quem possa nos dizer de viva voz, como se chega ao nível 3(CMMI) ou C(MPS.BR) de um processo que visa a troca do artesanato de software pela engenharia de sistemas. Temos, cada vez mais, exemplos locais a serem dados nas salas de aula , sem termos que importá-los, do exterior ou do interior. Os nossos alunos de graduação e de pós poderão, a partir de agora, citam as as empresas que começaram a construir uma história de sucesso, apostando na qualidade como elemento diferencial. Esperamos que até o fim deste ano mais 2 ou 3 empresas subam de patamar e coloque Minas Gerais com 31 ou 32 certificadas em MPS.BR, nos posicionando,cada vez mais, próximos da locomotiva paulista. E dessa forma , o nosso Estado estará iniciando um novo rumo, as empresas mineiras mudandoos seus caminhos e Minas não mais trabalhará em silêncio.