Metodologias geis e Extreme Programming(XP) Uma Introduo Jos
Paulo PapoAnalista de TI na rea de produtos auto-atendimento da
TECBAN S/A Professor da FIAP. E-mails: [email protected]
[email protected]
eXtreme Programming Supere o Medo
Klaus Wuestefeld e Humberto Soares Gerentes de
[email protected] [email protected]
Copyright 1996-2000 Objective Solutions LTDA
OBJECTIVE SOLUTIONS DESENVOLVER E IMPLANTAR SOLUES
PERSONALIZADAS DE SOFTWARE COM NOSSOS PARCEIROS E CLIENTES
Servios de Desenvolvimento e ConsultoriaProjetos Especiais
Processo e Ferramentas de Desenvolvimento
Faturamento.......R$4.5 milhes (2001) Escritrios..........So
Paulo e Curitiba +50 Consultores e Desenvolvedores
Principais Clientes
Por que processo? Para que metodologia?
Qual o melhor processo?
Montando a MochilaEquilibrando Utilidade, Peso e Confiabilidade
Menos tens tens Mais Leves Genricos: tens com multiplas funes Menos
Disciplina / Mais Diverso Sinergia: O conjunto de tens se
refora
Montando a MochilaQuem tem interesse em aumentar o peso da sua
mochila?Cliente? Gerente?
ObjetivosIntroduzir as Metodologias geis e seu Manifesto
Introduzir Extreme Programming, seus princpios e prticas Comparar e
relacionar XP e RUP Comparar e relacionar XP e CMM O que buscamos:
Aguar a curiosidade e o interesse de todos os participantes em
analisar e se aprofundar nas metodologias geis, em XP e outros
processos de desenvolvimento, com vistas a melhorar o
desenvolvimento de software de sua organizao e, conseqentemente, do
Brasil.
Riscos e mitos do desenvolvimento de softwareRiscosAtrasos no
cronograma. Cancelamento de projetos. Entropia de sistemas em
produo. Taxa de defeitos. Incompreenso dos requisitos de negcio e
sistemas. Mudanas constantes. Scope Creep(invaso de requisitos).
Alta taxa de evaso de desenvolvedores.
MitosPodemos coletar todos os requisitos de uma s vez. Podemos
antecipar todas as mudanas. Podemos controlar completamente todo o
projeto de software. Custo de mudana , por natureza, maior conforme
o projeto avana.
Metodologias geis:As motivaesPrimrdios do desenvolvimento de
software: code and fix. A primeira alternativa: imposio de um
processo disciplinado e detalhado, com o intuito de tornar o
desenvolvimento de software mais predizvel e eficiente. Inspirado
em outras disciplinas da rea de engenharia. A crtica mais freqente
que so burocrticas, no populares por imporem padres rgidos e no
serem to bem sucedidas como deveriam. Ficaram conhecidas como
metodologias heavyweight ou monumentais(termo de Jim Highsmith).
Como reao s metodologias heavyweight, surgiu um novo grupo de
metodologias nos ltimos anos, que ficaram conhecidas como
metodologias lightweight, mas agora receberam o termo geis.
Metodologias geis e Heavyweight: As diferenasO apelo inicial foi
a reao ao aspecto burocrtico das suas antecessoras e seu
compromisso entre nenhum processo e muito processo. Explicam que o
desenvolvimento de software inerentemente complexo e se assemelha a
sistemas no lineares e caticos. So mais adaptativas que preditivas.
So mais orientadas a pessoas que orientadas a processos.
Manifesto para o desenvolvimento de software gilNs estamos
descobrindo melhores maneiras de desenvolver software criando-o e
ajudando outros a cri-lo. Atravs deste trabalho passamos a
valorizar: Indivduos e interaes sobre processos e ferramentas.
Software funcional sobre documentao extensa. Colaborao do cliente
sobre negociao contratual. Responder a mudanas sobre seguir um
plano. Assim, enquanto h valor nos itens direita, ns damos mais
valor aos itens esquerda
Benefcios da adooCustos mais baixos ou no alterados Melhoria da
produtividade Melhoria da qualidade do software produzido Melhoria
da satisfao dos clientes e para o negcio
O que a XP?XP uma metodologia lightweight(ou gil) para equipes
pequenas e mdias, desenvolvendo software a partir de requisitos
vagos e em rpida e constante mudana. XP descreve uma maneira de
desenvolver software que combina melhores prticas existentes na rea
h muito tempo. Na XP essas prticas se complementam e controlam uma
outra. A diferena da XP que ela pega essas prticas do senso comum e
as utiliza a nveis extremos. XP o mais importante movimento de
nosso campo hoje. Eu vejo que ele ser to essencial para a gerao
presente quanto o SEI e o CMM foram para a anterior. - Tom
DeMarco
Os quatro valores da XPComunicao Simplicidade Feedback
Coragem
Carta de direitos do clienteVoc tem o direito a um plano, para
saber o que ser realizado, quando e a que custo. Voc tem o direito
de receber o maior valor possvel de cada semana de um
desenvolvedor. Voc tem o direito de ver o progresso de um sistema
sendo executado, que prove seu funcionamento ao passar por testes
repetidos que voc mesmo especifica. Voc tem o direito de mudar de
idia, substituir funcionalidade e mudar suas prioridades sem pagar
custos exorbitantes. Voc tem o direito de ser informado de mudanas
de cronograma, em tempo de escolher como reduzir o escopo para
restaurar a data original. Voc pode cancelar o projeto a qualquer
tempo e ainda assim ter um sistema funcionando refletindo o
investimento feito at o momento.
Carta de direitos do desenvolvedorVoc tem o direito de saber o
que necessrio, com claras declaraes de prioridade. Voc tem o
direito de produzir trabalho de qualidade o tempo todo. Voc tem o
direito de pedir e receber ajuda de seus pares, superiores e
clientes. Voc tem o direito de fazer e atualizar suas prprias
estimativas. Voc tem o direito de aceitar as suas
responsabilidades, ao invs de t-las impostas a voc de cima para
baixo.
As doze prticas da XPProcesso de Planejamento ( Planning Game )
Releases Curtos Met fora Projeto(Design) Simples Testes Refactoring
Programa o em Pares Propriedade Coletiva do C digo Integra o
Contnua Semana de 40 Horas On-Site Customer (Cliente sempre
presente) Padr es de Codifica o
On-Site Customer (Cliente Sempre Presente)Um cliente deve estar
sempre presente, ajudando a equipe a responder questes, resolver
disputas e colocar pequenas prioridades em tarefas. Pode-se dizer
que um cliente muito caro para se disponibilizar para a equipe de
desenvolvimento. Gerentes devem dizer o que tem mais valor: o
software estar pronto mais cedo ou o trabalho de uma ou duas
pessoas. Segundo o Standish CHAOS Report de 1998 os principais
fatores de sucesso para um projeto so o envolvimento do usurio,
suporte dos executivos e objetivos de negcio claros (50% de
importncia, em conjunto).
Planning Game - MotivaoDesenvolvimento de software um dilogo
constante entre pessoal de negcio e pessoal tcnico. Pessoas de
negcio decidem sobre: escopo, prioridade, composio de releases e
datas de lanamento. As pessoas de negcio no podem tomar essas
decises no vcuo. Elas precisam do pessoal tcnico para decidir
sobre: estimativas, conseqncias tcnicas, processo de
desenvolvimento do produto, cronograma detalhado.
Planning Game Como funciona?A XP trabalha com dois nveis de
planejamento. Planejamento do release: Cliente prop e user stories
(est rias) e os desenvolvedores avaliam sua dificuldade atrav s de
semanas ideais. Planejamento de itera o: cada itera o ir durar de
uma a tr s semanas. Cada release pode ter v rias itera es. Cada uma
delas ir implementar algumas est rias definidas para o release.
Cada itera o feita como uma timebox . Caso n o se consiga
implementar todas as funcionalidades requeridas, as que sobrarem s
o colocadas na pr xima itera o. Nunca se atrasa um milestone
(marco). O cliente pode mudar suas prioridades de requisitos a cada
itera o que passa. Como elas s o curtas(m dia de duas semanas) isso
garante que mudan as s o incorporadas tranq ilamente. Garante que o
cliente tenha o maior ROI(retorno sobre o investimento) em cada
itera o de desenvolvimento.
Releases CurtosCada release deve ser to curto quanto possvel,
contendo os requisitos de negcio de maior valor para o cliente. O
release deve fazer sentido como um todo. No deve existir um release
com metade de um requisito(o que no faz sentido). Releases Curtos
promovem o desenvolvimento iterativo e incremental. Se iteraes
curtas so boas(como reconhecido por Frederick Brooks), elas sero
feitas bem pequenas - alguns dias, semanas ou um ms por vez melhor
que seis meses ou um ano com antecedncia.
MetforaA metfora um meio de ajudar a todos(clientes e
desenvolvedores) a compreender melhor o objetivo e propsito do
produto sendo criado. Pode ser considerado como a arquitetura de um
sistema, vista como uma anlise de domnio. Desse modo, pode-se
construir entidades de software com alta coeso e baixo acoplamento
entre si. Se arquitetura importante, todos iro trabalhar
definindo-a e refinando-a o tempo todo.
Prticas de XPPair Programming Test Driven Development Simple
Design Refactoring
Propriedade Coletiva do CdigoMdulos no so propriedade de nenhum
desenvolvedor.
Todo desenvolvedor da equipe tem o direito de checar um mdulo e
modific-lo.
O cdigo propriedade da equipe. Dessa maneira, todos os
desenvolvedores se familiarizam com todo o cdigo.
Integrao ContnuaCdigo integrado e testado depois de algumas
horas(no mximo no final de cada dia). No final de um episdio de
desenvolvimento, o cdigo integrado e todos os casos de teste devem
rodar a 100%. Essa tcnica j existe h tempos e foi conhecida como
daily builds and smoke tests, largamente utilizada na Microsoft. Se
integrao de cdigo importante, ela ser feita vrias vezes ao dia.
Padres de CodificaoCada equipe deve possuir padres de codificao
que sero usados por todos. Idealmente, sero decididos por consenso.
Cada um dos padres deve ter o claro objetivo de ajudar a melhorar a
comunicao da equipe. Todos devem concordar em utiliz-los.
Semana de 40 Horas (Passo Sustentvel)
XP na perspectiva da RUPA RUP(e o Unified Process-UP) um
framework de processo, enquanto a XP um processo em si, j definido
e com limites claros. A RUP precisa ser customizada. Quatro dessas
customizaes apareceram que possuem grande semelhana com a XP e
buscam agilizar o RUP. Agile UP, de Craig Larman Processo dX,
Robert Martin Devido ao grande sucesso da XP entre os
desenvolvedores, a nova verso da RUP(2002) j vem com uma customizao
para projetos pequenos que possui caractersticas de metodologias
geis e da XP. A Rational tambm j disponibilizou um plugin de XP
para o RUP, em seu portal para clientes RDN(Rational Developer
Network). Duas diferenas importantes entre o Agile UP e a XP: A UP
recomenda a criao incremental de casos de uso e requisitos
no-funcionais. A UP recomenda mais tempo gasto com diagramao e
modelagem visual, e possui atividades mais detalhadas sobre isso.
Os principais proponentes da XP recomendam pouco tempo gasto nessas
atividades e com um nvel de formalismo menor. Resumindo, alguns
autores consideram a XP(apesar das diferenas) como uma espcie de
instncia customizada da RUP.
XP na perspectiva do CMMAs contradies vistas entre XP e o CMM so
mitos. O CMM um menu e no diz como desenvolver software. O CMM no
impe uma determinada metodologia ou ciclo de vida. XP no um
processo indisciplinado. Pelo contrrio, ele explicitamente
definido, gerenciado, medido, controlado e efetivo na definio de
Paulk. Como resultado, excluindo as KPAs de Gerenciamento de
Subcontratao e SQA, XP devidamente implementado em uma organizao
pode atingir o CMM nvel 2 e, com um pouco mais de trabalho, o nvel
3.
XP na perspectiva do CMMXP um outro exemplo de um bom processo
de software(ou filosofia) que, pelo menos dentro de um contexto
aproriado, pode satisfazer muitos objetivos do CMM nvel 2 e 3.
Segundo Mark Paulk, um dos pais do CMM, a seguinte tabela se
aplica:
O Futuro da XP e das Metodologias geisAs metodologias geis e a
XP esto tendo um alto grau de visibilidade por parte da comunidade
de software. Muito disso ocorre por seu sucesso em diversos
projetos ao redor do mundo. Geoffrey Moore definiu o ciclo de vida
de adoo de uma tecnologia(em seu livro Cruzando o Abismo)
progredindo dos entusiastas de tecnologia aos visionrios para os
pragmticos, depois os conservadores e chegando nos cticos. A XP e
as metodologias geis ainda continuam no domnio dos entusiastas e
visionrios, isto , ainda no penetraram no grande mercado, dominado
pelos pragmticos. Quanto mais projetos forem bem sucedidos e mais
estudos acadmicos surgirem na comunidade de desenvolvimento de
software, maiores as probabilidades de sucesso das metodologias
geis. Mas ainda est cedo para dizer se elas se tornaro o
equivalente a uma nova tecnologia de ruptura(como descrito em O
Dilema da Inovao de Clayton Christensen).
ConclusesAcredito, como defendido por Alistair Cockburn, que
cada tipo de organizao e/ou projeto demanda uma metodologia e
processos de desenvolvimento diferentes. Parafraseando Frederick
Brooks: No existe bala de prata. O vital para o sucesso de qualquer
iniciativa para atingir a meta da Melhoria do Processo de Software
que ela tenha apoio da Alta Gerncia e realmente seja vista como
fundamental e urgente para a organizao(seguindo o processo de oito
etapas de Kotter). Ainda assim, a controvrsia continuar por um
certo tempo, pois o paradigma das metodologias geis cria
radicalizaes de ambos os lados e que, como vimos, no passam de
mitos. Lembrando Martin Fowler: Qual a diferena entre um
metodologista e um terrorista? Resposta: Voc pode negociar com um
terrorista.
Bibliografia e Maiores InformaesAstels, Miller, Novak(2002)
Extreme Programming:Guia Prtico Ed Campus Beck, K. (2000). Extreme
Programming Explained: Embrace Change. Beck e Fowler(2001).
Planning Extreme Programming. Beck, K. (2002). Test-Driven
Development by Example Brooks, Frederick(1995) The Mythical
Man-Month 20th Anniversary Edition. Cantor, Murray(2002) Software
Leadership. Cockburn, A. (2000). Writing Effective Use Cases.
Cockburn, A. (2001). Agile software development. Cusumano, M. e
Yoffie, D.(1998). Competing on Internet Time. Fowler, Martin e
Scott, Kendal(2002) UML Essencial 2a. edio Highsmith, J. A. (2002).
Agile Software Development Ecosystems. Larman, Craig(2002).
Applying UML and Patterns, 2nd Edition. McBreen, Pete(2002).
Software Craftmanship. McBreen, Pete(2002). Questioning Extreme
Programming McCarthy, Jim(1995). Dynamics of Software Development.
Palmer e Felsing (2002). A practical guide to Feature-Driven
Development. Schwaber, K. e Beedle (2002). Agile Software
Development with SCRUM. Smith, P. e Reinertsen, D.(1997).
Desenvolvendo produtos na metade do tempo.
Bibliografia e Maiores Informaes(2)Agile Alliance:
www.agilealliance.org Agile Modeling: www.agilemodeling.org XP:
www.xispe.com.br; www.xpers.com.br; www.extremeprogramming.org;
www.xprogramming.com; Scrum: www.controlchaos.com Crystal:
www.crystalmethodologies.org A Comparison of RUP and XP:
www.rational.com/products/whitepapers/423.jsp Using RUP for Small
Projects: Expanding upon XP:
www.rational.com/products/whitepapers/tp183.jsp XP from a CMM
Perspective: www.sei.cmu.edu/papers/xp-cmmpaper.pdf The New
Methodology: www.martinfowler.com/articles/newMethodology.html
Dvidas, sugestes, opiniesSua idia precisa ser original apenas
quanto sua adaptao ao problema em que voc est trabalhando no
momento Thomas Edison Nada mais simples do que a grandeza; na
verdade, ser simples ser grande Ralph Waldo Emerson Pessoas so mais
importantes que qualquer processo. Grady Booch Le mieux est lennemi
du bien(O melhor inimigo do bom) Voltaire O nosso um mundo onde as
pessoas no sabem o que querem e esto dispostas a ir ao inferno para
consegu-lo. Don Marquis Previso muito difcil, especialmente se for
sobre o futuro. Annimo Hoje, a era do processo pesado terminou. -
Tom DeMarco No so as espcies mais fortes que sobrevivem, nem as
mais inteligentes, mas as mais aptas mudanas. Charles Darwin De
todos os projetos iniciados na Terra, falham aqueles com grandes
promessas. William Shakespeare
