Metodologias Ágeis de Desenvolvimento Com XP

METODOLOGIAS
ÁGEIS DE
DESENVOLVIMENTO
COM XP
Luiz Henrique Rauber Rodrigues

luizrauber.blogspot.com

Metodologias Ágeis de Desenvolvimento com XP – Luiz Rauber – Seminário 2009 Tchelinux em Porto Alegre
PLANO APRESENTAÇÃO
 NÚMEROS
 PROBLEMAS
 OBSERVAÇÃO
 METODOLOGIAS ÁGEIS
 EXTREME PROGRAMMING
 VALORES
 PRINCÍPIOS
 PAPÉIS
 PRÁTICAS
 CONCLUSÕES/ DICAS
 DÚVIDAS/ CRÍTICAS/ SUGESTÕES/ COMENTÁRIOS

 REFERÊNCIAS
NÚMEROS


Já fez parte da criação de um sistema? em qual
atribuição?
5%
5%
10%
Programador
Analista
Arquiteto
Cliente
Estudante
55%
25%
Fonte: pesquisa lista discussão Tchelinux

Foi feito uso de alguma metodologia? Qual?
5%
5%
10%
Nenhuma
50% 10%
Cascata
Espiral
Scrum
XP
5%
RUP
MA Própia
15%

O sistema foi concluído?
10%
Sim
Não
90%

O sistema foi concluído no prazo previsto no
cronograma?
40%
Sim
Não
60%

O sistema foi concluído dentro do limite orçamentário do
projeto?
25%
Sim
Não
75%

O sistema foi entregue com todas as funcionalidades
previstas no projeto?
15%
Sim
Não
85%

Após a entrega houve uma manutenção fora do previsto
no sistema?
30%
Sim
Não
70%

Atualmente faz parte do desenvolvimento de algum
sistema? Qual metodologia está sendo usada?
5%
5%
5%
38%
14% Não
Nenhuma
Cascata
Scrum
XP
DSDM
10%
XP min.
14% 10% MA Própria

Resumidamente – Após 20 respostas
10%
35%
Sucesso
Desafiados
Falharam
55%

Se fulano erra, não preciso errar também!

PROBLEMAS

1º – Comunicação ineficiente
2º – Sem documentação
3º – Cliente presente só no ínicio e final


fonte:blog.adsystems.com.br
COMUNICAÇÃO
”Quem não se comunica, se trumbica”

fonte:blogdonardini.blogspot.com
fonte:maninhoexpress.com.br

DOCUMENTAÇÃO
Documentar é Planejar!
Planejar é Documentar!


fonte:luizrauber.blogspot.com

 Muito Papel
 Perde-se Tempo
 Atraso de Software
 Custo Elevado
 Pouco Papel
 Ganha-se Tempo
 Difícil Modifição/ Atualização
 Custo Elevado
 Documentação errada ínicio = Software errado final
 Software mudou = Documentação errada
 Documentação após software = Retrabalho

Complexidade>
fonte:software engineering economis; Barry W. Boehm

CLIENTE
É quem vai pagar

É quem vai usar o sistema
É conhece a situação problema
Porque não esta presente?

Cliente:
O motor tá fazendo um
barulho diferente!
Mecânico:
Pode ser aqui o problema,
tá quebrado!
fonte:mercovel veículos – santiago rs

Acho que é mais pra lá e
acendeu uma luz
vermelha no painel!
Estas informações adicionais,
me facilitaram, sei o que é!
fonte:mercovel veículos – santiago rs

OBSERVAÇÃO

Software não é físico.
Não pense como
Eng. Civil
Pense como
Adm. Empresas
fonte:cityhall.com.br

Software deve ser adaptável,
deve ser de fácil implementação,
deve ser de fácil implantação,
deve ser livre de erros,
deve ser seguro,
deve ser de fácil expansão,
deve ter boa usabilidade.

Algum exemplo?

Software deve ser que nem Linux ;)

+ Personalizados
Prateleira
Cliente sabe o que quer e sabe que dá pra fazer!
(embora normalmente não se consegue entender
o que ele quer)

então...
Melhorar a comunicação de uma equipe que é

formada por nerds comumente tímidos!

...
Não documentar antes de programar porque o

software deve ser mutável, mas deve-se planejar
antes de programar.

...
Manter o cliente mais próximo possível desta

coisa que ele quer que leiamos da sua cabeça e
transformemos em um software.

…
¬¬ '
Qual a mágica?

fonte:agileprocess.org
METODOLOGIAS ÁGEIS

METODOLOGIAS ÁGEIS
XP/ Scrum/ DSDM
Foco em Projetos Pequenos

(”dividir para conquistar”)
Google/ Yahoo/ Microsoft

Manifesto Ágil
“Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através
desse trabalho, passamos a valorizar:
 Indivíduos e interação entre eles 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 havendo valor nos itens à direita, valorizamos mais
os itens à esquerda.” (agilemanifesto.org)

fonte:extremeprogramming.org
EXTREME PROGRAMMING

EXTREME PROGRAMMING
 Baseia-se no Manifesto Ágil
 ”A arte de maximizar a quantidade de software
que você não irá fazer.” Vinícius Teles
 Ideal equipes pequenas (<10-15 pessoas)
 Foco em Comunicação Efetiva
Cliente x Programador
 TDD Exaustivamente
 Diminuição Custos Mudanças

fonte:eupodiatamatando.com

EXTREME PROGRAMMING
 Valores
Coragem
 Aceitar que o cliente pode querer mudar o
que está pronto
 Confiar práticas XP
 Mudar, adaptar, refazer parte do software
se assim o cliente quiser

EXTREME PROGRAMMING
 Valores
Comunicação
 Priorizar entre o Cliente e Equipe
 Equipe x Equipe, uso 1 sala
 Pessoalmente> Videoconferência>
Telefonema> e-mail

EXTREME PROGRAMMING
 Valores
Feedback
 Fez confirma com o cliente
 Cliente deve dizer um sim/não, nunca
talvez
 Quantes antes achar o erro melhor

EXTREME PROGRAMMING
 Valores
Respeito
 Aceitar deficiências
 Saber ouvir
 Compreender
 Se importar um com o outro

EXTREME PROGRAMMING
 Valores
Simplicidade
 Não fazer mais que a necessidade
 Evitar ”firulas”
 Ver com cliente real necessidade de
certas exigências

EXTREME PROGRAMMING
 Princípios
Autosemelhança
 Deu Ok, passa adiante!
Benefício Mútuo
 Bom pra um, bom pra todos
Diversidade
 Visões diferentes, intuito em comum

EXTREME PROGRAMMING
 Princípios
Economia
 Fazer o que da retorno primeiro
 Reutilização/ Novas Funcionalidades
Falha
 Experimentar na busca erro
 Feedback concreto

EXTREME PROGRAMMING
 Princípios
Flow/ Fluidez
 Ir e vir sem problemas
 Diminuir a curva custos
Humanismo
 É gente que faz
Melhoria
 Fazer melhor, na próxima interação
EXTREME PROGRAMMING
 Princípios
Oportunidade
 Bug? Conhecimento pra todos
Passos de Bebê
 Menos é mais
Qualidade
 Mais é menos

EXTREME PROGRAMMING
 Princípios
Redundância
 Antes 2x do que 3-4x
 Evitar erro = evitar desmotivação
Reflexão
 Ver o bom, e o ruim
Responsabilidade
 Deixa pra mim
EXTREME PROGRAMMING
 Papéis
fonte:luizrauber.blogspot.com
EXTREME PROGRAMMING
 Práticas
Cliente Presente
 Cliente x Programador
 Sucesso e Fracasso é culpa do Cliente
 Software fica pronto + rápido >
 Custo Menor >
 Diminuição de recursos (firulas) não
usados no Software <

EXTREME PROGRAMMING
 Práticas
Planejamento Interativo
 Entrega Parcelada (Releases)
 Release a cada X tempo
 Melhor Adaptabilidade
 Aprimoramento (+Isso, -Aquilo, Muda Lá)
 Motiva a Todos

 Receita Antecipada

EXTREME PROGRAMMING
 Práticas
Ciclo Semanal
 Quadro Histórias
 Planning Poker
 Cliente + Equipe = Desafio Semana
 Planejar atividades da Semana
 Acertos/ Erros semana anterior

EXTREME PROGRAMMING
 Práticas
Design Incremental
 Software por partes
 Primeiro o básico depois acessórios
 Só fazer prioridades
 O que pode ser útil no futuro, será feito no
futuro

EXTREME PROGRAMMING
 Práticas
Ambiente Informativo
 Informações sobre/ andamento
 Quadros/ Murais
 Avisos – Post it
 Cartões visíveis

Quem sabe usar também

Hudson?
fonte:djibnet.com

EXTREME PROGRAMMING
 Práticas
Stand Up Meeting - Reunião do Cafézinho
 Prioridades do Dia
 Olhadela quadro tarefas
 Assumir atividade
Informal: Humor/ Críticas/ Problemas/ -Timidez

EXTREME PROGRAMMING
 Práticas
Teste 10 Minutos - Build
 Teste Automatizado/ Manual
 - Tempo Parado
 + Execuções teste
 - Erros acumulados
 + Fácil achar erro
 TDD

EXTREME PROGRAMMING
 Práticas
TDD denovo
 Passou 2x sem problemas?
 Acrescenta outra condição no TDD
 E faz denovo
 E denovo
 Blz? Então outra parte

EXTREME PROGRAMMING
 Práticas
Integração Contínua
 Unificar as partes
 Fez, testou, testou, ta Ok?
Manda Repositório
 CVS/ Subversion

EXTREME PROGRAMMING
 Práticas
Retrospectiva interação
 Não era isso que eu queria
 Agora Sim/ Não
 Isso deu Certo/ Errado

EXTREME PROGRAMMING
 Práticas
Trabalho Energizado
 Não trabalhar muito, mas trabalhar bem
 Mover na direção certa
 Evitar horas-extras
 Evitar déficit de atenção

fonte:eupodiatamatando.com

EXTREME PROGRAMMING
 Práticas
Programação em Par
 2 Cérebros é melhor que 1
 Inspeção código
 Disseminação conhecimento
 + Qualidade Software
 Revisão/ Correção

fonte:leonardofaria.net

EXTREME PROGRAMMING
 Práticas
Programação em Par
 Redução Bugs
 Pressão
 Dicas/ Sugestões
 Entrega Rápida
Dojo? Rally? Avião?
EXTREME PROGRAMMING
fonte:extremeprogramming.org

CONCLUSÕES/ DICAS
 Software deve ser adaptável
 Priorizar o básico, depois firulas
 Não ficar preso a regras/ documentação
 Fazer documentação junto desenvolvimento
 Planejar Semana/ Mês/ Software
 Não enrolar senão vai-se o tempo
 Comunicação nunca é pouca
 Não reinventem a roda
 Procurem desafios para aprender

 É possível melhorar sempre
DÚVIDAS ?
CRÍTICAS?
SUGESTÕES?
COMENTÁRIOS?

REFERÊNCIAS
 www.google.com  Kent Beck
 www.guma-rs.org  Kelly Waters
 www.extremeprogramming.org  James Shore
 http://improveit.com.br/xp  Vinicius Teles
 www.agilealliance.com  Brian Behlendorf
 www.agile-software-development.com  Manoel Pimentel Medeiros
 http://computerworld.uol.com.br  Jonathan Kohl
 www.baguete.com.br  Scott Ambler
 http://c2.com  Vitor Hugo Germano
 www.visaoagil.com  Alexandre Magno Figueiredo
 www.seatecnologia.com.br  Alexandre Gomes

 http://www.agile-process.org/  Daniel Wildt
OBRIGADO
luizrauber.blogspot.com


Metodologias Ágeis de Desenvolvimento Com XP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Metodologias Ágeis de Desenvolvimento Com XP

Uploaded by

Copyright:

Available Formats

METODOLOGIAS

Luiz Henrique Rauber Rodrigues

Fonte: pesquisa lista discussão Tchelinux

Fonte: pesquisa lista discussão Tchelinux

Fonte: pesquisa lista discussão Tchelinux

Fonte: pesquisa lista discussão Tchelinux

Fonte: pesquisa lista discussão Tchelinux

Fonte: pesquisa lista discussão Tchelinux

Fonte: pesquisa lista discussão Tchelinux

Fonte: pesquisa lista discussão Tchelinux

Fonte: pesquisa lista discussão Tchelinux

”Quem não se comunica, se trumbica”

É quem vai pagar

Melhorar a comunicação de uma equipe que é

Não documentar antes de programar porque o

Manter o cliente mais próximo possível desta

XP/ Scrum/ DSDM

Foco em Projetos Pequenos

Google/ Yahoo/ Microsoft

Informal: Humor/ Críticas/ Problemas/ -Timidez

 Blz? Então outra parte

Dojo? Rally? Avião?

You might also like