SlideShare uma empresa Scribd logo
Carlos Henrique M. da Silva
carloshenrique.85@globo.com
eXtreme
Programming
Extreme Programming (XP) é uma metodologia de desenvolvimento
de software, nascida nos Estados Unidos ao final da década de 90.
Vem fazendo sucesso em diversos países, por ajudar a criar
sistemas de melhor qualidade, que são produzidos em menos
tempo e de forma mais econômica que o habitual. Tais objetivos
são alcançados através de um pequeno conjunto de valores e
práticas, que diferem substancialmente da forma tradicional de se
desenvolver software.
Estudos demonstram que a maioria dos projetos de software falha,
seja porque não cumprem o orçamento, ou não cumprem o
cronograma, ou as funcionalidades não atendem às necessidades
dos usuários ou porque todos estes fatores estão presentes em
conjunto.
VINÍCIUS MANHÃES TELES
eXtreme Programming - Conceito
eXtreme Programming - Introdução
Por que cerca de
80% a 90% dos
projetos de Software
fracassam?
eXtreme Programming - Introdução
Desenvolver software é uma atividade arriscada. Segundo as
estatísticas, os principais problemas são:
 Gastos que superam o orçamento;
 Consumo de tempo que supera o cronograma;
 Funcionalidades que não resolvem os problemas
dos usuários;
 Mudanças constantes podendo estar relacionadas
a requisitos, cronograma, equipe...
 Baixa qualidade dos sistemas desenvolvidos.
eXtreme Programming - Introdução
Há algumas décadas a indústria de software vem buscando técnicas
de desenvolvimento que possam reduzir os riscos dos projetos de
software e tornar essa atividade mais produtiva. Um marco neste
sentido é a criação da disciplina de Engenharia de Software em
1968. De lá para cá, inúmeras propostas foram feitas para melhorar
o desempenho dos projetos, começando pelo processo de
desenvolvimento linear e seqüencial (em cascata) até chegar aos
atuais processos ágeis de desenvolvimento.
O XP é um dos representantes destes processos e foi criado por Kent
Beck em 1997 em um projeto para a Chrysler (fabricante de veículos
norte-americana). O XP é composto por um conjunto reduzido de
práticas de desenvolvimento que se organizam em torno de valores
básicos. Essas práticas possuem fortes inter-relacionamentos
formando um conjunto de elevada sinergia.
eXtreme Programming - Introdução
Desenvolvimento de SW no passado
 Processos Tradicionais
Analisar, projetar e só depois iniciar codificação
 Prever o futuro
Ter certeza do que se sabe hoje será exatamente o que se quer
amanhã
 Temores
Mudança de requisitos depois de concluída a fase de análise e
projeto
Custo
Análise Projeto Codificação Testes
Tempo
eXtreme Programming - Introdução
Desenvolvimento de SW hoje
 Processos modernos incentivam pequenas iterações
Mudanças em etapas posteriores se tornam mais baratas
 Adotar a mudança
- A Engenharia de SW é diferente das outras engenharias
- Componentes, frameworks, BDs podem absorver o alto custo da
mudança
eXtreme Programming - Introdução
A crise do software
 Em média, os atrasos representaram 63% mais tempo do que o estimado;
 Os projetos que não cumpriram o orçamento custaram em média 45% mais;
 No geral, apenas 67% das funcionalidades prometidas foram efetivamente
entregues.
Resultado final de projetos de software (Standish Group,2000)
eXtreme Programming - Introdução
Utilização de Funcionalidades
eXtreme Programming - Introdução
Utilização de Funcionalidades
eXtreme Programming - Introdução
Desperdício Falha na comunicação
Falta de tempo
eXtreme Programming - Introdução
Manifesto Ágil
Estamos evidenciando maneiras melhores de desenvolver software fazendo-
o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho,
passamos a valorizar:
 Interação entre pessoas MAIS QUE processos e ferramentas;
 Software em funcionamento MAIS QUE documentação abrangente;
 Colaboração com o cliente MAIS QUE negociação de contratos;
 Responder a mudanças MAIS QUE seguir um plano.
“Ou seja, mesmo tendo valor os itens à direita, valorizamos
mais os itens à esquerda.”
Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn,
Ward Cunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arie
van Bennekum, Martin Fowler, James Grenning, Jim Highsmith,
Andrew Hunt, Brian Marick, Ken Schwaber, Jeff Shuterland, Dave
Thomas
Referência
eXtreme Programming
eXtreme Programming
Extreme Programming ou XP, é um processo de desenvolvimento de software voltado para:
 Projetos cujos requisitos são vagos e mudam com frequência;
 Desenvolvimento de sistemas orientados a objetos;
 Equipes pequenas, preferencialmente até 12 desenvolvedores;
 Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser
implementado logo no início do projeto e vai ganhando novas funcionalidades ao
longo do tempo.
VISÃO GERAL
O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximo
de valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno
de um conjunto de valores e prática que atuam de forma harmônica e coesa para assegurar
que o cliente sempre receba um alto retorno do investimento em software.
Valores do XP
 Comunicação
 Simplicidade
 Feedback
 Coragem
 Respeito
Práticas do XP
 Cliente Presente
 Jogo do Planejamento
 Stand Up Meeting
 Programação em Par
 Desenvolvimento Guiado pelos Testes
 Refactoring
 Código Coletivo
 Código Padronizado
 Design Simples
 Metáfora
 Ritmo Sustentável
 Integração Contínua
 Releases Curtos
eXtreme Programming
Valores do XP
eXtreme Programming
Comunicação
A comunicação entre o cliente e a equipe permite que todos os
detalhes do projeto sejam tratados com a atenção e a agilidade
que merecem.
O XP procura assegurar que a comunicação ocorra da forma
mais direta e eficaz possível. Sendo assim, ele busca aproximar
todos os envolvidos do projeto de modo que todos possam se
comunicar face-a-face ou da forma mais rica que for viável.
eXtreme Programming
Simplicidade
A comunicação, embora seja essencial, não é suficiente para
garantir que o cliente possa aprender durante o projeto e gerar
feedback rapidamente. Também é necessário que a equipe
compreenda e utilize o valor da simplicidade, que nos ensina a
implementar apenas aquilo que é suficiente para atender a
cada necessidade do cliente. Ou seja, ao codificar uma
funcionalidade devemos nos preocupar apenas com os
problemas de hoje e deixar os problemas do futuro para o
futuro (NÃO DEVEMOS TENTAR PREVER O FUTURO), pois
raramente acertamos as previsões.
eXtreme Programming
Feedback
Quando o cliente aprende com o sistema que utiliza e re-avalia
as suas necessidades, ele gera feedback para a equipe de
desenvolvimento.
O feedback é o mecanismo fundamental que permite que o
cliente conduza o desenvolvimento diariamente e garanta que
a equipe direcione as suas atenções para aquilo que irá gerar
mais valor.
eXtreme Programming
Coragem
Existem temores que costumam assombrar os participantes de um projeto de software. Beck e
Fowler (2001) destacam alguns destes medos que exercem influência significativa nos
processos de desenvolvimento.
Desenvolvedores, por sua vez, temem:
 Ser solicitados a fazer mais do que sabem fazer;
 Ser ordenados a fazer coisas que não façam
sentido;
 Ficar defasados tecnicamente;
 Receber responsabilidades, sem autoridade;
 Não receber definições claras sobre o que precisa
ser feito;
 Sacrificar a qualidade em função de prazo;
 Ter que resolver problemas complicados sem
ajuda e
 Não ter tempo suficiente para fazer um bom
trabalho.
Clientes temem:
 Não obter o que pediram;
 Pedir a coisa errada;
 Pagar demais por muito pouco;
 Jamais ver um plano relevante;
 Não saber o que está acontecendo e
 Fixarem-se em suas primeiras
decisões e não serem capazes de reagir
a mudanças nos negócios.
eXtreme Programming
Respeito
eXtreme Programming
Todo mundo dá e se sente o respeito que merecem como um membro da equipe
valorizada. Todos contribuem valor mesmo que seja simplesmente entusiasmo.
Desenvolvedores respeitam a experiência dos clientes e vice-versa. Gestores
respeitam o direito de aceitar a responsabilidade e receber autoridade sobre nosso
próprio trabalho.
Respeito é um valor que dá sustentação a todos os demais. Membros de uma
equipe só irão se preocupar em comunicar-se melhor, por exemplo, se se
importarem uns com os outros. Respeito é o mais básico de todos os valores. Se ele
não existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, saber
compreender e respeitar o ponto de vista do outro é essencial para que um projeto
de software seja bem sucedido.
eXtreme Programming
eXtreme Programming
Equipe (Whole Team)
Equipe XP = Cliente + Time de Desenvolvimento
Os papéis do time de desenvolvimento
englobam:
• Desenvolvedores
• Testadores
(ajudam o cliente com os testes de aceitação)
• Analistas/projetistas
(ajudam o cliente a definir requisitos)
• Gerente (garante os recursos necessários)
• Coach
(orienta a equipe, controlando a aplicação do XP)
• Tracker (coleta as métricas do projeto)
As funções do cliente englobam:
• Definição dos requisitos do
projeto
• Definição de prioridades
• Controle do rumo do projeto
• Definir os testes de aceitação
do Software
eXtreme Programming
Jogo de Planejamento
(Planning Game)
 Principais definições
• Estimativas de cada tarefa
• Prioridades (tarefas + importantes)
 Próximos passos
• Planejamento de release
(cliente propõe as funcionalidades e desenvolvedores avaliam)
• Planejamento da iteração
(define as funcionalidades da iteração e os desenvolvedores estimam)
 Ótimo feedback para o cliente, que dirige o projeto
• Ideia clara do avanço do projeto
• Clareza: Redução de Riscos, aumentando a chance de sucesso
eXtreme Programming
Pequenos Lançamentos
(Small Releases)
 Disponibiliza a cada iteração Software 100% funcional
• Versão
• Redução (se o projeto terminar, parte existe e funciona)
• Detecção prévia de problemas
• Comunicação entre cliente e desenvolvedor
 Cada lançamento possui funcionalidades prioritárias para a iteração
 Lançamento pode ser destinado a
• Usuário/cliente (testa, avalia e oferece feedback)
• Usuário/final (sempre que possível)
 Design simples e integração contínua são práticas essenciais
eXtreme Programming
Testes de Aceitação
(Customer Tests)
 São elaborados pelo cliente em conjunto com analistas e testadores
• São automatizados
• Quando rodarem com sucesso, funcionalidade foi implementada
• Devem ser rodados a cada iteração
 Ótimo feedback para o cliente
• Pode se saber, a qualquer momento, o percentual de implementação do
Software e quanto falta
eXtreme Programming
Projetos Simples (Simple Design)
 Projeto está presente em todas as etapas XP
• Projeto começa simples e se mantém assim através de testes de
refinamento de código (refactoring)
 Em XP, é levado ao extremo
• Não é Permitido qualquer funcionalidade adicional que não será usada na
iteração atual
 Implementação ideal é aquela que
• Passa por todos os testes
• Expressa as ideias definidas no planejamento
• Não contém código duplicado ou que “cheire”
 Prever o futuro é impossível e é “anti-XP”
eXtreme Programming
Programação em Pares
(Pair Programming)
 Software é desenvolvido em pares
• “2 cabeças juntas são melhores que 2 cabeças separadas”
• 1 piloto e 1 copiloto
• Papéis são alternados frequentemente
 Benefícios
•Melhor qualidade de código (refactoring e testes)
•Revisão constante do código
•Nivelamento da equipe
•Maior comunicação
 “Um” pelo preço de “Dois”
Pesquisas demonstram que duplas produzem código de melhor qualidade em
aproximadamente o mesmo tempo que programadores que trabalham
sozinhos
eXtreme Programming
Desenvolvimento Dirigido por
Testes (Test-driven Development)
eXtreme Programming
Refinamento de código
(Refactoring)
http://www.refactoring.com/catalog/
eXtreme Programming
Integração Contínua
(Continuous Integration)
eXtreme Programming
Posse Coletiva
(Collective Ownership)
eXtremme Programming
Padrões de Codificação
(Coding Standards)
eXtremme Programming
Ritmo Saudável (Sustainable Pace)
eXtremme Programming
Metáfora (Metaphor)
eXtremme Programming
Reuniões em Pé (Stand-up Meeting)
eXtremme Programming
Spikes de Planejamento
(Spike Solution)
eXtremme Programming
Como Implantar?
 Uma prática de cada vez
• Enfatize o problema mais importante
 Dificuldades culturais
• Deixar alguém mexer no seu código
• Trabalhar em pares
 Dificuldades devido a mudança de hábitos
• Manter as coisas simples (e não tentar prever o futuro escrevendo "design
flexível")
• Jogar fora código desnecessário
• Escrever testes antes de codificar
• Refatorar com frequência (vencer o medo)
eXtremme Programming
Quando Não Usar XP
 Equipes grandes e espalhadas geograficamente
• Comunicação é um valor fundamental do XP
• Não é fácil garantir o nível de comunicação requerido em projetos XP em
grandes equipes
 Situações onde não se tem controle sobre o código
• Código legado que não pode ser modificado
 Situações onde o feedback é demorado
• Compile-link-build-test que leva 24 horas
• Testes muito difíceis, arriscados e que levam tempo
• Programadores espalhados em ambientes físicos distantes e sem
comunicação eficiente
eXtreme Programming
Características da Equipe
Uma equipe que utilize o XP normalmente é composta por pessoas
que representam os seguintes papéis:
 Gerente de Projeto
 Coach
 Analista de Teste
 Redator Técnico
 Desenvolvedor
eXtreme Programming
Gerente de Projeto
O gerente de projeto é responsável
pelos assuntos administrativos do
projeto. Ele procura liberar a equipe de
questões que não estejam diretamente
ligadas à atividade diária de
desenvolvimento. Além disso, administra
o relacionamento com o cliente
assegurando que o mesmo participe
ativamente do desenvolvimento e
forneça as informações essenciais para
que a equipe possa implementar o
sistema desejado.
eXtreme Programming
Coach
O coach é o profissional técnico do
projeto. O XP recomenda que um
profissional tecnicamente bem
preparado seja destacado para orientar a
equipe de modo que ela siga as boas
práticas recomendadas pelo XP. Embora
também possa atuar na implementação
do sistema, sua tarefa principal é
assegurar o bom funcionamento do
processo e buscar formas de melhorá-lo
continuamente.
eXtreme Programming
Analista de Testes
O analista de teste é responsável por
ajudar o cliente a escrever os testes de
aceitação. Quando estes testes não são
automatizados, o analista de teste deve
fazer com que eles sejam executados
diversas vezes ao longo das iterações do
projeto. Ele procura fazer com que os
eventuais defeitos do sistema sejam
identificados tão logo apareçam. Desta
forma, fornece feedback para a equipe
rapidamente, de modo que ela possa
fazer as correções com rapidez e evitar
que os problemas se propaguem.
eXtreme Programming
Redator Técnico
O redator técnico ajuda a equipe
de desenvolvimento a
documentar o sistema. A sua
presença permite que os
desenvolvedores se concentrem
prioritariamente na
implementação do software.
Embora eles possam continuar
fazendo algumas documentações,
o redator técnico é quem faz a
maior parte do trabalho de
documentação.
eXtreme Programming
Desenvolvedor
O desenvolvedor é a pessoa que analisa,
projeta e codifica o sistema. Em suma, é
a pessoa que efetivamente constrói o
software. Dentro do XP, não existem
divisões entre analista, projetista,
programador, etc. Cada desenvolvedor
exerce estes diferentes papéis em
diversos momentos do projeto.
eXtreme Programming
Desafios de Desenvolvimento de
Software
Modelo em Cascata
eXtreme Programming
 Análise: a equipe faz o levantamento de requisitos e busca compreendê-lo
detalhadamente
 Design: com base na análise a equipe projeta a arquitetura do sistema
 Implementação: a equipe se baseia na arquitetura e na análise para
implementar as diversas partes do software
 Teste: para verificar se o sistema atende às necessidades especificadas
pelo usuário, a equipe testa o software e faz as correções necessárias
 Implantação: o sistema é colocado em produção e os usuários finais
passam a utilizá-lo
 Manutenção: até o fim da sua vida, o software poderá sofrer alterações
por diversas razões, tais como correção e inclusão de novas funcionalidades
Desafios de Desenvolvimento de
Software
eXtreme Programming
Desenvolvimento Ágil
O termo “desenvolvimento ágil”, faz
referência ao desenvolvimento
iterativo, em espiral. Ele recomenda
que todas as fases descritas no
modelo em cascata sejam executadas
diversas vezes ao longo do projeto,
produzindo ciclos que se repetem ao
longo de todo o desenvolvimento.
Cada ciclo (da análise à
implementação) recebe o nome de
iteração. No desenvolvimento iterativo,
o software cresce a cada iteração, isto
é, o resultado de cada iteração é um
software pronto, testado e aprovado,
sendo que a primeira contém poucas
funcionalidades, enquanto a última
contém todas as funcionalidades do
sistema.
eXtreme Programming
Cliente Presente
Introdução
Tradicionalmente, quando pensamos no desenvolvimento de
software, delegamos ao cliente a tarefa de manifestar as suas
necessidades e à equipe de desenvolvimento a de implementar. Ou
seja, há uma divisão implícita entre as responsabilidades de cada
parte e um certo distanciamento entre elas.
eXtreme Programming
O XP trabalha com uma visão diferente
O XP sugere que o cliente esteja
presente durante o dia-a-dia do
projeto. A sua participação
contribui para o sucesso do
projeto, enquanto sua a sua
ausência é um sério fator de
risco.
A participação do cliente viabiliza
a simplicidade do processo. Além
disso, ela permite que o projeto
seja conduzido através de uma
série de pequenos ajustes e não
através de mudanças bruscas ao
longo do caminho.
eXtreme Programming
Estórias
As funcionalidades do sistemas são descritas brevemente em
cartões e recebem o nome de estórias. Estas estórias nada mais são
do que um convite ao diálogo. Sendo assim, quando os
desenvolvedores decidem começar a implementar uma determinada
estória, eles precisam dialogar com o cliente para entendê-las
melhor. Essa é uma das razões pelas quais é essencial que o cliente
esteja presente no dia-a-dia do desenvolvimento.
eXtreme Programming
Dúvidas Durante a Implementação
Enquanto os desenvolvedores se aprofundam na
modelagem da nova funcionalidade e começam a
implementá-la, dúvidas podem surgir. Mais uma vez, a
presença do cliente permite que as dúvidas sejam
respondidas rapidamente. Isso contribui com a agilidade
do processo e evita o trabalho especulativo.
eXtreme Programming
O Trabalho Especulativo
O trabalho especulativo, que ocorre quando a equipe não consegue
ter as dúvidas respondidas e assume premissas, representa um
enorme risco de retrabalho negativo. Assumindo premissas, a
equipe pode vir a construir partes da funcionalidades de forma
completamente incorreta, o que poderia ter sido evitado se o cliente
estivesse presente para responder às dúvidas.
eXtreme Programming
Confiança: um sub-produto da presença do
cliente
Além do feedback entre cliente e equipe de desenvolvimento, a
participação do cliente no desenvolvimento também contribui para
melhorar o relacionamento de ambas as partes. A aproximação
aumenta a confiança de todos os envolvidos.
É preciso notar que serviço é um produto intangível, como o próprio
software. Normalmente, temos mais facilidade em medir o valor de
algo que é concreto, que podemos ver, tocar, manipular. Ou seja,
normalmente, é mais fácil medir o valor de um carro, por exemplo,
que o valor de um serviço.
eXtreme Programming
Para a equipe de desenvolvimento, a aproximação do
cliente permite que muitas dúvidas sejam respondidas.
Além disso, com o cliente próximo, a equipe pode
apontar questões que tenham passados desapercebidas
aos olhos dele. Desta forma, a equipe pode preveni-lo de
situações incorretas.
Aproximação da equipe com o cliente
eXtreme Programming
 Por que é difícil ter o cliente presente?
 A sala de guerra (war room) com o cliente presente
 A sala de guerra com o cliente ausente
 A sala de guerra em outro prédio
 O que acontece com os projetos quando o cliente não está
presente?
Questionamentos importantes Equipe X Cliente
eXtreme Programming
O Jogo do Planejamento
O XP utiliza o planejamento para assegurar que a equipe de
desenvolvimento esteja sempre trabalhando naquilo que irá gerar
mais valor para o cliente a cada dia de trabalho. Este planejamento é
feito diversas vezes ao longo do projeto, para que todos tenham a
oportunidade de revisar as prioridades (Beck e Fowler, 2001).
 Dividindo as Responsabilidades
 Escrevendo Estórias
 Estimando Estórias
 Planejando os Releases
 Planejando as Iterações
 Encerrando uma Iteração
 Encerrando um Release
eXtreme Programming
Dividindo as Responsabilidades
A chave para gestão de um projeto de software é o equilíbrio de
poderes entre o cliente e a equipe de desenvolvimento. Por esta
razão, o XP procura separar claramente o papel de cada um, para
assegurar que o cliente tome todas as decisões de negócio, enquanto
a equipe de desenvolvimento cuida das decisões técnicas. (Beck e
Fowler, 2001). Isso dá origem a declaração de direitos do cliente e do
desenvolvedor (Jeffries et al., 2001).
eXtreme Programming
Direitos do Cliente
 Receber um plano geral para que saiba o que poderá ser feito, quando e
com que custo;
 Receber o máximo de valor de cada semana de trabalho da equipe de
desenvolvimento;
 Acompanhar o progresso do projeto através de um sistema executável,
que demonstra estar correto por passar nos testes que você especifica;
 Mudar de ideia, substituir funcionalidades e alterar prioridades sem ter
que pagar um preço exorbitante;
 Ser informado sobre mudanças no cronograma a tempo de decidir como
reduzir o escopo para ser capaz de manter a data original;
 Cancelar o projeto a qualquer momento e receber um sistema executável
que reflete todo o investimento que foi feito até a data do cancelamento.
eXtreme Programming
Direitos do Desenvolvedor
 Saber quais são as necessidades, bem como suas prioridades;
 Produzir um trabalho de alta qualidade permanentemente;
 Pedir e receber ajuda de seus colegas e do cliente;
 Gerar e atualizar as suas estimativas;
 Escolher as suas responsabilidades, ao invés delas serem determinadas
para você.
eXtreme Programming
Escrevendo Estórias
Todas as funcionalidades do sistema são levantadas através de estórias que
são registradas em pequenos cartões. Estas estórias devem ser escritas pelo
cliente, com suas próprias palavras.
eXtreme Programming
Escrevendo Estórias
Embora possa parecer estranho pedir ao cliente para escrever as
estórias, existem fortes razões para isso:
 O cliente é forçado a pensar melhor na funcionalidade;
 O cliente se torna responsável sobre aquilo que está sendo
solicitado;
 Fazer o cliente perceber que está gastando ao pedir uma
funcionalidade.
eXtreme Programming
Tarefas
A equipe de desenvolvimento utiliza os cartões para saber quais são
as funcionalidades desejadas pelo cliente. Os desenvolvedores
escolhem as estórias que irão implementar a cada dia de trabalho.
Entretanto, em projeto muito grande, os cartões podem acabar
representando estórias que consomem muito esforço para
implementar. Nestes casos, é comum a equipe dividir os cartões em
tarefas. Elas são registradas em novos cartões de modo que possam
ser distribuídas facilmente entre a equipe de desenvolvedores.
Exemplos:
1. Apresente ao cliente 10 tarifas mais
baratas para uma determinada rota;
2. O usuário deve poder alterar o seu perfil
(email, senha, primeiro nome, ultimo nome
e filiação). Dois campos de senha para
confirmação.
eXtreme Programming
Estimando Estórias
Para estimar a equipe de desenvolvimento precisa adotar uma
unidade de medida que será usada para todas as estórias.
Os desenvolvedores costumam estimar indicando a quantidade de
tempo (horas) que uma funcionalidade irá consumir.
O XP utiliza o conceito de dia ideal de desenvolvimento, que
representa um dia no qual o desenvolvedor trabalha na
implementação de funcionalidades, sem ter que se preocupar com
nenhuma atividade extra.
Usando pontos para estimar
Estimando por comparação
Estimando em equipe
eXtreme Programming
Planejando os Releases
O XP trabalha com o objetivo de gerar valor para o cliente ao longo
de todo o projeto. Para fazer isso, é importante que o software seja
entregue de forma incremental, de modo que após cada entrega o
cliente possa começar a utilizar o sistema e obter os benefícios que
ele oferece. Estas entregas recebem o nome de release em XP.
Os projetos em XP costumas ser divididos em releases, de modo que
cada release implementa um conjunto de funcionalidades que possui
um valor bem definido para o cliente. Por exemplo, imagine que o
projeto de oito meses seja dividido em quatro releases, como
ilustrado na figura abaixo.
8 sem.
Projeto dividido em releases
eXtreme Programming
Projeto Dividido em Releases
Suponha que este seja o projeto de um site de vendas on-line de
uma grande loja de departamentos. Poderíamos imaginar a seguinte
distribuição para os releases:
 R1: Consulta dos produtos em estoque;
 R2: Processamento de compras on-line;
 R3: Acompanhamento de pedidos;
 R4: Campanha de marketing de relacionamento.
Projetos XP procuram trabalhar com o conceito de releases
pequenos, isto é, os releases têm curta duração. Preferencialmente,
devem ter em torno de dois meses. Com isso, o cliente pode
começar a usufruir os benefícios do software e a equipe de
desenvolvimento passa a ter a oportunidade de receber feedback dos
usuários finais do sistema, o que permite que ela faça ajustes, de
modo a aprimorar a qualidade dos releases subsequentes.
eXtreme Programming
Priorizando as Estórias de Cada
Release
 As releases devem ter tamanhos fixos e pequenos
 Estabelecer a ordem (necessidades do cliente)
 Verificar a NECESSIDADE X ASPECTOS TÉCNICOS. Observar as
dependências técnicas
 Distribuir as estórias nos seus respectivos releases
 Não é necessário escrever todas as estórias do sistema no início
do projeto
 O cliente deve se concentrar nas estórias da primeira release (as
outras, deixar para o futuro para evitar trabalho especulativo)
 Dedicação nas estórias do release corrente e criar estórias para os
releases futuros
eXtreme Programming
Planejando as Iterações
Uma iteração é basicamente um pequeno espaço de tempo dedicado
para a implementação de um conjunto de estórias. Em sua maioria,
os projetos XP utilizam iterações de duas semanas.
O início de cada iteração é caracterizado por uma reunião que recebe
o nome de reunião de planejamento da iteração.
Tamanho da iteração = 2 semanas = 10 dias úteis
Deve-se descontar:
 1 dia útil para a reunião de planejamento de iteração
 1 dia útil para o encerramento da iteração
Dias úteis para desenvolvimento = 10 – 2 = 8
 Número de desenvolvedores = 4 = 2 x 2 = 2 pares
 1 par/dia = 1 ponto
 1 par em 8 dias = 1 x 8 = 8 pontos
 2 pares em 8 dias = 2 x 8 = 16 pontos
eXtreme Programming
Dependências Técnicas
A ordem em que o cliente deseja que as estórias sejam
implementadas é afetada por dependências técnicas que a equipe
deve identificar e lhe apresentar.
O XP recomenda que a equipe procure sempre respeitar a ordem
indicada pelo cliente. Na maioria dos casos isso é perfeitamente
possível, desde que a equipe implemente algumas simplificações.
As dependências técnicas costumam ser bem menos criticas do que
aparentam. Para contorná-las a equipe deve ser criativa e buscar
soluções que permitam ao cliente acesso às estórias tal como ele as
ordena.
Iterações são diferentes de releases: O XP apresenta um meio termo
que permite que o cliente tenha flexibilidade e a equipe trabalhe com
estabilidade. Durante todo o projeto, o cliente pode fazer alterações
nas estórias. Já dentro de uma iteração, e apenas neste caso, o
cliente tem que respeitar o acordo da reunião de planejamento.
eXtreme Programming
Encerrando uma Iteração
O último dia da iteração é reservado para uma reunião de
encerramento. Nela, o cliente executa todos os teste de aceitação
que foram escritos para as estórias da iteração.
O objetivo é que ele valide todo sistema e verifique se o resultado da
iteração está satisfatório.
Utilizando o sistema ele poderá detectar eventuais erros, bem como
aprender mais sobre os requisitos e, se houver necessidade, fazer
mudanças nos mesmos.
eXtreme Programming
Encerrando um Release
Um release se encerra ao final da ultima iteração prevista pra ele. Ao
final do release, a equipe coloca o sistema em produção para que
todos os usuários passem a ter acesso a ele.
Quanto mais entradas em produção o projeto tiver, melhor será o
seu resultado para os usuários, visto que a cada release eles terão a
oportunidade de fornecer feedback para a equipe de
desenvolvimento. Isso ajudará a equipe a direcionar seus esforços
pata fazer com que o sistema fique cada vez mais adequado às
necessidades de seus usuários.
eXtreme Programming
Stand up Meeting
Um dia de trabalho de uma equipe XP sempre começa com um stand up meeting. Este
nome significa “reunião em pé” em inglês. Esta reunião não tem apenas o objetivo de
avaliar o passado. Ela também é utilizada para decidir o que será feito no dia que se inicia.
Ela serve para priorizar as atividades dos membros da equipe ao longo do dia.
eXtreme Programming
Diariamente, no stand up meeting, a equipe decide em conjunto que
cartões serão tratados naquele dia e quem cuidará de cada cartão.
No fim do stand up meeting, cada membro da equipe sabe o que
deverá fazer ao longo do dia. É importante notar que a decisão sobre
o que fazer ao longo do dia não é tomada por uma única pessoa. Essa
decisão é tomada em equipe.
Stand up Meeting
eXtreme Programming
Programação em Par
Os desenvolvedores não trabalham sozinhos em um projeto que
utilize XP. Eles sempre trabalham em pares. Trata-se da programação
em par ou pair programming, como é conhecido em inglês.
eXtreme Programming
Os efeitos sobre a produtividade da equipe
A ideia da programação em par parece estranha a princípio porque
“enquanto um desenvolvedor o outro fica parado”. Isto é, “um
trabalha enquanto o outro não faz nada”. Obviamente não é isso o
que ocorre, mas é isso o que muita gente acaba interpretando
erroneamente.
Na verdade, um desenvolvedor digita enquanto o outro não digita.
Mas, ambos estão programando juntos. A programação em par
pressupõe uma comunicação contínua entre os desenvolvedores que
formam o par. Através da conversa, eles discutem as melhores
alternativas, corrigem erros, analisam cenários, enfim, discutem as
melhores ideias para a resolução de cada problema. Portanto, é
absolutamente incorreto acreditar que um trabalha enquanto o outro
fica parado. Ambos estão trabalhando o tempo todo.
eXtreme Programming
A pressão do Par
O ato de programar demanda grande concentração e produz um
gasto de energia considerável. Entretanto, no dia-a-dia de um
programador, ele se depara com diversas fontes de distração: email,
bate-papo com colegas, cansaço. Isto diminui seu ritmo de trabalho
no código.
A programação em par corrige estes desvios através da pressão em
par. O programador quando está acompanhado de outra pessoa, ele
deixa de ter um compromisso apenas consigo mesmo. O seu
compromisso se expande e passa a englobar também o seu colega.
Ou seja, sua responsabilidade aumenta já que passa a envolver mais
alguém. O efeito disso é que diversos focos de distração são
eliminados.
eXtreme Programming
Revezamento
A condução da programação é uma atividade que deve ser realizada
sempre por ambos os programadores que formam um par. Um de
cada vez, naturalmente. Para isso, é fundamental que eles se revezem
diversas vezes ao longo de um dia de trabalho.
O revezamento não se aplica apenas à questão de quem conduz o
teclado. Ele também nos leva à questão de quem será o nosso par.
Em um projeto, devemos trocar de par com frequência. Esta troca de
par é importante para a disseminação do conhecimento.
eXtreme Programming
Desafios
 A organização do escritório
 A visão gerencial
 O relacionamento humano
 Competição
eXtreme Programming
Refactoring
Desenvolvimento Guiado por
Testes (TDD)
eXtreme Programming
Refactoring – Conceitos básicos
Refactoring é o processo de modificar um software para melhorar a
estrutura interna do código.
Esse processo não repara erros e nem adiciona novas
funcionalidades.
Outra consequência é a melhora no entendimento do código, o que
facilita a manutenção e evita a inclusão de bugs. Esta melhora no
entendimento vem da constante alteração do código com objetivo de
facilitar a comunicação de motivações, intenções e objetivos por
parte do programador.
eXtreme Programming
 Obter um código-fonte claro e de fácil manutenção
 Reduzir a complexidade da aplicação
 Remover redundâncias desnecessárias
 Reutilizar código
 Otimizar o desempenho do software.
Objetivos Básicos
eXtreme Programming
Desenvolvimento Guiado pelos Testes (TDD)
Teste é parte do desenvolvimento de software que todo mundo sabe
que precisa ser feita, mas ninguem quer fazer.
Testar costuma ser considerado uma atividade chata, que consome
tempo e só é valorizada depois que o sistema entra em produção e
diversos problemas começam a surgir.
Grande parte dos projetos deixam os testes para serem feitos no final
(isso quando são feitos!)
eXtreme Programming
Por que Devemos Testar?
Se o desenvolvedor escreve um código incorreto e descobre isso dois
meses depois, a sua capacidade de aprendizado é muito baixa. Por
outro lado, se ele descobre alguns segundos após introduzir o erro,
ele aprende rapidamente que tipo de coisa ele fez que gera erro.
Sendo assim, ele provavelmente não errará de novo no futuro.
Quando os testes fazem parte do desenvolvimento, os
programadores recebem feedback rapidamente sobre aquilo que
estão fazendo. Com isso aprendem mais, resolvem os defeitos e tem
mais tempo para desenvolver funcionalidades e gerar valor para o
cliente.
eXtreme Programming
Testar é Investir
Quando testamos, estamos fazendo um investimento e esperamos
que ele gere um retorno no futuro. No caso de testes, este retorno
acontece quando:
• O desenvolvedor testa alguma coisa que deveria falhar e ela
simplesmente funciona.
• O teste falha quando já vinha funcionando normalmente, ou
seja, surgiu um defeito no sistema e o teste detectou.
eXtreme Programming
Testando o XP
O XP trabalha com dois tipos de testes: testes de unidade e testes de
aceitação.
Testes de unidade: é aquele realizado em cada classe do sistema para
verificar se os resultados gerados são corretos.
Testes de aceitação: São efetuados sobre cada funcionalidade, ou
estória do sistema.
eXtreme Programming
Testes de Unidade
 Devem ser automatizados
 100% deles devem rodar corretamente ao longo de todo o
desenvolvimento
Desafios
 Visto como aumento de trabalho pela equipe
 A programação em par
 Início difícil de trabalhar e automatizar
Fatores essenciais
 Conhecimento
 Ferramentas
 Programação em par
 Persistência
eXtreme Programming
Questões sobre os Testes de Unidade
 Testes com acesso a um BD?
 Testes rodando muito lentamente?
 E quando não consigo imaginar como testar uma classe?
 Como saber se testei tudo que podera quebrar?
 Código já escrito e não existem testes pra ele?
 Erros que aparecem da colaboração entre diferentes classes?
 GUIs?
 Meu código não pode ser testado porque…
 Testar a entrega
eXtreme Programming
Testes de Aceitação
Além de verificar se cada classe está funcionando corretamente, é
importante verificar se as classes englobadas por uma estória estão se
relacionando corretamente.
Quem cria e executa estes testes?
Cliente? Analista de testes? Os dois?
Testando em cada iteração
 Descrever os testes em cartões, depois juntem estes aos cartões
da estória.
 Um cartão só pode ser considerado finalizado quando o teste de
aceitação do mesmo for executado com sucesso.
Automatizando
HTML  HttpUnit
Java  Jbehave, Selenium WebDriver, …
Exemplo de Teste de Aceitação
Estória Visualizar os itens do carrinho de compras
Número Ação Resultado esperado
1
 Entrar no site
 Visualizar os itens do carrinho de compras
Mostra a mensagem: “Seu carrinho de
compras está vazio”
2
 Adicionar ao carrinho o produto: “Geladeira 380L”
 Visualizar os itens do carrinho de compras
Mostra uma linha contendo a
informação:
Geladeira 380L – 1 unidade – R$1500,00
3
 Adicionar ao carrinho o produto: “Fogão 4 bocas”
 Visualizar os itens do carrinho de compras
Mostra uma linha contendo a
informação:
Geladeira 380L – 1 unidade – R$1500,00
Fogão 4 bocas – 1 unidade – R$750,00
4
 Visualizar os itens do carrinho de compras
 Clicar em “Excluir” ao lado da linha que contém a
geladeira
Mostra uma linha contendo a
informação:
Fogão 4 bocas – 1 unidade – R$750,00
5
 Visualizar os itens do carrinho de compras
 Clicar em “Excluir” ao lado da linha que contém o fogão
Mostra a mensagem: “Seu carrinho de
compras está vazio”
eXtreme Programming
eXtreme Programming
Código Coletivo Padrões de
Codificação
eXtreme Programming
Código Coletivo
Quando um projeto é implementado por uma equipe, é comum
dividi-lo em partes, de modo que cada membro da equipe fique
responsável por uma ou mais partes. Desta forma, cada pessoa é
responsável por um subconjunto do código que forma o projeto.
A divisão do trabalho é uma prática comum em diversa áreas
profissionais. A forma como esta divisão é feita afeta diretamente o
resultado final de um projeto.
É bastante comum encontrarmos “ilhas de conhecimento” nos
projetos de software. Uma “ilha de conhecimento” pode ser
compreendida como sendo uma pessoa que possui um domínio
sobre uma área do projeto. Somente ela conhece aquela parte ou
aquele código. Se outra pessoa precisar mexer naquela parte, deverá
solicitar à ilha de conhecimento que entre em ação.
eXtreme Programming
A programação em par, por si só, já colabora para evitar a formação
de “ilhas de conhecimento”. Porém, o código coletivo vai além. Ele dá
a todas as pessoas a chance de mexer em qualquer parte do sistema.
É importante que ele seja sempre escrito da maneira mais legível
possível. Pois isto é o que garantirá que a equipe conseguirá
continuar a implementar o sistema.
Vale notar também que o código coletivo leva a equipe a ser mais
ágil no desenvolvimento. Como não existe um responsável por certa
parte do código, qualquer pessoa pode mexer nela tão logo sinta a
necessidade de fazê-lo. Não é necessário esperar por ninguém, não
é necessário esperar pelo especialista.
Código Coletivo
eXtreme Programming
Padrões de Codificação
Se você analisar o código de diferentes programadores,
provavelmente irá notar que existem diferenças de estilo. Por
exemplo, um programador prefere colocar { no final da declaração de
um método, enquanto outro prefere colocar na linha posterior.
O XP recomenda que a equipe adote um padrão no início do projeto.
Ela pode construir este padrão em conjunto ou pode adotar um que já
exista e esteja documentado em algum lugar, como por exemplo:
http://java.sun.com/docs/codeconv/html/CodeConventions.doc.html
eXtreme Programming
Padrões de Codificação
Procure adotar um padrão que seja fácil e simples. Isso evita
resistência e facilita a compreensão do código, ou seja, melhora a
comunicação.
Jeffries et al. (2001, p.79) apresenta alguns tópicos a considerar:
 Identação
 Letras maiúsculas e minúsculas
 Comentários (evitá-los tanto quanto possível)
 Nomes
eXtreme Programming
Design Simples
Metáfora
eXtreme Programming
Design Tradicional
“O custo de se corrigir um
problema em um software
cresce exponencialmente ao
longo do tempo. Um problema
que poderia ter custado um
dólar para ser corrigido se
tivesse sido encontrado durante
a análise pode custar milhares
de dólares para ser resolvido
depois que o software já estiver
em produção.”
eXtreme Programming
O custo de uma alteração no XP
A comunidade de desenvolvimento de software investiu uma enorme
quantidade de recursos nas últimas décadas no sentido de reduzir os
custos de uma alteração em um software. Estes investimentos gerou
diversos avanços:
 Melhores linguagens de programação
 Avanços na tecnologia de banco de dados
 Melhores práticas de programação
 Novos ambientes e ferramentas de desenvolvimento
 Computadores mais rápidos e mais baratos
 Orientação a objetos
eXtreme Programming
Infelizmente a única constante em um projeto de software é a
mudança:
 Os requisitos mudam
 O design muda
 A tecnologia muda
 A equipe muda
 Os membros da equipe mudam
O problema não está na mudança em si, porque ela vai acontecer de
qualquer jeito. O problema é a incapacidade de lidar com ela quando
ela chegar.
Design Tradicional
eXtreme Programming
Estratégia
Para alcançar um design simples, o XP recomenda que você utilize a
seguinte estratégia:
1. Comece escrevendo um teste.
2. Faça o design e implemente apenas o suficiente para passar
nos testes.
3. Execute os passos 1 e 2 novamente tanto quanto necessário.
4. Se você identificar a oportunidade de tornar o design mais
simples, faça isso.
No XP, o design é criado de forma incremental. Sendo assim, ao final
da primeira iteração, o seu software terá um design bastante simples,
suficiente para as funcionalidades daquela iteração. Na segunda, terá
que fazer alguns refactorings e fará alterações no design, de modo a
incorporar novas funcionalidades.
eXtreme Programming
Simplicidade
Exemplo de quatro regras básicas para definir simplicidade:
1. O sistema (código e testes em conjunto) deve expressar tudo
aquilo que você deseja comunicar
2. O sistema não deve conter nenhum código duplicado
3. O sistema deve ter o menor número de classes possível
4. O sistema deve ter o menor número de métodos possível
Atualmente, existe uma verdadeira febre pela utilização de
frameworks que possam facilitar o desenvolvimento de sistemas.
Tais frameworks contêm uma série de funcionalidades genéricas que
podem poupar esforço da equipe ao longo do desenvolvimento.
Entretanto, existem custos associados à utilização de frameworks:
curva de aprendizado e são abrangentes demais.
eXtreme Programming
Metáfora
Metáforas são usadas frequentemente durante o desenvolvimento de
sistemas, na medida em que os desenvolvedores criam elementos
dentro do computador para simular outros que existem
regularmente fora dele, no mundo físico.
eXtreme Programming
XP procura explorar ao máximo a utilização de metáforas, para que
clientes e desenvolvedores sejam capazes de estabelecer uma
vocabulário apropriado para o projeto, repleto de nomes
representando elementos físicos com os quais os clientes estejam
habituados em seu dia-a-dia, de modo a elevar a compreensão
mútua.
Metáfora
eXtreme Programming
Ritmo Sustentável
Integração Contínua
Releases Curtos
eXtreme Programming
Ritmo Sustentável
O XP PROÍBE que os desenvolvedores trabalhem até mais
tarde. O XP sugere um ritmo sustentável de 40 HORAS
SEMANAIS, respeitando assim a individualidade e o físico
de cada desenvolvedor. Desta forma a equipe estará
sempre concentrada e muito menos propensa a pequenas
falhas na implementação.
eXtreme Programming
Integração Contínua
O XP propõe uma integração contínua, se possível deve
ser efetuada diversas vezes ao dia para que toda a equipe
tenha conhecimento do código recém-desenvolvido. Com
esta prática o feedback sobre a alteração efetuada será
obtido em um menor espaço de tempo.
Dificuldades em integrar diversas vezes ao dia:
 Tempo de build
 Código Coletivo
 Programação em Par
eXtreme Programming
Integração Contínua
Segundo Jeffries et al. (2001), em XP o código avança em
3 fases:
 Local: As mudanças que o par executou no código
ainda não estão disponíveis para os demais.
 Candidato à Liberação: O par terminou a tarefa e está
tudo pornto para a disponibilização.
 Disponibilizado: Código pronto. Testes 100%.
eXtreme Programming
Integração Contínua
Ferramentas: Para que seja feita a integração contínua,
são necessárias ao menos duas categorias de
ferramentas para auxiliá-lo:
 Ferramenta de build – Ant ou Maven
 Sistema de controle de versão (Repositório) – CVS,
Git, ClearCase, SourceSafe (Team Foundation Server)
etc.
eXtreme Programming
Releases Curtos
O XP recomenda que pequenos investimentos sejam
efetuados de forma gradual e que busquem grandes
recompensas o mais rapidamente possível. Com a prática
de releases curtos, o XP pretende dar o máximo de valor
econômico ao cliente em um curto espaço de tempo.
Release é um conjunto de funcionalidades bem definidas
e que representam algum valor para o cliente.
eXtreme Programming
Releases Curtos
 Formado em Análise de Sistemas
 Pós-Graduado em Auditoria em T.I.
 Gerente de TI da CLIOC – Coleção de Leishmania do
Instituto Oswaldo Cruz – Fiocruz
 Certificado em Gestão de Segurança da Informação e
Gerenciamento de T.I. pela Academia Latino-Americana
(Microsoft TechNet / Módulo Security)
Carlos Henrique M. da Silva
carloshenrique.85@globo.com

Mais conteúdo relacionado

Mais procurados

Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de Software
Álvaro Farias Pinheiro
 
Qualidade de software
Qualidade de softwareQualidade de software
Qualidade de software
Alvaro Oliveira
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
Juliano Pires
 
Paradigmas De Engenharia De Software
Paradigmas De Engenharia De SoftwareParadigmas De Engenharia De Software
Paradigmas De Engenharia De Software
Robson Silva Espig
 
Scrum - evolução contínua
Scrum - evolução contínuaScrum - evolução contínua
Scrum - evolução contínua
Gabriel Alves Scavassa
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
Nécio de Lima Veras
 
Gerenciamento de projetos - Iniciação
Gerenciamento de projetos - IniciaçãoGerenciamento de projetos - Iniciação
Gerenciamento de projetos - Iniciação
Paulo Junior
 
Extreme Programming (XP) Metodologia Ágil
Extreme Programming (XP) Metodologia ÁgilExtreme Programming (XP) Metodologia Ágil
Extreme Programming (XP) Metodologia Ágil
Jaffer Veronezi
 
Metodologia Ágil
Metodologia ÁgilMetodologia Ágil
Metodologia Ágil
Elaine Cecília Gatto
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
Alessandro Rodrigues, CSM, SFC
 
Crystal method
Crystal methodCrystal method
Scrum na Prática
Scrum na PráticaScrum na Prática
Scrum na Prática
Alexandre Amorim
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
Mauricio Cesar Santos da Purificação
 
Gerenciamento do Escopo em Projetos
Gerenciamento do Escopo em ProjetosGerenciamento do Escopo em Projetos
Gerenciamento do Escopo em Projetos
Mauro Sotille, MBA, PMP
 
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOKAula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
Daniela Brauner
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de software
Alex Camargo
 
Apresentação Metodologia Ágil: Família Crystal de Cockburn
Apresentação Metodologia Ágil: Família Crystal de CockburnApresentação Metodologia Ágil: Família Crystal de Cockburn
Apresentação Metodologia Ágil: Família Crystal de Cockburn
Vanessa Finoto
 
Scrum
ScrumScrum
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
Marcelo Yamaguti
 
Apresentação do ERP
Apresentação do ERPApresentação do ERP
Apresentação do ERP
Murilojose10
 

Mais procurados (20)

Metodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de SoftwareMetodologias de Desenvolvimento de Software
Metodologias de Desenvolvimento de Software
 
Qualidade de software
Qualidade de softwareQualidade de software
Qualidade de software
 
Modelo de Prototipação
Modelo de PrototipaçãoModelo de Prototipação
Modelo de Prototipação
 
Paradigmas De Engenharia De Software
Paradigmas De Engenharia De SoftwareParadigmas De Engenharia De Software
Paradigmas De Engenharia De Software
 
Scrum - evolução contínua
Scrum - evolução contínuaScrum - evolução contínua
Scrum - evolução contínua
 
Modelos de processos de software
Modelos de processos de softwareModelos de processos de software
Modelos de processos de software
 
Gerenciamento de projetos - Iniciação
Gerenciamento de projetos - IniciaçãoGerenciamento de projetos - Iniciação
Gerenciamento de projetos - Iniciação
 
Extreme Programming (XP) Metodologia Ágil
Extreme Programming (XP) Metodologia ÁgilExtreme Programming (XP) Metodologia Ágil
Extreme Programming (XP) Metodologia Ágil
 
Metodologia Ágil
Metodologia ÁgilMetodologia Ágil
Metodologia Ágil
 
Treinamento Ágil / Scrum
Treinamento Ágil / ScrumTreinamento Ágil / Scrum
Treinamento Ágil / Scrum
 
Crystal method
Crystal methodCrystal method
Crystal method
 
Scrum na Prática
Scrum na PráticaScrum na Prática
Scrum na Prática
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Gerenciamento do Escopo em Projetos
Gerenciamento do Escopo em ProjetosGerenciamento do Escopo em Projetos
Gerenciamento do Escopo em Projetos
 
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOKAula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
Aula01 Gerência de Projetos - Conceitos e áreas de conhecimento do PMBOK
 
Qualidade de Software: Teste de software
Qualidade de Software: Teste de softwareQualidade de Software: Teste de software
Qualidade de Software: Teste de software
 
Apresentação Metodologia Ágil: Família Crystal de Cockburn
Apresentação Metodologia Ágil: Família Crystal de CockburnApresentação Metodologia Ágil: Família Crystal de Cockburn
Apresentação Metodologia Ágil: Família Crystal de Cockburn
 
Scrum
ScrumScrum
Scrum
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Apresentação do ERP
Apresentação do ERPApresentação do ERP
Apresentação do ERP
 

Destaque

Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
Rennan Martini
 
Extreme programming (xp)
Extreme programming (xp)Extreme programming (xp)
Extreme programming (xp)
Mohamed Abdelrahman
 
eXtreme Programming (xp)
eXtreme Programming (xp)eXtreme Programming (xp)
eXtreme Programming (xp)
Renato Pina
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
Daniel Wildt
 
Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)
Fernando Kenji Kamei
 
Engenharia Software Rup
Engenharia Software   RupEngenharia Software   Rup
Engenharia Software Rup
Felipe
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
Mr SMAK
 
extreme Programming
extreme Programmingextreme Programming
extreme Programming
Bilal Shah
 
Extreme Programming - XP
Extreme Programming - XPExtreme Programming - XP
Extreme Programming - XP
Paulo César M Jeveaux
 
Introdução: eXtreme Programming
Introdução: eXtreme ProgrammingIntrodução: eXtreme Programming
Introdução: eXtreme Programming
Denis L Presciliano
 
Modelagem Ágil
Modelagem ÁgilModelagem Ágil
Modelagem Ágil
Felipe Neves Brito
 
Programação Pragmática
Programação PragmáticaProgramação Pragmática
Programação Pragmática
elliando dias
 
Práticas Jedi eXtreme Programming
Práticas Jedi eXtreme ProgrammingPráticas Jedi eXtreme Programming
Práticas Jedi eXtreme Programming
Morvana Bonin
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
Milfont Consulting
 
Modelagem Ágil
Modelagem ÁgilModelagem Ágil
Modelagem Ágil
Rodrigo Branas
 
Extreme Project Managment
Extreme Project ManagmentExtreme Project Managment
Extreme Project Managment
Jack Ring
 
Xpm e xtreme project management
Xpm   e xtreme project managementXpm   e xtreme project management
Xpm e xtreme project management
GeneXus
 
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Flávio Steffens
 
PROCERGS 2015-03-25: Bad Smells em Bancos de Dados
PROCERGS 2015-03-25: Bad Smells em Bancos de DadosPROCERGS 2015-03-25: Bad Smells em Bancos de Dados
PROCERGS 2015-03-25: Bad Smells em Bancos de Dados
Fabrízio Mello
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
Rodrigo Gomes da Silva
 

Destaque (20)

Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)Introdução a Metodologia XP (E Xtreme Programming)
Introdução a Metodologia XP (E Xtreme Programming)
 
Extreme programming (xp)
Extreme programming (xp)Extreme programming (xp)
Extreme programming (xp)
 
eXtreme Programming (xp)
eXtreme Programming (xp)eXtreme Programming (xp)
eXtreme Programming (xp)
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
 
Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)
 
Engenharia Software Rup
Engenharia Software   RupEngenharia Software   Rup
Engenharia Software Rup
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
 
extreme Programming
extreme Programmingextreme Programming
extreme Programming
 
Extreme Programming - XP
Extreme Programming - XPExtreme Programming - XP
Extreme Programming - XP
 
Introdução: eXtreme Programming
Introdução: eXtreme ProgrammingIntrodução: eXtreme Programming
Introdução: eXtreme Programming
 
Modelagem Ágil
Modelagem ÁgilModelagem Ágil
Modelagem Ágil
 
Programação Pragmática
Programação PragmáticaProgramação Pragmática
Programação Pragmática
 
Práticas Jedi eXtreme Programming
Práticas Jedi eXtreme ProgrammingPráticas Jedi eXtreme Programming
Práticas Jedi eXtreme Programming
 
Extreme Programming
Extreme ProgrammingExtreme Programming
Extreme Programming
 
Modelagem Ágil
Modelagem ÁgilModelagem Ágil
Modelagem Ágil
 
Extreme Project Managment
Extreme Project ManagmentExtreme Project Managment
Extreme Project Managment
 
Xpm e xtreme project management
Xpm   e xtreme project managementXpm   e xtreme project management
Xpm e xtreme project management
 
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
 
PROCERGS 2015-03-25: Bad Smells em Bancos de Dados
PROCERGS 2015-03-25: Bad Smells em Bancos de DadosPROCERGS 2015-03-25: Bad Smells em Bancos de Dados
PROCERGS 2015-03-25: Bad Smells em Bancos de Dados
 
Introdução ao RUP
Introdução ao RUPIntrodução ao RUP
Introdução ao RUP
 

Semelhante a eXtreme Programming (XP)

Metodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareMetodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de Software
Luciano Almeida
 
Metodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareMetodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de Software
Emerson Henrique
 
Programacao Extrema
Programacao ExtremaProgramacao Extrema
Programacao Extrema
Robson Silva Espig
 
IPA Conhecendo XP
IPA Conhecendo XPIPA Conhecendo XP
IPA Conhecendo XP
Wildtech
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
Adriano Bertucci
 
Bate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XPBate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XP
Wildtech
 
eXtreme Programming
eXtreme ProgrammingeXtreme Programming
eXtreme Programming
Rafael Spínola
 
Agilidade em projetos de software
Agilidade em projetos de softwareAgilidade em projetos de software
Agilidade em projetos de software
Paulo Henrique Filho
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de software
Everton vitor
 
Trabalho xp
Trabalho xpTrabalho xp
Trabalho xp
Gustavo Medeiros
 
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento ÁgilEngenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Rebecca Betwel
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de software
Roberto Brandini
 
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
André Dias
 
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
Luiz Lemos
 
Leds zeppellin infraestrutura de apoio ao desenvolvimento
Leds zeppellin   infraestrutura de apoio ao desenvolvimentoLeds zeppellin   infraestrutura de apoio ao desenvolvimento
Leds zeppellin infraestrutura de apoio ao desenvolvimento
ledsifes
 
Desenvolvimento Ágil
Desenvolvimento ÁgilDesenvolvimento Ágil
Desenvolvimento Ágil
Gefferson Vivan
 
Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Software
alexandre_malaquias
 
Aula 4- Engenharia de Software
Aula 4- Engenharia de SoftwareAula 4- Engenharia de Software
Aula 4- Engenharia de Software
Rudson Kiyoshi Souza Carvalho
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWARE
Ernesto Bedrikow
 
Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013
Lourenco P Soares
 

Semelhante a eXtreme Programming (XP) (20)

Metodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareMetodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de Software
 
Metodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de SoftwareMetodologias Ágeis de Desenvolvimento de Software
Metodologias Ágeis de Desenvolvimento de Software
 
Programacao Extrema
Programacao ExtremaProgramacao Extrema
Programacao Extrema
 
IPA Conhecendo XP
IPA Conhecendo XPIPA Conhecendo XP
IPA Conhecendo XP
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
 
Bate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XPBate-papo com Especialista Terra XP
Bate-papo com Especialista Terra XP
 
eXtreme Programming
eXtreme ProgrammingeXtreme Programming
eXtreme Programming
 
Agilidade em projetos de software
Agilidade em projetos de softwareAgilidade em projetos de software
Agilidade em projetos de software
 
O uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de softwareO uso de metodos ageis no desenvolvimento de software
O uso de metodos ageis no desenvolvimento de software
 
Trabalho xp
Trabalho xpTrabalho xp
Trabalho xp
 
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento ÁgilEngenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
Engenharia de software aula 6 - Introdução ao Desenvolvimento Ágil
 
Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de software
 
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
 
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
 
Leds zeppellin infraestrutura de apoio ao desenvolvimento
Leds zeppellin   infraestrutura de apoio ao desenvolvimentoLeds zeppellin   infraestrutura de apoio ao desenvolvimento
Leds zeppellin infraestrutura de apoio ao desenvolvimento
 
Desenvolvimento Ágil
Desenvolvimento ÁgilDesenvolvimento Ágil
Desenvolvimento Ágil
 
Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Software
 
Aula 4- Engenharia de Software
Aula 4- Engenharia de SoftwareAula 4- Engenharia de Software
Aula 4- Engenharia de Software
 
Aula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWAREAula 1- ENGENHARIA DE SOFTWARE
Aula 1- ENGENHARIA DE SOFTWARE
 
Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013Princípios ágeis - UFRGS 2013
Princípios ágeis - UFRGS 2013
 

Mais de Carlos Henrique Martins da Silva

Segurança da Informação Aplicada a Negócios
Segurança da Informação Aplicada a NegóciosSegurança da Informação Aplicada a Negócios
Segurança da Informação Aplicada a Negócios
Carlos Henrique Martins da Silva
 
eXtensible Markup Language (XML)
eXtensible Markup Language (XML)eXtensible Markup Language (XML)
eXtensible Markup Language (XML)
Carlos Henrique Martins da Silva
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
Carlos Henrique Martins da Silva
 
Aula 9 - Backdoor
Aula 9 - BackdoorAula 9 - Backdoor
Aula 8 - SQL Injection
Aula 8 - SQL InjectionAula 8 - SQL Injection
Aula 8 - SQL Injection
Carlos Henrique Martins da Silva
 
Aula 7 - Ataque de Força Bruta
Aula 7 - Ataque de Força BrutaAula 7 - Ataque de Força Bruta
Aula 7 - Ataque de Força Bruta
Carlos Henrique Martins da Silva
 
Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)
Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)
Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)
Carlos Henrique Martins da Silva
 
Aula 5 - Assinatura e Certificado Digital
Aula 5 - Assinatura e Certificado DigitalAula 5 - Assinatura e Certificado Digital
Aula 5 - Assinatura e Certificado Digital
Carlos Henrique Martins da Silva
 
Aula 4 - Plano de Continuidade de Negócios (PCN)
Aula 4 - Plano de Continuidade de Negócios (PCN)Aula 4 - Plano de Continuidade de Negócios (PCN)
Aula 4 - Plano de Continuidade de Negócios (PCN)
Carlos Henrique Martins da Silva
 
Aula 3 - Política de Segurança da Informação (PSI)
Aula 3 - Política de Segurança da Informação (PSI)Aula 3 - Política de Segurança da Informação (PSI)
Aula 3 - Política de Segurança da Informação (PSI)
Carlos Henrique Martins da Silva
 
Aula 2 - Gestão de Riscos
Aula 2 - Gestão de RiscosAula 2 - Gestão de Riscos
Aula 2 - Gestão de Riscos
Carlos Henrique Martins da Silva
 
Aula 10 - Cross Site Scripting (XSS)
Aula 10 - Cross Site Scripting (XSS)Aula 10 - Cross Site Scripting (XSS)
Aula 10 - Cross Site Scripting (XSS)
Carlos Henrique Martins da Silva
 
Aula 1 - Introdução a Segurança da Informação
Aula 1 - Introdução a Segurança da InformaçãoAula 1 - Introdução a Segurança da Informação
Aula 1 - Introdução a Segurança da Informação
Carlos Henrique Martins da Silva
 
Deep web
Deep webDeep web
Segurança Através de Controles Biométricos - Carlos Henrique Martins da Silva
Segurança Através de Controles Biométricos - Carlos Henrique Martins da SilvaSegurança Através de Controles Biométricos - Carlos Henrique Martins da Silva
Segurança Através de Controles Biométricos - Carlos Henrique Martins da Silva
Carlos Henrique Martins da Silva
 
Invasão e Segurança
Invasão e SegurançaInvasão e Segurança
Invasão e Segurança
Carlos Henrique Martins da Silva
 

Mais de Carlos Henrique Martins da Silva (16)

Segurança da Informação Aplicada a Negócios
Segurança da Informação Aplicada a NegóciosSegurança da Informação Aplicada a Negócios
Segurança da Informação Aplicada a Negócios
 
eXtensible Markup Language (XML)
eXtensible Markup Language (XML)eXtensible Markup Language (XML)
eXtensible Markup Language (XML)
 
Rational Unified Process (RUP)
Rational Unified Process (RUP)Rational Unified Process (RUP)
Rational Unified Process (RUP)
 
Aula 9 - Backdoor
Aula 9 - BackdoorAula 9 - Backdoor
Aula 9 - Backdoor
 
Aula 8 - SQL Injection
Aula 8 - SQL InjectionAula 8 - SQL Injection
Aula 8 - SQL Injection
 
Aula 7 - Ataque de Força Bruta
Aula 7 - Ataque de Força BrutaAula 7 - Ataque de Força Bruta
Aula 7 - Ataque de Força Bruta
 
Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)
Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)
Aula 6 - Ataques de Negação de Serviço (DoS e D-DoS)
 
Aula 5 - Assinatura e Certificado Digital
Aula 5 - Assinatura e Certificado DigitalAula 5 - Assinatura e Certificado Digital
Aula 5 - Assinatura e Certificado Digital
 
Aula 4 - Plano de Continuidade de Negócios (PCN)
Aula 4 - Plano de Continuidade de Negócios (PCN)Aula 4 - Plano de Continuidade de Negócios (PCN)
Aula 4 - Plano de Continuidade de Negócios (PCN)
 
Aula 3 - Política de Segurança da Informação (PSI)
Aula 3 - Política de Segurança da Informação (PSI)Aula 3 - Política de Segurança da Informação (PSI)
Aula 3 - Política de Segurança da Informação (PSI)
 
Aula 2 - Gestão de Riscos
Aula 2 - Gestão de RiscosAula 2 - Gestão de Riscos
Aula 2 - Gestão de Riscos
 
Aula 10 - Cross Site Scripting (XSS)
Aula 10 - Cross Site Scripting (XSS)Aula 10 - Cross Site Scripting (XSS)
Aula 10 - Cross Site Scripting (XSS)
 
Aula 1 - Introdução a Segurança da Informação
Aula 1 - Introdução a Segurança da InformaçãoAula 1 - Introdução a Segurança da Informação
Aula 1 - Introdução a Segurança da Informação
 
Deep web
Deep webDeep web
Deep web
 
Segurança Através de Controles Biométricos - Carlos Henrique Martins da Silva
Segurança Através de Controles Biométricos - Carlos Henrique Martins da SilvaSegurança Através de Controles Biométricos - Carlos Henrique Martins da Silva
Segurança Através de Controles Biométricos - Carlos Henrique Martins da Silva
 
Invasão e Segurança
Invasão e SegurançaInvasão e Segurança
Invasão e Segurança
 

eXtreme Programming (XP)

  • 1. Carlos Henrique M. da Silva carloshenrique.85@globo.com eXtreme Programming
  • 2. Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores e práticas, que diferem substancialmente da forma tradicional de se desenvolver software. Estudos demonstram que a maioria dos projetos de software falha, seja porque não cumprem o orçamento, ou não cumprem o cronograma, ou as funcionalidades não atendem às necessidades dos usuários ou porque todos estes fatores estão presentes em conjunto. VINÍCIUS MANHÃES TELES eXtreme Programming - Conceito
  • 3. eXtreme Programming - Introdução Por que cerca de 80% a 90% dos projetos de Software fracassam?
  • 4. eXtreme Programming - Introdução Desenvolver software é uma atividade arriscada. Segundo as estatísticas, os principais problemas são:  Gastos que superam o orçamento;  Consumo de tempo que supera o cronograma;  Funcionalidades que não resolvem os problemas dos usuários;  Mudanças constantes podendo estar relacionadas a requisitos, cronograma, equipe...  Baixa qualidade dos sistemas desenvolvidos.
  • 5. eXtreme Programming - Introdução Há algumas décadas a indústria de software vem buscando técnicas de desenvolvimento que possam reduzir os riscos dos projetos de software e tornar essa atividade mais produtiva. Um marco neste sentido é a criação da disciplina de Engenharia de Software em 1968. De lá para cá, inúmeras propostas foram feitas para melhorar o desempenho dos projetos, começando pelo processo de desenvolvimento linear e seqüencial (em cascata) até chegar aos atuais processos ágeis de desenvolvimento. O XP é um dos representantes destes processos e foi criado por Kent Beck em 1997 em um projeto para a Chrysler (fabricante de veículos norte-americana). O XP é composto por um conjunto reduzido de práticas de desenvolvimento que se organizam em torno de valores básicos. Essas práticas possuem fortes inter-relacionamentos formando um conjunto de elevada sinergia.
  • 6. eXtreme Programming - Introdução Desenvolvimento de SW no passado  Processos Tradicionais Analisar, projetar e só depois iniciar codificação  Prever o futuro Ter certeza do que se sabe hoje será exatamente o que se quer amanhã  Temores Mudança de requisitos depois de concluída a fase de análise e projeto Custo Análise Projeto Codificação Testes Tempo
  • 7. eXtreme Programming - Introdução Desenvolvimento de SW hoje  Processos modernos incentivam pequenas iterações Mudanças em etapas posteriores se tornam mais baratas  Adotar a mudança - A Engenharia de SW é diferente das outras engenharias - Componentes, frameworks, BDs podem absorver o alto custo da mudança
  • 8. eXtreme Programming - Introdução A crise do software  Em média, os atrasos representaram 63% mais tempo do que o estimado;  Os projetos que não cumpriram o orçamento custaram em média 45% mais;  No geral, apenas 67% das funcionalidades prometidas foram efetivamente entregues. Resultado final de projetos de software (Standish Group,2000)
  • 9. eXtreme Programming - Introdução Utilização de Funcionalidades
  • 10. eXtreme Programming - Introdução Utilização de Funcionalidades
  • 11. eXtreme Programming - Introdução Desperdício Falha na comunicação Falta de tempo
  • 12. eXtreme Programming - Introdução Manifesto Ágil Estamos evidenciando maneiras melhores de desenvolver software fazendo- o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:  Interação entre pessoas MAIS QUE processos e ferramentas;  Software em funcionamento MAIS QUE documentação abrangente;  Colaboração com o cliente MAIS QUE negociação de contratos;  Responder a mudanças MAIS QUE seguir um plano. “Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda.” Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, Ward Cunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arie van Bennekum, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Brian Marick, Ken Schwaber, Jeff Shuterland, Dave Thomas
  • 14. eXtreme Programming Extreme Programming ou XP, é um processo de desenvolvimento de software voltado para:  Projetos cujos requisitos são vagos e mudam com frequência;  Desenvolvimento de sistemas orientados a objetos;  Equipes pequenas, preferencialmente até 12 desenvolvedores;  Desenvolvimento incremental (ou iterativo), onde o sistema começa a ser implementado logo no início do projeto e vai ganhando novas funcionalidades ao longo do tempo. VISÃO GERAL O XP é um processo de desenvolvimento que busca assegurar que o cliente receba o máximo de valor de cada dia de trabalho da equipe de desenvolvimento. Ele é organizado em torno de um conjunto de valores e prática que atuam de forma harmônica e coesa para assegurar que o cliente sempre receba um alto retorno do investimento em software.
  • 15. Valores do XP  Comunicação  Simplicidade  Feedback  Coragem  Respeito Práticas do XP  Cliente Presente  Jogo do Planejamento  Stand Up Meeting  Programação em Par  Desenvolvimento Guiado pelos Testes  Refactoring  Código Coletivo  Código Padronizado  Design Simples  Metáfora  Ritmo Sustentável  Integração Contínua  Releases Curtos eXtreme Programming
  • 16. Valores do XP eXtreme Programming
  • 17. Comunicação A comunicação entre o cliente e a equipe permite que todos os detalhes do projeto sejam tratados com a atenção e a agilidade que merecem. O XP procura assegurar que a comunicação ocorra da forma mais direta e eficaz possível. Sendo assim, ele busca aproximar todos os envolvidos do projeto de modo que todos possam se comunicar face-a-face ou da forma mais rica que for viável. eXtreme Programming
  • 18. Simplicidade A comunicação, embora seja essencial, não é suficiente para garantir que o cliente possa aprender durante o projeto e gerar feedback rapidamente. Também é necessário que a equipe compreenda e utilize o valor da simplicidade, que nos ensina a implementar apenas aquilo que é suficiente para atender a cada necessidade do cliente. Ou seja, ao codificar uma funcionalidade devemos nos preocupar apenas com os problemas de hoje e deixar os problemas do futuro para o futuro (NÃO DEVEMOS TENTAR PREVER O FUTURO), pois raramente acertamos as previsões. eXtreme Programming
  • 19. Feedback Quando o cliente aprende com o sistema que utiliza e re-avalia as suas necessidades, ele gera feedback para a equipe de desenvolvimento. O feedback é o mecanismo fundamental que permite que o cliente conduza o desenvolvimento diariamente e garanta que a equipe direcione as suas atenções para aquilo que irá gerar mais valor. eXtreme Programming
  • 20. Coragem Existem temores que costumam assombrar os participantes de um projeto de software. Beck e Fowler (2001) destacam alguns destes medos que exercem influência significativa nos processos de desenvolvimento. Desenvolvedores, por sua vez, temem:  Ser solicitados a fazer mais do que sabem fazer;  Ser ordenados a fazer coisas que não façam sentido;  Ficar defasados tecnicamente;  Receber responsabilidades, sem autoridade;  Não receber definições claras sobre o que precisa ser feito;  Sacrificar a qualidade em função de prazo;  Ter que resolver problemas complicados sem ajuda e  Não ter tempo suficiente para fazer um bom trabalho. Clientes temem:  Não obter o que pediram;  Pedir a coisa errada;  Pagar demais por muito pouco;  Jamais ver um plano relevante;  Não saber o que está acontecendo e  Fixarem-se em suas primeiras decisões e não serem capazes de reagir a mudanças nos negócios. eXtreme Programming
  • 21. Respeito eXtreme Programming Todo mundo dá e se sente o respeito que merecem como um membro da equipe valorizada. Todos contribuem valor mesmo que seja simplesmente entusiasmo. Desenvolvedores respeitam a experiência dos clientes e vice-versa. Gestores respeitam o direito de aceitar a responsabilidade e receber autoridade sobre nosso próprio trabalho. Respeito é um valor que dá sustentação a todos os demais. Membros de uma equipe só irão se preocupar em comunicar-se melhor, por exemplo, se se importarem uns com os outros. Respeito é o mais básico de todos os valores. Se ele não existir em um projeto, não há nada que possa salvá-lo. Saber ouvir, saber compreender e respeitar o ponto de vista do outro é essencial para que um projeto de software seja bem sucedido.
  • 23. eXtreme Programming Equipe (Whole Team) Equipe XP = Cliente + Time de Desenvolvimento Os papéis do time de desenvolvimento englobam: • Desenvolvedores • Testadores (ajudam o cliente com os testes de aceitação) • Analistas/projetistas (ajudam o cliente a definir requisitos) • Gerente (garante os recursos necessários) • Coach (orienta a equipe, controlando a aplicação do XP) • Tracker (coleta as métricas do projeto) As funções do cliente englobam: • Definição dos requisitos do projeto • Definição de prioridades • Controle do rumo do projeto • Definir os testes de aceitação do Software
  • 24. eXtreme Programming Jogo de Planejamento (Planning Game)  Principais definições • Estimativas de cada tarefa • Prioridades (tarefas + importantes)  Próximos passos • Planejamento de release (cliente propõe as funcionalidades e desenvolvedores avaliam) • Planejamento da iteração (define as funcionalidades da iteração e os desenvolvedores estimam)  Ótimo feedback para o cliente, que dirige o projeto • Ideia clara do avanço do projeto • Clareza: Redução de Riscos, aumentando a chance de sucesso
  • 25. eXtreme Programming Pequenos Lançamentos (Small Releases)  Disponibiliza a cada iteração Software 100% funcional • Versão • Redução (se o projeto terminar, parte existe e funciona) • Detecção prévia de problemas • Comunicação entre cliente e desenvolvedor  Cada lançamento possui funcionalidades prioritárias para a iteração  Lançamento pode ser destinado a • Usuário/cliente (testa, avalia e oferece feedback) • Usuário/final (sempre que possível)  Design simples e integração contínua são práticas essenciais
  • 26. eXtreme Programming Testes de Aceitação (Customer Tests)  São elaborados pelo cliente em conjunto com analistas e testadores • São automatizados • Quando rodarem com sucesso, funcionalidade foi implementada • Devem ser rodados a cada iteração  Ótimo feedback para o cliente • Pode se saber, a qualquer momento, o percentual de implementação do Software e quanto falta
  • 27. eXtreme Programming Projetos Simples (Simple Design)  Projeto está presente em todas as etapas XP • Projeto começa simples e se mantém assim através de testes de refinamento de código (refactoring)  Em XP, é levado ao extremo • Não é Permitido qualquer funcionalidade adicional que não será usada na iteração atual  Implementação ideal é aquela que • Passa por todos os testes • Expressa as ideias definidas no planejamento • Não contém código duplicado ou que “cheire”  Prever o futuro é impossível e é “anti-XP”
  • 28. eXtreme Programming Programação em Pares (Pair Programming)  Software é desenvolvido em pares • “2 cabeças juntas são melhores que 2 cabeças separadas” • 1 piloto e 1 copiloto • Papéis são alternados frequentemente  Benefícios •Melhor qualidade de código (refactoring e testes) •Revisão constante do código •Nivelamento da equipe •Maior comunicação  “Um” pelo preço de “Dois” Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores que trabalham sozinhos
  • 29. eXtreme Programming Desenvolvimento Dirigido por Testes (Test-driven Development)
  • 30. eXtreme Programming Refinamento de código (Refactoring) http://www.refactoring.com/catalog/
  • 33. eXtremme Programming Padrões de Codificação (Coding Standards)
  • 36. eXtremme Programming Reuniões em Pé (Stand-up Meeting)
  • 37. eXtremme Programming Spikes de Planejamento (Spike Solution)
  • 38. eXtremme Programming Como Implantar?  Uma prática de cada vez • Enfatize o problema mais importante  Dificuldades culturais • Deixar alguém mexer no seu código • Trabalhar em pares  Dificuldades devido a mudança de hábitos • Manter as coisas simples (e não tentar prever o futuro escrevendo "design flexível") • Jogar fora código desnecessário • Escrever testes antes de codificar • Refatorar com frequência (vencer o medo)
  • 39. eXtremme Programming Quando Não Usar XP  Equipes grandes e espalhadas geograficamente • Comunicação é um valor fundamental do XP • Não é fácil garantir o nível de comunicação requerido em projetos XP em grandes equipes  Situações onde não se tem controle sobre o código • Código legado que não pode ser modificado  Situações onde o feedback é demorado • Compile-link-build-test que leva 24 horas • Testes muito difíceis, arriscados e que levam tempo • Programadores espalhados em ambientes físicos distantes e sem comunicação eficiente
  • 40. eXtreme Programming Características da Equipe Uma equipe que utilize o XP normalmente é composta por pessoas que representam os seguintes papéis:  Gerente de Projeto  Coach  Analista de Teste  Redator Técnico  Desenvolvedor
  • 41. eXtreme Programming Gerente de Projeto O gerente de projeto é responsável pelos assuntos administrativos do projeto. Ele procura liberar a equipe de questões que não estejam diretamente ligadas à atividade diária de desenvolvimento. Além disso, administra o relacionamento com o cliente assegurando que o mesmo participe ativamente do desenvolvimento e forneça as informações essenciais para que a equipe possa implementar o sistema desejado.
  • 42. eXtreme Programming Coach O coach é o profissional técnico do projeto. O XP recomenda que um profissional tecnicamente bem preparado seja destacado para orientar a equipe de modo que ela siga as boas práticas recomendadas pelo XP. Embora também possa atuar na implementação do sistema, sua tarefa principal é assegurar o bom funcionamento do processo e buscar formas de melhorá-lo continuamente.
  • 43. eXtreme Programming Analista de Testes O analista de teste é responsável por ajudar o cliente a escrever os testes de aceitação. Quando estes testes não são automatizados, o analista de teste deve fazer com que eles sejam executados diversas vezes ao longo das iterações do projeto. Ele procura fazer com que os eventuais defeitos do sistema sejam identificados tão logo apareçam. Desta forma, fornece feedback para a equipe rapidamente, de modo que ela possa fazer as correções com rapidez e evitar que os problemas se propaguem.
  • 44. eXtreme Programming Redator Técnico O redator técnico ajuda a equipe de desenvolvimento a documentar o sistema. A sua presença permite que os desenvolvedores se concentrem prioritariamente na implementação do software. Embora eles possam continuar fazendo algumas documentações, o redator técnico é quem faz a maior parte do trabalho de documentação.
  • 45. eXtreme Programming Desenvolvedor O desenvolvedor é a pessoa que analisa, projeta e codifica o sistema. Em suma, é a pessoa que efetivamente constrói o software. Dentro do XP, não existem divisões entre analista, projetista, programador, etc. Cada desenvolvedor exerce estes diferentes papéis em diversos momentos do projeto.
  • 46. eXtreme Programming Desafios de Desenvolvimento de Software Modelo em Cascata
  • 47. eXtreme Programming  Análise: a equipe faz o levantamento de requisitos e busca compreendê-lo detalhadamente  Design: com base na análise a equipe projeta a arquitetura do sistema  Implementação: a equipe se baseia na arquitetura e na análise para implementar as diversas partes do software  Teste: para verificar se o sistema atende às necessidades especificadas pelo usuário, a equipe testa o software e faz as correções necessárias  Implantação: o sistema é colocado em produção e os usuários finais passam a utilizá-lo  Manutenção: até o fim da sua vida, o software poderá sofrer alterações por diversas razões, tais como correção e inclusão de novas funcionalidades Desafios de Desenvolvimento de Software
  • 48. eXtreme Programming Desenvolvimento Ágil O termo “desenvolvimento ágil”, faz referência ao desenvolvimento iterativo, em espiral. Ele recomenda que todas as fases descritas no modelo em cascata sejam executadas diversas vezes ao longo do projeto, produzindo ciclos que se repetem ao longo de todo o desenvolvimento. Cada ciclo (da análise à implementação) recebe o nome de iteração. No desenvolvimento iterativo, o software cresce a cada iteração, isto é, o resultado de cada iteração é um software pronto, testado e aprovado, sendo que a primeira contém poucas funcionalidades, enquanto a última contém todas as funcionalidades do sistema.
  • 49. eXtreme Programming Cliente Presente Introdução Tradicionalmente, quando pensamos no desenvolvimento de software, delegamos ao cliente a tarefa de manifestar as suas necessidades e à equipe de desenvolvimento a de implementar. Ou seja, há uma divisão implícita entre as responsabilidades de cada parte e um certo distanciamento entre elas.
  • 50. eXtreme Programming O XP trabalha com uma visão diferente O XP sugere que o cliente esteja presente durante o dia-a-dia do projeto. A sua participação contribui para o sucesso do projeto, enquanto sua a sua ausência é um sério fator de risco. A participação do cliente viabiliza a simplicidade do processo. Além disso, ela permite que o projeto seja conduzido através de uma série de pequenos ajustes e não através de mudanças bruscas ao longo do caminho.
  • 51. eXtreme Programming Estórias As funcionalidades do sistemas são descritas brevemente em cartões e recebem o nome de estórias. Estas estórias nada mais são do que um convite ao diálogo. Sendo assim, quando os desenvolvedores decidem começar a implementar uma determinada estória, eles precisam dialogar com o cliente para entendê-las melhor. Essa é uma das razões pelas quais é essencial que o cliente esteja presente no dia-a-dia do desenvolvimento.
  • 52. eXtreme Programming Dúvidas Durante a Implementação Enquanto os desenvolvedores se aprofundam na modelagem da nova funcionalidade e começam a implementá-la, dúvidas podem surgir. Mais uma vez, a presença do cliente permite que as dúvidas sejam respondidas rapidamente. Isso contribui com a agilidade do processo e evita o trabalho especulativo.
  • 53. eXtreme Programming O Trabalho Especulativo O trabalho especulativo, que ocorre quando a equipe não consegue ter as dúvidas respondidas e assume premissas, representa um enorme risco de retrabalho negativo. Assumindo premissas, a equipe pode vir a construir partes da funcionalidades de forma completamente incorreta, o que poderia ter sido evitado se o cliente estivesse presente para responder às dúvidas.
  • 54. eXtreme Programming Confiança: um sub-produto da presença do cliente Além do feedback entre cliente e equipe de desenvolvimento, a participação do cliente no desenvolvimento também contribui para melhorar o relacionamento de ambas as partes. A aproximação aumenta a confiança de todos os envolvidos. É preciso notar que serviço é um produto intangível, como o próprio software. Normalmente, temos mais facilidade em medir o valor de algo que é concreto, que podemos ver, tocar, manipular. Ou seja, normalmente, é mais fácil medir o valor de um carro, por exemplo, que o valor de um serviço.
  • 55. eXtreme Programming Para a equipe de desenvolvimento, a aproximação do cliente permite que muitas dúvidas sejam respondidas. Além disso, com o cliente próximo, a equipe pode apontar questões que tenham passados desapercebidas aos olhos dele. Desta forma, a equipe pode preveni-lo de situações incorretas. Aproximação da equipe com o cliente
  • 56. eXtreme Programming  Por que é difícil ter o cliente presente?  A sala de guerra (war room) com o cliente presente  A sala de guerra com o cliente ausente  A sala de guerra em outro prédio  O que acontece com os projetos quando o cliente não está presente? Questionamentos importantes Equipe X Cliente
  • 57. eXtreme Programming O Jogo do Planejamento O XP utiliza o planejamento para assegurar que a equipe de desenvolvimento esteja sempre trabalhando naquilo que irá gerar mais valor para o cliente a cada dia de trabalho. Este planejamento é feito diversas vezes ao longo do projeto, para que todos tenham a oportunidade de revisar as prioridades (Beck e Fowler, 2001).  Dividindo as Responsabilidades  Escrevendo Estórias  Estimando Estórias  Planejando os Releases  Planejando as Iterações  Encerrando uma Iteração  Encerrando um Release
  • 58. eXtreme Programming Dividindo as Responsabilidades A chave para gestão de um projeto de software é o equilíbrio de poderes entre o cliente e a equipe de desenvolvimento. Por esta razão, o XP procura separar claramente o papel de cada um, para assegurar que o cliente tome todas as decisões de negócio, enquanto a equipe de desenvolvimento cuida das decisões técnicas. (Beck e Fowler, 2001). Isso dá origem a declaração de direitos do cliente e do desenvolvedor (Jeffries et al., 2001).
  • 59. eXtreme Programming Direitos do Cliente  Receber um plano geral para que saiba o que poderá ser feito, quando e com que custo;  Receber o máximo de valor de cada semana de trabalho da equipe de desenvolvimento;  Acompanhar o progresso do projeto através de um sistema executável, que demonstra estar correto por passar nos testes que você especifica;  Mudar de ideia, substituir funcionalidades e alterar prioridades sem ter que pagar um preço exorbitante;  Ser informado sobre mudanças no cronograma a tempo de decidir como reduzir o escopo para ser capaz de manter a data original;  Cancelar o projeto a qualquer momento e receber um sistema executável que reflete todo o investimento que foi feito até a data do cancelamento.
  • 60. eXtreme Programming Direitos do Desenvolvedor  Saber quais são as necessidades, bem como suas prioridades;  Produzir um trabalho de alta qualidade permanentemente;  Pedir e receber ajuda de seus colegas e do cliente;  Gerar e atualizar as suas estimativas;  Escolher as suas responsabilidades, ao invés delas serem determinadas para você.
  • 61. eXtreme Programming Escrevendo Estórias Todas as funcionalidades do sistema são levantadas através de estórias que são registradas em pequenos cartões. Estas estórias devem ser escritas pelo cliente, com suas próprias palavras.
  • 62. eXtreme Programming Escrevendo Estórias Embora possa parecer estranho pedir ao cliente para escrever as estórias, existem fortes razões para isso:  O cliente é forçado a pensar melhor na funcionalidade;  O cliente se torna responsável sobre aquilo que está sendo solicitado;  Fazer o cliente perceber que está gastando ao pedir uma funcionalidade.
  • 63. eXtreme Programming Tarefas A equipe de desenvolvimento utiliza os cartões para saber quais são as funcionalidades desejadas pelo cliente. Os desenvolvedores escolhem as estórias que irão implementar a cada dia de trabalho. Entretanto, em projeto muito grande, os cartões podem acabar representando estórias que consomem muito esforço para implementar. Nestes casos, é comum a equipe dividir os cartões em tarefas. Elas são registradas em novos cartões de modo que possam ser distribuídas facilmente entre a equipe de desenvolvedores. Exemplos: 1. Apresente ao cliente 10 tarifas mais baratas para uma determinada rota; 2. O usuário deve poder alterar o seu perfil (email, senha, primeiro nome, ultimo nome e filiação). Dois campos de senha para confirmação.
  • 64. eXtreme Programming Estimando Estórias Para estimar a equipe de desenvolvimento precisa adotar uma unidade de medida que será usada para todas as estórias. Os desenvolvedores costumam estimar indicando a quantidade de tempo (horas) que uma funcionalidade irá consumir. O XP utiliza o conceito de dia ideal de desenvolvimento, que representa um dia no qual o desenvolvedor trabalha na implementação de funcionalidades, sem ter que se preocupar com nenhuma atividade extra. Usando pontos para estimar Estimando por comparação Estimando em equipe
  • 65. eXtreme Programming Planejando os Releases O XP trabalha com o objetivo de gerar valor para o cliente ao longo de todo o projeto. Para fazer isso, é importante que o software seja entregue de forma incremental, de modo que após cada entrega o cliente possa começar a utilizar o sistema e obter os benefícios que ele oferece. Estas entregas recebem o nome de release em XP. Os projetos em XP costumas ser divididos em releases, de modo que cada release implementa um conjunto de funcionalidades que possui um valor bem definido para o cliente. Por exemplo, imagine que o projeto de oito meses seja dividido em quatro releases, como ilustrado na figura abaixo. 8 sem. Projeto dividido em releases
  • 66. eXtreme Programming Projeto Dividido em Releases Suponha que este seja o projeto de um site de vendas on-line de uma grande loja de departamentos. Poderíamos imaginar a seguinte distribuição para os releases:  R1: Consulta dos produtos em estoque;  R2: Processamento de compras on-line;  R3: Acompanhamento de pedidos;  R4: Campanha de marketing de relacionamento. Projetos XP procuram trabalhar com o conceito de releases pequenos, isto é, os releases têm curta duração. Preferencialmente, devem ter em torno de dois meses. Com isso, o cliente pode começar a usufruir os benefícios do software e a equipe de desenvolvimento passa a ter a oportunidade de receber feedback dos usuários finais do sistema, o que permite que ela faça ajustes, de modo a aprimorar a qualidade dos releases subsequentes.
  • 67. eXtreme Programming Priorizando as Estórias de Cada Release  As releases devem ter tamanhos fixos e pequenos  Estabelecer a ordem (necessidades do cliente)  Verificar a NECESSIDADE X ASPECTOS TÉCNICOS. Observar as dependências técnicas  Distribuir as estórias nos seus respectivos releases  Não é necessário escrever todas as estórias do sistema no início do projeto  O cliente deve se concentrar nas estórias da primeira release (as outras, deixar para o futuro para evitar trabalho especulativo)  Dedicação nas estórias do release corrente e criar estórias para os releases futuros
  • 68. eXtreme Programming Planejando as Iterações Uma iteração é basicamente um pequeno espaço de tempo dedicado para a implementação de um conjunto de estórias. Em sua maioria, os projetos XP utilizam iterações de duas semanas. O início de cada iteração é caracterizado por uma reunião que recebe o nome de reunião de planejamento da iteração. Tamanho da iteração = 2 semanas = 10 dias úteis Deve-se descontar:  1 dia útil para a reunião de planejamento de iteração  1 dia útil para o encerramento da iteração Dias úteis para desenvolvimento = 10 – 2 = 8  Número de desenvolvedores = 4 = 2 x 2 = 2 pares  1 par/dia = 1 ponto  1 par em 8 dias = 1 x 8 = 8 pontos  2 pares em 8 dias = 2 x 8 = 16 pontos
  • 69. eXtreme Programming Dependências Técnicas A ordem em que o cliente deseja que as estórias sejam implementadas é afetada por dependências técnicas que a equipe deve identificar e lhe apresentar. O XP recomenda que a equipe procure sempre respeitar a ordem indicada pelo cliente. Na maioria dos casos isso é perfeitamente possível, desde que a equipe implemente algumas simplificações. As dependências técnicas costumam ser bem menos criticas do que aparentam. Para contorná-las a equipe deve ser criativa e buscar soluções que permitam ao cliente acesso às estórias tal como ele as ordena. Iterações são diferentes de releases: O XP apresenta um meio termo que permite que o cliente tenha flexibilidade e a equipe trabalhe com estabilidade. Durante todo o projeto, o cliente pode fazer alterações nas estórias. Já dentro de uma iteração, e apenas neste caso, o cliente tem que respeitar o acordo da reunião de planejamento.
  • 70. eXtreme Programming Encerrando uma Iteração O último dia da iteração é reservado para uma reunião de encerramento. Nela, o cliente executa todos os teste de aceitação que foram escritos para as estórias da iteração. O objetivo é que ele valide todo sistema e verifique se o resultado da iteração está satisfatório. Utilizando o sistema ele poderá detectar eventuais erros, bem como aprender mais sobre os requisitos e, se houver necessidade, fazer mudanças nos mesmos.
  • 71. eXtreme Programming Encerrando um Release Um release se encerra ao final da ultima iteração prevista pra ele. Ao final do release, a equipe coloca o sistema em produção para que todos os usuários passem a ter acesso a ele. Quanto mais entradas em produção o projeto tiver, melhor será o seu resultado para os usuários, visto que a cada release eles terão a oportunidade de fornecer feedback para a equipe de desenvolvimento. Isso ajudará a equipe a direcionar seus esforços pata fazer com que o sistema fique cada vez mais adequado às necessidades de seus usuários.
  • 72. eXtreme Programming Stand up Meeting Um dia de trabalho de uma equipe XP sempre começa com um stand up meeting. Este nome significa “reunião em pé” em inglês. Esta reunião não tem apenas o objetivo de avaliar o passado. Ela também é utilizada para decidir o que será feito no dia que se inicia. Ela serve para priorizar as atividades dos membros da equipe ao longo do dia.
  • 73. eXtreme Programming Diariamente, no stand up meeting, a equipe decide em conjunto que cartões serão tratados naquele dia e quem cuidará de cada cartão. No fim do stand up meeting, cada membro da equipe sabe o que deverá fazer ao longo do dia. É importante notar que a decisão sobre o que fazer ao longo do dia não é tomada por uma única pessoa. Essa decisão é tomada em equipe. Stand up Meeting
  • 74. eXtreme Programming Programação em Par Os desenvolvedores não trabalham sozinhos em um projeto que utilize XP. Eles sempre trabalham em pares. Trata-se da programação em par ou pair programming, como é conhecido em inglês.
  • 75. eXtreme Programming Os efeitos sobre a produtividade da equipe A ideia da programação em par parece estranha a princípio porque “enquanto um desenvolvedor o outro fica parado”. Isto é, “um trabalha enquanto o outro não faz nada”. Obviamente não é isso o que ocorre, mas é isso o que muita gente acaba interpretando erroneamente. Na verdade, um desenvolvedor digita enquanto o outro não digita. Mas, ambos estão programando juntos. A programação em par pressupõe uma comunicação contínua entre os desenvolvedores que formam o par. Através da conversa, eles discutem as melhores alternativas, corrigem erros, analisam cenários, enfim, discutem as melhores ideias para a resolução de cada problema. Portanto, é absolutamente incorreto acreditar que um trabalha enquanto o outro fica parado. Ambos estão trabalhando o tempo todo.
  • 76. eXtreme Programming A pressão do Par O ato de programar demanda grande concentração e produz um gasto de energia considerável. Entretanto, no dia-a-dia de um programador, ele se depara com diversas fontes de distração: email, bate-papo com colegas, cansaço. Isto diminui seu ritmo de trabalho no código. A programação em par corrige estes desvios através da pressão em par. O programador quando está acompanhado de outra pessoa, ele deixa de ter um compromisso apenas consigo mesmo. O seu compromisso se expande e passa a englobar também o seu colega. Ou seja, sua responsabilidade aumenta já que passa a envolver mais alguém. O efeito disso é que diversos focos de distração são eliminados.
  • 77. eXtreme Programming Revezamento A condução da programação é uma atividade que deve ser realizada sempre por ambos os programadores que formam um par. Um de cada vez, naturalmente. Para isso, é fundamental que eles se revezem diversas vezes ao longo de um dia de trabalho. O revezamento não se aplica apenas à questão de quem conduz o teclado. Ele também nos leva à questão de quem será o nosso par. Em um projeto, devemos trocar de par com frequência. Esta troca de par é importante para a disseminação do conhecimento.
  • 78. eXtreme Programming Desafios  A organização do escritório  A visão gerencial  O relacionamento humano  Competição
  • 80. eXtreme Programming Refactoring – Conceitos básicos Refactoring é o processo de modificar um software para melhorar a estrutura interna do código. Esse processo não repara erros e nem adiciona novas funcionalidades. Outra consequência é a melhora no entendimento do código, o que facilita a manutenção e evita a inclusão de bugs. Esta melhora no entendimento vem da constante alteração do código com objetivo de facilitar a comunicação de motivações, intenções e objetivos por parte do programador.
  • 81. eXtreme Programming  Obter um código-fonte claro e de fácil manutenção  Reduzir a complexidade da aplicação  Remover redundâncias desnecessárias  Reutilizar código  Otimizar o desempenho do software. Objetivos Básicos
  • 82. eXtreme Programming Desenvolvimento Guiado pelos Testes (TDD) Teste é parte do desenvolvimento de software que todo mundo sabe que precisa ser feita, mas ninguem quer fazer. Testar costuma ser considerado uma atividade chata, que consome tempo e só é valorizada depois que o sistema entra em produção e diversos problemas começam a surgir. Grande parte dos projetos deixam os testes para serem feitos no final (isso quando são feitos!)
  • 83. eXtreme Programming Por que Devemos Testar? Se o desenvolvedor escreve um código incorreto e descobre isso dois meses depois, a sua capacidade de aprendizado é muito baixa. Por outro lado, se ele descobre alguns segundos após introduzir o erro, ele aprende rapidamente que tipo de coisa ele fez que gera erro. Sendo assim, ele provavelmente não errará de novo no futuro. Quando os testes fazem parte do desenvolvimento, os programadores recebem feedback rapidamente sobre aquilo que estão fazendo. Com isso aprendem mais, resolvem os defeitos e tem mais tempo para desenvolver funcionalidades e gerar valor para o cliente.
  • 84. eXtreme Programming Testar é Investir Quando testamos, estamos fazendo um investimento e esperamos que ele gere um retorno no futuro. No caso de testes, este retorno acontece quando: • O desenvolvedor testa alguma coisa que deveria falhar e ela simplesmente funciona. • O teste falha quando já vinha funcionando normalmente, ou seja, surgiu um defeito no sistema e o teste detectou.
  • 85. eXtreme Programming Testando o XP O XP trabalha com dois tipos de testes: testes de unidade e testes de aceitação. Testes de unidade: é aquele realizado em cada classe do sistema para verificar se os resultados gerados são corretos. Testes de aceitação: São efetuados sobre cada funcionalidade, ou estória do sistema.
  • 86. eXtreme Programming Testes de Unidade  Devem ser automatizados  100% deles devem rodar corretamente ao longo de todo o desenvolvimento Desafios  Visto como aumento de trabalho pela equipe  A programação em par  Início difícil de trabalhar e automatizar Fatores essenciais  Conhecimento  Ferramentas  Programação em par  Persistência
  • 87. eXtreme Programming Questões sobre os Testes de Unidade  Testes com acesso a um BD?  Testes rodando muito lentamente?  E quando não consigo imaginar como testar uma classe?  Como saber se testei tudo que podera quebrar?  Código já escrito e não existem testes pra ele?  Erros que aparecem da colaboração entre diferentes classes?  GUIs?  Meu código não pode ser testado porque…  Testar a entrega
  • 88. eXtreme Programming Testes de Aceitação Além de verificar se cada classe está funcionando corretamente, é importante verificar se as classes englobadas por uma estória estão se relacionando corretamente. Quem cria e executa estes testes? Cliente? Analista de testes? Os dois? Testando em cada iteração  Descrever os testes em cartões, depois juntem estes aos cartões da estória.  Um cartão só pode ser considerado finalizado quando o teste de aceitação do mesmo for executado com sucesso. Automatizando HTML  HttpUnit Java  Jbehave, Selenium WebDriver, …
  • 89. Exemplo de Teste de Aceitação Estória Visualizar os itens do carrinho de compras Número Ação Resultado esperado 1  Entrar no site  Visualizar os itens do carrinho de compras Mostra a mensagem: “Seu carrinho de compras está vazio” 2  Adicionar ao carrinho o produto: “Geladeira 380L”  Visualizar os itens do carrinho de compras Mostra uma linha contendo a informação: Geladeira 380L – 1 unidade – R$1500,00 3  Adicionar ao carrinho o produto: “Fogão 4 bocas”  Visualizar os itens do carrinho de compras Mostra uma linha contendo a informação: Geladeira 380L – 1 unidade – R$1500,00 Fogão 4 bocas – 1 unidade – R$750,00 4  Visualizar os itens do carrinho de compras  Clicar em “Excluir” ao lado da linha que contém a geladeira Mostra uma linha contendo a informação: Fogão 4 bocas – 1 unidade – R$750,00 5  Visualizar os itens do carrinho de compras  Clicar em “Excluir” ao lado da linha que contém o fogão Mostra a mensagem: “Seu carrinho de compras está vazio”
  • 91. eXtreme Programming Código Coletivo Padrões de Codificação
  • 92. eXtreme Programming Código Coletivo Quando um projeto é implementado por uma equipe, é comum dividi-lo em partes, de modo que cada membro da equipe fique responsável por uma ou mais partes. Desta forma, cada pessoa é responsável por um subconjunto do código que forma o projeto. A divisão do trabalho é uma prática comum em diversa áreas profissionais. A forma como esta divisão é feita afeta diretamente o resultado final de um projeto. É bastante comum encontrarmos “ilhas de conhecimento” nos projetos de software. Uma “ilha de conhecimento” pode ser compreendida como sendo uma pessoa que possui um domínio sobre uma área do projeto. Somente ela conhece aquela parte ou aquele código. Se outra pessoa precisar mexer naquela parte, deverá solicitar à ilha de conhecimento que entre em ação.
  • 93. eXtreme Programming A programação em par, por si só, já colabora para evitar a formação de “ilhas de conhecimento”. Porém, o código coletivo vai além. Ele dá a todas as pessoas a chance de mexer em qualquer parte do sistema. É importante que ele seja sempre escrito da maneira mais legível possível. Pois isto é o que garantirá que a equipe conseguirá continuar a implementar o sistema. Vale notar também que o código coletivo leva a equipe a ser mais ágil no desenvolvimento. Como não existe um responsável por certa parte do código, qualquer pessoa pode mexer nela tão logo sinta a necessidade de fazê-lo. Não é necessário esperar por ninguém, não é necessário esperar pelo especialista. Código Coletivo
  • 94. eXtreme Programming Padrões de Codificação Se você analisar o código de diferentes programadores, provavelmente irá notar que existem diferenças de estilo. Por exemplo, um programador prefere colocar { no final da declaração de um método, enquanto outro prefere colocar na linha posterior. O XP recomenda que a equipe adote um padrão no início do projeto. Ela pode construir este padrão em conjunto ou pode adotar um que já exista e esteja documentado em algum lugar, como por exemplo: http://java.sun.com/docs/codeconv/html/CodeConventions.doc.html
  • 95. eXtreme Programming Padrões de Codificação Procure adotar um padrão que seja fácil e simples. Isso evita resistência e facilita a compreensão do código, ou seja, melhora a comunicação. Jeffries et al. (2001, p.79) apresenta alguns tópicos a considerar:  Identação  Letras maiúsculas e minúsculas  Comentários (evitá-los tanto quanto possível)  Nomes
  • 97. eXtreme Programming Design Tradicional “O custo de se corrigir um problema em um software cresce exponencialmente ao longo do tempo. Um problema que poderia ter custado um dólar para ser corrigido se tivesse sido encontrado durante a análise pode custar milhares de dólares para ser resolvido depois que o software já estiver em produção.”
  • 98. eXtreme Programming O custo de uma alteração no XP A comunidade de desenvolvimento de software investiu uma enorme quantidade de recursos nas últimas décadas no sentido de reduzir os custos de uma alteração em um software. Estes investimentos gerou diversos avanços:  Melhores linguagens de programação  Avanços na tecnologia de banco de dados  Melhores práticas de programação  Novos ambientes e ferramentas de desenvolvimento  Computadores mais rápidos e mais baratos  Orientação a objetos
  • 99. eXtreme Programming Infelizmente a única constante em um projeto de software é a mudança:  Os requisitos mudam  O design muda  A tecnologia muda  A equipe muda  Os membros da equipe mudam O problema não está na mudança em si, porque ela vai acontecer de qualquer jeito. O problema é a incapacidade de lidar com ela quando ela chegar. Design Tradicional
  • 100. eXtreme Programming Estratégia Para alcançar um design simples, o XP recomenda que você utilize a seguinte estratégia: 1. Comece escrevendo um teste. 2. Faça o design e implemente apenas o suficiente para passar nos testes. 3. Execute os passos 1 e 2 novamente tanto quanto necessário. 4. Se você identificar a oportunidade de tornar o design mais simples, faça isso. No XP, o design é criado de forma incremental. Sendo assim, ao final da primeira iteração, o seu software terá um design bastante simples, suficiente para as funcionalidades daquela iteração. Na segunda, terá que fazer alguns refactorings e fará alterações no design, de modo a incorporar novas funcionalidades.
  • 101. eXtreme Programming Simplicidade Exemplo de quatro regras básicas para definir simplicidade: 1. O sistema (código e testes em conjunto) deve expressar tudo aquilo que você deseja comunicar 2. O sistema não deve conter nenhum código duplicado 3. O sistema deve ter o menor número de classes possível 4. O sistema deve ter o menor número de métodos possível Atualmente, existe uma verdadeira febre pela utilização de frameworks que possam facilitar o desenvolvimento de sistemas. Tais frameworks contêm uma série de funcionalidades genéricas que podem poupar esforço da equipe ao longo do desenvolvimento. Entretanto, existem custos associados à utilização de frameworks: curva de aprendizado e são abrangentes demais.
  • 102. eXtreme Programming Metáfora Metáforas são usadas frequentemente durante o desenvolvimento de sistemas, na medida em que os desenvolvedores criam elementos dentro do computador para simular outros que existem regularmente fora dele, no mundo físico.
  • 103. eXtreme Programming XP procura explorar ao máximo a utilização de metáforas, para que clientes e desenvolvedores sejam capazes de estabelecer uma vocabulário apropriado para o projeto, repleto de nomes representando elementos físicos com os quais os clientes estejam habituados em seu dia-a-dia, de modo a elevar a compreensão mútua. Metáfora
  • 105. eXtreme Programming Ritmo Sustentável O XP PROÍBE que os desenvolvedores trabalhem até mais tarde. O XP sugere um ritmo sustentável de 40 HORAS SEMANAIS, respeitando assim a individualidade e o físico de cada desenvolvedor. Desta forma a equipe estará sempre concentrada e muito menos propensa a pequenas falhas na implementação.
  • 106. eXtreme Programming Integração Contínua O XP propõe uma integração contínua, se possível deve ser efetuada diversas vezes ao dia para que toda a equipe tenha conhecimento do código recém-desenvolvido. Com esta prática o feedback sobre a alteração efetuada será obtido em um menor espaço de tempo. Dificuldades em integrar diversas vezes ao dia:  Tempo de build  Código Coletivo  Programação em Par
  • 107. eXtreme Programming Integração Contínua Segundo Jeffries et al. (2001), em XP o código avança em 3 fases:  Local: As mudanças que o par executou no código ainda não estão disponíveis para os demais.  Candidato à Liberação: O par terminou a tarefa e está tudo pornto para a disponibilização.  Disponibilizado: Código pronto. Testes 100%.
  • 108. eXtreme Programming Integração Contínua Ferramentas: Para que seja feita a integração contínua, são necessárias ao menos duas categorias de ferramentas para auxiliá-lo:  Ferramenta de build – Ant ou Maven  Sistema de controle de versão (Repositório) – CVS, Git, ClearCase, SourceSafe (Team Foundation Server) etc.
  • 109. eXtreme Programming Releases Curtos O XP recomenda que pequenos investimentos sejam efetuados de forma gradual e que busquem grandes recompensas o mais rapidamente possível. Com a prática de releases curtos, o XP pretende dar o máximo de valor econômico ao cliente em um curto espaço de tempo. Release é um conjunto de funcionalidades bem definidas e que representam algum valor para o cliente.
  • 111.  Formado em Análise de Sistemas  Pós-Graduado em Auditoria em T.I.  Gerente de TI da CLIOC – Coleção de Leishmania do Instituto Oswaldo Cruz – Fiocruz  Certificado em Gestão de Segurança da Informação e Gerenciamento de T.I. pela Academia Latino-Americana (Microsoft TechNet / Módulo Security) Carlos Henrique M. da Silva carloshenrique.85@globo.com

Notas do Editor

  1. Equipes XP reconhecem estes temores e buscam formas de lidar com eles de maneira corajosa. Ter coragem em XP significa ter confiança nos mecanismos de segurança utilizados para proteger o projeto.