EXtreme Programming Grupo Pará.

Apresentação em tema: "EXtreme Programming Grupo Pará."— Transcrição da apresentação:

1 eXtreme Programming Grupo Pará

2 1 -Definição “XP é a arte de maximizar a quantidade de software que você não vai fazer” ImprovIT “XP é um jeito leve, eficiente, de baixo risco, flexível, preditivo, científico e divertido de se desenvolver software” Kent Beck “XP é uma disciplina, porque existem coisas que você precisa fazer para dizer que está fazendo XP ” Kent Beck Se revisar código é bom, faremos o tempo inteiro (programação em par). Se testar é bom, vamos testar o tempo inteiro (testes unitários) e o cliente também (testes funcionais). Se um projeto eficiente é bom, será uma rotina (refatoração). XP como disciplina: é uma questão cultural.

3 2 - Valores do XP Comunicação Simplicidade Feedback Coragem

4 Comunicação Sincroniza o time em torno do mesmo objetivo

5 Comunicação Práticas de comunicação
Programação em par colocam as pessoas lado a lado sem individualismo Testes unitários esclarecem os objetivos do código fonte Estimativas envolvem programadores, gerentes e clientes

6 Simplicidade Coisas simples são mais fáceis de entender, manter, construir em cima e, se for necessário, derrubar e refazer

7 Simplicidade A tendência de software é o custo de mudança aumentar ao longo do tempo

8 Simplicidade A proposta é achatar essa curva

9 Simplicidade Itens complexos demoram. Você vai perder tempo em algo que não será usado?

10 Feedback Quanto antes você tiver feedback sobre uma situação, mais rápido você pode agir

11 Feedback Formas de feedback:
Estimativa imediata do time para o cliente Leitura do código (pergunte ao sistema) Testes unitários / TDD Testes funcionais Integração Contínua Deploy Contínuo

12 Coragem “Coragem é resistência ao medo, domínio do medo, e não ausência do medo.” Mark Twain

13 Papéis Gerente de projetos
Responsável pelo relacionamento entre equipe e cliente. Reporta o andamento, os problemas e os riscos. Filtra para a equipe de desenvolvimento os aspectos administrativos e burocráticos. Contatar clientes, agendar, garantir a presença do cliente; Garantem à equipe: equipamentos, softwares, itens de escritório.

14 Papéis Gerente de projetos
Deve compreender os valores e práticas da XP. Mentalidade industrial representa ameaça ao projeto. (programação em par, equipe gerenciável. ritmo sustentável (40h/semana, industria: repetição, software: criatividade/esforço mental, cansaço)) Desaconselháveis fazer com que uma pessoa assuma o papel de gerente e coach. proximidade: coach-equipe-tecnico, gerente=cliente=admin

15 Papéis Coach Assegura que a equipe respeita e utiliza os valores e práticas do XP. Possui conhecimento técnico e do processo de desenvolvimento de software. Sendo o XP voltado para o comportamento humano, o coach verifica o andamento e mostra eventuais erros.

16 Papéis Analista de testes Testa e garante a qualidade do sistema.
Ajuda o cliente a escrever testes de aceitação e que assegura que o sistema os respeite. Não envolvido com o desenvolvimento. (Visão de fora, não da codificação.)

17 Papéis Redator técnico Mantém a documentação do sistema atualizada.
Evita envolver o desenvolvedor na documentação. Sintonia com a equipe e cliente

18 Papéis Desenvolvedor Analisa, projeta, codifica.
Equipe multidisciplinar (membros exercem vários papéis em momentos diferentes do projeto). Não existe aristocracia ou hierarquia. Todos aprendem com todos (programação em par)

19 3 – Práticas do XP

20 Envolvimento do Cliente
Sugere que os usuários finais sejam envolvidos diretamente no processo de desenvolvimento. Vantagens: Feedback rápido Percepção se o que está implementado consegue ser usado facilmente pelos usuários finais.

21 Releases Curtos Melhor fazer pequenos lotes de trabalho de cada vez, validá-los e só então seguir adiante. Quando os erros são descobertos rapidamente e abrangem um escopo pequeno, solucionar torna-se mais fácil.

22 Jogo do Planejamento O que fazer na próxima semana
Estórias (cliente escreve) Estimativa Seleção de cartões Aguarde e confie Reunião diária

23 Jogo do Planejamento Estórias (Cliente escreve)

24 Jogo do Planejamento Estimativa

25 Jogo do Planejamento Seleção de estórias

26 Jogo do Planejamento Aguarde e confie...

27 Jogo do Planejamento

28 Jogo do Planejamento Reuniões diárias

29 Jogo do Planejamento Reunião diária
Ocorre todos os dias, com todos os membros da equipe. Objetiva,15 min, em pé. O que cada um fez no dia anterior (equipe atualizada com o andamento do projeto) O que será feito (quais cartões,quem faz o quê, decisões tomadas em equipe).

30 Programação em Par Une várias técnicas em uma só:
Revisão de código Correções imediatas Evita acumulo de pequenos erros. Melhor Modelagem da Solução Todo desenvolvimento feito em pares. Um computador, dois programadores. Um piloto, um co-piloto Papéis são alternados freqüentemente Pares são trocados periodicamente

31 Programação em Par Um digita, outro revisa código, e os dois discutem soluções juntos. Interpretação errada: uma pessoa trabalha, e a outra fica parada (desperdício).

32 Programação em Par Pressão do Par
Minimiza focos de distração (bate papo, , etc...). Responsabilidade compartilhada.

33 Programação em Par Revezamento Fundamental. Não há regra definida.
Desenvolvedores sabem hora de trocar.

34 Programação em Par Disseminação de Conhecimento
Troca de par incentiva disseminação de conhecimento. Nivela equipe por alto. Facilita inserção de novos membros.

35 Programação em Par Benefícios:
Melhor qualidade do design, código e testes Revisão constante do código Nivelamento da equipe Maior comunicação

36 Programação em Par Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores trabalhando sozinho.

37 Programação em Par Principais Desafios
Exige que as pessoas envolvidas sejam receptivas, compreensivas umas com as outras, engajadas e, sobretudo, humildes. Organização física do escritório. Visão Gerencial: desenvolvedores vistos como operários.

38 Desenvolvimento guiado por testes
Testar é a parte do desenvolvimento de software que todo mundo sabe que precisa ser feita, mas ninguém quer fazer. Software é complexo, erros são inevitáveis (natureza lógica, atenção, interpretação de requisitos).

39 Desenvolvimento guiado por testes
ACEITE ISSO!

40 Desenvolvimento guiado por testes
É possível fazer algo QUANDO os erros são detectados e diminuir QUANTO de impacto será causado no cronograma. Diminuir o tempo entre uma ação e o feedback que ela gera é essencial para o aprendizado.

41 Desenvolvimento guiado por testes
Plano de saúde Prevenir x Remediar

42 Desenvolvimento guiado por testes
Prevenindo… Investimento monetário inicial Benefícios a longo prazo Custo inferior comparado à necessidade de remediar em caso de fatalidade

43 Desenvolvimento guiado por testes
Doenças = Bugs = Tempo de depuração Aumento do custo (tempo de inserção tempo de descoberta)

44 Desenvolvimento guiado por testes
Testes expõem o defeito assim que ele entra no sistema. Testes dizem exatamente ONDE está o erro.

45 Desenvolvimento guiado por testes
TESTES DE UNIDADE - realizado em cada classe do sistema para verificar se o resultado gerado é correto. TESTE DE ACEITAÇÃO - realizado sobre cada funcionalidade, ou estórias do sistema. A interação entre várias classes que implementam uma funcionalidade.

46 Desenvolvimento guiado por testes
TESTES AUTOMATIZADOS - Classes que testam outras classes

47 Desenvolvimento guiado por testes
Testes dão confiança ao time, pois diminuem o risco da mudança

48 Refatoração Conceito Porque Refatorar? Quando Refatorar?
Como Refatorar? Riscos e impedimentos Reflexão

49 Refatoração "Refatoração é o processo de alteração
de um sistema de software de modo que  o comportamento externo do código  não mude, mas que sua estrutura interna  seja melhorada." Vinícius Teles, citando ASTELS

50 Refatoração Conceito A Refatoração é utilizada após a implementação da funcionalidade, ou seja, depois que a função estiver sendo executada perfeitamente, usa-se a Refatoração.

51 Refatoração Por que refatorar? Mudança contínua de Requisitos
Refatorar melhora o projeto do software Torna o software mais fácil de entender Ajuda a encontrar falhas Ajuda a programar mais rapidamente 

52 Refatoração Quando refatorar? Regra de três Quando acrescentar funções
Quando existe duplicação Quando precisar consertar uma falha Enquanto revisa o código

53 Refatoração Como refatorar?
O primeiro passo para Refatorar é criar um sólido conjunto de testes para o  trecho de código.

54 Refatoração Riscos e impedimentos Desenvolver códigos com erros
Sem metodologia de Refatoração o risco aumenta Tempo: pode ocorrer atraso no término do produto Gera custos

55 Refatoração Reflexão Se Refatorar me toma mais tempo, me dá mais trabalho, que a implementação da funcionalidade em si, então porque Refatorar? Trabalhando desta maneira você se assegura que conseguirá adicionar uma próxima funcionalidade com menos esforço, e assim sucessivamente

56 Integração Contínua Integrar e testar o sistema inteiro diversas vezes por dia. Ferramentas: SVN, TFS, etc O build rápido é uma prioridade. Código coletivo.

57 Metáfora Construir ideais para explicar outras ideias.

58 A Documentação do Projeto
Documentar não é o Objetivo Principal. Documenta-se o mínimo necessário antes. A documentação mais abrangente acontece quando o código está pronto.

59 A Documentação do Projeto
Documentos que compõem a documentação: Estória. Testes. Javadoc Diagramas de classe. – Rational Rose Modelos de dados. Manual do usuário. UML. Fotos.

60 4.Conclusões XP leva princípios e práticas do senso comum a níveis extremos: Se revisar o código é bom, revisaremos o tempo inteiro (programação em par); Se testar é bom, todos vão testar o tempo inteiro; Se o projeto é bom, ele fará parte das funções diárias de todos (refatoração);

61 Conclusões Se simplicidade é bom, sempre deixaremos o sistema com o projeto mais que simples que suporte a funcionalidade atual; Se testes de integração são importantes, vamos integrar e testar várias vezes ao dia; Se iterações são boas, faremos iterações muito, muito pequenas - horas e semanas, não meses e anos;

62 5. Fontes [Beck 2004] Kent Beck. Extreme Programming Explained. Addison-Wesley, 2004. [Teles 2004] Vinícius Manhães Teles. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo software com agilidade e alta qualidade. Novatec, 2004. [Improve IT]

63 Perguntas ?