A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "1/30 Visão Geral sobre o XP – eXtreme Programming Alexandre Monteiro."— Transcrição da apresentação:

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

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

3 3/30 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 4/30 Metodologias Ágeis eXtreme Programming eXtreme Programming FDD Lean Software Development Cristal Family Scrum (...)

5 5/30 Kent Beck 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 O surgimento do XP

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

7 7/30 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 8/30 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 9/30 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 10/30 Mudar não é tão caro Requisitos Análise ProjetoImplementaçãoTestesProdução t custo

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

12 12/30 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 13/30 Coragem Extreme Programming é novo e diferente Atitude é mais importante que processo Coragem pra dizer a verdade, para recomeçar do zero, para inovar

14 14/30 Feedback Feedback Comunicação Feedback aumenta aprendizado e produtividade

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

16 16/30 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 17/30 Boas Práticas Test First Design Refactoring Stand-up Meeting Continuous Integration 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. 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. Reuniões rápidas e diárias com a equipe A reconstrução baseia-se na remoção de redundância, eliminação de funcionalidades inúteis, e reconstrução de projetos obsoletos.

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

19 19/30 Boas Práticas The Customer is Always Available Small Release Simple Design O cliente está sempre disponível para resolver dúvidas, alterar o escopo de uma iteração e definir prioridades. O código está, a qualquer momento, na forma mais simples que passe todos os testes. 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.

20 20/30 Boas Práticas 40-Hour Week On-Site Customer Acceptance Tests 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. Ter um papel de cliente na equipe XP em tempo integral para responder as perguntas São definidos pelo usuário e são os critérios de aceitação do software.

21 21/30 Boas Práticas System Metaphor 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 22/30 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 23/30 Papéis no XP Xp Gold Owner (Cliente - O proprietário do ouro Xp Gold Owner (Cliente - O proprietário do ouro) É quem paga pelo sistema, geralmente o dono da empresa. Deve fazer: Escrever User Stories Definir prioridades Definir testes de aceitação Validar testes de aceitação Esclarecer dúvidas Xp Goal Donor Não deve fazer: Implementar código Definir quanto tempo uma tarefa leva para ser feita

24 24/30 Papéis no XP Xp Coach Xp Tracker Responsável pela negociação com o cliente quanto ao escopo e pela coordenação do Planning Game. Coordenadores 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)

25 25/30 Papéis no XP 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 Programador (Driver/Partner)

26 26/30 Um Projeto XP

27 27/30

28 28/30 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.

29 29/30 Conclusão Extreme Programming Atitude Disciplina Mudança é algo normal Aceitar, não fugir Conjunto de boas práticas

30 30/30 Referências XPRecife – Grupo de Estudos de Métodos Ágeis de Recife Xispê – Portal Brasileiro de XP


Carregar ppt "1/30 Visão Geral sobre o XP – eXtreme Programming Alexandre Monteiro."

Apresentações semelhantes


Anúncios Google