Programao Extrema (XP)

O mtodo Programao eXtrema (XP, do ingls eXtreming Programming) uma

proposta de desenvolvimento gil e iterativa. O mtodo XP prope um processo leve,
centrado no desenvolvimento iterativo e com a entrega constante de pequenas partes
da funcionalidade do software. As partes devem ser incrementadas e requerem a
melhoria constante do cdigo (re-trabalho).
A possibilidade de entrega rpida do cdigo um dos fatores de sucesso do XP. Isto
no entanto, apenas pode ser feito com o envolvimento constante do cliente que se
torna um membro ativo da equipe de desenvolvimento. Esta uma das caractersticas
importantes para o mtodo funcionar bem. No entanto, nem sempre o cliente est
disponvel para a participao ativa.
Uma das caractersticas importantes do XP que no existe um processo de design
tradicional com a elaborao de modelos da arquitetura do software. O sistema
concebido a partir de uma metfora e so descritos em estrias do usurio. Uma
metfora a transposio de uma conceitualizao do mundo real para o sistema a
ser desenvolvido. Por exemplo, os programas de correio eletrnico foram construdos
utilizando os conceitos de mensagem, caixa de entrada e caixa de sada. Cada
mensagem possui remetente, destinatrio, assunto e cpias carbono (cc). Este modelo
conceitual reflete a forma como correspondncias so enviadas nos escritrios e pelo
sistema de correio dos Estados Unidos. A metfora passa a ser fundamental para a
elaborao das estrias de usurios.
O uso de cartes CRC (Classes, Responsabilidades e Colaboraes) recomendado
de forma a permitir o design em equipe. Cartes CRC permitem a descrio dos
conceitos identificados na metfora na forma de classes. Responsabilidades so
identificadas para cada classe. As colaboraes determinam as interaes entre
classes. Os cartes permitem que o todo o time possa colaborar com design

Estrias de usurios
A elaborao de estrias de usurio uma das atividades fundamentais no XP. As
estrias de usurio descrevem cenrios com situaes de utilizao que os envolvidos
gostariam que o sistema em desenvolvimento viesse a oferecer. Elas deve devem ser
escritas pelos prprios usurios. As estrias de usurio so semelhantes aos casos de
uso da UML, mas no so a mesma coisa. A diferena que elas no se limitam a
descrever o processo de interao do usurio com o sistema.
No XP, as estrias de usurio ocupam o lugar dos longos documentos de requisitos
nos mtodos tradicionais. Cada estria deve ser um texto escrito com
aproximadamente 3 sentenas.
As estrias de usurio so a base para a criao de estimativas de tempo que sero
utilizadas nas reunies de planejamento de entregas (releases). O plano de entregas
direciona todo o planejamento do desenvolvimento e do plano de iteraes para cada
iterao individual. Cada estria deve levar de 2 a 3 semanas para ser implementada
em uma iterao individual. Se levar mais do que isso, a estria precisa ser dividida
em duas. Um nmero de 80 estrias aproximadamente suficiente para definir um

plano de entregas
As estrias de usurio so tambm a base para a elaborao dos testes de aceitao.
Um ou mais testes de aceitao automatizados deve ser criados para verificar se o
programa implementa a estria corretamente.
O envolvimento do usurio, portanto, como autor das estrias, fundamental para a
elaborao do plano de entregas e dos testes de aceitao em cada iterao de
desenvolvimento.
Prticas de programao:
O processo de programao tem como caractersticas a programao em pares e a
propriedade
coletiva do cdigo.

Na programao em pares, dois programadores ocupam um nico computador.

Embora, a princpio, isto possa ser visto como um desperdcio de esforos, vrias
vantagens podem ser obtidas. Esta estratgia aumenta a qualidade do cdigo e no
altera o tempo de entrega, uma vez que haver um ganho posterior nas etapas de
retirada de erros (defeitos). Os dois programadores atuam de forma colaborativa.
Enquanto o que est com o teclado e mouse est pensando diretamente na
codificao (sintaxe, variveis, fluxos de controle, etc.), o outro pode pensar
estrategicamente em como o cdigo ir interagir como outras partes do programa.
Alm disso, um atua com uma viso mais crtica corrigindo erros dos companheiros e
pode pensar nas futuras mudanas e etapas posteriores. Isto permite que a
tradicionalmente prtica do codifica-e-conserta, criticada nas origens do
desenvolvimento de software, possa ser realiza sem perda da qualidade do software.
A propriedade coletiva do cdigo outra caracterstica fundamental do mtodo XP,
com a rotatividade do cdigo entre os programadores e reunies freqentes para
estabilizar o cdigo. A propriedade coletiva encoraja o time todo a contribuir com novas
idias. Qualquer membro do time pode adicionar funcionalidade, corrigir erros ou refabricar o cdigo. No existe a figura do arquiteto chefe. Todos so responsveis pelo
cdigo inteiro. No existe algum para aprovar as mudanas. Reunies freqentes
devem ser definidas como parte do processo iterativo de programao. Estas reunies
devem ser
curtas e so realizadas com todos de p.

A prtica do codifica-e-conserta tambm requer um processo constante de teste de

unidade e integrao. Para isto funcionar bem, os desenvolvedores devem trabalhar
com uma ferramenta de testes automtico e um repositrio coletivo do cdigo fonte.
Os desenvolvedores devem criar testes de unidades e liberar o cdigo apenas quando
estiver 100% testado. Uma vez no repositrio, qualquer um pode fazer alteraes e
adicionar novas funcionalidades. Uma ferramenta de controle de verses
fundamental.

O re-trabalho ou re-fabricao uma atividade fundamental e necessria para o XP

funcionar. Mesmo que o cdigo esteja 100% testado, para viabilizar reuso, ele precisa
ser revisto para remover redundncias, retirar funcionalidades desnecessrias e
modificar arquitetura obsoletas. O re-trabalho do cdigo ao longo de todo o ciclo de
vida reduz o tempo total de entrega do cdigo e aumenta a qualidade do software
produzido
Regras e Prticas
Planejando
Estrias do usurio
Planejando liberaes (releases) e pequenas liberaes
Dividir projetos em iteraes (ciclos)
Medindo velocidade do projeto
Dinmica de pessoal
Reunies dirias em p
Projetando (designing)
Simplicidade (no adicione funcionalidades antes do tempo)
Metfora
Cartes CRC (Classes, Responsabilidades e Colaborao)
Re-fabricar (refactor)
Codificando
O cliente deve estar sempre disponvel.
Programao em pares.
Codificar de acordo com padres acordados.
Codificar testes de unidade primeiro.
Integrar com freqncia.
O cdigo propriedade coletiva.
No atrase.
Testando
Todo cdigo deve ter os testes de unidade.
Cada unidade deve ser testada antes de liberada.
Quando um erro encontrado, testes devem ser realizados.
Testes de aceitao devem ser freqentes.
A programao extrema tem sido bem sucedida em projetos pequenos com times
pequenos. Relatos mostram que para projetos grandes o mtodo XP no
recomendado.
Fonte:http://engenhariadesoftware.blogspot.com.br/2007/03/programao-extremaxp.html
Para saber mais, consulte www.extremeprogramming.org

Scrum, Desenvolvimento gil, Desenvolvimento de Software.

Introduo
A maioria dos projetos de software falha. As metodologias geis surgiram com a
proposta de desburocratizar o processo de desenvolvimento de software, permitindo
que as equipes sejam mais adaptveis, respondendo rapidamente s constantes
mudanas nos projetos de software.
Uma figura importante no desenvolvimento gil o SCRUM, uma metodologia para o
desenvolvimento gil de software.
Neste artigo iremos ver como o scrum funciona, e como pode ser usado para
gerenciar equipes pequenas de desenvolvimento de software, tornado o processo
mais gil e agregando valor aos produtos desenvolvidos.
Scrum
Scrum uma metodologia gil de Gerenciamento de Projetos. As metodologias geis
de desenvolvimento permitem responder rapidamente s mudanas, reduzindo o
impacto das mudanas nos projetos, permitindo inclusive mudanas tardias nos
requisitos ou mesmo no escopo do projeto. O cliente fica mais satisfeito, pois
constantemente h entrega de funcionalidades 100% desenvolvidas, e ele participa
ativamente no projeto, trazendo seu conhecimento sobre o prprio negcio.
O nome Scrum vem do jogo de rugby, esporte semelhante ao futebol, com bola oval e
jogado tambm com as mos.
No rugby, o scrum utilizado para reposio da bola, aps faltas ou penalidades. Oito
jogadores de cada equipe posicionam-se frente frente, formando um crculo. Um
jogador da equipe que no cometeu a infrao lana a bola no espao entre os
jogadores alinhados que tentam, com os ps, ganhar a bola para isso, a grupo deve
trabalhar em conjunto, como se fosse uma unidade.
A utilizao da palavra scrum associada ao desenvolvimento de produtos foi feita

primeira vez por Takeuchi e Nonaka, no livro The New Product Development Game
(Harvard Business Review, Janeiro-Fevereiro 1986), onde os autores defendem a idia
de que no desenvolvimento toda a equipe deve trabalhar como uma unidade para
atingir um objetivo comum, como no scrum do rugby.
Apesar de muito utilizado no desenvolvimento de software, o scrum foi criado para
gerenciamento de projetos de fabricao de automveis e produtos de consumo. Sua
popularizao no desenvolvimento de software ocorreu em 1995, aps a formalizao
de sua definio, feita por Ken Schwaber.
O scrum pode ser utilizado sempre que um grupo de pessoas precise trabalhar em
conjunto para atingir um objetivo comum, desde o gerenciamento de projetos de
software at tarefas do cotidiano, como organizar uma festa.
Ao contrrio de metodologias definidas (como o RUP), onde o processo de
desenvolvimento bem definido e repetvel, o scrum uma metodologia emprica, na
qual defendida a idia de que "problemas fundamentalmente empricos no podem
ser resolvidos com sucesso utilizando uma abordagem tradicional de controle"[WIKI
1].
[WIK1]: Wikipdia (Scrum)
A Rotina do Scrum
Os requisitos do projeto so organizados em uma lista de tarefas, chamada de product
backlog, em ordem decrescente de prioridade (itens mais importantes no topo). Essa
lista deve ser constantemente atualizada e repriorizada.
O scrum trabalha com desenvolvimento incremental, onde cada iterao chamada
de sprint. Os sprints so curtos, tendo durao de 30 dias. A equipe separa uma parte
do topo do backlog para o sprint, formando o sprint backlog (lista de tarefas do sprint).
A equipe tem autonomia para decidir como as tarefas sero implementadas, mas as
tarefas do sprint backlog no podem ser trocadas por outras do product backlog,
garantindo que os requisitos mais importantes sejam implementados primeiro e que a
equipe mantenha o foco durante o sprint. O sprint possui um objetivo claro e definido,
conhecido de toda a equipe.
comum que os requisitos do final do product backlog, com o tempo, percam sua
importncia e acabem removidos da lista.
Durante o sprint, a equipe tem curtas reunies dirias, sempre no mesmo horrio,
junto com o scrum master (vide Os Papis do Scrum abaixo), chamadas de scrums.
Nessas reunies discutido o andamento do trabalho, onde cada membro da equipe
responde s questes:
O que fiz desde ontem?
O que pretendo fazer at amanh? - Existe algum obstculo?
Sempre que surgir algum obstculo ao progresso do trabalho, tarefa do scrum
master (vide Os Papis do Scrum abaixo) remov-lo.
A sada do sprint um conjunto de funcionalidades 100% desenvolvidas, que sero
aprovadas pelo product owner e entregues ao cliente. Ao final de cada iterao, toda a
equipe participa de uma retrospectiva do sprint.
Aps a concluso do sprint, reinicia-se o ciclo, retirando-se a prxima fatia do product
backlog para o prximo sprint.
Os Papis do Scrum Os principais papis no scrum so:
Equipe: o grupo de pessoas que trabalha na construo do produto.
Product Owner (ou Dono do Projeto): representa a viso do negcio no projeto. Scrum Master: seria o lder da equipe, se esta no fosse auto-gerenciada.

A Equipe
A equipe o grupo de pessoas que trabalha no desenvolvimento do produto. Deve ser
pequena (normalmente de 5 a 9 pessoas), multi-disciplinar e trabalhar em conjunto,
como uma unidade. No h papis definidos na equipe, embora membros da equipe
possam ser especialistas em determinadas reas ou assuntos.
O cliente parte da equipe de desenvolvimento, tendo participao ativa no processo
de desenvolvimento. comum incluir um usurio na equipe de desenvolvimento para
representar o cliente.
No existe um coordenador ou lder de equipe, sendo esta auto-gerida. A equipe tem
total autonomia para gerir seu trabalho, incluindo distribuir e decidir como sero
realizadas as tarefas do sprint backlog. Isso pode parecer desorganizao primeira
vista, mas essa liberdade compensada pela responsabilidade, que da equipe como
um todo, distribuda igualmente entre todos os seus membros.
A equipe deve sempre manter o foco, trabalhando para atingir um objetivo comum,
bem definido e conhecido por todos.
A comunicao entre a equipe deve ser constante, para que ela possa trabalhar em
conjunto e atingir seu objetivo.
Product Owner
O product owner (dono do projeto, em portugus) representa a viso do negcio no
projeto, sendo responsvel pela definio e priorizao do product backlog. Na maioria
das vezes este papel atribudo ao prprio cliente, podendo tambm ser representado
por um analista de negcios ou sistemas, ou outra pessoa que conhea bem o
domnio do produto e as prioridades do negcio.
O product owner deve constantemente revisar o product backlog, redefinindo as
prioridades. Deve tambm revisar a sada de cada sprint, para aprovao das
funcionalidades desenvolvidas.
Scrum Master
O scrum master o correspondente mais prximo a um lder de equipe que temos no
scrum; no entanto, a equipe auto-gerida (a equipe o prprio lder). O scrum master
responsvel por remover obstculos ao trabalho, resolver conflitos e assegurar que a
equipe esteja seguindo as prticas de scrum, sendo s vezes visto como guia da
equipe; sua principal funo garantir que a equipe tenha as melhores condies de
para atingir o objetivo do sprint.
Concluso
O scrum uma metodologia gil de gerenciamento de projetos, que valoriza muito o
trabalho em equipe. recomendada para equipes pequenas; equipes grandes, para
adotar o scrum, devem ser dividas em sub-equipes menores, dividindo-se tambm o
projeto em sub projetos, um para cada equipe.
Como o cliente faz parte da equipe de desenvolvimento e define a prioridade dos
requisitos, aliado diviso destes em iteraes com objetivo bem definido e conhecido
por todos, a equipe trabalha focada num objetivo, gerando ganho de produtividade.
O scrum no fica restrito fase de desenvolvimento do software; na fase de
manuteno, os requisitos (novos requisitos ou alteraes nos requisitos existentes),
podem ser agrupados em um sprint backlog, ou diretamente num nico sprint,
conforme o tamanho das alteraes. Pode-se ainda encarar cada nova verso de
software como um projeto parte, usando o scrum em sua totalidade.
O fato da equipe ser auto-gerenciada exige alto grau de responsabilidade, organizao

e comprometimento por parte da equipe. Essa ausncia da figura do lder de equipe

pode
representar uma barreira para a adoo do scrum por parte das organizaes,
temendo o caos pela falta de coordenao.
Fonte: http://rafaelrgi.wordpress.com/2007/11/23/scrum-metodologia-para-odesenvolvimento-agil-de-software/
Referncias bibliogrficas
Dicas-L. Disponvel em http://www.dicas-l.com.br/brod/brod_20061031.php. Acesso em
01 de 11 de 2007
Scrum em 2 Minutos. Disponvel em
http://dojofloripa.wordpress.com/2007/02/07/scrum-em2-minutos/. Acesso em 29 de 10
de 2007.
Scrum in 5 Minutes. Disponvel em
http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf.
Acesso em 30 de 10 2007. Scrum with XP. Disponvel em
http://www.informit.com/articles/article.aspx?p=26057&rl=1. Acesso em 29 de 10 2007.
Wikipdia (Desenvolvimento gil de Software). Disponvel em
http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software. Acesso em 30
de 10 de 2007
Wikipdia (Rugby). Disponvel em http://pt.wikipedia.org/wiki/Rugby. Acesso em 26 de
10 de 2007
Wikipdia (Scrum). Disponvel em http://pt.wikipedia.org/wiki/Scrum. Acesso em 25 de
10 de 2007