Extreme Programming e Qualidade de Software

Transcrição

1 Extreme Programming e Qualidade de Software Antonio Sergio Ferreira Bonato Departamento de Sistemas Digitais Escola Politécnica Universidade de São Paulo asbonato@ieee.org Resumo Nos últimos anos tem surgido uma nova gama de metodologias de desenvolvimento de software conhecidas como metodologias ágeis. Consideradas por alguns como um antídoto ao excesso de burocracia e uma solução para os problemas das pequenas equipes e por outros como coisa de hackers, estas metodologias vem se firmando e atraindo cada vez mais atenção sobre si. Dentre estas metodologias, a que mais tem se destacado é a Extreme Programming, gerando um grande número de publicações, congressos e aficionados. E um bom número de detratores também. Entretanto, estas metodologias são capazes de produzir software confiável e de qualidade? O intuito deste trabalho é fazer um pequeno estudo neste sentido, analisando a Extreme Programming sob a ótica de uma interpretação não rigorosa do SW-CMM, o Capability Maturity Model para Software, verificando em que pontos ela é aderente ao modelo e em quais pontos ela é não conforme. Por que o SW-CMM? Bem, o modelo SW-CMM é amplamente aceito pela comunidade mundial de Engenharia de Software como um padrão a ser seguido para se produzir software confiável e de qualidade. O trabalho está estruturado de modo a, no início, falar sobre aspectos gerais que caracterizam as metodologias ágeis. Depois, fala sobre os conceitos da Extreme Programming. No final é feita uma breve explicação do SW-CMM e é descrito como cada uma das áreas de processo é ou não atendida pela Extreme Programming. Keywords: Processo, metodologias, desenvolvimento de software, metodologias ágeis, Extreme Programming, qualidade de software, CMM. Introdução O desenvolvimento de software tem se mostrado como uma das atividades mais desafiadoras da humanidade. Apesar de estar envolvida nesta empreitada a quase 50 anos, ainda parece praticamente impossível concluir um projeto de desenvolvimento de software dentro do prazo, do orçamento, com todas os requisitos satisfeitos e alta qualidade. A atividade de desenvolvimento de software é caótica, normalmente caracterizada pela expressão "code & fix", i.e., codifica e conserta. Isto geralmente funciona bem em projetos muito pequenos, mas à medida que as coisas crescem, os problemas começam a aparecer. Como é caracterizada por longas fases de debugging (remoção de erros) após a implementação de cada funcionalidade, difíceis de determinar o quanto duram, via de regra o cronograma não é cumprido. Nos primórdios do software as coisas funcionavam deste jeito (e ainda funcionam assim em muitos lugares quando se trata de pequenas equipes). Com o passar do tempo, entretanto, foram surgindo metodologias com o intuito de tornar o desenvolvimento de software uma atividade mais disciplinada, eficiente e previsível. Só que muitas vezes estas metodologias são acusadas de burocráticas, pois exigem uma grande quantidade de Extreme Programming Brasil - São Paulo - dezembro de

2 Extreme Programming, Qualidade e Confiabilidade de Software documentos. Além disso, é constante a reclamação de que o uso da metodologia por si só atrasa o projeto, tamanho o número de tarefas "improdutivas" realizado. Por tudo isso, estas metodologias são chamadas de pesadas (heavyweight methodologies). As metodologias pesadas se mostraram adequadas aos grandes projetos tocados por grandes equipes, onde há farta disponibilidade de recursos materiais e humanos que torna possível tanto a existência do sem número de papéis exigidos por estes processos bem como a produção da elevada quantidade de documentação demandada. Entretanto, o tamanho destes projetos os torna naturalmente complexos, principalmente nas tarefas de coordenação dos mais variados grupos, justificando o uso destas metodologias. Já os pequenos projetos, tocados por pequenas organizações, não precisam de todo este rigor e formalismo, podendo ser encarados de maneira muito mais simples. Para estes projetos, as metodologias pesadas não são adequadas, pois não há como encolhê-las para se ajustarem ao tamanho do projeto e da organização, que na maioria das vezes não tem como arcar com os recursos necessários para suportar o emprego destas metodologias. É justamente nestes casos que o uso de uma metodologia é pior do que o uso de nenhuma. Como reação à tudo isso apareceram, nos últimos anos, algumas metodologias denominadas metodologias ágeis. Tais metodologias se colocam como um meiotermo entre a ausência de processo e o processo exagerado. Exigindo pouca documentação, às vezes até colocando o código fonte como documentação, elas diferem das metodologias pesadas em dois aspectos básicos: são adaptativas ao invés de preditivas; são orientadas às pessoas, e não orientadas aos processos. Existem várias metodologias que podem ser carimbadas com o estereótipo de ágeis. Todas elas tem em comum o fato de acomodarem bem as mudanças de requisitos e de serem processos fáceis de serem aceitos pelo pessoal de desenvolvimento. Apesar destas semelhanças, todas elas tem diferenças na maneira como conduzem o ciclo de vida de desenvolvimento. Dentre as metodologias ágeis, a que mais tem se destacado é a Extreme Programming, talvez por sua fundamentação teórica e sua estruturação como disciplina, talvez pelo grande senso de marketing de seu principal criador, Kent Beck [1]. Entretanto, mesmo sendo as metodologias ágeis mais adequadas para os pequenos projetos, ainda resta às pequenas organizações o desafio da qualidade. Como usar um modelo de qualidade de processo como o SW- CMM sem perder agilidade. Isso é possível desde que se faça uma interpretação do modelo com bom senso [6]. Desta forma, o uso das metodologias ágeis propicia às pequenas organizações um modo de desenvolver software com agilidade e qualidade. Pequenas Empresas e Pequenos Projetos As pequenas empresas são parte importante da economia do país. A grande maioria das organizações que desenvolvem software no Brasil, segundo levantamento realizado pelo núcleo SOFTEX, que se destina a promover a excelência do software brasileiro, é composta por pequenas organizações [7]. De um universo de 699 empresas pesquisadas, 36% tem o porte de micro organizações, com um número de funcionários variando entre 1 e % das organizações estão na categoria de pequenas, com 10 a 49 funcionários. Portanto, de acordo com o critério força de trabalho, 78% das empresas podem ser consideradas como pequenas organizações. Ainda relatando a mesma pesquisa, 88,8% das 699 empresas são desenvolvedoras de software e a maioria software orientado a negócios, sendo relatados aplicativos como administração de serviços (31,3%), automação comercial (30,0%), página web (29,4%), e- business (26,5%), contabilidade (18,0%), dentre outros. Estas informações corroboram o fato de que no Brasil a maior parte do software desenvolvido é orientado a negócios. Geralmente, as pequenas organizações desenvolvem pequenos projetos. Estes, com relação ao seu tamanho, podem ser classificados como [6]: pequenos, quando envolvem de 3 a 5 pessoas e tem duração de até 6 meses; muito pequenos, quando envolvem de 2 a 3 pessoas e tem duração de até 4 meses; minúsculos, quando envolvem de 1 a 2 pessoas e tem duração de até 2 meses; individual, quanto apenas uma pessoa trabalha no projeto por uma semana. Ainda assim, apesar de pequenos, estes projetos falham. Pode-se citar o CHAOS Report do ano 2000, que relata que neste ano apenas 28% dos projetos de dsenvolvimento de software nos Estados Unidos obtiveram sucesso, 23% falharam totalmente e os 49% restantes terminaram fora do prazo, do orçamento e com menos funcionalidades do que o requisitado no início do projeto [8]. Nota-se aqui que a falta de maturidade e 2

3 capacidade no desenvolvimento de software ainda é grande nos Estados Unidos. Infelizmente não existem informações deste tipo relacionadas à organizações brasileiras, mas pode-se inferir que o resultado seria o mesmo ou até pior. O que é Extreme Programming? Extreme Programming, ou XP, é uma metodologia leve para equipes de tamanho pequeno e médio desenvolverem software face a requisitos vagos ou que mudem muito rapidamente. Criada em 1996 por Kent Beck, Ron Jeffries e Ward Cuningham a partir de um projeto piloto realizado na Daymler-Crysler, a XP vem ganhando cada vez mais espaço no mercado. Porque extreme? Porque a XP pega um conjunto de práticas de desenvolvimento que estão por aí já faz um longo tempo, conhecidas como best practices, e as leva ao extremo [2]. Por exemplo, se revisão por pares é bom, então vamos fazê-la o tempo todo, implantando a programação aos pares; se projeto é bom, vamos fazer dele nosso dia a dia, com a remodelagem de código; se testar é bom, vamos fazê-lo o tempo todo, e assim por diante. XP é uma maneira ágil, eficiente, de baixo risco, flexível, previsível, científica e até divertida de desenvolver software. Ela se distingue das outras metodologias por seu precoce, concreto e contínuo feedback fornecido pelos ciclos curtos; sua abordagem de planejamento incremental, que rapidamente cria um plano que evolue durante o ciclo de vida do projeto; sua habilidade em tornar flexível a implementação de funcionalidades, respondendo às necessidades de mudança dos negócios; sua dependência dos testes automatizados escritos pelos programadores e clientes para monitorar o progresso do desenvolvimento e encontrar defeitos precocemente; sua dependência da comunicação oral, nos testes e no código fonte para comunicar o intento e a estrutura do sistema; sua dependência do processo de projeto evolutivo que dura enquanto o projeto dura; sua dependência na colaboração estreita entre programadores com habilidades comuns; sua dependência em práticas que funcionam tanto com os instintos de curto prazo dos programadores como com os interesses de longo prazo do projeto. XP é também uma maneira disciplinada de desenvolvimento de software. É disciplinada porque existem determinadas práticas que devem ser executadas para que se pratique a XP. Estas práticas, ou 12 práticas, estão fundamentadas em uma história, quatro valores, alguns princípios e em quatro atividades básicas. Vejamos cada um deles. Os quatros valores fundamentais da XP Comunicação: problemas em projetos normalmente são traduzidos por um "alguém que não falou alguma coisa importante para alguém". A XP torna praticamente impossível a falta de comunicação. Simplicidade: sempre faça a coisa mais simples que possa funcionar. XP é uma aposta de que é sempre mais barato fazer algo simples e mudar depois do que tentar prever o futuro fazer algo complicado que ninguém vai acabar usando. Feedback: retorno concreto dos clientes e dos usuários o mais cedo possível mantém o projeto nos trilhos. Coragem: é preciso coragem para manter os três primeiros valores sempre. Princípios Básicos Os princípios fundamentais são: Feedback rápido: quanto mais demorado o feedback menor o aprendizado produzido por ele. Simplicidade assumida: tratar cada problema como se pudesse ser resolvido de maneira simples; não tentar prever o futuro, resolvendo hoje os problemas de hoje, e deixando para amanhã os de amanhã. Mudança incremental: grandes mudanças tendem a não funcionar; os problemas são normalmente resolvidos com uma série de pequenas mudanças naquilo que faz diferença. Aceitar mudanças: a melhor estratégia é aquela que preserva a maioria das opções enquanto verdadeiramente resolve o problema que estiver pressionando mais; Trabalho de qualidade: todos gostam de fazer um trabalho de qualidade; se as pessoas que estão no Extreme Programming Brasil - São Paulo - dezembro de

4 Extreme Programming, Qualidade e Confiabilidade de Software projeto não gostam da qualidade do trabalho que estão fazendo, a tendência do projeto é fracassar. Além destes princípios fundamentais, existem outros que também são importantes: Ensinar a aprender: melhor do que um monte de frases doutrinárias, tais como "Você deve testar como XYZ...", devemos focar em ensinar estratégias de se aprender quanto teste deve ser feito; isto também vale para a remodelagem de código, projeto, planejamento, etc. Pequeno investimento inicial: muito dinheiro logo no início do projeto não faz bem; a melhor abordagem é ter dinheiro o suficiente para começar e ir incrementando o orçamento conforme o retorno do investimento que vai sendo dado para o cliente. Jogar para ganhar: deve-se sempre jogar para ganhar, e não jogar para não perder. Experiências concretas: antes de tomar decisões deve-se experimentar algumas alternativas. Comunicação honesta e aberta: falta de comunicação dentro da equipe prejudica o ambiente de trabalho e o projeto como um todo. Trabalhar de acordo com o instinto das pessoas, e não contra eles. Responsabilidade aceita: responsabilidade não deve ser imposta às pessoas, mas aceita por elas. Adaptação local: os costumes e práticas de desenvolvimento locais devem ser respeitados ao máximo quando da implantação da XP. Viagem leve: não carregue documentação que não seja essencial para o projeto; jogue fora aquilo que não precisa mais; o código fonte é uma das melhores formas de documentação. Medição honesta: medir sempre o desenvolvimento, mas nunca numa maneira que não seja suportada pelos instrumentos disponíveis. Atividades Básicas A XP considera que o desenvolvimento de software está dividido em apenas quatro atividades básicas: Codificação: no final do dia, sempre tem que haver código; quer seja desenhando diagramas que gerem código ou digitando programas, a atividade principal do desenvolvimento é a codificação; o código permite que os testes sejam feitos, dando rapidamente o feedback necessário de que o que está sendo feito está correto e de acordo com os requisitos do cliente. Testes: são a maneira mais rápida e segura de se obter feedback e aumentar a confiança da equipe e do cliente; nenhuma funcionalidade que não possa ser demonstrada por intermédio de testes realmente existe. Audição: os programadores normalmente não sabem nada da área de negócios; o pessoal de negócios dificilmente sabe alguma coisa de desenvolvimento de software; ambas as partes devem ouvir sempre umas as outras para que o projeto sempre ande na direção correta. Projeto: não se pode apenas ouvir, escrever casos de testes e codificar o tempo todo; é necessário antes se projetar o que vai ser feito; o projeto deve sempre ser simples, e deve ser melhorado sempre que possível. As doze práticas da XP As doze práticas da XP que a definem como uma disciplina são fundamentadas nos quatro valores, nos princípios básicos e nas quatro atividades básicas [3]. O Jogo do Planejamento Ninguém sabe tudo logo no começo. Tanto clientes como desenvolvedores aprendem durante o progresso do projeto. A XP reconhece isso e coloca isso em prática através do jogo do planejamento. A principal idéia por trás deste prática é fazer um plano aproximado no princípio e refiná-lo conforme as coisas vão se tornando mais claras. Os artefatos do jogo do planejamento são uma pilha de cartões, contendo histórias do cliente, que irão orientar as iterações do projeto; e um plano aproximado do próximo release. O fator crítico do trabalho de planejamento é deixar os clientes tomarem as decisões de negócios, enquanto o pessoal do desenvolvimento toma as decisões técnicas. Ao pessoal do desenvolvimento cabe: estimar quanto tempo vai demorar para desenvolver uma história; implicações de custo no uso de várias opções tecnológicas; a organização da equipe; o risco de cada história; 4

5 a ordem do desenvolvimento de cada história dentro de cada iteração. Os clientes tomam as decisões de negócio: escopo (as histórias para um release e as histórias de cada iteração); datas dos releases; prioridades (quais as funcionalidades devem ser desenvolvidas antes, baseados em valor para o negócio). O planejamento ocorre com freqüência. Isto fornece uma oportunidade para que clientes e desenvolvedores façam ajustes a medida em que aprendem coisas novas. Programação por pares Em XP, pares de programadores usando apenas um computador escrevem todo o código fonte. Esta abordagem pode soar ineficiente, uma vez que se utiliza dois recursos para produzir a mesma coisa, mas na verdade ela traz uma série de benefícios, econômicos e outros, tais como: todas as decisões de projeto envolvem pelo menos dois cérebros; pelo menos duas pessoas estão familiarizadas com cada parte do sistema; há menos chance de ambas as pessoas negligenciarem tarefas, tais como testes e remodelagem de código; a mudança de pares difunde o conhecimento pela equipe; o código é sempre revisado por pelo menos duas pessoas. Há dois papéis em cada par. Um dos parceiros, o que detém o teclado e o mouse, pensa na melhor maneira de se implementar um determinado método. O outro parceiro deve pensar mais estrategicamente, como por exemplo, se a abordagem como um todo vai funcionar, se existem ainda casos de teste que não foram testados, se há um modo de fazer aquilo de maneira mais simples, etc. Testes Em XP há dois tipos de testes: testes de unidade; testes de aceitação. Os desenvolvedores escrevem os testes de unidade enquanto escrevem o código. O cliente escreve os testes de aceitação após definir as histórias. Os testes de unidade dizem aos desenvolvedores quando o sistema funciona em qualquer ponto do tempo. Os testes de aceitação dizem à equipe quando o sistema faz o que os usuários desejam que ele faça. Os desenvolvedores escrevem testes de unidade para cada método que possa falhar, antes mesmo de escrever o código para tais métodos. Então eles escrevem somente código o suficiente para passar nos testes. Trabalhar desta forma parece estranho, mas esta abordagem proporciona: mais completo conjunto de testes possível; código mais simples que possa funcionar; uma visão clara da intenção do código. Um desenvolvedor não pode integrar o código ao repositório de código fonte enquanto ele não passar em todos os testes de unidade. Os testes de unidade dão aos desenvolvedores confiança de que o código deles funciona. Eles também dão ao desenvolvedor coragem para fazer a remodelagem do código fonte, porque uma falha no teste diz ao desenvolvedor imediatamente se alguma coisa foi danificada. Os testes de unidade devem ser automatizados e dar um resultado claro do tipo passa/não passa. Os clientes são responsáveis por garantir que cada história tenha um teste de aceitação para validá-la. O cliente pode escrever os testes por si só, recrutar algum membro da organização para fazer isso por ele ou combinar as duas abordagens. Os testes dizem aos clientes se o sistema tem todas as funcionalidades que deveriam ter e se elas funcionam corretamente. Idealmente, o cliente deve ter os testes de aceitação de todas as histórias a serem implementadas em uma interação escritos antes da interação estar terminada. Os testes de aceitação devem ser automatizados e devem ser executados freqüentemente para garantir que os desenvolvedores não estejam estragando nenhuma funcionalidade já implementada enquanto eles implementam uma nova. Nem todos os testes de aceitação tem que passar todo o tempo. Eles ajudam o cliente a medir o quanto do projeto já está pronto. Eles também permitem aos clientes tomar decisões informadas sobre o que está ou não pronto em um determinado release. Remodelagem A remodelagem (refactoring) é uma técnica que permite a melhoria do código sem a mudança de funcionalidade. Uma equipe de XP deve fazer a remodelagem sem perdão. Existem duas oportunidades chave para os Extreme Programming Brasil - São Paulo - dezembro de

6 Extreme Programming, Qualidade e Confiabilidade de Software desenvolvedores melhorarem o código: antes e depois de implementar uma funcionalidade. Antes, os desenvolvedores tentam determinar se a mudança no código existente tornaria a implementação da nova funcionalidade mais fácil. Depois, eles olham para o código que acabaram de escrever para ver se há uma maneira de simplificá-lo. por exemplo, se eles vêem uma oportunidade para abstração, eles fazem a remodelagem para remover todo o código duplicado das implementações concretas. A XP diz que se deve escrever o código mais simples que possa funcionar, mas também diz que se aprende coisa pelo caminho. A remodelagem permite que se incorpore o aprendizado ao código sem danificar os testes. Ele mantém o código limpo. Isto significa que o código irá sobreviver por mais tempo, introduzir menos problemas para os futuros desenvolvedores e guiá-los na direção correta. Projeto simples As metodologias pesadas dizem que até o mais simples projeto (design) deve ser feito logo no começo. XP diz que o projeto não deve ser feito todo de uma vez, no início, na ilusão de que nada vai mudar depois. A XP considera o projeto tão importante que ele deve ser uma preocupação constante. Deve-se sempre tentar usar o projeto mais simples que possa funcionar em um determinado ponto, mudando-o quando ele não mais refletir a realidade. E o que é o projeto mais simples que possa funcionar? É aquele que: passa em todos os testes; não contém código em duplicidade; demonstra claramente as intenções do programador; contém o menor número possível de classes e métodos. Um projeto simples não implica em que todos os projetos sejam pequenos ou triviais. Eles apenas devem ser o mais simples possível e ainda assim funcionarem. Nunca inclua funcionalidades extras que não serão utilizadas. Propriededade Coletiva do Código Qualquer pessoa da equipe deve ter a autoridade para mudar o código a fim de melhorá-lo. Todos possuem o código, de modo que todos são responsáveis por ele. Esta técnica permite às pessoas fazerem as mudanças necessárias em uma peça de código sem caírem no gargalo da propriedade individual do código. O fato de todos serem responsáveis pelo código evita o caos da falta de propriedade do código. Dizer que todos possuem o código não é o mesmo que dizer que ninguém possui o código. Quando ninguém possui o código as pessoas podem causar danos onde bem entenderem e alegarem não ter nenhuma responsabilidade. A XP diz, "Você estraga, você conserta". Existem testes de unidade que devem ser executados antes e depois de cada integração. Se você danifica alguma coisa que estava funcionando, é sua responsabilidade consertá-la, não importa em que lugar do código ela esteja. Isto requer extrema disciplina. Integração Contínua A integração freqüente do código ajuda a evitar o pesadelo da integração. As equipes de XP integram seu código várias vezes ao dia, após terem todos os testes de unidade executados sem problemas. Abordagens tradicionais tendem a trabalhar deste modo: codificam um monte, fazem uma grande integração e depois gastam uma grande quantidade de tempo consertando os problemas. Este estilo realmente atrasa o projeto. Grandes integrações criam uma grande carga de problemas todos de uma vez, e estes problemas podem ter centenas de causas possíveis. Quando a integração é freqüente, a causa das falhas de uma integração em particular é mais óbvia: os testes funcionavam antes, então o que se acabou de integrar é o culpado. Deste modo, quando se encontram problemas, há um conjunto limitado de causas. Consertar é mais fácil, leva menos tempo e mantém a equipe trabalhando em velocidade máxima. Cliente no local Para funcionar de maneira ótima, uma equipe de XP precisa ter um cliente disponível no local para clarear algumas histórias e tomar decisões críticas de negócio. Os desenvolvedores não podem fazer isso sozinhos. Ter um cliente disponível elimina gargalos que possam aparecer quando os desenvolvedores tem que esperar por decisões dos clientes. A XP não finge que um cartão de história seja todo o direcionamento que um desenvolvedor necessite para entregar o código necessário. A história é um compromisso para uma posterior conversa entre o cliente e o desenvolvedor para descrever os detalhes. A idéia é que a comunicação face a face minimize a chance de maus entendidos, o que não ocorre quando se escreve todos os requisitos em um documento estático. Apesar de ter o cliente o local o tempo todo ser a melhor situação possível, este não é o único cenário que funciona. O mínimo necessário é que o cliente esteja 6

7 disponível sempre que necessário para responder à questões e para fornecer direcionamento paro o time baseado em valor para o negócio. Se isto puder acontecer sem a necessidade do cliente estar o tempo todo no local, ótimo. A presença física com a equipe torna as coisas mais fáceis, embora seja apenas uma recomendação. Pequenas versões As versões (releases) devem ser tão pequenas quanto possível e mesmo assim ter valor o suficiente para o negócio de modo que valham à pena. Libere o sistema tão logo ele tenha algum sentido. Isto fornece valor para o cliente tão cedo quanto possível. Pequenas versões também fornecem um feedback concreto para os desenvolvedores sobre quais as expectativas dos clientes foram atendidas e quais não foram. A equipe então pode incluir estas lições no planejamento do próxima versão. Semana de 40 horas Os desenvolvedores devem estar renovados e ansiosos a cada manhã, cansados e satisfeitos toda noite. As 40 horas por semana levam a isso. O número exato de horas não é importante - o princípio sim. Queimar óleo por longos períodos mata a performance. Desenvolvedores cansados cometem mais erros, o que diminui a velocidade do projeto no longo prazo mais do que um horário de trabalho normal o faria. Mesmo que os desenvolvedores possam funcionar bem por longos períodos não significa que devam. Eventualmente eles ficam cansados e deixam seus empregos, ou começam a ter problemas pessoais que acabam tendo impacto negativo em sua performance. Horas extras não são resposta a um problema no projeto. De fato, são um sintoma de um problema maior. Padrões de codificação Ter padrões de codificação faz duas coisas: evita que a equipe se distraia com discussões estúpidas sobre coisas que não importam tanto quanto trabalhar em velocidade máxima; suporta as outras práticas. Sem padrões de codificação é mais difícil melhorar o código, mais difícil trocar os pares de programadores e mais difícil ir rápido. O objetivo é que ninguém na equipe possa reconhecer quem escreveu determinada parte do código. Cria-se um padrão que todos concordem, e então se adota o padrão. Este não deve conter uma lista extensa de regras, mas apenas linha gerais que garantam que o código se comunique claramente. O padrão de codificação deve começar simples e evoluir baseado na experiência da equipe. Não se deve gastar muito tempo com isso no princípio. Criase o padrão mais simples que possa funcionar, e então se coloca em prática. Metáfora O que uma arquitetura faz? Ela fornece uma figura dos vários componentes de um sistema e como eles interagem - um tipo de mapa que permite aos desenvolvedores ver onde novas peças irão se encaixar. A metáfora do sistema em XP é análoga ao que a maioria das metodologias chama de arquitetura. A metáfora dá à equipe uma foto consistente que ela possa usar para descrever o modo como o sistema existente trabalha, onde as novas partes irão se encaixar e qual forma elas devem ter. É importante lembrar que todos entenderem como o sistema funciona como um todo é crítico e fundamental para o sucesso do projeto. Como as práticas funcionam juntas O todo é maior do que a soma das partes. Pode-se implementar práticas simples, ou um pequeno conjunto delas, e ainda assim obter grandes benefícios. Mas só se consegue o máximo de benefícios quando se implementa todas as práticas, pois o poder delas vem da sua interação. Deve-se aplicar a XP ao integralmente no começo. Uma vez que se entende como as práticas interagem, tem-se o conhecimento necessário para adaptar a XP a um contexto em particular. É importante lembrar que a XP não é um objetivo, e sim um meio. O objetivo, sim, é desenvolver software de qualidade rapidamente. Ciclo de Vida de um Projeto de XP O ciclo de vida de um projeto de XP consiste em por as práticas e estratégias da XP em funcionamento de maneira ordenada. Ele consiste de um pequena fase inicial de desenvolvimento seguida por um longo período de refinamento e suporte à produção. O ciclo de vida pode ser divido nas seguintes fases: Exploração: preparar ambiente de produção, praticar a escrita de histórias de usuário, estimar e testar tecnologias e tarefas de programação; desta fase sai a metáfora. Planejamento: por em prática o Jogo do Planejamento; obter o menor número de histórias a ser implementado no versão curta. Extreme Programming Brasil - São Paulo - dezembro de

8 Extreme Programming, Qualidade e Confiabilidade de Software Iterações: planejar cada iteração, fazer o desenho mais simples, criar os casos de teste de unidade, programar aos pares, testar continuamente, integrar diariamente, remodelar sem perdão, fazer os testes de aceitação, implementar as histórias da versão. Produção: em iterações de uma semana, colocar o sistema em produção; implementar novos testes e ajustar a performance do sistema. Manutenção: simultaneamente produzir novas funcionalidades e manter o sistema existente rodando, remodelar se necessário ou migrar para uma nova tecnologia; experimentar novas arquiteturas. Morte: o usuário não consegue pensar em novas histórias; preparar documentação do sistema e encerrar o projeto. O Software CMM O Capability Maturity Model for Software é um modelo organizacional para construção de software que tem sido amplamente adotado na comunidade de software e além dela. O CMM-SW é um modelo em cinco níveis que descreve boas práticas de engenharia e gerenciamento e prescreve prioridades de melhoria para organizações de software [5]. O modelo possui cinco níveis, sumariados a seguir: nível 1 - inicial: nenhum processo; nível 2 - repetível: foco em gerenciamento de projeto; nível 3 - definido: foco em processos de engenharia e no suporte organizacional; nível 4 - gerenciado: foco na qualidade dos processos e do produto; nível 5 - otimizando: foco na melhoria contínua do processo. Cada um dos níveis do CMM (exceto o nível 1) possui um certo número de KPAs, ou áreas chave de processo. Cada KPA permite alcança um certo conjunto de metas ou objetivos. A satisfação a estes objetivos permite dizer se uma organização atingiu um determinado nível de maturidade. As KPAs do nível 2 são: RM - Requirements Management (Gerência de Requisitos), SPP - Software Project Planning (Planejamento de Projeto de Software), SPTO - Software Project Tracking & Oversight (Acompanhamento e Supervisão de Projeto de Software), SSM - Software Subcontract Management (Gerência de Subcontratação de Software, SQA - Software Quality Assurance (Garantia de Qualidade de Software), SCM - Software Configuration Management (Gerência de Configuração de Software). As do nível 3: OPF - Organization Process Focus (Foco no Processo Organizacional), OPD - Organization Process Definition (Definição do Processo Organizacional), TP - Training Program (Programa de Treinamento), ISM - Integrated Software Management (Gerência Integrada de Software), SPE - Software Product Engineering (Engenharia de Produto de Software), IC - Intergroup Coordination (Coordenação entre Grupos), PR - Peer Reviews (Revisões por Pares). As do nível 4: QPM - Quantitative Process Management (Gerência de Processo Quantitativa), SQM - Software Quality Management (Gerência de Qualidade de Software), E, finalmente, as do nível 5: DP - Defect Prevention (Prevenção de Defeitos), TCM - Technology Change Management (Gerência de Mudança Tecnológica), PCM - Process Change Management (Gerência de Mudança de Processo). O CMM é focado nas grandes organizações que desenvolvem software em grandes projetos para o governo. Apesar disso, ele é escrito de uma maneira hierárquica que contém "verdades universais" sobre a engenharia de software e a gerência de projetos. Quando visando apenas a melhoria do processo de desenvolvimento, se interpretado de maneira correta e com bom senso, o CMM pode ser usado por praticamente todas as organizações, independentemente de seu tamanho [6]. 8

9 O Software CMM tem a intenção de ser: um aplicação de bom senso de processos de gerenciamento e conceitos de melhoria de qualidade ao desenvolvimento e manutenção de software; um guia desenvolvido pela comunidade, pois as informações fornecidas por centenas de profissionais de software foram levadas em conta na confecção do modelo; um modelo para melhoria organizacional, que implica em uma série de prioridades que podem diferir das de um projeto específico, mas que se provaram efetivas na transformação de uma organização; uma estrutura para métodos de avaliação baseados no CMM confiável e consistente. Embora o CMM seja descrito em um livro com mais de 500 páginas, os requisitos para uma organização estar no nível 5 podem ser concisamente colocados em 52 sentenças: os objetivos das 18 áreas de processo. As práticas, sub-práticas e exemplos que também são descritos no modelo servem apenas como material informativo para guiar os profissionais de software que estejam adotando o CMM. RM - Requirements Management O objetivo da KPA RM é estabelecer mecanismos para que o produto de software reflita e expectativa do cliente. Objetivo 1: Os requisitos de software são controlados para estabelecer uma baseline que será usada como base tanto para o desenvolvimento quanto para atividades de gerência. Objetivo 2: Os planos de desenvolvimento, os produtos e todas as atividades são mantidos em consistência com os requisitos de software. Documentar os requisitos e os compromissos assumidos, mesmo que seja em apenas uma folha de papel. SPP - Software Project Planning O objetivo desta KPA é estabelecer planos efetivos para servirem como base para as atividades de desenvolvimento de software e gerência. Objetivo 1: As estimativas de software são documentadas para uso no planejamento e acompanhamento do projeto. Objetivo 2: O projeto de software tem as suas atividades e compromissos associados planejados e documentados. Objetivo 3: Os grupos e indivíduos que tenham alguma relação com o desenvolvimento do software conhecem os compromissos assumidos e concordam com eles. Fazer um plano básico que contenha as principais atividades a serem realizadas, bem como os produtos gerados por cada uma delas. Revisar o plano conforme o projeto estiver em andamento. Estabelecer pontos de verificação. SPTO - Software Project Tracking & Oversight O objetivo da KPA SPTO é permitir a visibilidade e acompanhamento do andamento do projeto para que a gerência, nos seus vários níveis, possa tomar as ações apropriadas quando o projeto desviar de maneira significativa do que foi planejado. Objetivo 1: É feito um acompanhamento do realizado com relação ao que foi planejado. Objetivo 2: Quando o andamento do projeto desvia de maneira significativa do que foi planejado ações corretivas são executadas e gerenciadas até a sua conclusão efetiva. Objetivo 3: Eventuais mudanças de compromissos de quaisquer natureza são negociadas e concordadas por todos os grupos afetados. Comparar o que foi feito com o que foi planejado. Atualizar o plano de maneira simples. As tarefas devem ser pacotes binários: ou terminadas ou não terminadas. Uma tarefa 87% pronta é sinal de chute. Se o projeto estiver saindo da linha, parar e replanejar. SSM - Software Subcontract Management O objetivo do SSM é a seleção de subcontratados para o desenvolvimento e sua gerência de maneira Extreme Programming Brasil - São Paulo - dezembro de

10 Extreme Programming, Qualidade e Confiabilidade de Software efetiva. Objetivo 1: O contratante seleciona subcontratados qualificados. Objetivo 2: O contratante e o subcontratado concordam quanto aos compromissos assumidos mutuamente. Objetivo 3: O contratante e o subcontratado mantém comunicação permanente. Pequenas organizações geralmente não subcontratam. Se subcontratarem, escolher organizações competentes e gerenciar seu trabalho. SQA - Software Quality Assurance O objetivo da SQA é proporcionar visibilidade aos vários níveis gerenciais dos produtos e processos em uso. Objetivo 1: As atividades de SQA são planejadas. Objetivo 2: Os produtos e atividades em uso atendem a todos os padrões, normas e requisitos aplicáveis. Objetivo 3: Todos os grupos afetados são informados das atividades do grupo de SQA e dos seus relatórios. Objetivo 4: Não conformidades encontradas e não resolvidas no contexto do projeto são tratadas pela gerência superior. Verificar se os requisitos e os padrões estão sendo atendidos. Utilizar-se de checklists para isso. SCM - Software Configuration Management O objetivo do SCM é estabelecer e manter a integridade de todos os produtos de trabalho ao longo do ciclo de vida do projeto. Objetivo 1: As atividades de SCM são planejadas. Objetivo 2: Produtos de trabalho selecionados, os itens de configuração, são identificados, controlados e tornados disponíveis. Objetivo 3: As mudanças dos itens de configuração são controladas. Objetivo 4: Os grupos afetados e indivíduos são mantidos informados da situação e conteúdo do baseline de software. Estabelecer baselines e controlar sua mudança. OPF - Organization Process Focus Tem por objetivo estabelecer a responsabilidade organizacional pelas atividades de processo de software que melhorem a capacitação geral do processo de software da organização. Objetivo 1: Atividades de desenvolvimento e melhoria do processo de software são coordenadas através da organização. Objetivo 2: Os pontos fortes e fracos dos processos de software utilizados são identificados com relação a um processo padrão. Objetivo 3: Atividades de desenvolvimento e melhoria do processo de software em nível organizacional são planejadas. Atribuir a responsabilidade de melhoria e manutenção do processo de desenvolvimento para alguém. OPD - Organization Process Definition O objetivo desta KPA é desenvolver e manter um conjunto utilizável de processos de software que melhorem a performance do processo através dos projetos e forneçam uma base para benefícios cumulativos e de longo prazo para a organização. Objetivo 1: Um processo de software padrão para a organização é desenvolvido e mantido. Objetivo 2: Informações relacionadas ao uso do processo de software padrão da organização pelos projetos de software são coletadas, revistas e tornadas disponíveis. Documentar o processo de desenvolvimento de software, em alto nível e de maneira e objetiva. Mantenha o processo simples. 10

11 TP - Training Program O objetivo do programa de treinamento é desenvolver as habilidades e o conhecimento dos indivíduos de modo que eles possam desempenhar seus papéis de maneira eficiente e eficaz. Objetivo 1: As atividades de treinamento são planejadas. Objetivo 2: Treinamento para desenvolver as habilidades e o conhecimento necessários para realização de tarefas técnicas e de gerência de projeto é fornecido. Objetivo 3: Indivíduos do grupo de engenharia de software e grupos relacionados ao software recebem o treinamento necessário para desempenharem suas tarefas. Os desenvolvedores tem que dominar as técnicas que utilizam. O treinamento não precisa ser em sala de aula. Atividades de mentoring muitas vezes são mais eficientes. ISM - Integrated Software Management O objetivo desta KPA integrar as atividades de engenharia de software e as de gerenciamento em um processo de software definido e coerente, adaptado do processo de software padrão da organização e de demais processos relacionados. Objetivo 1: O processo de software definido para um determinado projeto é uma versão adaptada do processo de software padrão da organização. Objetivo 2: O projeto é planejado e gerenciado conforme o processo de software definido para o projeto. Nem todos os projetos exigem o uso do mesmo processo. Por isso, o processo original da organização tem que poder ser adaptado para as necessidades do projeto. SPE - Software Product Engineering O objetivo desta KPA é realizar consistentemente um processo de engenharia bem definido que integre todas as atividades de engenharia de software para produzir software correto e consistente de maneira efetiva e eficiente. Objetivo 1: As tarefas de engenharia de software são definidas, integradas e realizadas consistentemente para produzir software. Objetivo 2: Produtos de trabalho de software são mantidos consistentes uns com os outros. Use sempre um processo de desenvolvimento consistente, mesmo para pequenos projetos. Não queime fases. Considere este processo quando for fazer o planejamento. Sempre gaste mais tempo com análise de requisitos, design e planejamento dos testes. IC - Intergroup Coordination O objetivo da KPA IC é estabelecer meios para o grupo de engenharia de software atuar ativamente com os outros grupos de engenharia de modo que o projeto satisfaça as necessidades de cliente eficazmente e eficientemente. Objetivo 1: Todos os grupos afetados concordam com os requisitos do cliente. Objetivo 2: Todos os grupos afetados concordam com os compromissos entre os grupos de engenharia. Objetivo 3: Os grupos de engenharia identificam, acompanham e resolvem questões intergrupos. Comunique-se com seu cliente. Registre compromissos. Resolva conflitos. PR - Peer Reviews O objetivo das revisões por pares é remover defeitos dos produtos de software precocemente e eficientemente. Objetivo 1: As atividades de revisão por pares são planejadas. Objetivo 2: Os defeitos dos artefatos de software são identificados e removidos. Submeta sempre todo trabalho a alguma espécie de revisão. Inspeções geralmente são o modo mais adequado. Extreme Programming Brasil - São Paulo - dezembro de

12 Extreme Programming, Qualidade e Confiabilidade de Software QPM - Quantitative Process Management O objetivo desta KPA é controlar a performance do projeto de software quantitativamente. A performance do processo de software representa os resultados verdadeiros alcançados por seguir um processo de software. Objetivo 1: As atividades de gerenciamento quantitativo de processo são planejadas. Objetivo 2: A performance do processo definido para um projeto é controlada quantitativamente. Objetivo 3: A capacitação do processo de software padrão da organização é conhecida em termos quantitativos. Definir poucas métricas simples e coerentes. Coletálas com disciplina. Comparar os resultados atingidos. SQM - Software Quality Management O objetivo desta KPA é desenvolver um entendimento quantitativo da qualidade dos produtos de software de um projeto e alcançar metas de qualidade específicas. Objetivo 1: As atividades de gerenciamento de qualidade de software são planejadas. Objetivo 2: Metas mensuráveis para a qualidade do software e suas prioridades são definidas. Objetivo 3: O progresso verdadeiro em direção ao atingimento das metas de qualidade para os produtos de software é quantificado e gerenciado. Usando-se as metas coletadas na KPA QPM, definir metas de qualidade a atingir. Monitorar o atingimento destas metas. DP - Defect Prevention O objetivo desta KPA é identificar a causa de defeitos e evitar que eles ocorram novamente. Objetivo 1: As atividades de prevenção de defeitos são planejadas. Objetivo 2: As causas comuns dos defeitos são procuradas e identificadas. Objetivo 3: As causas comuns dos defeitos são priorizadas e sistematicamente eliminadas. Identificar as causas dos efeitos e evitar que ocorram novamente. TCM - Technology Change Management O objetivo desta KPA é identificar novas tecnologias e implantá-las na organização de maneira ordenada. Objetivo 1: A incorporação de mudanças tecnológicas é planejada. Objetivo 2: Novas tecnologias são avaliadas para se determinar seus efeitos em termos de qualidade e produtividade. Objetivo 3: Novas tecnologias apropriadas são transferidas para as práticas normais da organização. Fazer sempre projetos piloto. Coletar as métricas padrão da organização. Medir o impacto do uso da nova tecnologias nestas métricas. Avaliar o custo/benefício. PCM - Process Change Management O objetivo desta KPA é melhorar continuamente o processo de software usado na organização com o intuito de melhorar a qualidade do software, aumentar a produtividade e diminuir seu tempo de desenvolvimento. Objetivo 1: A melhoria contínua do processo é planejada. Objetivo 2: Toda a organização participa das atividades de melhoria de processo de software. Objetivo 3: O processo de software padrão da organização e os processos de software adaptados para os projetos são melhorados continuamente. Manter um programa de sugestões. Avaliar o uso de novas práticas em projetos piloto. A XP e o CMM Os valores da XP devem ser levados em consideração em qualquer projeto de software, mesmo que sua implementação varie radicalmente conforme o ambiente. Comunicação e simplicidade, por exemplo, podes ser colocadas em outros termos, como coordenação e elegância. Mas a verdade é que sem elas qualquer projeto enfrenta problemas enormes. Os princípios de comunicação e simplicidade também são princípios de 12

13 projeto de processo fundamentais para organizações que usam o CMM. Quando estão definindo seus processos as organizações devem capturar a mínima informação essencial necessária, usar bons princípios de projeto ao estruturar suas definições e enfatizar a usabilidade e a serventia. O feedback rápido é crucial para o controle de processo em tempo real. É necessário ter coragem para efetivar a mudança cultural necessária a organização para movê-la do nível 1 para o nível 2. Muito do formalismo que caracteriza a melhoria de processo baseada no CMM é devida aos grandes projetos ou a severas restrições de confiabilidade, especialmente para sistemas que envolvem risco de vida. A estrutura hierárquica do CMM é feita para suportar uma ampla gama de implementações dentro do contexto das 18 áreas chave de processo e os 52 objetivos que consistem nos requisitos para um processo de software totalmente maduro. A medida em que os sistemas vão se tornando maiores, algumas das práticas da XP se tornam difíceis de implementar. Conforme o projeto cresce, a ênfase na boa arquitetura se torna crítica para o sucesso do projeto. Arquitetura baseada em projeto, projetar para a mudança, refactoring e filosofias de projeto similares enfatizam a necessidade de lidar com a mudança de modo sistemático. Variantes destes conceitos, incluindo a arquitetura baseada em projeto e equipes de produto integradas podem ser mais apropriadas para projetos grandes, talvez em conjunto com a XP dentro das equipes. Levando-se em consideração que o projeto de arquitetura que enfatiza a flexibilidade é a meta de qualquer boa metodologia orientada a objetos, então XP (com refactoring) e orientação a objetos foram feitas uma para a outra. Equipes multidisciplinares também são problemáticas, uma vez que XP é direcionada somente para software. A principal objeção ao uso da XP na melhoria de processo é que ela mal toca nas questões gerenciais e organizacionais que o CMM enfatiza. Colocar em prática o tipo de ambiente altamente colaborativo que a XP assume requer gerenciamento esclarecido e apropriada infra-estrutura organizacional. A conversa de que um processo disciplinado ao modo CMM é antiético para XP não é convincente. XP também é um processo disciplinado e bem definido. Na verdade, XP e CMM podem ser considerados complementares. O CMM diz o que deve ser feito em linhas gerais, enquanto a XP e um conjunto de melhores práticas que contém informações de como fazer - um modelo de implementação - para um tipo de ambiente em particular. As práticas da XP podem ser compatíveis com as intenções de uma área chave de processo, mesmo que não a realizem completamente [4]. No nível 2, a KPA Requirements Management é tratada pelas histórias, o cliente disponível no local e a integração contínua. As histórias são os acordos dos requisitos entre os clientes e os desenvolvedores. O cliente no local está sempre esclarecendo os detalhes dos requisitos, e a integração contínua e os testes de aceitação garantem que os requisitos sejam cumpridos. A KPA Software Project Planning é tratada pelo jogo do planejamento e pelos releases curtos. O jogo do planejamento, que inclue os planos de release, os planos de interação e as reuniões diárias demonstra a ênfase da XP no planejamento das atividades. Os releases curtos facilitam o planejamento. A KPA Software Project Tracking & Oversight é tratada pelo "big visual chart" - um grande gráfico, atualizado semanalmente, que mostra para todos a evolução do projeto e outras métricas, pela project velocity (velocidade do projeto), ou a quantidade de dias de calendário dividida pela quantidade de dias estimada para a realização da tarefa. As histórias são os compromissos dos releases curtos. O processo de comprometimento para a XP cria expectativas claras para os clientes e a equipe de desenvolvimento no nível tático e maximiza a flexibilidade do projeto no nível estratégico. A ênfase da XP nas 40 horas de trabalho é um conceito geral de gerenciamento que não é considerado pelo CMM, apesar de se tratar de uma boa prática. A XP também tem ênfase no ambiente de trabalho, outra questão deixada de fora do CMM. A KPA Software Subcontract Management não é tratada pela XP. Embora seja improvável um grupo independente de SQA fazer parte da cultura da XP, a KPA Software Quality Assurance é tratada pela programação aos pares; a conformidade aos padrões de codificação, cuja garantia é tarefa típica do grupo de SQA, é garantida pela pressão dos pares no ambiente de XP. Uma vez implantado, um processo baseado em CMM tem mecanismos para verificar objetivamente a aderência aos requisitos, padrões e procedimentos. A dependência da XP à pressão dos pares, mesmo que eficiente na maioria dos ambientes, pode ser vulnerável a pressões externas, e esta vulnerabilidade deve ser considerada no nível organizacional. A KPA Software Configuration Management é parcialmente tratada via propriedade coletiva do código, releases curtos e integração contínua. Mesmo que não completamente e explicitamente tratada, a gerência de configuração está implícita nestas praticas. A integração contínua, por exemplo, coloca o código sob controle de configuração. A propriedade coletiva do código proporciona um certo controle de mudança, enfatizado Extreme Programming Brasil - São Paulo - dezembro de

14 Extreme Programming, Qualidade e Confiabilidade de Software pelas histórias dos releases curtos. Mas a propriedade coletiva de código pode ser problemática em sistemas grandes, e canais de comunicação mais formais devem ser estabelecidos para serem efetivos no controle de mudança. No nível 3, a KPA Organization Process Focus é tratada no nível de equipe em vez de sê-lo no nível organizacional, mas a filosofia por trás da adoção da XP - uma prática por vez e regras justas - implica em focar em questões de processo. Uma vez que a XP foca nos processos de engenharia de software em vez de focar em questões de infra-estrutura organizacional, este e outros processos que estejam no nível de organização devem ser tratados de maneira independente pelas organizações que estejam adotando a XP. De modo análogo, a KPA Organization Process Definition e a KPA Training Program são parcialmente tratadas por vários livros, artigos, cursos e sites sobre XP, mas questões organizacionais estão fora do escopo da mesma. Como conseqüência, a KPA Integrated Software Management não pode ser tratada uma vez que não há processo organizacional para adaptar. A KPA Software Product Engineering é muito bem endereçada de muitas formas pela Extreme Programming com as metáforas, o projeto simples, o refactoring, o mothball tour - congelar modelos relacionados a código que não vai mais sofrer alterações, os coding standards e os testes. A ausência de documentação de projeto seria uma preocupação em muitos ambientes, tais como sistemas de tempo real, sistemas muito grandes ou equipes virtuais. Nestes ambientes, bons projetos são essenciais para o sucesso, e a estratégia de refactoring pode ser arriscada. Por exemplo, fazer refactoring após um sistema ter provado ser satisfatório a requisitos de tempo real pela técnica da análise monotônica de taxa significaria que toda a análise teria de ser refeita - assumir que a mudança não tem um custo alto não vale para este tipo de ambiente. A KPA Intergroup Coordination é tratada pelo cliente no local e a programação aos pares. A ênfase da XP na comunicação parece resultar em uma solução que compreende a coordenação intergrupos e o desenvolvimento integrado de processo e produto, embora o contexto somente de software ignore ambientes multidisciplinares. A KPA Peer Reviews é tratada pela programação aos pares. A programação aos pares pode ser mais poderosa do que a revisão por pares, comparando-se a leitura de código e a programação propriamente dita, embora a falta de estrutura possa diminuir a eficácia. Poucas das KPAs dos níveis 4 e 5 são tratadas pela XP em um sentido rigorosamente estatístico, embora a KPA Defect Prevention possa ser parcialmente tratada pelo feedback devido aos releases curtos. A satisfação das áreas chaves de processo do CMM pela XP, dentro do domínio apropriado, está sumariada na tabela 1. kpas nível 2 kpas nível 3 satisfação satisfação RM XX OPF X QPM -- SPP XX OPD X SQM -- SPTO XX TP -- SSM -- ISM -- DP X SQA X SPE XX TCM -- SCM X IC XX PCM -- PR XX kpas alta maturidade satisfação TABELA 1 - Satisfação das KPAs do CMM pela XP - XX significa totalmente atendido, X significa parcialemente atendido e -- não atendido Muitas das áreas chave de processo parcialmente cobertas ou não tratadas pela XP são sem dúvida nenhuma tratadas em projetos reais. A XP não pode sobreviver sem gerenciamento e sem suporte de infraestrutura, mesmo que ela não fale disso explicitamente. Parece justo afirmar que a XP foca no trabalho técnico, enquanto o CMM foca no trabalho gerencial, mas a preocupação com questões culturais é evidente em ambas. Conclusão Usar metodologias ágeis não é para qualquer um. Há uma certo número de coisas que se deve ter em mente quando se decide seguir este caminho. Entretanto, estas metodologias são largamente aplicáveis e devem ser usadas por mais pessoas do que as que atualmente consideram usá-las. Nas organizações de hoje, a metodologia mais comum é o code and fix. Aplicando mais disciplina do que caos certamente irá ajudar, e a abordagem ágil tem a vantagem de serem muito menos trabalhosa de se adotar do que as metodologias pesadas. Muito da vantagem dos métodos ágeis está no fato de eles serem leves. É mais provável que processos mais simples sejam seguidos quando se está acostumado a não seguir processo nenhum. Uma das maiores limitações destas novas metodologias está em como elas lidam com equipes maiores. Não há registro na literatura do uso destas metodologias em projetos que envolvam mais de 50 pessoas. As metodologias ágeis são boas quando os requisitos são incertos ou voláteis. Quando não se tem estabilidade nos requisitos fica difícil manter um projeto estável e seguir um processo planejado. Nestas situações o uso de 14

15 um processo ágil é mais confortável. Geralmente a maior barreira é o cliente. É importante fazer o cliente entender que seguir um processo preditivo é arriscado quando os requisitos são instáveis. Isto posto, fica claro que o uso de uma metodologia ágil é melhor do que nada. Mas usar a XP - uma metodologia ágil - me garante software de qualidade, ou é melhor continuar com o code and fix e não perder meu tempo com isso? A maior parte da XP consiste de boas práticas que deveriam ser sabiamente consideradas em qualquer ambiente. Enquanto o mérito destas práticas possa ser discutido em comparação com outros, nenhuma delas deve ser arbitrariamente rejeitada. Colocar todas estas práticas juntas em uma metodologia é uma mudança de paradigma. Além disso, a XP atende a boa parte das KPAs do nível 2 e 3 do CMM, isto quando se faz uma leitura menos rigorosa destas KPAs, usando-se o bom senso. A XP fornece uma perspectiva sistemática para a programação, do mesmo modo que o CMM fornece uma perspectiva sistemática a melhoria de processo organizacional. Organizações que querem melhorar sua capacitação deveriam tirar vantagem das boas idéias de ambos e usar o bom senso no uso e na aplicação destas idéias. O CMM foca nas questões de gerenciamento associadas com colocar processos eficientes e eficazes em prática, juntamente com uma melhoria sistemática de processo. A XP é um conjunto específico de práticas - uma metodologia - que é efetiva dentro do contexto das equipes pequenas e que trabalham juntas. Ambas tem boas idéias que podem ser sinergéticas, particularmente em conjunto com outras boas práticas de engenharia e gerência. É questionável se a XP, como publicada, tem uso em sistemas onde há risco de vida ou sistemas de alta confiabilidade. A falta de documentação de projeto e a falta de ênfase na arquitetura seriam julgadas decisões arriscadas pela maioria dos profissionais competentes, mas uma das virtudes da XP está em que ela pode ser mudada e melhorada para diferentes ambientes. Conclue-se que a XP é capaz de produzir software de qualidade, mas seu uso é limitado. Mas o próprio autor, ciente destas limitações, estabelece o ambiente ideal para o uso de XP: equipes pequenas ou médias, requisitos instáveis, sistemas comerciais onde o maior risco envolvido é o financeiro. Levando-se em consideração eu a maioria das empreitadas de desenvolvimento de software tem estas características, e justamente por isso não usam metodologia nenhuma, pode-se considerar que o uso da XP pode resolver grande parte dos recorrentes problemas de desenvolvimento: custo e tempo maiores do que o previsto, baixa qualidade e diminuição na funcionalidade. Bibliografia [1] FOWLER, Martin - The New Methodology - Software Development Magazine - Dezembro/2000 [2] BECK, Kent - Extreme Programming Explained - Addison Wesley [3] MILLER, Roy W.; COLLINS, Christopher T. - XP Distilled - IBM DeveloperWorks - Março/2001 [4] PAULK, Mark C. - Extreme Programming from a CMM Perspective - IEEE Software - Novembro/2001 [5] PAULK, Mark C.; et al - The Capability Maturity Model: guidelines for improving the software process - Addison Wesley [6] PAULK, Mark C. - Using the Software CMM with Good Judgment - ASQ Sofware Quality Professional, Junho/1999 [7] MINISTÉRIO DA CIÊNCIA E TECNOLOGIA. Secretaria de Política de Informática. Sociedade SOFTEX. Levantamento do Universo das Associadas SOFTEX. Brasilia. Ago [8] The Standish Group International. The CHAOS Report. Dennis, MA, Extreme Programming Brasil - São Paulo - dezembro de