com Flávio Marini, Gustavo Luís Falcade e Lucas Mazzer *
————–

Neste artigo pretendemos apresentar dois modelos de desenvolvimento de software amplamente divulgados na Engenharia de Software nos últimos anos.

De um lado, a metodologia XP (Extreme Programming), um dos métodos ágeis de desenvolvimento mais conhecidos no mercado. Do outro, o modelo de maturidade de processos CMMI (Capability Maturity Model Integrated) focado na melhoria dos processos de desenvolvimento de software como um todo.

Recentemente, algumas pesquisas têm sido desenvolvidas com o objetivo de adequar processos formais de desenvolvimento de software às técnicas de processos ágeis. Portanto, apresentamos um comparativo entre o Extreme Programming (XP) e o modelo CMMI, bem como uma análise da aplicação das práticas do XP associadas ao modelo de maturidade CMMI.

A motivação para esse artigo é tornar conhecidos as práticas da metodologia XP e detalhes do modelo de processos CMMI de forma objetiva e clara, observando as possibilidades de interação entre esses modelos de desenvolvimento de software.

Método XP

Surgiu a partir das idéias de Kent Beck, Ron Jeffries e Ward Cunningham. O primeiro projeto usando as práticas XP foi realizado em 1996, onde Kent Beck fazia parte. Em 2000, Beck lança o primeiro livro sobre XP, o “Extreme Programming Explained: Embrace Change”.

O XP aplica práticas de desenvolvimento de software conhecidas como Processos Ágeis de Desenvolvimento. Através de um constante feedback do sistema desenvolvido, o cliente direciona o desenvolvimento de modo eu seja produzido de acordo com suas prioridades de negócios.

São várias as práticas do método XP

Cliente presente: é essencial a presença ativa do cliente no processo de desenvolvimento para que o feedback à equipe aconteça. Trata-se também de um importante ponto para a comunicação.

Jogo do planejamento: prática que determina o próximo release, prioridades de desenvolvimento tanto técnicos como de negócios. Aqui o cliente decide o que será desenvolvido de acordo com suas prioridades e datas.

Stand up meeting (Reunião em pé): uma simples reunião realizada pela manhã que permitirá a revisão do que foi feito no dia anterior e o que será desenvolvido durante o dia.

Programação em par: toda a produção do código é escrita por dois programadores diante do mesmo computador. A programação em par visa uma revisão constante e a implementação das funcionalidades de forma simples e eficaz.

Desenvolvimento guiado pelos testes: os desenvolvedores escrevem testes durante o desenvolvimento, estes são os testes unitários. O cliente por sua vez especifica os testes de aceitação para que as funcionalidades desenvolvidas sejam aceitas e finalizadas.

Refactoring: reestruturação do código sem afetar as funcionalidades que ele implementa. O objetivo é simplificá-lo, removendo duplicações e torná-lo mais fácil de manipular e entender.

Código coletivo: todos os desenvolvedores têm acesso ao código produzido. De forma que todos podem alterar aquilo que julgarem importante em qualquer momento sem a necessidade de pedir autorização pra isso.

Código padronizado: a equipe estabelece um padrão de codificação. Essa prática visa a facilidade de comunicação entre os membros da equipe, tornar o sistema mais homogêneo possível e permitir que qualquer manutenção futura seja feita mais rapidamente.

Design simples: oferecer ao cliente um design simples da funcionalidade implementada, sem se preocupar com generalizações do código e necessidades futuras.

Metáfora: guia todo o desenvolvimento através de uma simples estória que mostra o funcionamento do sistema como um todo. Segundo Jeffries metáfora é “uma integridade conceitual baseada em uma simples metáfora que todos entendam, que explique a essência de como o programa funciona”.

Ritmo sustentável: os membros da equipe não devem trabalhar mais do que oito horas diárias, evitem sempre que possível fazer horas-extras. Isso tem por objetivo manter a equipe sempre descansada, atenta e criativa.

Integração contínua: integra diversas vezes no dia as funcionalidades desenvolvidas pelos pares com o restante do sistema. O build do software é gerado e os testes devem ser executados para assegurar que a integração ocorra com sucesso.

Releases curtos: a equipe implementa um conjunto de funcionalidades rapidamente e disponibiliza para o cliente fazer uso deles. No andamento do projeto vai-se incorporando novas funcionalidades que agregam mais valor ao produto e ao cliente.

Por dentro do CMMI

O Capabiblity Maturity Model Integration é um modelo de referência que contém práticas para melhoria dos processos de desenvolvimento de software das organizações.

Desenvolvido pelo SEI (Software Engineering Institute) da Universidade de Carnegie Mellon, o CMMI é uma evolução do CMM e ajuda a integrar funções organizacionais tradicionalmente separadas, estabelecer um processo de melhoria nos objetivos e prioridades, fornecer um guia para processos de qualidade e fornecer um ponto de referência para instruir processos atuais.

O modelo possui duas representações: contínua e por estágios. A representação por estágios usa níveis de maturidade, enquanto que a representação contínua usa níveis de capacidade.

Os níveis de capacidade, que pertencem a representação contínua, se aplicam a obtenção da melhoria dos processos de uma organização em áreas de processo individuais.

Os níveis de maturidade, que pertencem a representação por estágios, se aplicam a obtenção da melhoria dos processos de uma organização através de múltiplas áreas de processo.

A seguir descrevemos resumidamente a definição de cada um dos níveis de capacidade.

Nível 0 – Incompleto: um processo incompleto é aquele que ainda não é realizado ou parcialmente realizado.

Nível 1 – Realizado: um processo realizado é aquele que satisfaz os objetivos específicos de uma área de processo.

Nível 2 – Gerenciado: um processo gerenciado é um processo realizado (nível 1) que tem a infra-estrutura básica para sustentar o processo.

Nível 3 – Definido: um processo definido é um processo gerenciado (nível 2) que é adaptação do conjunto de processos padrões da organização. No nível 3, os padrões, descrições do processo e procedimentos de um projeto são adaptados do conjunto padrão para se adequar a um projeto particular ou unidade organizacional, se tornando mais consistentes.

Nível 4 – Quantitativamente Gerenciado: um processo quantitativamente gerenciado é um processo definido (nível 3) que é controlado usando técnicas estatísticas. A aplicação de tais técnicas é usada como critério de gerenciamento do processo em busca de qualidade e desempenho.

Nível 5 – Otimizando: um processo dado como otimizando é aquele quantitativamente gerenciado (nível 4) e que está continuamente aperfeiçoando o desempenho do processo através de melhorias gradativas e inovadoras.

Em um mundo globalizado, onde a informação percorre de forma tão veloz e exigida na sua forma mais íntegra e confiável, os projetos de software tendem a ser cada vez mais obrigados a dar conta do recado.

Projetos de software não são apenas aplicações de métodos tecnológicos, porém antes de tudo nasce a partir de idéias e só se desenvolve saudavelmente através de aplicações essenciais de gerenciamento de projetos.

Daniel D. Galorath [2] descreve as sete características de um projeto de software disfuncional e seus valores estatísticos:

• Falha ao aplicar Práticas Essenciais ao Gerenciamento do Projeto – 57%.
• Otimismo não justificado e expectativas de gerenciamento irrealistas – 41%.
• Falha ao implementar efetivos processos de software – 30%.
• Declarações prematuras de sucesso – 20%.
• Falta de um programa de gestão de liderança – 13%.
• Tomadas de decisões prematuras – 8%.
• Falta de uma gestão de risco pró ativa – 3%.

Assim sendo, se faz necessário estimar e planejar. Estes conceitos são uma das chaves para o sucesso do projeto de software, segundo Galorath.

XP vs CMMI

Como visto, o CMMI tem seu foco nas questões pertinentes ao gerenciamento eficiente das diversas áreas de processo e na melhoria contínua dos processos sistemáticos de uma organização.

Portanto, o modelo descreve o que é esperado para que a organização defina como melhor desenvolver, por isso diferentes soluções podem ser adotadas para atender o modelo.

Por outro lado, o XP é um conjunto específico de práticas eficientes na aplicação em pequenas equipes que necessitam suprir as mudanças rapidamente. Porém, juntos os dois métodos podem gerar boas aplicações de engenharia e gerenciamento de processos de forma ágil e eficiente.

Diversos estudos têm tentado mapear as práticas do XP aos processos CMMI nível 2 por se tratarem de processos de gerenciamento e planejamento de software e, de alguma forma propor a aplicação desse novo modelo de mapeamento.

Em [1] foi elaborado um guia prático de aplicação do XP em CMMI nível 2 e foi discutido também diversos pontos problemáticos em questões de compatibilidade entre os modelos. Porém, concluímos que grande parte dos processos envolvidos no CMMI nível 2 podem ser atendidos sem uma rigorosa leitura e aplicação dos mesmos.

Gerenciando os requisitos –

CMMI – Busca através desta área de processo estabelecer um entendimento comum entre cliente e a equipe responsável pelo projeto de software no tocante às necessidades do cliente.

XP – Através do uso de estórias, o XP mantém junto ao cliente uma contínua integração. O feedback do cliente com seus requisitos e suas expectativas permitem o desenvolvimento de pequenos releases e quais estórias deverão ser implementadas em seguida.

Planejando projetos de software –

CMMI – Estabelece planos para engenharia de software, sobretudo gerenciamento do projeto.

XP – Faz uso da prática do Jogo do Planejamento e o desenvolvimento de pequenos releases. XP integra toda a equipe num compromisso de alcançar a todo esforço a implementação de uma estória do cliente em releases de até duas semanas para sua conclusão.

O cliente também mantém o controle do desenvolvimento de acordo com as suas prioridades de negócios e define quais estórias serão implementadas para o próximo release. O plano de projeto torna-se então incremental e evolutivo, de forma que desenvolvedores podem identificar e gerenciar riscos eficientemente.

Monitorando e supervisionando o software –

CMMI – Segundo Mark Paulk: “Monitoramento e Supervisão do Projeto de Software provê visibilidade adequada no progresso real de forma que o gerenciamento possa tomar ações efetivas quando a performance do projeto de software desvia significativamente dos planos de software” [5]. A base de acompanhamento do projeto é o Plano do Projeto.

XP – A criação de releases a cada nova estória implementada dá velocidade ao projeto. Isso fornece a todos os envolvidos, desde o técnico até o estratégico a real situação do projeto, bem como prioridades e novas estórias a serem desenvolvidas.

Garantindo a qualidade de software –

CMMI – Fornece o gerenciamento com a visibilidade necessária na qualidade do produto e no processo de software.

XP – A programação em par é a principal prática em busca da qualidade do software. Nessa prática se busca constante melhoria do código inserido através da refatoração sempre que necessário. Porém para o nível de gerência esta prática não oferece grande visibilidade e pode não ser eficaz em grandes projetos.

Gerenciando a configuração do software –

CMMI – Estabelece e mantém a integridade dos produtos de software do projeto.

XP – Propriedade coletiva do código, pequenos releases e integração contínua implicam em um gerenciamento, embora não completo, da configuração do software. Segundo Paulk, propriedade coletiva pode ser problemática para grandes projetos, pois necessita de canais mais formais de comunicação para prevenirem falhas no gerenciamento da configuração.

Cenários de Aplicação

O modelo CMMI vem para preencher a lacuna existente da necessidade de conhecermos quais as melhores práticas que devem ser adotados em níveis crescentes de maturidade.

Embora o cenário pareça ser único e promissor, Fred Brooks já nos alertava que não haveria uma única solução “bala de prata” (silver bullet) para as dificuldades essenciais no desenvolvimento de software.

Ainda segundo Alfonso Fugetta, “nós temos de prestar atenção na complexa interpelação de numerosos fatores organizacionais, culturais, tecnológicos e econômicos do desenvolvimento de software” [6].

Apesar de XP oferecer toda uma estrutura para o desenvolvimento de software de forma ágil, nem todos os projetos são tidos como aplicáveis a essa metodologia.

Alguns defendem o uso do XP em pequenos projetos de no máximo dez pessoas, porém segundo Beck e Fowler, XP pode ser aplicado em grandes projetos desde que eles sejam divididos em subprojetos que tenham duração de uma a três semanas [4]. Há algumas outras restrições quanto ao uso da metodologia [3]:

• Problemas de obtenção de feedback – se o ambiente demora a oferecer o feedback para a equipe, a integração de software e a realização de testes, por exemplo, serão comprometidos.
• Falta de testes automáticos – sem a execução de testes várias vezes ao dia dificulta a produção de código confiável e consequentemente a evolução do projeto de software.
• Dificuldade de comunicação entre a equipe – sem uma comunicação facilitada entre a equipe, certas práticas da metodologia ficam prejudicadas, por exemplo, a programação em pares de programadores.
• Horas de trabalho – para o XP horas de trabalho além do planejado não significa comprometimento, mas é um sinal de problemas no projeto.
• Documentação – ambientes em que a exigência de especificações detalhadas e documentadas antes mesmo do início do desenvolvimento.

Portanto, diante do cenário descrito, XP tem sua aplicação focada na frequente iteração do projeto, simplicidade na solução dos problemas, contínuo e rápido feedback, trabalho de qualidade como agente motivador e comunicação o tempo todo.

A adoção do XP pelas empresas passa inevitavelmente pela coragem de mudança de suas atitudes e costumes organizacionais e uma nova postura de visão e interação com seus clientes.

É fato que o mercado de desenvolvimento de software passa por grandes transformações e mais do que nunca se faz necessário que empresas que fazem parte deste mercado estejam preparadas em dois pontos fundamentais na construção de software: a qualidade e a produtividade.

Observamos também que metodologias e programas de melhoria de processos são grandes meios elaborados para tornar nossa indústria de software competitiva, mas não o suficiente se os mecanismos de gerenciamento e estratégias das organizações não se atentarem para o fato de que planejamento, estimativas, controles de risco e gerenciamento da qualidade e produtividade não caminharem juntos em busca do mesmo objetivo.

Temos, portanto, não só barreiras metodológicas e técnicas a serem transpostas, mas também organizacionais.

Esperamos finalmente, através de observações de diversos pontos entre as metodologias estudadas, poder estabelecer referências de aplicação entre CMMI e XP sob o ponto de vista organizacional e gerencial da produção qualificada de software.  [Webinsider]

Referências –

[1] Campelo, Renata E. C., “XP-CMM2: Um guia para Utilização de Extreme Programming em um Ambiente Nível 2 do CMM”, Dissertação de Mestrado – Universidade Federal de Pernambuco, Novembro 2003.

[2] Daniel D. Galorath – Galorath Incorporated 2006.

[3] K. Beck, Extreme Programming Explained: Embrace Change, Addison – Wesley, 1999.

[4] K. Beck et al., Planning Extreme Programming, Addison Wesley, 2000.

[5] M.C. Paulk et al., The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, 1995.

[6] Revista InfoBrasil – edição de Junho/Agosto 2009. Qualidade para Desenvolvedores e Prestadores de Serviço no Software Público Brasileiro (p. 24,25).

…………………
* Flávio Marini, Gustavo Luís Falcade e Lucas Mazzer, graduados em Ciência da Computação pela Universidade Paulista (UNIP) de Campinas-SP, também são autores da pesquisa original e deste artigo. Atuam profissionalmente em diversas áreas da computação.
…………………
Conheça os serviços de conteúdo da Rock Content..