Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Basicão da Metodologia Desenvolvimento XP

Basicão da Metodologia Desenvolvimento XP

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Basicão da Metodologia Desenvolvimento XP

Informações Importantes
http://luizrauber.blogspot.com Motivos?
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 Luiz Rauber para o FLISOL 2010 em
Caxias do Sul, 24/04/2010 Basicão da Metodologia de Desenvolvimento XP 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! Porque tais coisas ditas? Cliente é quem vai pagar! Cliente é que sabe o quê o software
deve fazer.
Cliente é que vai usar. 4° Cliente Acertar Metodologias Ágeis Porquê precisa ficar assim?

Se fulano erra, não preciso errar também! Metodologias Ágeis? XP/ Scrum/ DSDM Foco em Projetos Pequenos
(”dividir para conquistar”) Google/ Yahoo/ Microsoft “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) Manifesto Ágil eXtreme Programming ”A arte de maximizar a quantidade de software que você não irá fazer.” Vinícius Teles
3° Divisão Ideal equipes pequenas
(<10-15 pessoas) Foco em Comunicação Efetiva. Cliente x Programador
TDD Exaustivamente
Desenvolvimento Incremental
Diminuição Custos Mudanças


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
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 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

Simplicidade
Não fazer mais que a necessidade
Evitar ”firulas”
Ver com cliente real necessidade de certas exigências
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
Economia
Fazer o que da retorno primeiro
Reutilização/ Novas Funcionalidades
Falha
Experimentar na busca erro
Feedback concreto

Flow/ Fluidez
Ir e vir sem problemas
Diminuir a curva custos
Humanismo
Programador também é gente
Melhoria
Fazer melhor, na próxima interação
Oportunidade
Bug? Conhecimento pra todos
Passos de Bebê
Menos é mais
Qualidade
Mais é menos

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

Papéis Redatores Técnicos Gerentes de Projeto Designers de Iteração Arquitetos Programadores Recursos Humanos Usuários Analista de Testes Gerentes de Produto Executivos Práticas 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 <
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
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
Ambiente Informativo
Informações sobre/ andamento
Quadros/ Murais
Avisos – Post it
Cartões visíveis

Stand Up Meeting
Prioridades do Dia
Olhadela quadro tarefas
Assumir atividade

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

Retrospectiva iteração
Não era isso que eu queria
Agora Sim/ Não
Isso deu Certo/ Errado
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? Custo de Mudança torna-se complexidade

E tempo torna-se desmotivação

Fazer 1x por ciclo 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
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 + Personalizados
- Prateleira
Cliente sabe o que quer e sabe que dá pra fazer!
(embora normalmente não se consegue entender o que ele quer)
Não reinventem a roda
Procurem desafios para aprender
É possível melhorar sempre

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 Referências Espaço Dúvidas


críticas?
sugestões? Obrigado! 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
Full transcript