1 / 30

Visão Geral sobre o XP – eXtreme Programming

Visão Geral sobre o XP – eXtreme Programming. Alexandre Monteiro. Manifesto Ágil [1/5]. Assinado por 17 desenvolvedores com reconhecimento mundial em Utah em fevereiro/2001. Declaração de 4 valores http://www.agilemanifesto.org/. Manifesto Ágil [2/2].

saul
Download Presentation

Visão Geral sobre o XP – eXtreme Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Visão Geral sobre o XP – eXtreme Programming Alexandre Monteiro

  2. Manifesto Ágil [1/5] • Assinado por 17 desenvolvedores com reconhecimento mundial em Utah em fevereiro/2001. • Declaração de 4 valores • http://www.agilemanifesto.org/

  3. Manifesto Ágil [2/2] “Estamos evidenciando maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a entender que: • Indivíduos e interações são mais importantes que processos e ferramentas. • Software funcionandoé mais importante do que documentação completa e detalhada. • Colaboração com o cliente é mais importante do que negociação de contratos. • Adaptação a mudanças é mais importante do que seguir o plano inicial. Ou seja, mesmo tendo valor os itens à direita, valorizamos mais os itens à esquerda. “

  4. Metodologias Ágeis • eXtreme Programming • FDD • Lean Software Development • Cristal Family • Scrum • (...)

  5. O surgimento do XP • Em meados de 1990, Kent Beck procurou formas mais simples e eficientes de desenvolver software • Identificou o que tornava simples e o que dificultava o desenvolvimento de software • Em Março de 1996, ele iniciou um projeto com novos conceitos que resultaram na metodologia XP - eXtreme Programming

  6. O que é eXtreme Programming? “Trata-se de uma metodologia ágil para equipes pequenas e médias desenvolvendo software com requisitos vagos e em constante mudança” Kent Beck

  7. Programando ao Extremo • Levar todas as boas práticas ao Extremo • Se testar é bom, vamos testar toda hora!! • Se projetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa! • Se integrar é bom, vamos integrar a maior quantidade de vezes possível! • Se iterações curtas é bom, vamos deixar as iterações realmente curtas!

  8. Mudanças sempre ocorrem • Clientes não sabem o que querem no início • Desenvolvedores não sabem qual a melhor maneira de fazer o software no início • Medo da mudança trava o desenvolvimento

  9. Avanços • Nos últimos 30 anos... • Melhoria nos processos • Iterativo Incremental • Melhorias nas ferramentas • IDEs, automação... • Maior abstração no desenvolvimento • Orientação a Objetos • Orientação a Aspectos • Orientação a ...

  10. Mudar não é tão caro custo t Requisitos Análise Projeto Implementação Testes Produção

  11. XP inclui... • Comunicação • Coragem • Feedback • Simplicidade • Respeito

  12. Comunicação • Soluções de problemas normalmente já são conhecidas... • O problema é a solução chegar a quem precisa • Comunicação face a face é a maneira mais rápida de “espalhar” conhecimento

  13. Coragem • Extreme Programming é novo e diferente • Atitude é mais importante que processo • Coragem pra dizer a verdade, para recomeçar do zero, para inovar

  14. Feedback • Feedback <-> Comunicação • Feedback aumenta aprendizado e produtividade

  15. Simplicidade • Regra geral • Pensar sempre : “ O que pode ser feito que seja o mais simples que funciona?” • Simplicidade normalmente gera mais valor Geração de valor overhead Simplicidade

  16. Respeito • Coragem, Feedback, Simplicidade, Comunicação... • Respeito é necessário para tirar o máximo desses valores • Respeito pelo próximo • Feedback, Comunicação • Respeito por si mesmo • Coragem, Simplicidade

  17. Test First Design Refactoring Stand-up Meeting Continuous Integration Boas Práticas A criação de testes leva em conta não o tempo ganho com a criação dos mesmos antes da codificação, mas conhecer previamente as possíveis falhas do seu sistema. A reconstrução baseia-se na remoção de redundância, eliminação de funcionalidades inúteis, e reconstrução de projetos obsoletos. Reuniões rápidas e diárias com a equipe Os diversos módulos do software são integrados diversas vezes por dia e todos os testes unitários são executados. O código não passa até obter sucesso em 100% dos testes unitários.

  18. Pair Programming Move People Around CollectiveCodeOwnership CodingStandards Boas Práticas Todo código de produção é desenvolvido por duas pessoas trabalhando com o mesmo teclado, o mesmo mouse e o mesmo monitor. As duplas de programação são revezadas em média a cada 2h. E equipe como um todo é responsável por cada arquivo de código. Não é preciso pedir autorização para alterar qualquer arquivo. Todo código é desenvolvido seguindo um padrão.

  19. The Customer is Always Available Small Release Simple Design Boas Práticas O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma iteração e definir prioridades. O software é entregue em pequenas versões para que o cliente possa obter o seu ganho o mais cedo possível e para minimizar riscos. O código está, a qualquer momento, na forma mais simples que passe todos os testes.

  20. 40-Hour Week On-Site Customer Acceptance Tests Ter um papel de cliente na equipe XP em tempo integral para responder as perguntas Boas Práticas Cada programador trabalha 40 horas por semana. Se o horário for flexível, deve-se respeitar o horário do par naquele período, senão enquanto um trabalha o outro vai pra casa . São definidos pelo usuário e são os critérios de aceitação do software.

  21. System Metaphor Boas Práticas Ajuda a manter todos os desenvolvedores em sintonia com o projeto quando dando nomes a objetos ou classes. A idéia é que exista um objeto "produto" que sofre várias modificações ao longo da "linha de montagem", onde outros objetos trabalham sobre o produto. A vantagem é que é simples adicionar "máquinas novas" a linha de montagem. A Fábrica Quando o "produto" precisa passar pela mão de várias pessoas, às vezes para conhecimento, aprovação ou modificação do conteúdo. Podem existir modificações feitas pelo sistema, nesse caso, existem "destinatários virtuais" que recebem a mensagem, analisam e despacham para quem deve. A diferença básica do Correio para a Fábrica é que ele não segue uma linha. O Correio O objeto é um "turista", o Servlet e o Banco são hospedagens, os dados são a bagagem, o objeto que tira os dados do "turista" e coloca ou no Servlet (em XML) ou no Banco são "carregadores de bagagem". Quando a "bagagem" está guardada no hotel "Banco de Dados" o "turista" recebe um ticket da bagagem para poder pegar ela depois (o Identificador único da tabela). Turista

  22. Papéis no XP Big Boss / XpManager • Deve fazer: • Agendar reuniões; • Escrever atas; • Manter o XP Tracker informado dos acontecimentos das reuniões • Não deve fazer: • Deixar que problemas externos interfiram no desenvolvimento • Dizer quando as coisas devem acontecer • Dizer às pessoas o que fazer • Cobrar das pessoas

  23. Papéis no XP Xp Gold Owner (Cliente - O proprietário do ouro) É quempaga pelo sistema, geralmente o dono da empresa. Xp Goal Donor • Deve fazer: • Escrever User Stories • Definir prioridades • Definir testes de aceitação • Validar testes de aceitação • Esclarecer dúvidas • Não deve fazer: • Implementar código • Definir quanto tempo uma tarefa leva para ser feita

  24. Papéis no XP Coordenadores Xp Coach Xp Tracker Responsável pela negociação com o cliente quanto ao escopo e pela coordenação do Planning Game. • Deve fazer: • Coletar métricas • Manter todos informados do que está acontecendo • Definir testes de aceitação • Tomar atitudes diante de problemas • Sugerir sessões de CRC (Class, Responsabilities , Collaboration) métricas

  25. Papéis no XP Programador (Driver/Partner) • Deve fazer: • Estimar prazos de User Stories • Implementar código de produção • Trabalhar em par • Fazer refactoring • Corrigir bugs • Não deve fazer: • Criar/Alterar novas funcionalidades • Escrever testes de aceitação

  26. Um Projeto XP

  27. Planejamento das iterações • Divida o projeto em etapas de 1 ou 2 semanas; • Considere prazos fixos e escolha um dia da semana para integrações e entregas; (segunda ou sexta-feira); • Planeje reuniões diárias para acompanhar a evolução do projeto (“stand-up”, meeting matinal); • As iterações serão as unidades de referência para fazer estimativas; • Entre no jogo para entregar um produto a cada iteração.

  28. Conclusão • Extreme Programming • Atitude • Disciplina • Mudança é algo normal • Aceitar, não fugir • Conjunto de boas práticas

  29. Referências • XPRecife – Grupo de Estudos de Métodos Ágeis de Recife • www.cin.ufpe.br/~xprecife • Xispê – Portal Brasileiro de XP • www.xispe.com.br

More Related