Antonio Sergio F.

Bonato Extreme Programming e Qualidade de Software

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 Pro-
gramming 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 coisas crescem, os problemas começam a aparecer. Como

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
é 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 2002 1

Antonio Sergio F. Bonato 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 meio-
termo 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
2
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 10. 42% 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
Antonio Sergio F. Bonato
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;
Extreme Programming Brasil - São Paulo - dezembro de 2002
Extreme Programming e Qualidade de Software
• 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
3
Antonio Sergio F. Bonato 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
4
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;
Antonio Sergio F. Bonato
• 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
Extreme Programming Brasil - São Paulo - dezembro de 2002
Extreme Programming e Qualidade de Software
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
5
Antonio Sergio F. Bonato 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
6
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
Antonio Sergio F. Bonato
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
Extreme Programming Brasil - São Paulo - dezembro de 2002
Extreme Programming e Qualidade de Software
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. Cria-
se 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.
7
Antonio Sergio F. Bonato 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),
8
• 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].
Antonio Sergio F. Bonato
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.
Bom senso
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.
Extreme Programming Brasil - São Paulo - dezembro de 2002
Extreme Programming e Qualidade de Software
• 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.
Bom senso
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.
Bom senso
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
9
Antonio Sergio F. Bonato 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.
Bom senso
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.
Bom senso
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.
10
• Objetivo 4: Os grupos afetados e indivíduos são
mantidos informados da situação e conteúdo do
baseline de software.
Bom senso
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.
Bom senso
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.
Bom senso
Documentar o processo de desenvolvimento de
software, em alto nível e de maneira e objetiva.
Mantenha o processo simples.
Antonio Sergio F. Bonato
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.
Bom senso
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.
Bom senso
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
Extreme Programming Brasil - São Paulo - dezembro de 2002
Extreme Programming e Qualidade de Software
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.
Bom senso
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.
Bom senso
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.
Bom senso
Submeta sempre todo trabalho a alguma espécie de
revisão. Inspeções geralmente são o modo mais
adequado.
11
Antonio Sergio F. Bonato 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.
Bom senso
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.
Bom senso
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.
12
Bom senso
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.
Bom senso
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.
Bom senso
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
Antonio Sergio F. Bonato
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 é
Extreme Programming Brasil - São Paulo - dezembro de 2002
Extreme Programming e Qualidade de Software
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
13
Antonio Sergio F. Bonato Extreme Programming, Qualidade e Confiabilidade de Software

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

14
Antonio Sergio F. Bonato Extreme Programming e Qualidade de Software

um processo ágil é mais confortável. Geralmente a maior funcionalidade.

barreira é o cliente. É importante fazer o cliente entender
que seguir um processo preditivo é arriscado quando os Bibliografia
requisitos são instáveis.
Isto posto, fica claro que o uso de uma metodologia [1] FOWLER, Martin - The New Methodology -
ágil é melhor do que nada. Mas usar a XP - uma Software Development Magazine -
metodologia ágil - me garante software de qualidade, ou Dezembro/2000
é melhor continuar com o code and fix e não perder meu [2] BECK, Kent - Extreme Programming
tempo com isso? Explained - Addison Wesley - 2000
A maior parte da XP consiste de boas práticas que MILLER, Roy W.; COLLINS, Christopher T. -
[3]
deveriam ser sabiamente consideradas em qualquer
XP Distilled - IBM DeveloperWorks -
ambiente. Enquanto o mérito destas práticas possa ser
Março/2001
discutido em comparação com outros, nenhuma delas
deve ser arbitrariamente rejeitada. Colocar todas estas [4] PAULK, Mark C. - Extreme Programming from
práticas juntas em uma metodologia é uma mudança de a CMM Perspective - IEEE Software -
paradigma. Além disso, a XP atende a boa parte das Novembro/2001
KPAs do nível 2 e 3 do CMM, isto quando se faz uma
[5] PAULK, Mark C.; et al - The Capability
leitura menos rigorosa destas KPAs, usando-se o bom
Maturity Model: guidelines for improving the
senso.
software process - Addison Wesley - 1994
A XP fornece uma perspectiva sistemática para a
[6] PAULK, Mark C. - Using the Software CMM
programação, do mesmo modo que o CMM fornece uma
with Good Judgment - ASQ Sofware Quality
perspectiva sistemática a melhoria de processo
Professional, Junho/1999
organizacional. Organizações que querem melhorar sua
capacitação deveriam tirar vantagem das boas idéias de [7] MINISTÉRIO DA CIÊNCIA E TECNOLOGIA.
ambos e usar o bom senso no uso e na aplicação destas Secretaria de Política de Informática. Sociedade
idéias. SOFTEX. Levantamento do Universo das
O CMM foca nas questões de gerenciamento Associadas SOFTEX. Brasilia. Ago 2001.
associadas com colocar processos eficientes e eficazes [8] The Standish Group International. The CHAOS
em prática, juntamente com uma melhoria sistemática de Report. Dennis, MA, 2000.
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

Extreme Programming Brasil - São Paulo - dezembro de 2002 15