ConhecendoConhecendo o o

eeXXtremetreme PProgrammingrogramming

Quem sou eu?

Guilherme Lacerdaguilhermeslacerda@gmail.com

� Mestre em Ciência da Computação, área de Engenharia de Software (UFRGS)

� Professor de Graduação (FACENSA e UniRitter) e Pós-Graduação (UniRitter)

� Consultor de TI, com mais de 15 anos na área de desenvolvimento de Software e 10 anosde experiência em modelagem e desenvolvimento OO

� Instrutor/Consultor de Metodologias Ágeis da TargetTrust

� Pioneiro em Metodologias Ágeis no Brasil (Lean, SCRUM e XP)

� Fundador do XP-RS (Grupo de Usuários de Metodologias Ágeis do RS) e Vice-Coordenadordo GUMA (Grupo de Usuários de Metodologias Ágeis) vinculado a SUCESU-RS

� Editor do Portal InfoQ Brasil

� Membro do IASA e da Scrum Alliance

Quem faz programa?

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

Fonte: Standish Group

� Sistemas entregues com atrasos e/ou orçamento estourado

Principais Problemas

� Sistemas entregues com atrasos e/ou orçamento estourado

� Não atendem os requisitos de negócio

� Clientes descontentes (sem confiança nos desenvolvedores)

� Clientes não têm compreensão clara do que é desenvolvido

� Clientes não dão suporte correto para o desenvolvimento

� Clientes não estão interessados em participar de processoscomplexos

� Desenvolvedores trabalham muitas horas!

� Desenvolvedores relaxam na disciplina

� Desenvolvedores perdem o foco

Principais Problemas

� Desenvolvedores perdem o foco

� Processos prescritivos são atrativos para a gerência mas não paraos desenvolvedores� Baseados no paradigma do comando e controle

� Tenta minimizar o papel do cliente

� Foco em tecnologia e não no negócio

Como resolvê-los?

Como resolvê-los?

� Características importantes:� Foco nas necessidades do cliente (resultado!)

� Ágil é ser rápido, ligeiro (dicionário)� Eficaz: produz o resultado esperado� Eficiente: produz o resultado esperado, mas com qualidade

O que é ser Ágil?

� Foco nas necessidades do cliente (resultado!)� Liderança� Envolvimento das pessoas� Melhoria Contínua� Tomada de decisões baseada em análise de dados e informações(controle!)

� Planejamento Geral, definindo o que pode ser realizado, quando e aque custo

� Ver e acompanhar o andamento do projeto e, principalmente, oprogresso do SW, passando por testes definidos em conjunto com aequipe

Direitos do Cliente (Ron Jeffries)

� Mudar de idéia, substituir funcionalidades, sem pagar custosexorbitantes

� Ser informado de mudanças no cronograma, em tempo de escolher ereduzir o escopo

� Poder cancelar o projeto a qualquer momento e ainda assim ter umsistema funcionando, refletindo o investimento realizado até omomento

� Saber o que é necessário, com declarações claras deprioridade

� Produzir trabalho de qualidade o tempo todo

Direitos do Desenvolvedor (Ron Jeffries)

� Pedir e receber ajuda da equipe, superiores e clientes

� Fazer e atualizar suas próprias estimativas

� Aceitar as suas responsabilidades, ao invés de tê-las impostas

� Processos Tradicionais� Analisar, projetar e só depois iniciar codificação

� Prever o futuro� Ter certeza do que se sabe hoje será exatamente o que se quer amanhã

� Temores� Mudança de requisitos depois de concluída a fase de análise e projeto

Processos de Software

“Estamos evidenciando maneiras melhores de desenvolversoftware fazendo-o nós mesmos e ajudando outros a fazê-lo.Através desse trabalho, passamos a valorizar:

� Interação entre pessoas MAIS QUE processos e ferramentas;

� Software em funcionamento MAIS QUE documentação abrangente;

� Responder a mudanças MAIS QUE seguir um plano.

Manifesto Ágil

� Colaboração com o cliente MAIS QUE negociação de contratos;

� Responder a mudanças MAIS QUE seguir um plano.

Ou seja, mesmo tendo valor os itens à direita, valorizamosmais os itens à esquerda.”

Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, WardCunningham, 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

Utah – Fevereiro de 2001

Waterfall X Ágil

Cone da Incerteza

� Riscos de Planejamento� Será que conseguiremosterminar até outubro?

� Riscos de Custo

Riscos

� Riscos de Custo� Será que conseguiremos comprar o servidor pelo preço definidoanteriormente?

� Riscos de Requisitos� Será que temos todas as informações para começar o trabalho?

Alto RiscoAlto Valor

Baixo RiscoAlto Valor

Alto RiscoBaixo Valor

Baixo RiscoBaixo Valor

Risco

Risco X Valor

Valor

Fazer Primeiro

Fazer depois

Evitar

Fazer por último

Risco

Valor

Waterfall, Iterativo

eXtreme Programming

eXtremeeXtreme ProgrammingProgrammingeXtremeeXtreme ProgrammingProgramming

Criado por Kent Beck, Ron Jeffries e Ward Cunningham

XP

� Criado por Kent Beck, Ron Jeffries e Ward Cunningham

� Principal tarefa é a codificação

� Disciplina de desenvolvimento de SW, voltada para equipespequenas e médias, com requisitos vagos ou que mudamfreqüentemente

XP

� Comunicação

Valores

� Comunicação� Práticas valorizam a comunicação, não limitada a procedimentos formais

� Simplicidade� Incentiva ao extremo práticas que reduzam a complexidade

� Feedback� Práticas garantem um rápido feedback sobre várias partes do projeto

� Coragem� Práticas aumentam a confiança dos desenvolvedores e do próprio cliente

Comunicação

Comunicação

Comunicação

Processos Tradicionais � Tempo� Escopo� Custo

Manipula-se aQualidade

Variáveis de um Projeto

eXtreme Programming

� Tempo� Qualidade� Custo

Manipula-se aEscopo

XP

Práticas organizacionais

Práticas de equipe

Práticas de pares

Equipe (Whole Team)

Equipe XP = Cliente + Time de Desenvolvimento

� As funções do cliente englobam:

� Definição dos requisitos do projeto� Definição de prioridades� Controle do rumo do projeto� Controle do rumo do projeto� Definir os testes de aceitação do SW

� Os papéis do time de desenvolvimento englobam:

� desenvolvedores� testadores (ajudam o cliente com os testes de aceitação)� analistas/projetistas (ajudam o cliente a definir requisitos)� gerente (garante os recursos necessários)� coach (orienta a equipe, controlando a aplicação do XP)� tracker (coleta as métricas do projeto)

Equipe (Whole Team)

Jogo de Planejamento (Planning Game)

� Principais definições

� Definição das User Stories (atividade + tarefas)� Estimativas de User Stories� Prioridades (tarefas + importantes)

� Próximos passos

� Planejamento de release (cliente propõe as funcionalidades e� Planejamento de release (cliente propõe as funcionalidades edesenvolvedores avaliam)� Planejamento da iteração (define as funcionalidades da iteração e osdesenvolvedores estimam)

� Ótimo feedback para o cliente, que dirige o projeto

� Idéia clara do avanço do projeto� Clareza: Redução de Riscos, aumentando a chance de sucesso

Produto, Release, Planejamento

Release 1 Release 2 Release 3

Planejamento

Iteração 1 Iteração 2 Iteração 3-5

Tarefa A

Tarefa B

Tarefa C

Releases, Iterações, Velocidade

� Um release é formado de múltiplas iterações

� Cada iteração pode ser planejada com o mesma caixa de tempo

� Stories são colocadas dentro de cada caixa, até estar completa

�� O tamanho da caixa é a velocidade planejada

3 4

5

2 6

3 4

5

2 6

2 7

4

4 5

Testes de Aceitação (Acceptance Tests)

� São elaborados pelo cliente em conjunto com analistas e testadores

� São automatizados� Quando rodarem com sucesso, funcionalidade foi implementada� Devem ser rodados a cada iteração� Roteiro com um conjunto de respostas esperadas

� Ótimo feedback para o cliente

� Pode se saber, a qualquer momento, o % de implementação do SW equanto falta

Pequenos Lançamentos (Small Releases)

� Disponibiliza a cada iteração SW 100% funcional� Versão disponibilizada imediatamente� Redução de riscos (se o projeto terminar, parte existe e funciona)� Detecção prévia de problemas� Comunicação entre cliente e desenvolvedor

� Cada lançamento possui funcionalidades prioritárias para a iteração� Cada lançamento possui funcionalidades prioritárias para a iteração

� Lançamento pode ser destinado a� usuário/cliente (testa, avalia e oferece feedback)� usuário/final (sempre que possível)

� Design simples e integração contínua são práticas essenciais

Projeto Simples (Simple Design)

� Projeto está presente em todas as etapas XP� Projeto começa simples e se mantém assim através de testes erefinamento de código (refactoring)

� Não é permitido implementar qualquer funcionalidade adicional quenão será usada na iteração atual

� Em XP, é levado ao extremo

� Implementação ideal é aquela que

não será usada na iteração atual

� Prever o futuro é impossível e é “anti-XP”

� Passa por todos os testes� Expressa todas as idéias definidas no planejamento� Não contém código duplicado ou que “cheire”

Programação em Pares (Pair Programming)

� SW é desenvolvido em pares� “2 cabeças juntas são melhores que duas cabeças separadas”� 1 piloto e 1 co-piloto� Papéis são alternados freqüentemente

� Melhor qualidade de código (refactoring, testes)� Revisão constante do código

� Benefícios

� “Um” pelo preço de “Dois”??

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

� Pesquisas demonstram que duplas produzem código de melhorqualidade em aproximadamente o mesmo tempo que programadoresque trabalham sozinhos

Programação em Pares (Pair Programming)

� Efeitos sobre a produtividade da equipe� “Um trabalha enquanto o outro não faz nada...”� Pressupõe comunicação contínua� pesquisas mostram atividades desempenhadas na metade do tempo dedesenvolvimento� Produtividade a curto prazo X longo prazo

� Pressão do Par

� Desafios

�Concentração, incentivo, responsabilidade� Revezamentos� Disseminação do conhecimento

� Pressão do Par

�Organização do escritório, visão gerencial, relacionamento humano,competição

Desenvolvimento Dirigido por Testes (Test-Driven Development)

� XP valoriza o desenvolvimento dirigido por testes

� Testes “puxam” o desenvolvimento

� São automatizados, executados o tempo todo

� Testes dão coragem para mudar

� Cada unidade de código só tem valor se o teste funcionar 100%

� De que adianta a OO isolar a interface da implementação se odesenvolvedor tem medo de mudar a implementação?

Desenvolvimento Dirigido por Testes (Test-Driven Development)

Obtertarefa Criar Código de

Teste para a tarefa

TDD

Codificar Fazer RefactoringTeste para a tarefa Refactoring

Passou nos testes?

Sim: Nova tarefa Não: Revisar código

Refatoração (Refactoring)

� Design é melhorado continuamente através de refinamento� Mudança proposital no código que está funcionando� Melhorar sua estrutura interna sem alterar a funcionalidade� Visa simplificar o código, remover o código duplicado

� Principal referência é o catálogo de refactorings de Martin Fowler

� Existência prévia de testes é fundamental para utilização destaprática (elimina o medo dos desenvolvedores de adotar a mudança)

� Principal referência é o catálogo de refactorings de Martin Fowler

� “Software é como a nossa casa”� Organizados X desorganizados

� XP enfatiza código de alta qualidade

Integração Contínua (Continuous Integration)

� XP mantém 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 integração” - Martin Fowler

� Benefícios� Expõe o estado atual de desenvolvimento� Oferece feedback� Estimula agilidade e versões freqüentes do SW

Posse Coletiva (Collective Ownership)

� O código tem um único dono: a equipe� Qualquer par de programadores pode melhorar o código� Revisão constante do código� Aumenta a comunicação� Aumenta a qualidade (menos duplicação, maior coesão) e diminui osriscos de dependência de indivíduos

� Todos compartilham a responsabilidade pelas alterações

� “Todos conhecem tudo”� Testes e integração contínua são essenciais e dão segurança

� Ideal que se troque os pares periodicamente

Padrões de Codificação (Coding Standards)

� Os padrões de codificação são definidos pela equipe� Organização de código� Nomenclaturas

� Código com aspecto de escrito por um único desenvolvedor

� Competência� Organização

� Posse coletiva� Comunicação� Programação em Pares� Refactoring� Projeto Simples

� Práticas e valores favorecidos

� Organização

Metáfora (Metaphor)

� Equipes XP mantém uma visão compartilhada do sistema�Analogia com outros sistemas (natural, computacional, abstrato)�Exercício de criatividade e abstração

�� Ótima fonte de comunicação entre a equipe, facilitando inclusive asestimativas

� Pattern de alto nível

Ritmo Saudável (Sustainable Pace)

� XP está na arena para ganhar

� Semanas de 80 horas

� Projetos vampiros não são projetos XP

� Semanas de 80 horas� Código ruim, relaxamento da disciplina, stress da equipe� Tempo ganho será perdido depois

� São aceitáveis eventuais horas extras quando a produtividade émaximizada

Reuniões em Pé (StandUp Mettings)

� A maioria dos desenvolvedores odeiam reuniões

� As reuniões são valiosas quando

� Assuntos demorados e desgastantes� Impedem os desenvolvedores de codificar

� Não perdem o foco� São breves

� As reuniões são valiosas quando

� São abordadas tarefas realizadas e a realizar

Spikes de Planejamento (Spike Solution)

� São investigações de tecnologias que podem ser utilizadas noprojeto

�

� Auxiliam nas estimativas e na especificação do projeto� Podem durar horas ou dias, porém devem ser curtos

� Avaliações de arquiteturas� Algoritmos� componentes e frameworks� BDs� Servidores de aplicação, Web� Utilização de artefatos e ferramentas

� Englobam

Ambiente de Trabalho

� O ambiente deve apoiar a aplicação das práticas

� Equipamentos

� Tem importância vital para um projeto de software� Trabalhar próximo dos colegas� Facilitar a comunicação

� Mesas e cadeiras� Equipamentos tecnológicos� Telefones� Mural� Quadro Branco� Calendário� Comida ☺

� Isolamento (equipes e projetos)

� Equipamentos

Documentação Ágil

� Complexidade do Software� Tempo de desenvolvimento� Equipes� Futuras manutenções

� Até que ponto documentar?

� Uso incorreto da documentação

� User stories, testes de aceitação, testes de unidade, documentação decódigo fonte, Modelo de Classes, Modelo de Dados, Processos deNegócio, Manual de usuário, Acompanhamento diário,Acompanhamento do Projeto

� Documentos que compõem a documentação

� Uso incorreto da documentação� Quando documentar?

Ferramentas de Apoio

Mais em http://xprogramming.com/software.htm

IDEs

IDEs

Teste de Unidade

Teste de Unidade

Teste de Unidade

Testes Funcionais

Patterns, Boas Práticas, Refactoring

Patterns, Boas Práticas, Refactoring

Code Coverage

Code Coverage

Code Coverage

Code Coverage

Code Coverage

Code Coverage

Documentação

Integração Contínua

Integração Contínua

Padrões de Codificação

Padrões de Codificação

Mercado

� HP� Ford� Symantec� Motorola� Chrysler� BMW� Borland� IBM�

� Objective Solutions� ImproveIt� Brasil Telecom� Embrapa� Qualiti� Trevisan Tecnologia� Argonavis� CETIP�

� IBM� First National Bank� Thought Works� CC Pace Systems� Industrial Logic� Moore� Workshare� Xerox� Siemens� Object Mentor

� CETIP� Secretaria da Fazenda SP� Smart Tech Consulting� iQualy� IME-USP� EverSystems� PowerLogic Consultoria� UFRJ� PUC-Rio� Surya Tecnologia

Principais Eventos

Adotando e Escalando XP

� Adote as práticas em doses homeopáticas� Não seja afobado, saboreie a mudança� Enfatize o problema mais importante

� Dificuldades culturais� Deixar alguém mexer no seu código� Pedir ajuda� Pedir ajuda� Ânsia de tentar prever o futuro� Escrever testes antes de codificar� Refatorar com freqüência (superar o medo)

� Situações difíceis de aplicar XP� Equipes grandes e distribuídas geograficamente� Perda do controle sobre código� Feedback demorado

Adotando e Escalando XP

� XP e os processos ágeis valorizam as pessoas� Bons desenvolvedores criam bons SWs

� Processos ágeis são suplementos aos outros métodos� São atitudes� São efetivos� São efetivos� Não é um ataque à documentação e sim a criação de documentos quetem valor� Não são para todos

� O segredo está na sinergia de suas práticas� Menos formalidade, mais diversão

Considerações Finais

� XP é uma disciplina de desenvolvimento ágil de SW baseada em comunicação, feedback, simplicidade e coragem

� Para usar XP é preciso fazer com que a equipe se una em torno depráticas simples, obtendo feedback e reajustando estas práticas paracada situação particular

� XP pode ser implementada aos poucos, porém, a maior parte daspráticas são essenciais

� Nem todos os projetos são bons candidatos para XP.� XP não é para todo mundo, mas todo mundo pode aprender com XP

� Adotar Processos Ágeis não é simplesmente aplicá-lo� É preciso entender sua filosofia

Combinando Lean + SCRUM + XP

Combinando Lean + SCRUM + XP

Formação em Metodologias Ágeis

� Introdução ao Lean – Promovendo a Mudança Cultural (8h)

� Projetos Ágeis com SCRUM – Gestão e Acompanhamento (20h)

� Técnicas para gerar Código de Qualidade com eXtreme Programming(12h)

Cursos In Company e Consultorias

Apoio