Programming

Daniel Pohren

eXtreme

Quem faz programa?

Por que cerca de 80% a 90% dos projetos de SW fracassam?

Principais Problemas

Atrasos no cronograma

Falta de planejamento (lei do 80/20)

Inmeros bugs

Incompreenso dos requisitos de negcio e sistema

Mudanas constantes podendo estar relacionadas a requisitos, cronograma, equipe...

Direitos do Cliente

Por Ron Jeffries

Planejamento Geral, definindo o que pode ser realizado, quando e a que custo Ver e acompanhar o andamento do projeto e, principalmente, o progresso do SW, passando por testes definidos em conjunto com a equipe Mudar de idia, substituir funcionalidades, sem pagar custos exorbitantes Ser informado de mudanas no cronograma, em tempo de escolher e reduzir o escopo Poder cancelar o projeto a qualquer momento e ainda assim ter um sistema funcionando, refletindo o investimento realizado at o momento

Direitos do Desenvolvedor

Por Ron Jeffries

Saber o que necessrio, com declaraes claras de prioridade Produzir trabalho de qualidade o tempo todo Pedir e receber ajuda da equipe, superiores e clientes Fazer e atualizar suas prprias estimativas Aceitar as suas responsabilidades, ao invs de t-las impostas

Desenvolvimento de SW no passado
Processos Tradicionais
Analisar, projetar e s depois iniciar codificao

Prever o futuro Temores

Ter certeza do que se sabe hoje ser exatamente o que se quer amanh Mudana de requisitos depois de concluda a fase de anlise e projeto (Play not to loose)

Custo

Tempo

Desenvolvimento de SW hoje
Processos modernos incentivam pequenas iteraes
Mudanas em etapas posteriores se tornam mais baratas

Adotar a mudana

- A Engenharia de SW diferente das outras engenharias - Componentes, frameworks, BDs podem absorver o alto custo da mudana (play to win)

Custo

Tempo

Manifesto gil
Estamos evidenciando maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse trabalho, passamos a valorizar:

Interao entre pessoas MAIS QUE processos e ferramentas; Software em funcionamento MAIS QUE documentao abrangente; Colaborao com o cliente MAIS QUE negociao de contratos;

Responder a mudanas MAIS QUE seguir um plano.

Ou seja, mesmo tendo valor os itens direita, valorizamos mais os itens esquerda.
Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, Ward Cunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arie van Bennekum, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Brian Marick, Ken Schwaber, Jeff Shuterland, Dave Thomas

eXtreme Programming
Disciplina de desenvolvimento de SW, voltada para equipes pequenas e mdias, com requisitos vagos ou que mudam freqentemente Criado por Kent Beck, Ron Jeffries e Ward Cunningham Principal tarefa a codificao nfases - Menor em processos formais de desenvolvimento
- maior em disciplina rigorosa

Aborda

TDD, participao do cliente como membro da equipe, reviso permanente do cdigo, refactoring, integrao contnua, refinamento contnuo da arquitetura, planejamento

Valores do XP
Comunicao
Prticas valorizam a comunicao, no limitada a procedimentos formais

Simplicidade

Incentiva ao extremo prticas que reduzam a complexidade

Feedback

Prticas garantem um rpido feedback sobre vrias partes do projeto

Coragem

Prticas aumentam a confiana dos desenvolvedores e do prprio cliente

Variveis de um Projeto

Processos Tradicionais
Tempo Escopo Custo

Manipula-se a Qualidade

eXtreme Programming
Tempo Qualidade Custo

Manipula-se a Escopo

Ciclo de Vida
Cliente
Implementa funcionalidades

Desenvolvedor

Escolhe Prioridades

Comunicao Simplicidade Feedback Coragem

Cliente

Define escopo

Desenvolvedor

Estima T-F-C

Prticas XP

Equipe (Whole Team)

Equipe XP = Cliente + Time de Desenvolvimento
As funes do cliente englobam:
Definio dos requisitos do projeto Definio de prioridades Controle do rumo do projeto Definir os testes de aceitao do SW

Os papis do time de desenvolvimento englobam:

desenvolvedores testadores (ajudam o cliente com os testes de aceitao) analistas/projetistas (ajudam o cliente a definir requisitos) gerente (garante os recursos necessrios) coach (orienta a equipe, controlando a aplicao do XP) tracker (coleta as mtricas do projeto)

Jogo de Planejamento (Planning Game)

Principais definies
- Estimativas de cada tarefa - Prioridades (tarefas + importantes)

Prximos passos
- Planejamento de release (cliente prope as funcionalidades e desenvolvedores avaliam) - Planejamento da iterao (define as funcionalidades da iterao e os desenvolvedores estimam)

timo feedback para o cliente, que dirige o projeto

- Idia clara do avano do projeto - Clareza: Reduo de Riscos, aumentando a chance de sucesso

Testes de Aceitao (Customer Tests)

So elaborados pelo cliente em conjunto com analistas e testadores
- So automatizados - Quando rodarem com sucesso, funcionalidade foi implementada - Devem ser rodados a cada iterao

timo feedback para o cliente

- Pode se saber, a qualquer momento, o % de implementao do SW e quanto falta

Pequenos Lanamentos (Small Releases)

Disponibiliza a cada iterao SW 100% funcional
Verso disponibilizada imediatamente Reduo de riscos (se o projeto terminar, parte existe e funciona) Deteco prvia de problemas Comunicao entre cliente e desenvolvedor

Cada lanamento possui funcionalidades prioritrias para a iterao Lanamento pode ser destinado a
- usurio/cliente (testa, avalia e oferece feedback) - usurio/final (sempre que possvel)

Design simples e integrao contnua so prticas essenciais

Projeto Simples (Simple Design)

Projeto est presente em todas as etapas XP
Projeto comea simples e se mantm assim atravs de testes e refinamento de cdigo (refactoring)

Em XP, levado ao extremo

No permitido implementar qualquer funcionalidade adicional que no ser usada na iterao atual

Implementao ideal aquela que

- Passa por todos os testes - Expressa todas as idias definidas no planejamento - No contm cdigo duplicado ou que cheire

Prever o futuro impossvel e anti-XP

Programao em Pares (Pair Programming)

SW desenvolvido em pares
- 2 cabeas juntas so melhores que duas cabeas separadas - 1 piloto e 1 co-piloto - Papis so alternados freqentemente

Benefcios
Melhor qualidade de cdigo (refactoring, testes) Reviso constante do cdigo Nivelamento da equipe Maior comunicao

Um pelo preo de Dois??

Pesquisas demonstram que duplas produzem cdigo de melhor qualidade em aproximadamente o mesmo tempo que programadores que trabalham sozinhos

Desenvolvimento dirigido por Testes (Test-driven Development)

XP valoriza o desenvolvimento dirigido por testes
So automatizados, executados o tempo todo

Testes puxam o desenvolvimento

Cada unidade de cdigo s tem valor se o teste funcionar 100%

Testes do coragem para mudar

De que adianta a OO isolar a interface da implementao se o desenvolvedor tem medo de mudar a implementao?

TDD
Obter tarefa
Criar Cdigo de Teste para a tarefa Codificar Fazer Refactoring

Passou nos testes?

Sim: Nova tarefa

No: Revisar cdigo

Desenvolvimento dirigido por Testes (Test-driven Development)

Refinamento de Cdigo (Refactoring)

Design melhorado continuamente atravs de refinamento

- Mudana proposital no cdigo que est funcionando - Melhorar sua estrutura interna sem alterar a funcionalidade - Visa simplificar o cdigo, remover o cdigo duplicado

Principal referncia o catlogo de refactorings de Martin Fowler

Existncia prvia de testes fundamental para utilizao desta prtica (elimina o medo dos desenvolvedores de adotar a mudana)

Integrao Contnua (Continuous Integration)

XP mantm o SW integrado o tempo todo
- Realizada pelo menos uma vez por dia - Para integrar, deve-se realizar os testes primeiro

Reduz o tempo passado no inferno da integrao - Martin Fowler

Benefcios
- Expe o estado atual de desenvolvimento - Oferece feedback - Estimula agilidade e verses freqentes do SW

Posse Coletiva (Collective Ownership)

O cdigo tem um nico dono: a equipe
- Qualquer par de programadores pode melhorar o cdigo - Reviso constante do cdigo - Aumenta a comunicao - Aumenta a qualidade (menos duplicao, maior coeso) e diminui os riscos de dependncia de indivduos

Todos compartilham a responsabilidade pelas alteraes

Ideal que se troque os pares periodicamente

- Todos conhecem tudo - Testes e integrao contnua so essenciais e do segurana

Padres de Codificao (Coding Standards)

Os padres de codificao so definidos pela equipe
- Organizao de cdigo - Nomenclaturas

Cdigo com aspecto de escrito por um nico desenvolvedor

- Competncia - Organizao

Prticas e valores favorecidos

Posse coletiva Comunicao Programao em Pares Refactoring Projeto Simples

Metfora (Metaphor)

Equipes XP mantm uma viso compartilhada do sistema

Analogia com outros sistemas (natural, computacional, abstrato)

tima fonte de comunicao entre a equipe, facilitando inclusive as estimativas

Pattern de alto nvel

Ritmo Saudvel (Sustainable Pace)

XP est na arena para ganhar

Projetos vampiros no so projetos XP

- Semanas de 80 horas - Cdigo ruim, relaxamento da disciplina, stress da equipe - Tempo ganho ser perdido depois

So aceitveis eventuais horas extras quando a produtividade maximizada

Reunies em P (Stand-up Meeting)

A maioria dos desenvolvedores odeiam reunies
- Assuntos demorados e desgastantes - Impedem os desenvolvedores de codificar

As reunies so valiosas quando

- No perdem o foco - So breves

So abordadas tarefas realizadas e a realizar

Spikes de Planejamento (Spike Solution)

So investigaes de tecnologias que podem ser utilizadas no projeto

- Auxiliam nas estimativas e na especificao do projeto - Podem durar horas ou dias, porm devem ser curtos

Englobam
Avaliaes de arquiteturas Algoritmos componentes e frameworks BDs Servidores de aplicao, Web Utilizao de artefatos e ferramentas

Principais ferramentas que apoiam as prticas XP

Mercado
HP Ford Symantec Motorola Chrysler BMW Borland IBM First National Bank Thought Works CC Pace Systems Industrial Logic Moore Workshare Xerox Siemens Object Mentor Objective Solutions ImproveIt Brasil Telecom Embrapa Qualiti APOENA Software Livre Argonavis CETIP Secretaria da Fazenda SP Smart Tech Consulting iQualy IME-USP EverSystems PowerLogic Consultoria UFRJ PUC-Rio Surya Tecnologia Bluestar Technology

Pesquisas na Web

Pesquisas na Web

Pesquisas na Web

Principais Eventos XP

Adotando e Escalando XP
Adote as prticas em doses homeopticas
- No seja afobado, saboreie a mudana - Enfatize o problema mais importante

Dificuldades culturais
Deixar algum mexer no seu cdigo Pedir ajuda nsia de tentar prever o futuro Escrever testes antes de codificar Refatorar com freqncia (superar o medo)

Situaes difceis de aplicar XP

- Equipes grandes e distribudas geograficamente - Perda do controle sobre cdigo - Feedback demorado

Adotando e Escalando XP
XP e os processos geis valorizam as pessoas
Bons desenvolvedores criam bons SWs

Processos mtodos

geis

so

suplementos

aos

outros

- So atitudes - So efetivos - No um ataque documentao e sim a criao de documentos que tem valor - No so para todos

O segredo est na sinergia de suas prticas

Menos formalidade, mais diverso

Consideraes Finais
XP uma disciplina de desenvolvimento gil de SW baseada em comunicao, feedback, simplicidade e coragem Para usar XP preciso fazer com que a equipe se una em torno de prticas simples, obtendo feedback e reajustando estas prticas para cada situao particular XP pode ser implementada aos poucos, porm, a maior parte das prticas so essenciais Nem todos os projetos so bons candidatos para XP XP no para todo mundo, mas todo mundo pode aprender com XP

Principais Fontes
http://agilemanifesto.org http://www.agilemodeling.com http://www.extremeprogramming.org http://www.xprogramming.com http://www.pairprogramming.com http://www.martinfowler.com http://wwwobjectmentor.com http://www.c2.com http://www.xispe.com.br http://www.naphta.com.br/xpmanager.html

XP-RS
http://www.xp-rs.org
Guilherme Lacerda (APOENA) e Daniel Wildt (BlueStar) Criada em 05/04 aps evento do RSJUG Aproximadamente 240 inscritos Principal idia: criar reunies mensais e fortalecer XP no RS

Muito Obrigado!

eXtreme

Programming

Daniel Pohren daniel@naphta.com.br