O modelo CMM de qualidade de software, apresentado na edição de Março da DevMag, tem um pai. Líder da equipe que criou e divulgou o modelo, Watts Humphrey é hoje um dos mais respeitados pregadores da qualidade de software. Sua enorme experiência no gerenciamento de projetos de Engenharia de Hardware e Software, especialmente na IBM, deu consistência e foco prático ao modelo. Hoje estudando a aplicação dos conceitos do CMM ao desenvolvedor individual e às pequenas equipes de desenvolvimento, Humphrey mostra seu espírito de pesquisador e inovador. Presente ao Software Engineering Process Group Conference ´97, um evento de qualidade do processo de software organizado pelo SEI, nosso colaborador Átila Belloquim teve a oportunidade de entrevistar com exclusividade Watts Humphrey, trazendo ao desenvolvedor brasileiro suas idéias mais recentes.

Como lhe ocorreu, pessoalmente e como grupo no SEI, a necessidade de um modelo estruturado (o CMM) para a melhoria do processo de software?

Veio de minha própria experiência. Trabalhei na IBM por muitos anos e, num determinado momento, fiquei responsável por todo o software da IBM. Eu tinha 4000 engenheiros desenvolvendo os grandes sistemas operacionais /360. Era óbvio na ocasião que havia sérios problemas gerenciais. Eu já tinha trabalhado por muitos anos como engenheiro construindo hardware, e minha experiência era que era necessário ter cronogramas, ter um bom sistema gerencial para conduzir projetos, ou você nunca entregaria as coisas em tempo. Assim, quando assumi a área de software da IBM, tratei de por em prática estes mesmos princípios. Eu descobri que nenhum dos 15 laboratórios sob minha responsabilidade fazia cronogramas. Eles simplesmente tentavam produzir código o mais rápido possível. Era muito improdutivo. É como tentar produzir algum produto sem nenhuma estrutura de planejamento, sem ninguém para adquirir matéria-prima etc. Um caos total. Os engenheiros concordavam que eles deveriam ter cronogramas e planos, mas eles diziam que não o faziam porque não tinham tempo. Eu concluí que era um problema que não era culpa deles, mas minha e de meu predecessor. Nós permitíamos que eles prosseguissem desenvolvendo programas sem nenhuma estrutura de planejamento. Então eu decidi -depois de obter a concordância do topo da Companhia- parar todo trabalho que não tivesse planos. Nós não anunciaríamos produtos, não entregaríamos produtos, não entraríamos em projetos a menos que tivessem planos. E ponto final. Assim, eu fiz disto algo essencial: não havia modo de alguém produzir código se não tivesse um plano! Isto limpou a situação em poucos meses. Foi impressionante! Paramos tudo e fizemos os engenheiros-chefes sentarem-se e fazerem planos. Os planos foram feitos e cumpridos por alguns meses. A partir daí, anunciamos os prazos de entrega e não estouramos nenhum prazo por dois anos e meio. Nem um!

Ficou claro para mim que o requisito básico do gerenciamento sólido são bons planos. Também ficou claro que nada mais poderia ser feito pelo processo de software antes que isto estivesse feito. A partir daí, continuamos aprendendo sobre os outros problemas e modos de resolvê-los. E acabou ficando claro para mim, depois de muito trabalho duro, que precisa haver um critério básico sobre o que constitui um trabalho de qualidade.

Quando me aposentei na IBM, eu tinha que decidir o que eu faria pelo resto da minha vida. Eu não queria simplesmente sentar na praia. Então eu decidi que eu iria me comprometer a tentar mudar o modo como se faz software. Por isso, fui trabalhar no SEI, e é o que eu faço até hoje.

Uma das primeiras coisas que a Força Aérea nos perguntava no SEI era: como decidir se um fornecedor de software é melhor do que o outro, em uma concorrência? Fui colocado em uma equipe que tinha por objetivo avaliar não os produtos, mas o processo. As avaliações antes eram feitas analisando-se as propostas. Eu disse então: Não! queremos olhar o processo. Se você quer comprar chips, você não olha os chips, olha a fábrica. Tínhamos que fazer o mesmo com software. Mas olhar o quê? Não foi surpresa descobrir que a primeira coisa a olhar era a existência de um sistema básico de planejamento. Assim, fomos considerando o que deveria ser olhado em seguida, e assim por diante. Foi assim que acabamos por estruturar isto tudo em níveis, pois percebemos que as organizações não podem melhorar tudo ao mesmo tempo. Este é um dos problemas de muitos dos programas de qualidade: eles são “planos”, você tem que fazer tudo ao mesmo tempo. Mas as empresas não funcionam assim. Uma empresa tem um problema que, se não for resolvido, não há como ir para a frente. São como barreiras em uma estrada. Se você está parado em uma barreira, você não se preocupa com o que há mais para a frente. Você tem que superar esta barreira primeiro, para depois se preocupar com a próxima. Portanto, a questão era: em que ordem as barreiras aparecem, qual é a ordem certa para a remoção de barreiras? Quais os problemas que você enfrentará que lhe causarão mais dor de cabeça no início? É basicamente o planejamento, o comprometimento, este tipo de coisa fundamental. Se isto não estiver resolvido, todas as outras coisas não farão a menor diferença. Você pode tentar usar ferramentas avançadas, inspeções etc., mas se o sistema básico de planejamento não estiver lá, nada mais vai funcionar direito.

É uma espécie de Caminho Crítico…

Exato. São passos seqüenciais. É como aprender Matemática. Se você não aprender Aritmética, não adianta brigar com a Álgebra. Até que você domine a Álgebra, não perca seu tempo com Cálculo. Se você não pode lidar com o Cálculo, esqueça a Mecânica Quântica. Assim fomos organizando os níveis. O mais radical foi definir os níveis 4 e 5, pois não tínhamos visto estes níveis! Mas nosso julgamento parece ter sido confirmado pelas empresas que chegaram a estes níveis. Havia uma lógica por trás disto.

O CMM está se tornando um modelo bastante popular para a melhoria do processo de software e está chegando agora à sua segunda versão. O Sr. acredita que esta estrutura continuará sendo a mesma ao longo do tempo, ou existe a possibilidade de grandes mudanças?

É difícil dizer. No momento, não vejo nada que possa precisar de grandes mudanças, mas a tecnologia pode surpreender. Quando todo mundo estiver nos níveis 3, 4 ou 5, podemos descobrir que existem outras estruturas para pensar. Eu não ficaria surpreso. Mas ao menos por enquanto a estrutura parece ser sólida e funcionar muito bem. Mas é importante mantermo-nos flexíveis. Em 10, 15 ou 20 anos podemos descobrir necessidades completamente diferentes. É difícil prever, mas ao menos para o futuro visível não vejo nenhuma mudança fundamental.

O Sr. não acha que o CMM é muito pesado para aplicações cada vez mais construídas a partir de componentes em vez de a partir do nada?

Não. Acredito que o CMM é baseado numa estrutura gerencial, praticamente independente da tecnologia. A necessidade de controle, de planejamento, de qualidade, de gerenciamento de contratos são as peças do CMM. Você pode juntar partes e ter um problema de qualidade, mesmo que as partes em si sejam de alta qualidade. A estrutura gerencial faz sentido mesmo se você não escrever nenhum código. Na verdade, as pessoas têm percebido que simplesmente trocando a palavra “software” por outra, elas podem usar a estrutura do CMM para hardware ou qualquer outra coisa. Os princípios são amplamente aplicáveis, quase não importa do se trata.

Existem vários novos modelos alternativos ao CMM para avaliar a maturidade do processo de software de uma organização, como o SPICE. O que o Sr. acredita que acontecerá: estes modelos irão competir, ser integrados, ou o quê?

Bem, eu acredito que existam algumas diferenças fundamentais entre o CMM e o Spice e estes outros métodos. Sempre fiquei frustrado pela quantidade destes outros métodos, porque me parecem um reflexo deste tipo de “doença” dos programadores. Quando a comunidade de software é confrontada com um problema, ela corre e inventa algo novo. É por isso que temos literalmente milhares de linguagens de programação. Todo mundo tem que ter a sua própria nova linguagem! A idéia de construir sobre o trabalho de outras pessoas e avançar a partir daí, parece que as pessoas simplesmente não querem fazê-lo  quando estão na comunidade de software, por alguma razão. Eles querem construir coisas novas, começar tudo de novo e fazer do modo deles. E isto infelizmente é uma grande dose de esforço desperdiçado, reproduzindo tudo o que já foi feito anteriormente. Levamos anos para chegar onde estamos, e parece que as pessoas não querem aproveitar isso. Criam cada vez novos métodos que têm como principal conseqüência confundir as pessoas, que acabam perdendo de vista o fato de que o propósito desta coisa toda não é ter um modo cada vez mais belo de descrever software. O propósito disto tudo é focar em como melhorar o modo como o software é desenvolvido. E uma parte muito substancial disto é justamente encontrar um modo melhor de realizar a comunicação entre gerentes e engenheiros de software, isto é, como os gerentes podem entender o que os engenheiros estão fazendo, como os engenheiros podem entender melhor o que o gerente quer, como pôr juntas todas estas coisas e fazê-las funcionar. Quando eu vejo descrições de 30 páginas sobre por que isso é assim, quais são as distinções entre isso e aquilo, etc, fico frustrado. O público destes métodos, os gerentes e engenheiros não entendem as diferenças, não vêem porquê  se discute a respeito disto, e eu também não! É uma perda de tempo. As pessoas não aprenderam com o que fizemos. Pegam parte do nosso material e mudam, querem obter descrições muito mais precisas do processo e vêm perdendo anos tentando reproduzir aquilo que nós já fizemos! Começamos a trabalhar no modelo de maturidade há 15 anos, fizemos a primeira avaliação na IBM em 1983. São anos e anos de experiência e as pessoas querem vir com suas próprias novidades sem ao menos sentar e conversar conosco! Vão inventando suas coisas com base em algo que leram e acabam fazendo a coisa errada. Sei que se pode imaginar coisas inteligentes, e que há pessoas brilhantes e que às vezes aparecem coisas boas. Mas fundamentalmente é uma perda de tempo, um desperdício de esforços. A multiplicidade de métodos confunde as pessoas, que não sabem se devem usa o CMM ou o Spice ou isto ou aquilo. Infelizmente, é o que estão fazendo, mas não vou combatê-los.

O problema é que a maioria destes métodos é baseado em medições, procuram obter uma medida precisa, o que a empresa é exatamente. Acontece que, na verdade, isto não importa! O CMM não é baseado em medição, é baseado em mudança, em como você consegue fazer a organização realmente mudar! O foco de nosso esforço não está em obter uma medida precisa da organização. É claro que ajuda ter uma medida aproximada, mas a questão é que você está procurando fazer com que a empresa entenda o que acontece. O CMM é uma ferramenta para ajudar a entender as organizações e motivá-las a melhorar. Não é uma medida precisa, não tem toda esta objetividade. O problema com o Spice e outros grupos é que estão focados em como obter melhores medidas.

E não mostram os caminhos para mudar e melhorar…

Bem, eles dão. Você pode usá-los, e eles ajudam. Não estou dizendo que eles sejam ruins, de modo algum! Eles têm algumas coisas boas e podem ajudar, mas o que eles tentam fazer é obter um modo muito mais preciso de descrever as organizações, o que você acaba descobrindo que, na verdade, não importa! Está-se indo às organizações para medi-las com precisão, quando o problema é motivar as pessoas a melhorar. Se você esperar três semanas, sua organização estará diferente do que você mediu. Organizações são muito dinâmicas. Não adianta tomas medidas até à terceira casa decimal. Se você for por um caminho um pouco diferente, se você fala com as pessoas num dia diferente da semana ou se você entrevista algumas pessoas diferentes, você obtém uma medida totalmente diferente. Organizações são muito complicadas. Todas estas medidas são aproximações muito cruas do que realmente está acontecendo. Nós descobrimos que em cada avaliação nós não estamos atrás de números e medidas. Nós as obtemos porque as pessoas gostariam de ter uma idéia, mas o que estamos realmente atrás é de compreender a ética, a cultura, o que motiva as pessoas, como elas se comunicam, qual é a sua linguagem, este tipo de coisa. O CMM o ajuda a entender isto. Mas se você não conseguir compreender estas coisas, as medidas que colher não servirão para nada. Assim é. Outras pessoas continuarão criando seus próprios métodos. Ter 3 ou 4 métodos competindo é como ter 3 ou 4 linguagens diferentes ao mesmo tempo. Você terá que ter ferramentas suportando cada uma, diferentes pessoas para dar suporte a cada uma etc. O problema real que nós temos não é como obter uma medida mais precisa, mas como chamar a atenção da gerência para mudar, para melhorar. Cada vez que surge um novo método, fica mais difícil chamar a atenção da gerência, pois ela fica confusa. Isto apenas dá desculpas para que as pessoas não faças o que precisa ser feito. É triste.

O Sr. desviou sua atenção do CMM para o PSP (Personal Software Process) nos últimos anos. Por quê o Sr. decidiu seguir este novo caminho?

O CMM estava em seu caminho, estava indo bem. Na verdade, era importante que eu saísse do caminho. Um dos problemas que havia no trabalho do CMM era que, se eu estivesse em uma reunião e estivesse havendo alguma discussão, no momento em que eu falasse algo a discussão acabava. “Está gravado em pedra, o Grande Homem falou…”, você sabe (risos). Portanto, eu estava barrando o progresso. Eu precisava sair do caminho para que as pessoas pudessem pensar, mover-se, fazer progresso por conta própria, e eles o fizeram muito bem. Uma segunda razão, muito importante, era que muitas organizações pequenas não viam como o CMM pudesse aplicar-se a elas. Como o CMM se aplica a empresas de 18 pessoas, ou a times de 4 pessoas etc. Um grande número de pequenas organizações produzem muito software. Nós tentamos convencê-los de que o CMM se aplicava a eles, mas não conseguimos. Durante anos eu me interessei pela idéia de aplicar processos ao trabalho pessoal. Assim, quando sai do projeto do CMM pude mudar-me para Florida e começar a pesquisar sobre o Processo Pessoal, usando-o eu mesmo. Escrevi um monte de programas, umas 25.000 linhas de código em C++. Assim, eu não estava abandonando o CMM, mas eu tinha que sair do caminho.

Em que o Sr. está trabalhando no momento?

Estou trabalhando no que chamo de TSP – Team Software Process. Como você pega engenheiros que foram treinados no PSP e faz com que trabalhem juntos para produzir projetos. O que geralmente acontece hoje em dia é que você pega um grupo de engenheiros e lhes diz: “o.k., quero que vocês construam esta coisa”. O problema é que os engenheiros não entendem realmente o que a gerência quer, não entendem a estrutura de pensamento da gerência. Não entendem os objetivos do negócio e como isto está relacionado com eles. Não sabem que processos usar, não sabem que vai fazer o quê, não têm planos. Mas nós esperamos que eles vão e façam o que pedimos. Não é surpresa que eles tenham problemas, briguem e percam um monte de tempo. O TSP parte do princípio que os engenheiros foram treinados no PSP. Pegamos aqueles conhecimentos e então o TSP mostra a eles como usá-los para tocar um projeto em conjunto. O CMM visa construir capacitação organizacional. O PSP está focado em construir a capacitação e as habilidades dos engenheiros. E o TSP está focado em usar isto para construir produtos. Existe 16 grupos usando o TSP no momento, estamos numa fase experimental.

O CMM, o PSP e outros modelos do SEI estão muito relacionados a questões culturais dentro da organização. Com base em sua experiência internacional, o Sr. acredita que este modelo podem ser usados como são em países com culturas diferentes da Norte Americana, ou deveriam eles ser alterados para a cultura específica de cada país?

É claro que existem diferenças culturais. Mas o que me surpreendeu é que eu pude observar culturas tão diversas quanto a Japonesa, Indiana, Européia e Sul-Americana, incluindo variações dentro do mesmo país, e não encontrei diferenças fundamentais. As pessoas no Japão ou na Índia entendem o que eu digo imediatamente. Os desenvolvedores de software encontram problemas quase idênticos em todas as partes do mundo. Existem, é claro, diferenças na estrutura gerencial, na formalidade, etc. Mas os princípios do CMM parecem aplicar-se de forma bastante geral. Afinal, eles são bem básicos. Demming e Juran já tinha demonstrado que os princípio de qualidade funcionavam bastante bem em todas as partes do mundo, e no nosso caso parece que o mesmo se aplica. Ainda é muito cedo para se ter certeza, mas parece que funciona.

 

Artigo publicado na revista Developers’ Magazine em 1997.