eXtreme Programming Grupo Pará

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.

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

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

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

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

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

Simplicidade A proposta é achatar essa curva

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

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

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

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

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.

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

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.

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

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

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)

3 – Práticas do XP

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.

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.

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

Jogo do Planejamento Estórias (Cliente escreve)

Jogo do Planejamento Estimativa

Jogo do Planejamento Seleção de estórias

Jogo do Planejamento Aguarde e confie...

Jogo do Planejamento

Jogo do Planejamento Reuniões diárias

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

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

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

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

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

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.

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

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

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.

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

Desenvolvimento guiado por testes ACEITE ISSO!

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.

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

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

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

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

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.

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

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

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

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

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.

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 

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

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

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

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

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.

Metáfora Construir ideais para explicar outras ideias.

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.

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.

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

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;

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] http://improveit.com.br

Perguntas ?