Grupo Pará

“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

Comunicação

Simplicidade

Feedback

Coragem

Sincroniza o time em torno do mesmo objetivo

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

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

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

A proposta é achatar essa curva

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

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

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 é resistência ao medo, domínio do medo, e não ausência do medo.” Mark Twain

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.

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

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.

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

Redator técnico Mantém a documentação do sistema

atualizada. Evita envolver o desenvolvedor na

documentação. Sintonia com a equipe e cliente

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)

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.

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.

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

Estórias (Cliente escreve)

Estimativa

Seleção de estórias

Aguarde e confie...

Reuniões diárias

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

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

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

Pressão do Par Minimiza focos de distração (bate papo,

email, etc...). Responsabilidade compartilhada.

Revezamento Fundamental. Não há regra definida. Desenvolvedores sabem hora de trocar.

Disseminação de Conhecimento Troca de par incentiva disseminação

de conhecimento. Nivela equipe por alto. Facilita inserção de novos membros.

Benefícios: Melhor qualidade do design, código e

testes Revisão constante do código Nivelamento da equipe Maior comunicação

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

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.

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

ACEITE ISSO!

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

Plano de saúdePrevenir x Remediar

Prevenindo… Investimento monetário inicial Benefícios a longo prazo Custo inferior comparado à necessidade

de remediar em caso de fatalidade

Doenças = Bugs = Tempo de depuração

Aumento do custo (tempo de inserção ............. tempo de

descoberta)

Testes expõem o defeito assim que ele entra no sistema.

Testes dizem exatamente ONDE está o erro.

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.

TESTES AUTOMATIZADOS - Classes que testam outras classes

Testes dão confiança ao time, pois diminuem o risco da mudança

ConceitoPorque Refatorar?Quando Refatorar? Como Refatorar?Riscos e impedimentosReflexã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

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.

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 

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

Como refatorar? O primeiro passo para Refatorar é criar

um sólido conjunto de testes para o  trecho de código.

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

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

Integrar e testar o sistema inteiro diversas vezes por dia. Ferramentas: SVN, TFS, etc

O build rápido é uma prioridade.

Código coletivo.

Construir ideais para explicar outras ideias.

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.

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.

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

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;

[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

?