Basicão da Metodologia Desenvolvimento XP

comprometimento?

agilidade?

melhor caminho?

organização?

comunicação?

respeito?

motivação?

programação em par?

revisão código?

tdd?

listas atividades?

Apresentação

• Informações e Reflexões
• Metodologias Ágeis ?
• Extreme Programming?

Valores;

Princípios;

Papéis;

Práticas

• Pré Conclusões
• + Informações
• Referências
• Espaço Dúvidas

Informações Importantes

rapidamente...

1o Comunicação ineficiente

2o Sem documentação

3o Projeto muito grande

4o Cliente presente só

no ínicio e final

1° Comunicação!

Mesma Linguaguem

2° Documentação

Documentar é Planejar!

Planejar é Documentar!

3° Divisão

4° Cliente

Cliente é que sabe o quê o software

deve fazer.

Cliente é que vai usar.

Cliente é quem vai pagar!

Porque tais coisas ditas?

Porquê precisa ficar assim?

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

Acertar Metodologias Ágeis

Foco em Projetos Pequenos

(”dividir para conquistar”)

XP/ Scrum/ DSDM

Google/ Yahoo/ Microsoft

”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
• Desenvolvimento Incremental
• Diminuição Custos Mudanças

Valores

Comunicação

• Priorizar entre o Cliente e Equipe
• Equipe x Equipe, uso 1 sala
• Pessoalmente é melhor que

Videoconferência que é melhor que Telefonema que é melhor que e-mail

Simplicidade

• Não fazer mais que a necessidade
• Evitar ”firulas”
• Ver com cliente real necessidade de certas exigências

Feedback

• Fez confirma com o cliente
• Cliente deve dizer um sim/não, nunca talvez
• Quantes antes achar o erro melhor

Respeito

• Aceitar deficiências
• Saber ouvir
• Compreender
• Se importar um com o outro

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

Princípios

• Flow/ Fluidez

Ir e vir sem problemas

Diminuir a curva custos

• Humanismo

Programador também é gente

• Melhoria

Fazer melhor, na próxima interação

• Economia

Fazer o que da retorno primeiro

Reutilização/ Novas Funcionalidades

• Falha

Experimentar na busca erro

Feedback concreto

• 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

• Autosemelhança

Deu Ok, passa adiante!

• Benefício Mútuo

Bom pra um, bom pra todos

• Diversidade

Visões diferentes, intuito em comum

• Oportunidade

Bug? Conhecimento pra todos

• Passos de Bebê

Menos é mais

• Qualidade

Mais é menos

Práticas

Stand Up Meeting

• Prioridades do Dia
• Olhadela quadro tarefas
• Assumir atividade

Planejamento Interativo

• Entrega Parcelada (Releases)
• Release a cada X tempo
• Melhor Adaptabilidade
• Aprimoramento

(+Isso, -Aquilo, Muda Lá)

• Motiva a Todos
• Receita Antecipada

Ciclo Semanal

• Quadro Histórias
• Planning Poker
• Cliente + Equipe = Desafio Semana
• Planejar atividades da Semana
• Acertos/ Erros semana anterior

Cliente Presente

• Cliente x Programador
• Sucesso e Fracasso é culpa do Cliente
• Software fica pronto + rápido >
• Custo Menor >
• Diminuição de recursos não usados <

Ambiente Informativo

• Informações sobre/ andamento
• Quadros/ Murais
• Avisos – Post it
• Cartões visíveis

Design Incremental

• Software por partes, 1+1+1
• Primeiro o básico depois acessórios
• Só fazer prioridades
• O que pode ser útil no futuro, será feito no futuro

Custo de Mudança torna-se complexidade

E tempo torna-se desmotivação

Fazer 1x por ciclo

Padrões de Codificação

• Todos devem falar a mesma lingua em sentido de regras codificação

Posse Coletiva

• Código pertence a todos
• Eu que fiz, mas outro pode modificar

Teste 10 Minutos - Build

• Teste Automatizado/ Manual

- Tempo Parado

+ Execuções teste

- Erros acumulados

+ Fácil achar erro

TDD

TDD denovo

• Passou 2x sem problemas?
• Acrescenta outra condição no TDD
• E faz denovo
• E denovo
• Blz? Então outra parte

Integração Contínua

• Unificar as partes
• Fez, testou, testou, ta Ok?

Manda Repositório

Trabalho Energizado

• Não trabalhar muito,

mas trabalhar bem

• Mover na direção certa
• Evitar horas-extras
• Evitar déficit de atenção
• 40 horas/semana, 8 horas/dia

Programação em Par

• 2 Cérebros é melhor que 1
• Inspeção código
• Disseminação conhecimento
• + Qualidade Software
• Revisão/ Correção

• Redução Bugs
• Pressão
• Dicas/ Sugestões
• Entrega Rápida

Exemplos

Dojo?

Rally?

Avião?

Retrospectiva iteração

• Não era isso que eu queria
• Agora Sim/ Não
• Isso deu Certo/ Errado

Pré Conclusões

• Comunicação nunca é pouca
• Priorizar o básico, depois firulas
• Não ficar preso a regras/ documentação
• Fazer documentação junto desenvolvimento
• Planejar Software/ Semana/ Mês/ Vida
• Não enrolar senão vai-se o tempo

+ Informações

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

Software não é físico.

Não pense como

Engenharia Civil

Pense como

Administração Empresas

+ Personalizados

- Prateleira

Cliente sabe o que quer e sabe que dá pra fazer!

(embora normalmente não se consegue entender o que ele quer)

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.

Um exemplo?

Linux

Não reinventem a roda

Procurem desafios para aprender

É possível melhorar sempre

Obrigado!

Espaço Dúvidas

críticas?

sugestões?

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

algumas imagens

ayagebeely.blogspot.com/2009/10/stand-up-meeting.html

Livro: Software Engineering Economis; Barry W. Boehm

foto gurias fim interação: Laborvox PUC SP

scrumeta.wordpress.com

Motivos?

Gerentes de Projeto

Redatores Técnicos

Designers de Iteração

Basicão da Metodologia de Desenvolvimento XP

Arquitetos

Papéis

Luiz Rauber para o FLISOL 2010 em

Caxias do Sul, 24/04/2010

Programadores

Usuários

Referências

eXtreme Programming

Recursos Humanos

http://luizrauber.blogspot.com

Analista de Testes

Gerentes de Produto

Executivos

Metodologias Ágeis?

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)