Extreme Programming (XP)
Introdução
- Alguns super-programadores (e irreverentes!) de smalltalk decidiram criar um processo
simples de desenvolvimento de software
- Talvez achando que os outros processos eram complexos?!?
- Ward Cunningham, Ron Jeffries, Martin Fowler, Kent Beck
- Cunningham e Beck são a turma do cartão CRC
- Cuidado! XP foi testado para times pequenos e talvez requeira excelentes programadores.
Não se sabe a aplicabilidade geral da técnica
- Não é para qualquer um, mas pode ter resultado impressionantes
- Muita informação aqui sobre
isso. Vale a pena conferir.
- Também tem um excelente livro de Beck
Extreme Programming
- Alegação básica: software é difícil demais para gastar tempo com coisas que não
são importantes
- Então, o que é importante?
- Codificar: se, no final do dia, o programa não funciona e
não ajuda o cliente a ganhar dinheiro, você não fez nada
- Testar: você tem que saber quando terminou. Os testes
dizem isso. Se você for inteligente, vai escrevê-los primeiro para saber
instantaneamente quando você terminou
- Escutar: tem que saber qual é o problema a resolver.
Escute clientes, gerentes e pessoas do negócio
- Refatorar: você tem que escutar o que o programa está
dizendo para você sobre sua própria estrutura e colocar este conhecimento de volta no
programa
- Se alguém falar para você que fazer software é outra coisa (além de codificar,
testar, escutar, refatorar), ele está tentando lhe vender algo
- Não falei que eram irreverentes?!
- Por isso, inventaram uma disciplina de desenvolvimento de software (xp) baseada nos
seguintes valores:
- Simplicidade
- Comunicação
- Feedback
- Agressividade
- As práticas de XP foram definidas para balancear as forças
agindo no projeto
Resumo do processo (com links para o wiki)
- Planejamento feito com o PlanningGame
- Autoridade é delegada para os clientes definirem os requisitos usando UserStories (parecem Use Cases)
- Autoridade é delegada para os clientes estabelecerem as prioridades de desenvolvimento
das estórias
- Autoridade é delegada para os desenvolvedores estimarem
quanto tempo cada estória levará para ser desenvolvida
- Esta delegação de autoridade (que é rara!) provê um ambiente de desenvolvimento
livre de estresse
- Os clientes possuem boa informação sobre quanto tempo as coisas levam e podem portanto
maximizar o custo-benefício das estórias que são desenvolvidas primeiro
- Os desenvolvedores pouco se importam com as funcionalidades pedidas (o que também é
raro!), porque eles estimam quanto tempo as coisas levam
- Já que delegar as prioridades para o cliente pode ser perigoso em alguns casos (pedir
algo fundamental mas difícil no fim do projeto é perigoso!), há uma regra que balanceia
as coisas: as piores coisas são atacadas primeiro (WorstThingsFirst)
- Semelhante ao processo unificado "risk-confronting"
- O trabalho é acompanhado através de um cronograma (CommitmentSchedule) revisado a cada
poucas iterações
- Para avaliar novos riscos e oportunidades
- As iterações são planejadas (IterationPlanning)
entre desenvolvedores e clientes
- Nada é feito que não seja imediatamente útil e
necessário para não impactar os prazos de desenvolvimento (YouArentGonnaNeedIt)
- Eles não acreditam em pensar muito no futuro para se preparar para o que vem depois
- Faça funcionar o UserStory de hoje!
- A simplicidade sempre reina: só se usa a solução mais simples que satisfaça os
requisitos do problema (DoTheSimplestThingThatCouldPossiblyWork)
- As duas regras acima (YouArentGonnaNeedIt
e DoTheSimplestThingThatCouldPossiblyWork)
acabam gerando código que precisa ser alterado às vezes. Para simplificar a
manutenção/evolução, o código tem que estar sempre limpo e não duplicado. A regra é
refatorar impiedosamente (RefactorMercilessly).
Práticas de XP
- Para terminar esta introdução, eis a lista de práticas de XP (leia cada uma dessas
práticas no wiki e resuma cada uma em uma frase nas suas próprias palavras)
- DoTheSimplestThingThatCouldPossiblyWork
encoraja não sobre-projetar (nem sub-projetar)
- AskTheCode porque ele sabe (... dizer
que precisa ser refatorado, ... dizer onde está o bug, ...)
- UnitTests: essa turma testa, testa, testa
... para não quebrar o código um do outro. Unit testes são escritos para cada classe e
testados usando o TestingFramework.
Testes de unidade pertencem ao desenvolvedor.
- FunctionalTests para testar as
estórias e saber se as necessidades do usuário estão sendo atingidas. Os usuários
forneceram os dados usados nestes testes. Testes funcionais pertencem ao cliente.
- ContinuousIntegration gerando
um processo iterativo para evitar IntegrationHell.
A integração de uma nova versão de algo (mesmo pequeno) é quase instantânea, logo
depois dos testes.
- ContinuousIntegrationRelentlessTesting
(como acima, mas lembrando que tem que testar, testar e testar)
- RefactorMercilessly para manter
o código limpo e o progresso rápido (ver também WikiPagesAboutRefactoring).
Só funciona bem se tiver muitos testes para se assegurar de que não quebrou nada.
- Recomenda-se chegar à ExtremeNormalForm
- "Your classes are small and your methods are small; you've said everything OnceAndOnlyOnce and you've removed the
last piece of unnecessary code.
Somewhere far away an aikido master stands in a quiet room. he is centered.. aware.. ready
for anything.
Outside a sprinter shakes out her legs and settles into the block, waiting for the crack
of the gun while a cool wind arches across the track.
Ssoftly, a bell sounds.. all of your tests have passed.
Your code is in ExtremeNormalForm...
tuned to today and poised to strike at tomorrow."
- ProgrammingInPairs provê
qualidade mais alta, treinamento mútuo e velocidade mais alta. Use uma pessoa menos
experiente no teclado e uma mais experiente junto.
- SpikeSolution soluções
exploratórias rápidas para certos problemas
- ModelFirst mais SpartanUserInterface ajudam a
manter o foco nas necessidades do usuário. SpartanUserInterface significa
fazer uma interface simples e deixar o usuário usar, melhorar o que atrapalha, jogar fora
o que não é usado até que o resultado satisfaça.
- ExtremePlanning bolar um mapa
rápido da solução global com refinamentos incrementais
- PlanningGame para formalizar os papeis
e responsabilidades no planejamento
- CountDownToRelease discute como
usar ExtremePlanning quando a data de
release final se aproxima. As regras:
- ExtremeReuse adotando software de
terceiros e adequando-o a XP pela construção de testes
- TossIt para fazer e manter projetos magros,
jogue o que não parece útil pela janela. Não precisa ser mantido, documentado, etc.
- SystemMetaphor formas de comunicar o
sistema para outros e os próprios desenvolvedores. Outras palavras para arquitetura
- Pouca coisa: algumas classes, alguns padrões, ...
- XpDesign quem projeta em XP e quando?
- Solução: o time (pequeno) inteiro usando CRC
- ExtremeDocuments documentação
faz parte, embora ela seja diferente às vezes
- Para requisitos: UserStories e FunctionalTests (Sim! testes funcionais
são requisitos que devem ser satisfeitos! Pense sobre isso ...)
- Para análise e design: nenhum documento, só cartões CRC
- Para codificação: um comentário por classe, se necessário
- Se o usuário quiser um documento, manual, etc. é só fazer um UserStory pedindo!
- SupportCrisis o que fazer quando a
m..... bate no ventilador?
- Regra 1: pareça calmo (não precisa sê-lo, só parecer)
- Regra 2: escreva cada problema num cartão
- Regra 3: atribua um fator de urgência a cada cartão
- Regra 4: trate de um cartão de cada vez. faça o primeiro. faça o segundo, ... até
que a crise vá embora.
etc-2 programa anterior
próxima