Transcript Trabalho de Fundamentos da Engenharia de Software Universidade Federal do Rio de Janeiro eXtreme Programming Daniel Fabio Domingues Posner 099233844 Rafael Elias de Lima.

Trabalho de Fundamentos da Engenharia de Software
Universidade Federal do Rio de Janeiro
eXtreme Programming
Daniel Fabio Domingues Posner 099233844
Rafael Elias de Lima Escalfoni 100134931
Rafael de S. Tenório Cavalcanti 104120277
Introdu₤₧o
eXtreme Programming
Criada em 1996 por Kent Beck e Ward
Cunningham no desenvolvimento de um sistema de
recursos humanos chamado “C3” para a montadora
de automóveis Chrysler.
Metodologia ágil, voltada para equipes de
pequeno e m₫dio porte de desenvolvimento de
software, que precisam lidar com problemas que
estejam em mudan₤as constantes, principalmente
causados pela dificuldade do levantamento de
requisitos iniciais.
Introdu₤₧o
eXtreme Programming
Nos modelos tradicionais o custo de mudan₤as ₫ alto.
(tem que fazer ajustes na fase inicial do projeto)
A eXtreme Programming já trabalha pensando que
mudan₤as ir₧o ocorrer, o que diminui o custo para
uma altera₤₧o.
Introdu₤₧o
eXtreme Programming
Recomendada para equipes de 2 à 12 membros,
devido a necessidade de comunica₤₧o e simplicidade.
Para implementar em grandes empresas, basta fazer
uma divis₧o em várias equipes.
A eXtreme Programming ₫ baseada em quatro
valores: Comunica₤₧o, Simplicidade, Feedback e
Coragem, que s₧o responsáveis pela melhoria do
custo de uma altera₤₧o de requisitos durante o ciclo
de vida do projeto.
Introdu₤₧o
eXtreme Programming
A eXtreme Programming se baseia em uma s₫ria
de práticas, que podem ser utilizadas
individualmente, mas que obt₫m melhores resultados
quando utilizadas em conjunto.
Muitas práticas da eXtreme Programming s₧o
apenas de bom senso e as pessaos já as utilizam
mesmo sem saber. O nome “eXtreme Programming”
vem da aplica₤₧o dessas praticas a níveis extremos.
Introdu₤₧o
eXtreme Programming
Se ₫ bom fazer revis₧o de código, ent₧o o código será
sempre revisado (Pair Programming).
Se ₫ bom fazer testes, todos v₧o testar o código o tempo
todo (Unit Testing), at₫ mesmo o cliente (Functional
Testing).
Se fazer projetos ₫ bom, ent₧o será parte do dia-a-dia de
todos (Refactoring).
Se ₫ bom o projeto ser simples, o sistema será sempre na
forma mais simples que suporte as necessidades
requisitadas (The Simpliest Thing That Could Possibly
Work).
Valores
eXtreme Programming
Baseada em 4 valores: Comunica₤₧o, Simplicidade,
Feedback e Coragem.
Comunica₤₧o: Principal valor da XP, grande parte
das práticas est₧o baseadas nela. Se n₧o for
eficiente pode causar atrasos e problemas no projeto.
Uma equipe deve ter meios de se comunicar de
maneira rápida e eficiente com o cliente, com o
gerente do projeto e com outros desenvolvedores
envolvidos.
Valores
eXtreme Programming
Simplicidade: É muito difícil n₧o olhar para frente,
para os requisitos que precisam ser implementados
amanh₧, na próxima semana e no próximo m₨s.
Mas ficar compulsivamente pensando no futuro ₫ um
dos problemas da curva do custo exponencial das
mudan₤as. A XP aposta que ₫ melhor fazer algo
simples e de desenvolvimento rápido hoje, e ter que
gastar um pouco mais no futuro para remodelar um
processo, do que implementar um grande projeto, que
acabe tendo muitas funcionalidades que acabem
nunca sendo necessárias.
Valores
eXtreme Programming
Feedback: O cliente deve receber o sistema o quanto
antes, a fim de poder dar um feedback rápido,
guiando assim o desenvolvedor do software. Quanto
mais cedo o cliente colocar o sistema em produ₤₧o,
mais rápido podem ser feitos ajustes para que o
mesmo fique de acordo com o que o cliente realmente
quer.
Coragem: É preciso coragem para mudar a maneira
pela qual se desenvolve sistemas. Colocar um sistema
em produ₤₧o assim que ele tenha valor para o
cliente, fazer apenas o que se precisa para o momento
e adiar o processo de análise n₧o ₫ nada facil.
Práticas
eXtreme Programming
A XP ₫ baseada em um conjunto de 12 práticas
fundamentais, que podem ser aplicadas
individualmente, mas que funcionam melhor em
conjunto.
1. The Customer is Always Available
2. Planning Game
3. Collective Code Ownership
4. Acceptance Tests
5. Test First Design
6. Continuous Integration
7. Simple Design
8. Refactoring
9. Pair Programming
10. Small Releases
11.Coding Standards
12. 40 Hour Week
Práticas
eXtreme Programming
1. The Customer is Always Available: O cliente está
sempre disponível para resolver dúvidas, alterar o
escopo de uma itera₤₧o e definir prioridades.
Na XP todas as decisões sobre o rumo do projeto
devem ser tomadas pelo cliente. Ele deve priorizar as
tarefas, ser responsável pelos testes de aceita₤₧o e
orientar os desenvolvedores durante o processo de
programa₤₧o.
Esse prática encontra alguma resist₨ncia por
que as empresas acham muito caro destinar um
funcionário para ficar acompanhando o processo.
Como solu₤₧o ou pode-se nomear um membro da
equipe para representar ou cliente, ou se fazer
Práticas
eXtreme Programming
2. Planning Game: Os jogadores do jogo do
planejamento s₧o o cliente e os t₫cnicos. O objetivo:
colocar em produ₤₧o as funcionalidades de maior
valor possível durante o decorrer do jogo.
No planning game o software ₫ efetivamente
planejado pela equipe de desenvolvimento e pela
equipe do cliente. Nesta atividade, cada equipe tem o
seu papel bem claro e definido: a equipe do cliente ₫
responsável por definir escopo e prioridades e a
equipe de desenvolvimento por fornecer estimativas.
Práticas
eXtreme Programming
2. Planning Game (continua₤₧o)
Muitas vezes ₫ difícil manter as equipes focadas
exclusivamente no seu papel. Por isto, cabe ao coach
da equipe de desenvolvimento ficar alertando sobre
possíveis desvios, evitando que os desenvolvedores
escolham as tarefas e que o cliente fa₤a estimativas de
prazo de entrega.
Para a realiza₤₧o do Planning Game, o cliente
já deve ter as User Stories definidas e baseado em
conhecimentos anteriores os desenvolvedores devem
fornecer estimativas para o desenvolvimento para
cada Story.
Práticas
eXtreme Programming
2. Planning Game (continua₤₧o)
Se n₧o for possível estimar uma Story, quer
dizer que ela esta muito complexa e deve ser dividida
em Stories menores, por outro lado, se esta for muito
pequena, deve ser agregada a outras. Normalmente
ela ₫ adequada quando pode ser desenvolvida em dois
ou tr₨s dias.
A rela₤₧o entre as
funcionalidades
entregues e as
solicitadas pelo
cliente a cada
itera₤₧o ₫
Práticas
eXtreme Programming
2. Planning Game (continua₤₧o)
De posse das User Stories e das estimativas feitas
pela quipe de desenvolvimento, os clientes devem
definir o escopo da próxima itera₤₧o, selecionando
aquelas que ele deseja que sejam implementadas.
Nas reuniões do Planning Game tamb₫m s₧o
repassadas para o cliente as informa₤ões sobre o
andamento da release atual e informa₤ões sobre
eventuais atrasos.
Práticas
eXtreme Programming
3. Collective Code Ownership: A equipe como um
todo ₫ responsável por cada arquivo de código. N₧o
₫ preciso pedir autoriza₤₧o para alterar qualquer
arquivo.
O código deve ser de propriedade de todos e
todos devem ter permiss₧o para alterar o que for
necessário para que seu trabalho possa ser
desenvolvido.
Todos s₧o donos e responsáveis por todo o
código. Para garantir o mínimo de problemas com
esta t₫cnica, existem os testes automatizados e a
Continuous Integration, que garante que as
altera₤ões feitas v₧o ser anexadas rapidamente ao
Práticas
eXtreme Programming
4. Acceptance Tests: Os testes de aceita₤₧o s₧o a
melhor maneira pela qual o cliente pode fornecer
feedback sobre o sistema. S₧o eles que indicam para
os desenvolvedores quando a story que eles est₧o
desenvolvendo está pronta ou n₧o.
Os testes devem ser escritos pela equipe do
cliente, fornecendo material para que os
desenvolvedores do sistema possam avaliar o
progresso da implementa₤₧o, e ter certeza de que o
que est₧o desenvolvendo está correto.
Práticas
eXtreme Programming
4. Acceptance Tests: (continua₤₧o)
Os testes devem ser escritos antes que inicie o
desenvolvimento da Story, e devem ser automatizados
para diminuir o tempo gasto com eles.
Os testes sendo definidos pelo cliente, fazem com
que o produto final fique mais de acordo com o que o
cliente realmente precisa, uma vez que cada tarefa só
vai será concluída depois de passar pelos testes que o
próprio cliente definiu. Colocando a cria₤₧o de
testes como uma tarefa do cliente o obriga a
participar de forma realmente efetiva do
desenvolvimento do sistema e cria uma
"cumplicidade" maior entre equipe de
Práticas
eXtreme Programming
5. Test First Design: Define que qualquer m₫todo de
cada objeto que possa falhar deve ter um teste
automatizado que garanta o seu funcionamento.
Após os programadores receberem a Story a ser
implementada, eles passam a escrever os testes
unitários para ela.
Os testes automatizados s₧o fundamentais para
a XP, uma vez que d₧o suporte a outras t₫cnicas da
metodologia, como o Refactoring e o Collective Code
Ownership
Práticas
eXtreme Programming
6. Continuous Integration: A t₫cnica de Continuous
Integration diz que o código desenvolvido por cada
par de desenvolvedores deve ser integrado ao código
base constantemente.
Geralmente os problemas de integra₤₧o
ocorrem por haver muita diferen₤a entre os códigos
desenvolvidos, pois muito trabalho foi feito por cada
membro da equipe entre cada integra₤₧o
Com a integra₤₧o contínua, e os unit tests, estes
problemas se reduzem bastante, pois cada vez que
algum código ₫ integrado, todos os unit tests devem
ser rodados, e se algum deles falhar, ₫ porque o
código rec₫m integrado foi o responsável por inserir
Práticas
eXtreme Programming
7. Simple Design: Deve-se projetar apenas "a coisa
mais simples que possa funcionar".
Esta ent₧o ₫ a aposta da XP, que n₧o deve ser
desenvolvido nada que n₧o seja necessário para a
itera₤₧o na qual se está trabalhando agora,
"resistindo à tenta₤₧o" de fazer uma rotina "mais
completa". Este princípio ₫ conhecido na XP pela
sigla YANGNI (you are not gonna need it), que diz
que normalmente se acaba n₧o precisando de todas
as funcionalidades e flexibilidade que se coloca em um
código que poderia ser implementado de forma
simples.
Práticas
eXtreme Programming
8. Refactoring: Deve-se reescrever o código,
melhorando e simplificando o mesmo, sempre que for
possível.
Indícios de que um código precisa de refactoring
s₧o: código duplicado, m₫todos de classes muito
longos, m₫todos cujos nomes n₧o indicam
claramente o que fazem e excesso de comentário no
código.
Com o refactoring se consegue Simple Design e
os Testes automatizados d₧o seguran₤a ao processo,
assim vemos como as práticas do XP se
Práticas
eXtreme Programming
9. Pair Programming: Todo o código deve ser
produzido por duas pessoas utilizando o mesmo
computador. Enquanto um dos parceiros se preocupa
com detalhes da implementa₤₧o, ficando responsável
pela digita₤₧o do código, o outro deve tentar ter uma
vis₧o mais ampla da rotina, revisando o código.
Duas pessoas conseguem pensar em um número
maior de testes automatizados, existe uma troca de
experi₨ncias fazendo um nivelamento da equipe e
garante que todos os membros da equipe já tenham
trabalhado em todos os módulos dos sistema.
Práticas
eXtreme Programming
10. Small Releases: Com pequenas releases ₫ possível
existir um feedback constante do cliente, conseguindo
dados para o Planning Game. Assim ₫ possível
ajustar o desenvolvimento às necessidades que v₧o
surgindo no decorrer do processo.
Geralmente trabalha-se com releases mais
curtas, já que quanto menor o tempo entre cada
vers₧o, mais facil fica corrigir eventuais problemas.
Práticas
eXtreme Programming
11. Coding Standards: Para que todos possam ter
acesso a qualquer parte do código e que as pessoas
possam trabalhar em pares, ₫ importante que os
desenvolvedores sigam um padr₧o de
desenvolvimento. O ideal ₫ que, com o passar do
tempo, algu₫m que olhe o código n₧o saiba dizer por
quem o mesmo foi escrito. Assim fica mais fácil
conseguir um código simples, e muito mais ágil o
processo no caso da necessidade de um Refactoring
Práticas
eXtreme Programming
12. 40 Hour Week: Trabalhar por longos períodos ₫
contraproducente. Um programador cansado coloca
mais erros no código e o tempo ganho em uma noite
de hora extra muitas vezes ₫ perdido no dia seguinte,
procurando por um bug dentro de uma rotina. O
número 40 ₫ apenas uma sugest₧o, cada pessoa tem
sua própria capacidade de trabalho, este tempo
poderia ser de 35 ou 45 hora.
Variáveis
eXtreme Programming
Na Extreme Programming, s₧o consideradas
quatro variáveis que est₧o presentes no
desenvolvimento de um projeto: custo, tempo,
qualidade e escopo.
Se o cliente decide, por exemplo, em ter um
projeto com o menor custo, no menor prazo e com a
qualidade máxima, a quarta variável, neste caso
escopo, deve ser definida de acordo pela equipe de
desenvolvimento, ficando neste exemplo bastante
prejudicada.
Variáveis
eXtreme Programming
Custo: poucos recursos para um projeto podem
trazer s₫rios prejuízos para as demais variáveis, pois
com um or₤amento muito apertado normalmente
n₧o se consegue contar com a equipe que se gostaria,
e isto pode trazer problemas para a efetiva resolu₤₧o
do problema do cliente.
Tempo: um prazo maior para a entrega final do
sistema aumenta a qualidade e o escopo do mesmo,
dentro de um limite. Por outro lado, caso o prazo seja
muito pequeno, prejudica-se o escopo da aplica₤₧o.
Variáveis
eXtreme Programming
Qualidade: Pode-se ter ganhos pequenos (dias ou
semanas) se sacrificando a qualidade em alguns
pontos do projeto, como por exemplo definindo-se um
número menor de unit tests para uma classe.
Contudo, mas este ganho tende a desaparecer na
medida em que a baixa qualidade pode causar
problemas que tomar₧o tempo para serem
corrigidos.
Escopo: um escopo menor pode melhorar a
qualidade, pois se tem menos tarefas para serem
desenvolvidas, e tamb₫m reduz o prazo e o custo.
Variáveis
eXtreme Programming
As variáveis custo e tempo normalmente s₧o
decis₧o do cliente, pois ₫ dele a decis₧o sobre
quando precisa do sistema implementado e qual o
valor que está disposto a pagar por isto. A variável
qualidade n₧o deve ser sacrificada. Portanto,
normalmente a variável sobre a qual a equipe de
desenvolvimento acaba tendo o controle ₫ sobre o
escopo.
M₫tricas
eXtreme Programming
O Release Plan ₫ o plano de desenvolvimento
gerado a partir das sessões de planning game. Neste
plano est₧o definidas quais as stories far₧o parte de
cada itera₤₧o dentro da release, qual o
desenvolvedor responsável por cada story e a
estimativa de prazo.
Um termo importante dentro do planejamento
de projetos XP ₫ velocity. A velocity ₫ a rela₤₧o entre
funcionalidades entregues e as funcionalidades
planejadas por cada desenvolvedor e deve ser medida
a cada itera₤₧o.
M₫tricas
eXtreme Programming
Toda metodologia de desenvolvimento deve fornecer
ao seu gerente condi₤ões para avaliar o andamento do
projeto, atrav₫s de medi₤ões de qualidade (tanto do
produto quanto do processo de desenvolvimento) e
prazos. Estas medi₤ões s₧o conhecidas no
desenvolvimento de sistemas como m₫tricas. As
m₫tricas mais importantes na XP s₧o:
Velocity: Número de funcionalidades entregues
comparado ao número de funcionalidades
prometidas.
40 Hour Week: Quantidade de horas
trabalhadas por semana por desenvolvedor.
M₫tricas
eXtreme Programming
Test Coverage of the Code: Quantidade de Unit
Tests por classe, tamb₫m ₫ uma m₫trica de qualidade
interna de trabalho, pois serve para medir o qu₧o
testado está um sistema.
Acceptance Test Coverage: Quantidade de testes
de aceita₤₧o do projeto como um todo.
Acceptance Test Pass: Percentual de testes de
aceita₤₧o aprovados para cada itera₤₧o enviada,
em rela₤₧o ao total de testes de aceita₤₧o da
mesma.
Relative Bug Density: Quantidade de erros
encontrados pelo usuário para cada classe
multiplicado pelo tempo que cada um levou para ser
M₫tricas
eXtreme Programming
Estas m₫tricas s₧o possíveis gra₤as ao caráter
dinâmico da XP, onde o cliente pode fornecer
feedback sobre o desenvolvimento durante o mesmo,
e n₧o apenas após ter o produto final em suas m₧os.
Por este aspecto, e tamb₫m por suas características de
ser fortemente baseado em testes, tanto unitários
quanto de aceita₤₧o, que a ger₨ncia de projetos em
XP difere tanto da ger₨ncia tradicional.
Casos bem sucedidos
eXtreme Programming
Algumas empresas que utilizam eXtreme
Programming:
Brasil
Empresa
Objective Solutions
Improve It
BrasilTelecom
Embrapa Informática
Agropecuária
Qualiti
Secretaria da Fazenda do
Estado de São Paulo
CETIP
A&L Software
Argonavis
SoftSite Tecnologia
Cidade
São Paulo, SP e Curitiba, PR
Rio de Janeiro, RJ
Brasília, DF
Campinas, SP
Site
www.objective.com.br
www.improveit.com.br
www.brasiltelecom.com.br
www.cnptia.embrapa.br
Recife, PE
São Paulo, SP
www.qualiti.com.br
www.fazenda.sp.gov.br
Rio de Janeiro, RJ
Campinas, SP
São Paulo, SP
Fortaleza, Ceará
www.cetip.com.br
www.alsoftware.com.br
www.argonavis.com.br
www.softsite.com.br
Casos bem sucedidos
eXtreme Programming
Estados Unidos
Empresa
Industrial Logic, Inc.
ThoughtWorks, Inc.
RoleModel Software, Inc.
Monster Consulting, Inc.
Object Mentor, Inc.
Trilogy
Symantec, Inc.
Motorola, Inc.
CC Pace Systems
Kuvera Enterprise Solutions, Inc.
Escrow.com
Thinkspark
IONA Technologies
Verio, Inc.
Net Objectives, Inc.
e-automate Corporation
TRW, Inc.
Sabre
Quest Software
Fidelity Investiments
Jera Design
LearningPatterns.com, Inc.
Trivera Technologies
Twin Bridge Consulting
Poppendieck.LLC
BoldTech Systems
Bespoke Technologies
Virtuas
Cidade
Berkeley, CA
Chicago
Holly Springs, NC
Bountiful, Utah
Vernon Hills, IL
Austin, Texas
Beaverton, OR
Arlington Heights, IL
Fairfax, VA
Boulder, CO
Santa Ana, CA
Dallas, Texas
Waltham, MA
Orem, UT
Issaquah, WA
American Fork, UT
Aurora, Colorado
Southlake, Texas
Irvine, CA
Cincinnati, OH
San Francisco, CA
New York, NY
Medford Lakes, NJ
Skokie, IL
Eden Prairie, MN
Denver, CO
Denver, CO
Englewood, CO
Site
www.industriallogic.com
www.thoughtworks.com
www.rolemodelsoft.com
www.monsterconsulting.com
www.objectmentor.com
www.trilogy.com
www.symantec.com
www.motorola.com
www.www.ccpace.com
www.kuvera.com
www.escrow.com
www.thinkspark.com
www.iona.com
www.verio.net
www.netobjectives.com
www.e-automate.com
www.trw.com
www.sabre.com
www.quest.com
www.fidelity.com
www.jera.com
www.learningpatterns.com
www.triveratech.com
www.twinbridgeconsulting.com
www.poppendieck.com
www.boldtech.com
www.bespoketechnologies.com
www.virtuas.com
Casos bem sucedidos
eXtreme Programming
América Latina
Empresa
RMyA
Primal Forces
Walicxe
Inglaterra
Empresa
Secure Trading
Workshare Technology
Connextra
ThoughtWorks Ltd.
LogicaCMG
eXoftware
Cidade
Buenos Aires
Buenos Aires
Montevideo
País
Argentina
Argentina
Uruguai
Cidade
Bangor
Londres
Londres
Londres
Londres
Londres
Alemanha
Empresa
OFFIS
Siemens AG
DaimlerChrysler AG
Daedalos Consulting
Córtex Brainware
Agile Software & Consulting GmbH
fumiX IT Consulting GmbH
Site
www.rmya.com.ar
www.132.com.ar
www.walicxe.com
Site
www.securetrading.com
www.workshare.com
www.connextra.com
www.uk.thoughtworks.com
www.logicacmg.com
www.exoftware.com
Cidade
Oldenburg
Munique
Stuttgart
Witten
Pullach im Isartal
Hahnstätten
Heidelberg
Site
www.offis.de
www.siemens.de
www.daimlerchrysler.de/
www.daedalos.de
www.cortex-brainware.de
www.agile-gmbh.de
www.fumix.de
Casos bem sucedidos
eXtreme Programming
Canadá
Empresa
ClearStream Consulting Inc.
Red Hook Group Red Hook Group
Mayford Technologies
Saorsa Development Inc.
Agile Logic
Software Productivity Center, Inc.
Europa
Empresa
Lesire Software Engineering
Europeloan Bank
Alcatel R&I
Tryx bvba
TietoEnator Consulting
Banca IMI S.p.A.
eXoftware
Software Improvement
Group
Daedalos
Mandrillo Consulting
Lysholdt Consulting A/S
ISB
Invest Valley.com
Cidade
Calgary
Toronto
Almonte
Nova Scotia
Fullerton
Vancouver
Cidade
Leuven
Bruxelas
Antuérpia
Marcoussis
Mechelen
Oslo
Milão
Dublin
Holanda
Zurique
Johanneshov
Solrød Strand
Barcelona
Saint-Priest
Site
www.clearstream.com
www.redhookgroup.com
www.mayford.ca
www.saorsa.com
www.agilelogic.com
www.spc.ca
País
Bélgica
Bélgica
Bélgica
França
Bélgica
Noruega
Itália
Irlanda
Amsterda
m
Suíça
Suécia
Dinamarca
Espanha
França
Site
www.lesire.com
www.europeloan.com
www.alcatel.be
www.alcatel.fr
www.tryx.com
www.tietoenator.com
www.bancaimi.it
www.exoftware.com
www.software-improvers.com/
www.daedalos.com
www.mandrillo.se
www.lysholdt-consulting.com
www.isb.es
www.invest-valley.com
Programas que utilizam
eXtreme Programming
Iterate: ₫ uma ferramenta comercial desenvolvida
pela empresa Diamond Sky e foca exclusivamente
no controle das user stories e no planning game.
http://www.diamond-sky.com/products/iterate
Programas que utilizam
eXtreme Programming
XpPlanit: ₫ uma ferramenta comercial on-line para
gerenciamento de projetos XP, tamb₫m baseada no
planejamento de itera₤ões e na medi₤₧o constante
da velocity, com a característica de ter um
repositório central de projetos que possam ser
acessados pelos membros da equipe pela Web.
http://www.xpplanit.com/
Programas que utilizam
eXtreme Programming
VersionOne: desenvolvido pela empresa
VersionOne, ₫ mais uma ferramenta comercial de
controle de itera₤ões baseada em user stories, que, a
exemplo das anteriores, tamb₫m gera estatísticas
sobre a medi₤₧o da velocity da equipe.
http://www.versionone.net/
Programas que utilizam
eXtreme Programming
Select Scope Manager: ₫ uma ferramenta comercial,
bastante completa, que permite o controle de itera₤ões e
releases, e tem como diferencial em rela₤₧o às
ferramentas anteriores a possibilidade de exportar dados
para o MS-project.
http://www.selectbs.com/products/scope.htm
Programas que utilizam
eXtreme Programming
XP Tracker Plugin: O XP Tracker Plugin ₫ um plugin para
a interface wik i, utilizada no desenvolvimento de páginas
web colaborativas. Na verdade n₧o ₫ uma ferramenta,
mas sim uma esp₫cie de linguagem de script para a
interface citada acima, que possibilita o controle de stories
e a medi₤₧o da velocity.
http://twiki.org/cgi-bin/view/Plugins/XpTrackerPlugin
Conclusões
eXtreme Programming
Como rela₤₧o às metodologias tradicionais,
consideradas muito pesadas para equipes pequenas, um
novo grupo de metodologias surgiu nos últimos anos. Elas
s₧o chamadas de metodologias ágeis, entre as quais a XP
se enquadra, e propõem uma diminui₤₧o na burocracia
do desenvolvimento de software.
Em um encontro em Utah, nos Estados Unidos, em
fevereiro de 2001, os principais autores das ent₧o
chamadas metodologias leves se encontraram para discutir
as semelhan₤as entre suas metodologias, e descobriram
que elas t₨m muito em comum. Nesta ocasi₧o foi criado
o termo metodologias ágeis, e foi escrito o "manifesto
ágil", que descreve as quatro principais diferen₤as entre as
Conclusões
eXtreme Programming
1) Indivíduos e itera₤ões ao inv₫s de processos e
ferramentas.
2) Software em funcionamento ao inv₫s de
documenta₤₧o compreensível.
3) Colabora₤₧o do cliente ao inv₫s de negocia₤₧o de
contrato.
4) Responder às mudan₤as ao inv₫s de seguir o plano.
Conclusões
eXtreme Programming
Sendo as duas principais diferen₤as entre as
metodologias ágeis e as tradicionais:
1) Elas s₧o adaptativas, ao inv₫s de previsivas: as metodologias
tradicionais tentam planejar uma grande parte do software em
muitos detalhes com bastante anteced₨ncia. Por isto elas s₧o
resistentes à mudan₤a. Já nas metodologias ágeis, as mudan₤as de
requisitos durante o desenvolvimento s₧o bem-vindas. Elas tendem
a ajustar o desenvolvimento do software às mudan₤as de requisitos,
sendo mais flexíveis neste ponto.
2) Elas s₧o orientadas às pessoas, n₧o aos processos: a meta das
metodologias de desenvolvimento ₫ desenvolver um processo que
vai funcionar da mesma maneira, independente de quem o esteja
utilizando. Metodologias ágeis levam mais em conta a habilidade da
Conclusões
eXtreme Programming
As metodologias ágeis s₧o hoje uma realidade, uma
vez que est₧o ficando cada vez mais populares entre os
desenvolvedores. Estas metodologias t₨m em comum um
foco maior na comunica₤₧o e na codifica₤₧o, ao inv₫s
de focar no processo, como as metodologias tradicionais.
Uma destas metodologias ₫ a Extreme Programming,
baseada em um conjunto de t₫cnicas e valores rígidos, que
devem ser observados durante todo o ciclo de vida do
desenvolvimento. A XP, por seu caráter informal, gera
pouca documenta₤₧o e prega que qualquer t₫cnica de
ger₨ncia de projetos que for empregada deve ser o menos
burocrática possível, pois o foco da equipe de
desenvolvimento deve se a produ₤₧o do software.
Conclusões
eXtreme Programming
A ger₨ncia de projetos XP, ent₧o, deve ser o mais
"leve" possível, n₧o gerando documenta₤₧o
desnecessária e n₧o pertinente ao desenvolvimento. Para
tanto, as t₫cnicas de ger₨ncia de projetos aplicadas a esta
metodologia devem seguir as características da mesma,
como o uso de user stories, o planejamento de releases e o
acompanhamento das tarefas dos desenvolvedores. Por
outro lado, ₫ necessário aos administradores do negócio
um acompanhamento da rentabilidade dos projetos,
característica que n₧o ₫ pertinente à metodologia, mas
que pode ser obtida pelos mesmos lan₤amentos efetuados
para o tracking do projeto.
Conclusões
eXtreme Programming
Verificamos tamb₫m que o eXtreme Programming ₫
uma metodologia bastante promissora, que pode ser
bastante vantajosa se for bem utilizada. Encontramos uma
grande dificuldade em definir vantagens e desvantagens na
sua utiliza₤₧o, já que este assunto ₫ muito subjetivo.
Algumas consequencias da implementa₤₧o do eXtreme
Programming como a diminui₤₧o da documenta₤₧o e a
necessidade de mais pessoas nas equipes, podem ser vistas
como vantagens para algumas pessoas e como
desvantagens para outras, ent₧o tentamos nos manter
objetivos, e apenas explicar as consequencias da sua
utiliza₤₧o, e deixar o leitor decidir por si próprio se
considera cada consquencia uma vantagem ou uma
Bibliografia
eXtreme Programming
eXtreme Programming Refactored - The case against XP
Matt Stephens.
eXtreme Programming for Web Projects
Doug Wallace. IsobelRagget.
eXtreme Programming Applied - Playing to Win
Travis Griggs.
eXtreme Programming Explained
Kent Beck.
Questioning eXtreme Programming
Pete McBreen.
Extreme Programming
Vinicius Teles.