Extreme Programming

Abrace a mudança!

Extreme Programming

Juan di Carlo Damasceno

Maurício Linhares

Manifesto Ágil

Organizando a bagunça e as idéias

Princípios

Indivíduos e interações mais que processos e ferramentas

Software funcional mais que extensa documentação

Colaboração com o cliente mais que negociação de contratos

Responder à mudança mais que seguir um plano

Chrysler C3

Nascimento do XP

Onde – Quando - Como

Chrysler

Março de 1996

Projeto C3 (Chrysler Comprehensive Compensation)

Dirigir

“Dirigir não é colocar o carro na direção certa, é manter uma atenção constante e

corrigir sempre que necessário”

Mãe do Kent Beck

Isso é XP!

Prestar atenção

Adaptar

Mudar

A mudança é um problema?

Requerimentos mudam Modelos mudam Negócios mudam Tecnologias mudam Times mudam Membros do time mudam

Tudo muda!

A mudança não é um problema, é uma realidade

Então, qual o problema?

Lidar com a mudança!

O que é XP?

São ciclos curtos de desenvolvimento; É o planejamento incremental e

baseado no conhecimento atual; É a habilidade de flexibilizar os prazos

para entrega de implementações; É apoiar-se em testes automatizados

para fazer mudanças;

O que é XP?

É confiança na comunicação oral, testes automáticos e código para “falar” sobre o projeto;

É se basear em uma modelagem evolucionária que abraça a mudança;

É apoiar a colaboração constante das pessoas envolvidas;

É basear-se em práticas que funcionam no curto e no longo prazo;

Ciclo básico de um projeto XP

1. Planning Game (normalmente uma manhã no primeiro dia da semana)

1. Definir as estórias

2. Definir prioridades

3. Pontuar histórias

2. Definir quem vai implementar o que

3. Implementar

4. Entregar a estória implementada

5. Tudo outra vez até o projeto acabar

Ciclo contínuo

Modelagem

Testes

PlanejamentoCodificação

Só isso? Como é que pode?

Como é que eles conseguem fazer o Eclipse, Hibernate, MyFaces e Spring desse jeito?

As bases do XP

Valores

“O que lhe traz problemas não é o que você não sabe, mas o que você acha que sabe e não sabe”

Will Rogers

Comunicação

Ninguém sabe tudo

Times só trabalham juntos quando se comunicam juntos

Comunicação eficiente é a que melhor serve ao time no momento

Simplicidade

Qual a coisa mais simples que poderia funcionar?

Simples não é simplista

Simplicidade depende do contexto (qual o nível do time?)

Feedback

Direções mudam

Não é possível fazer certo “de primeira” (ou é?)

Feedback demais também não é bom

Coragem

Heróis (burros) morrem cedo É controlar o medo É tomar a decisão quando ela deve

ser tomada É não se esconder atrás de uma pilha

de papéis ou documentos assinados

Respeito

Goste do que você faz Goste das pessoas com as quais

você trabalha Goste do lugar aonde você trabalha “Eu sou importante, assim como

você”

Outros?

O que as pessoas ao seu redor valorizam?

Princípios

Guiando o comportamento

Humanidade

Pessoas...produzem softwaretem necessidades própriasdevem ser respeitadasdevem se sentir segurasdevem se sentir importantes

Economia

Software não é de graça Sucesso tecnológico nem sempre é

sucesso econômico Software que não oferece valor para o

cliente, não vale os recursos que consumiu

Primeiro o mais importante economicamente, depois o resto

Benefício Mútuo

Se algo não é bom pra um dos lados, não é bom pra ninguém

Ganhar-Ganhar-Ganhar é a ordem

Esforços desnecessários não são toleráveis

Auto-Similaridade

Tem algo funcionando lá embaixo? Faça o mesmo aqui em cima!

Soluções únicas não são ruins, mas normalmente são incomuns

Evolução

“Excelência não é um modo de agir, mas um hábito” – Aristóteles

Faça o melhor possível hoje

Não existe processo perfeito

Tudo deve evoluir

Diversidade

Times homogêneos sobem e descem juntos

Pessoas diferentes com experiências diferentes se completam

Já imaginou time de futebol só de atacantes?

Reflexão

Analisar Porque? Analisar Como? Analisar Reflexão vem após a ação Aprender é refletir sobre a ação

Fluxo

Não somos fábricas...

...mas o fluxo não pode ser descontínuo demais

Integração contínua é a lei

Oportunidade

Problemas como chances de mudar

“Sobreviver” não é o suficiente

Não aprender hoje é tirar nota baixa amanhã outra vez

Não esqueça Murphy!

Redundancia

“Como é que é? Não tem plano B?”

Existem várias maneiras de se resolver um único problema, porque não tentar elas?

Remover redundância apenas quando ela realmente não servir pra nada

Falhar

Não funciona? Jogue fora!

Tá “mais ou menos”? Jogue fora!

Fugir da falha hoje é pedir pra fugir ainda mais quando o cliente ligar reclamando amanhã

Qualidade

Menos qualidade não quer dizer menos tempo

Mais qualidade não quer dizer mais tempo

Mais qualidade – Menos bugs – Mais clientes – Mais $$$$

Passos de bebê

Cuidado pra não tropeçar

Quanto maior a altura, pior a queda

Um passo de cada vez, mas também não precisa se arrastar

Aceitar Responsabilidade

Não está seguro pra fazer? Diga que não faz

Não sabe se a pessoa pode fazer? Não mande ela fazer

Não tem ninguém aqui que sabe? Encontre alguém fora que saiba!

Responsabilidade é aceita, não obrigada

Práticas

Luz! Câmeras! Ação!

Todo mundo junto

Time junto, todo no mesmo lugar, todos escutando uns aos outros

Time Completo

Somos uma família

Espaço informativo

Quem está alocado em qual projeto? Qual é a minha estória? O que foi que eu já fiz? O que foi que meu par já fez? O que ainda falta fazer?

Trabalho energizado

Nada de horas extras

Nada de matar o fim de semana

Nada de matar o happy-hour

Nade de ficar sem CS na quinta à noite

Pessoas cansadas e sem motivação não produzem, enrolam

Programação em Par

Duas cabeças pensam melhor que uma

O código é de todos...

...e o conhecimento também

Estórias

Deixe o cliente definir Simples e diretas, ele não deve saber

nem definir implementação Não entendeu? Pergunte a ele

denovo! Estória grande? Quebre-a em tarefas!

Cartão de estória

Ciclo semanal

Planejar o trabalho para apenas uma semana;

Quando menor o tamanho do ciclo:Mais fácil planejar;Mais fácil se manter no prazo;Mais fácil de se ter feedback do

cliente;

Ciclo mensal (ou de 4 semanas)

Definição de rumos de um projeto; Manter foco na implementação do

que é interessante para o cliente; Muitas falhas? Muitos problemas? Hora de arrumar a casa;

Ócio

É, isso mesmo que você viu aí em cima;

Não, ninguém tem que trabalhar o dia todo (nem ninguém trabalha, diga-se de passagem);

Ócio não quer dizer não trabalhar, mas ter tempo pra fazer alguma coisa diferente;

O mais famoso produto do ócio de um programador

Build em 10 minutos

Se o seu projeto demora mais do que 10 minutos pra terminar o build, tá na hora de ajeitar isso;

Qual programador gosta de apertar um botão ter que esperar mais do que 10 minutos pra poder testar o que acabou de desenvolver?

Integração contínua

Todo dia, todo turno, toda hora, o sistema deve estar funcional e executando;

Não se faz commit de código que não funciona;

Integrando continuamente e cedo, até os problemas de comunicação desaparecem;

Teste primeiro – Programe depois

Primeiro se escreve o teste; Depois se implementa a

funcionalidade até que ela passe no teste;

A implementação é direcionada a resolver um problema real, não a imaginação do programador;

É difícil de testar? Está errado!

Modelagem incremental

Ninguém conhece o modelo todo antes de começar a implementar;

A implementação modifica o modelo “perfeito” pensado pelo analista;

O conhecimento pelo domínio do modelo vem com a implementação e a interação com pessoas que entendem “do riscado”;

Um time XP

Escalando a seleção

Papéis

Testadores Desenvolvedores de interações Arquitetos Gerentes de projeto Gerentes de produto Executivos Escritores de material técnico Usuários Programadores Recursos humanos

Mundo perfeito

Quando não usar XP?

Quando não usar XP?

Quando as pessoas não querem mudar;

Quando o cliente quer a análise toda antes de começar o sistema;

Quando a empresa valoriza workaholics;

Quando a complexidade é absolutamente necessária;

Quando não usar XP?

Quando os testes automáticos não são fáceis ou até mesmo possíveis de serem feitos;

Quando o local de desenvolvimento do projeto não ajuda;

“There’s no silver bullet”

Frederick P. Brooks

Conclusão

XP não é fácil de aplicar em ambientes que resistem a mudanças;

É provavelmente um dos mais difíceis e “engessados” processos de software;

É a fonte do sucesso gigantesco de grandes projetos de software;

Conclusão

É foco no que é interessante para quem paga, não para quem recebe;

É valorizar as pessoas que desenvolvem o projeto, não os papéis que elas produzem;

É entender que quem funciona é o código, não documentação obsoleta;

Referências

Extreme Programming Explained: Embrace Change, Second Edition. Kent Beck, Cynthia Andres. Addisson Wesley, 2004;

Extreme Programming Explained. Kent Beck. Addisson Wesley, 1999;

The Mythical Man-Month: Essays on Software Engineering. Frederick P. Brooks. Addisson Wesley, 1975-1995.

Referências

eXtreme Programming -> http://www.extremeprogramming.org/

Eclipse Project -> http://eclipse.org/ JUnit -> http://junit.org/ Wikipedia -> http://en.wikipedia.org/