SlideShare uma empresa Scribd logo
1 de 78
Baixar para ler offline
Conhecendo o
eXtreme Programming
Quem sou eu?

  Guilherme Lacerda
guilhermeslacerda@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 anos
de 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-Coordenador
do 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
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 processos
complexos
Principais Problemas

Desenvolvedores trabalham muitas horas!

Desenvolvedores relaxam na disciplina

Desenvolvedores perdem o foco

Processos prescritivos são atrativos para a gerência mas não para
os 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?
O que é ser Ágil?

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


Características importantes:
    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!)
Direitos do Cliente (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 idéia, substituir funcionalidades, sem pagar custos
exorbitantes

  Ser informado de mudanças 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 (Ron Jeffries)

  Saber o que é necessário, com declarações claras de
prioridade


 Produzir trabalho de qualidade o tempo todo


 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 de Software
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
Manifesto Ágil
“Estamos evidenciando maneiras melhores de desenvolver
software 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.

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

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
                           Utah – Fevereiro de 2001
Waterfall X Ágil
Cone da Incerteza
Riscos

Riscos de Planejamento
  Será     que      conseguiremos
  terminar até outubro?


Riscos de Custo
  Será que conseguiremos comprar o servidor pelo preço definido
  anteriormente?


Riscos de Requisitos
  Será que temos todas as informações para começar o trabalho?
Risco X Valor
           Alto Risco               Alto Risco
          Baixo Valor               Alto Valor
Risco


          Baixo Risco              Baixo Risco
          Baixo Valor               Alto Valor


                           Valor


             Evitar            Fazer Primeiro
Risco



        Fazer por último           Fazer depois



                        Valor
Waterfall, Iterativo
eXtreme Programming
eXtreme Programming
XP




 Criado por Kent Beck, Ron Jeffries e Ward Cunningham

  Disciplina de desenvolvimento de SW, voltada para equipes
pequenas e médias, com requisitos vagos ou que mudam
freqüentemente

 Principal tarefa é a codificação
XP
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
Variáveis de um Projeto

Processos Tradicionais
  Tempo
  Escopo                          Manipula-se a
  Custo                            Qualidade




eXtreme Programming
  Tempo                          Manipula-se a
  Qualidade                        Escopo
  Custo
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
  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
   desenvolvedores avaliam)
     Planejamento da iteração (define as funcionalidades da iteração e os
   desenvolvedores 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       2
                                       3          7
                                                  4

                           5                  4
                                              5

                       2       6       4
                                       2          5
                                                  6
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 e
  quanto 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


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 e
   refinamento de código (refactoring)


Em XP, é levado ao extremo
     Não é permitido implementar qualquer funcionalidade adicional que
   não será usada na iteração atual


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


Prever o futuro é impossível e é “anti-XP”
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

Benefícios
    Melhor qualidade de código (refactoring, testes)
    Revisão constante do código
    Nivelamento da equipe
    Maior comunicação

“Um” pelo preço de “Dois”??
     Pesquisas demonstram que duplas produzem código de melhor
   qualidade em aproximadamente o mesmo tempo que programadores
   que 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 de
   desenvolvimento
     Produtividade a curto prazo X longo prazo

Pressão do Par
    Concentração, incentivo, responsabilidade
    Revezamentos
    Disseminação do conhecimento

Desafios
    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
    São automatizados, executados o tempo todo



Testes “puxam” o desenvolvimento
   Cada unidade de código só tem valor se o teste funcionar 100%




Testes dão coragem para mudar
   De que adianta a OO isolar a interface da implementação se o
 desenvolvedor tem medo de mudar a implementação?
Desenvolvimento Dirigido por Testes (Test-Driven
                                            Development)



                                       TDD
Obter
tarefa    Criar Código de              Codificar             Fazer
         Teste 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 desta
   prática (elimina o medo dos desenvolvedores de adotar a mudança)

“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 os
  riscos de dependência de indivíduos

Todos compartilham a responsabilidade pelas alterações


Ideal que se troque os pares periodicamente
    “Todos conhecem tudo”
    Testes e integração contínua são essenciais e dão segurança
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



Práticas e valores favorecidos
    Posse coletiva
    Comunicação
    Programação em Pares
    Refactoring
    Projeto Simples
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 as
estimativas




 Pattern de alto nível
Ritmo Saudável (Sustainable Pace)

 XP está na arena para ganhar




 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
    Assuntos demorados e desgastantes
    Impedem os desenvolvedores de codificar




As reuniões são valiosas quando
    Não perdem o foco
    São breves




São abordadas tarefas realizadas e a realizar
Spikes de Planejamento (Spike Solution)

  São investigações de tecnologias que podem ser utilizadas no
projeto
     Auxiliam nas estimativas e na especificação do projeto
     Podem durar horas ou dias, porém devem ser curtos



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

O ambiente deve apoiar a aplicação das práticas
    Tem importância vital para um projeto de software
    Trabalhar próximo dos colegas
    Facilitar a comunicação



Equipamentos
    Mesas e cadeiras
    Equipamentos tecnológicos
    Telefones
    Mural
    Quadro Branco
    Calendário
    Comida ☺
    Isolamento (equipes e projetos)
Documentação Ágil

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

Até que ponto documentar?
   Uso incorreto da documentação
   Quando documentar?

Documentos que compõem a documentação
    User stories, testes de aceitação, testes de unidade, documentação de
  código fonte, Modelo de Classes, Modelo de Dados, Processos de
  Negócio,     Manual      de     usuário,     Acompanhamento      diário,
  Acompanhamento do Projeto
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                    Objective Solutions
Ford                  ImproveIt
Symantec              Brasil Telecom
Motorola              Embrapa
Chrysler              Qualiti
BMW                   Trevisan Tecnologia
Borland               Argonavis
IBM                   CETIP
First National Bank   Secretaria da Fazenda SP
Thought Works         Smart Tech Consulting
CC Pace Systems       iQualy
Industrial Logic      IME-USP
Moore                 EverSystems
Workshare             PowerLogic Consultoria
Xerox                 UFRJ
Siemens               PUC-Rio
Object Mentor         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
    Â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
    Não é um ataque à documentação e sim a criação de documentos que
  tem 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 de
práticas simples, obtendo feedback e reajustando estas práticas para
cada situação particular


  XP pode ser implementada aos poucos, porém, a maior parte das
prá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

Mais conteúdo relacionado

Mais procurados

Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - ResumoDaniel Brandão
 
Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Fernando Kenji Kamei
 
eXtreme Programming (xp)
eXtreme Programming (xp)eXtreme Programming (xp)
eXtreme Programming (xp)Renato Pina
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingDaniel Wildt
 
Extreme Programming (XP) Metodologia Ágil
Extreme Programming (XP) Metodologia ÁgilExtreme Programming (XP) Metodologia Ágil
Extreme Programming (XP) Metodologia ÁgilJaffer Veronezi
 
Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Claudia Melo
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareDaniel Cukier
 
Oficina Métodos Ágeis UDESC
Oficina Métodos Ágeis UDESCOficina Métodos Ágeis UDESC
Oficina Métodos Ágeis UDESCWildtech
 
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...Luiz Lemos
 

Mais procurados (20)

Extreme programming (xp) - Resumo
Extreme programming (xp) - ResumoExtreme programming (xp) - Resumo
Extreme programming (xp) - Resumo
 
Introdução ao TDD
Introdução ao TDDIntrodução ao TDD
Introdução ao TDD
 
Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)Desenvolvimento de Software com Extreme Programming (XP)
Desenvolvimento de Software com Extreme Programming (XP)
 
eXtreme Programming (XP)
eXtreme Programming (XP)eXtreme Programming (XP)
eXtreme Programming (XP)
 
Extreme programming (xp)
 Extreme programming   (xp) Extreme programming   (xp)
Extreme programming (xp)
 
eXtreme Programming (xp)
eXtreme Programming (xp)eXtreme Programming (xp)
eXtreme Programming (xp)
 
Metodologias Ageis
Metodologias AgeisMetodologias Ageis
Metodologias Ageis
 
Conhecendo o eXtreme Programming
Conhecendo o eXtreme ProgrammingConhecendo o eXtreme Programming
Conhecendo o eXtreme Programming
 
Extreme Programming (XP) Metodologia Ágil
Extreme Programming (XP) Metodologia ÁgilExtreme Programming (XP) Metodologia Ágil
Extreme Programming (XP) Metodologia Ágil
 
Extreme Programming XP
Extreme Programming XPExtreme Programming XP
Extreme Programming XP
 
Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)Introdução à Programação Extrema (Extreme Programming - XP)
Introdução à Programação Extrema (Extreme Programming - XP)
 
Programacao Extrema
Programacao ExtremaProgramacao Extrema
Programacao Extrema
 
Introdução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de SoftwareIntrodução a Métodos Ágeis de Desenvolvimento de Software
Introdução a Métodos Ágeis de Desenvolvimento de Software
 
Aula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xpAula03 04 agile_scrum_xp
Aula03 04 agile_scrum_xp
 
Oficina Métodos Ágeis UDESC
Oficina Métodos Ágeis UDESCOficina Métodos Ágeis UDESC
Oficina Métodos Ágeis UDESC
 
Metodologias Ageis
Metodologias AgeisMetodologias Ageis
Metodologias Ageis
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Métodos Ágeis
Métodos ÁgeisMétodos Ágeis
Métodos Ágeis
 
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
 
Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento Metodologias ágeis de desenvolvimento
Metodologias ágeis de desenvolvimento
 

Destaque

(TDC2014) Oba! Cenários Complexos
(TDC2014) Oba! Cenários Complexos(TDC2014) Oba! Cenários Complexos
(TDC2014) Oba! Cenários ComplexosWildtech
 
Agile Brazil 2010 - DSD + Open Source + Agile Methods
Agile Brazil 2010 - DSD + Open Source + Agile MethodsAgile Brazil 2010 - DSD + Open Source + Agile Methods
Agile Brazil 2010 - DSD + Open Source + Agile MethodsWildtech
 
Palestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPROPalestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPROWildtech
 
Agiles 2009 Learning Agile
Agiles 2009 Learning AgileAgiles 2009 Learning Agile
Agiles 2009 Learning AgileWildtech
 
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...Wildtech
 
[XPConfBR2014] Desvendando o eXtreme Programming
[XPConfBR2014] Desvendando o eXtreme Programming[XPConfBR2014] Desvendando o eXtreme Programming
[XPConfBR2014] Desvendando o eXtreme ProgrammingWildtech
 

Destaque (7)

(TDC2014) Oba! Cenários Complexos
(TDC2014) Oba! Cenários Complexos(TDC2014) Oba! Cenários Complexos
(TDC2014) Oba! Cenários Complexos
 
Agile Brazil 2010 - DSD + Open Source + Agile Methods
Agile Brazil 2010 - DSD + Open Source + Agile MethodsAgile Brazil 2010 - DSD + Open Source + Agile Methods
Agile Brazil 2010 - DSD + Open Source + Agile Methods
 
Garra - Manual da Marca
Garra - Manual da MarcaGarra - Manual da Marca
Garra - Manual da Marca
 
Palestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPROPalestra Métodos Ágeis SERPRO
Palestra Métodos Ágeis SERPRO
 
Agiles 2009 Learning Agile
Agiles 2009 Learning AgileAgiles 2009 Learning Agile
Agiles 2009 Learning Agile
 
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...
[VEM2014] PolymorphicView: Visualizando o uso do Polimorfismo em Projetos de ...
 
[XPConfBR2014] Desvendando o eXtreme Programming
[XPConfBR2014] Desvendando o eXtreme Programming[XPConfBR2014] Desvendando o eXtreme Programming
[XPConfBR2014] Desvendando o eXtreme Programming
 

Semelhante a IPA Conhecendo XP

Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareRoberto Brandini
 
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)André Dias
 
Desenvolvimento Ágil de Software com Extreme Programming
Desenvolvimento Ágil de Software com Extreme ProgrammingDesenvolvimento Ágil de Software com Extreme Programming
Desenvolvimento Ágil de Software com Extreme Programmingluizeof
 
A Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao SêniorA Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao SêniorMarcos Pereira
 
Caminhos do Scrum
Caminhos do ScrumCaminhos do Scrum
Caminhos do Scrumjrompkovski
 
Scrum e o Ambiente de Desenvolvimento Ágil
Scrum e o Ambiente de Desenvolvimento ÁgilScrum e o Ambiente de Desenvolvimento Ágil
Scrum e o Ambiente de Desenvolvimento Ágilabacrazy
 
Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Softwarealexandre_malaquias
 
Aplicando eXtreming Programing ao cenário do Borland ALM - BorCon 2003
Aplicando  eXtreming Programing  ao cenário do  Borland ALM - BorCon 2003Aplicando  eXtreming Programing  ao cenário do  Borland ALM - BorCon 2003
Aplicando eXtreming Programing ao cenário do Borland ALM - BorCon 2003Edgar Silva
 
Aula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a ObjetosAula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a ObjetosLeandro Rezende
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCPFrank Coelho
 
1 apresentacao metodologia rcp
1  apresentacao metodologia rcp1  apresentacao metodologia rcp
1 apresentacao metodologia rcpFrank Coelho
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPaulo Furtado
 
Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?Igor Abade
 
Introdução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com ScrumIntrodução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com ScrumJuan Bernabó
 

Semelhante a IPA Conhecendo XP (20)

Gerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de softwareGerenciamento de equipes no desenvolvimento de software
Gerenciamento de equipes no desenvolvimento de software
 
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
 
eXtreme Programming
eXtreme ProgrammingeXtreme Programming
eXtreme Programming
 
Apresentacao UNA
Apresentacao UNAApresentacao UNA
Apresentacao UNA
 
Desenvolvimento Ágil de Software com Extreme Programming
Desenvolvimento Ágil de Software com Extreme ProgrammingDesenvolvimento Ágil de Software com Extreme Programming
Desenvolvimento Ágil de Software com Extreme Programming
 
Métodos Ágeis - Aula02
Métodos Ágeis - Aula02Métodos Ágeis - Aula02
Métodos Ágeis - Aula02
 
A Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao SêniorA Carreira de Desenvolvedor: do Jr ao Sênior
A Carreira de Desenvolvedor: do Jr ao Sênior
 
Caminhos do Scrum
Caminhos do ScrumCaminhos do Scrum
Caminhos do Scrum
 
Scrum 8
Scrum 8Scrum 8
Scrum 8
 
Scrum e o Ambiente de Desenvolvimento Ágil
Scrum e o Ambiente de Desenvolvimento ÁgilScrum e o Ambiente de Desenvolvimento Ágil
Scrum e o Ambiente de Desenvolvimento Ágil
 
Métodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de SoftwareMétodos Ágeis para Desenvolvimento de Software
Métodos Ágeis para Desenvolvimento de Software
 
Aplicando eXtreming Programing ao cenário do Borland ALM - BorCon 2003
Aplicando  eXtreming Programing  ao cenário do  Borland ALM - BorCon 2003Aplicando  eXtreming Programing  ao cenário do  Borland ALM - BorCon 2003
Aplicando eXtreming Programing ao cenário do Borland ALM - BorCon 2003
 
Aula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a ObjetosAula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a Objetos
 
1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP1- Apresentacao Metodologia RCP
1- Apresentacao Metodologia RCP
 
1 apresentacao metodologia rcp
1  apresentacao metodologia rcp1  apresentacao metodologia rcp
1 apresentacao metodologia rcp
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em Juazeiro
 
Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?Menos teste e mais qualidade - como equilibrar essa equação?
Menos teste e mais qualidade - como equilibrar essa equação?
 
38484931 questionario-es
38484931 questionario-es38484931 questionario-es
38484931 questionario-es
 
SETIC Scrum & XP
SETIC Scrum & XPSETIC Scrum & XP
SETIC Scrum & XP
 
Introdução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com ScrumIntrodução A Gestão Ágil De Projetos Com Scrum
Introdução A Gestão Ágil De Projetos Com Scrum
 

Mais de Wildtech

Voltando para as raízes do desenvolvimento ágil
Voltando para as raízes do desenvolvimento ágilVoltando para as raízes do desenvolvimento ágil
Voltando para as raízes do desenvolvimento ágilWildtech
 
O que a agilidade me ensinou no desenvolvimento de software
O que a agilidade me ensinou no desenvolvimento de softwareO que a agilidade me ensinou no desenvolvimento de software
O que a agilidade me ensinou no desenvolvimento de softwareWildtech
 
XP e a Academia
XP e a AcademiaXP e a Academia
XP e a AcademiaWildtech
 
Abordagens para adoção/transformação ágil através de mentoring e coaching
Abordagens para adoção/transformação ágil através de mentoring e coachingAbordagens para adoção/transformação ágil através de mentoring e coaching
Abordagens para adoção/transformação ágil através de mentoring e coachingWildtech
 
TDC 2016 - Agilidade além da TI
TDC 2016 - Agilidade além da TITDC 2016 - Agilidade além da TI
TDC 2016 - Agilidade além da TIWildtech
 
TDC 2016 - Desvendando o Onion Architecture
TDC 2016 - Desvendando o Onion ArchitectureTDC 2016 - Desvendando o Onion Architecture
TDC 2016 - Desvendando o Onion ArchitectureWildtech
 
TDC 2016 - Retrospectivas como Catalisadores de Melhoria Contínua
TDC 2016 - Retrospectivas como Catalisadores de Melhoria ContínuaTDC 2016 - Retrospectivas como Catalisadores de Melhoria Contínua
TDC 2016 - Retrospectivas como Catalisadores de Melhoria ContínuaWildtech
 
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...Wildtech
 
Agile Clinic - Agile Coaching Patterns
Agile Clinic - Agile Coaching PatternsAgile Clinic - Agile Coaching Patterns
Agile Clinic - Agile Coaching PatternsWildtech
 
TDC 2016 - O Novo Professor
TDC 2016 - O Novo ProfessorTDC 2016 - O Novo Professor
TDC 2016 - O Novo ProfessorWildtech
 
Swarm Debugging
Swarm DebuggingSwarm Debugging
Swarm DebuggingWildtech
 
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...Wildtech
 
[Agile brazil2014] Bad Smells em Bancos de Dados
[Agile brazil2014] Bad Smells em Bancos de Dados[Agile brazil2014] Bad Smells em Bancos de Dados
[Agile brazil2014] Bad Smells em Bancos de DadosWildtech
 
5S em Código: Seminário de PHP "Show me the code!"
5S em Código: Seminário de PHP "Show me the code!"5S em Código: Seminário de PHP "Show me the code!"
5S em Código: Seminário de PHP "Show me the code!"Wildtech
 
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)Wildtech
 
Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)Wildtech
 
CBSoft 2013 - Descrição dos Problemas (CbE)
CBSoft 2013 - Descrição dos Problemas (CbE)CBSoft 2013 - Descrição dos Problemas (CbE)
CBSoft 2013 - Descrição dos Problemas (CbE)Wildtech
 
CBSoft2013 - Tutorial Coding By Example
CBSoft2013 - Tutorial Coding By ExampleCBSoft2013 - Tutorial Coding By Example
CBSoft2013 - Tutorial Coding By ExampleWildtech
 
AgileBrazil 2013 - Baby Steps Game
AgileBrazil 2013 - Baby Steps GameAgileBrazil 2013 - Baby Steps Game
AgileBrazil 2013 - Baby Steps GameWildtech
 
AgileDay2012 - Resumo Coding By Example
AgileDay2012 - Resumo Coding By ExampleAgileDay2012 - Resumo Coding By Example
AgileDay2012 - Resumo Coding By ExampleWildtech
 

Mais de Wildtech (20)

Voltando para as raízes do desenvolvimento ágil
Voltando para as raízes do desenvolvimento ágilVoltando para as raízes do desenvolvimento ágil
Voltando para as raízes do desenvolvimento ágil
 
O que a agilidade me ensinou no desenvolvimento de software
O que a agilidade me ensinou no desenvolvimento de softwareO que a agilidade me ensinou no desenvolvimento de software
O que a agilidade me ensinou no desenvolvimento de software
 
XP e a Academia
XP e a AcademiaXP e a Academia
XP e a Academia
 
Abordagens para adoção/transformação ágil através de mentoring e coaching
Abordagens para adoção/transformação ágil através de mentoring e coachingAbordagens para adoção/transformação ágil através de mentoring e coaching
Abordagens para adoção/transformação ágil através de mentoring e coaching
 
TDC 2016 - Agilidade além da TI
TDC 2016 - Agilidade além da TITDC 2016 - Agilidade além da TI
TDC 2016 - Agilidade além da TI
 
TDC 2016 - Desvendando o Onion Architecture
TDC 2016 - Desvendando o Onion ArchitectureTDC 2016 - Desvendando o Onion Architecture
TDC 2016 - Desvendando o Onion Architecture
 
TDC 2016 - Retrospectivas como Catalisadores de Melhoria Contínua
TDC 2016 - Retrospectivas como Catalisadores de Melhoria ContínuaTDC 2016 - Retrospectivas como Catalisadores de Melhoria Contínua
TDC 2016 - Retrospectivas como Catalisadores de Melhoria Contínua
 
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...
QCon 2016 - Estratégias e Desafios na Implantação de Lean no Setor Público e ...
 
Agile Clinic - Agile Coaching Patterns
Agile Clinic - Agile Coaching PatternsAgile Clinic - Agile Coaching Patterns
Agile Clinic - Agile Coaching Patterns
 
TDC 2016 - O Novo Professor
TDC 2016 - O Novo ProfessorTDC 2016 - O Novo Professor
TDC 2016 - O Novo Professor
 
Swarm Debugging
Swarm DebuggingSwarm Debugging
Swarm Debugging
 
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...
(AgileBrazil2014) Agilidade no Judiciário: um relato de experiência de Agile ...
 
[Agile brazil2014] Bad Smells em Bancos de Dados
[Agile brazil2014] Bad Smells em Bancos de Dados[Agile brazil2014] Bad Smells em Bancos de Dados
[Agile brazil2014] Bad Smells em Bancos de Dados
 
5S em Código: Seminário de PHP "Show me the code!"
5S em Código: Seminário de PHP "Show me the code!"5S em Código: Seminário de PHP "Show me the code!"
5S em Código: Seminário de PHP "Show me the code!"
 
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)
Retrospectiva: O motor da melhoria contínua (4a. do Conhecimento - PROCERGS)
 
Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)Descrição Tutorial Coding By Example (CBSoft2013)
Descrição Tutorial Coding By Example (CBSoft2013)
 
CBSoft 2013 - Descrição dos Problemas (CbE)
CBSoft 2013 - Descrição dos Problemas (CbE)CBSoft 2013 - Descrição dos Problemas (CbE)
CBSoft 2013 - Descrição dos Problemas (CbE)
 
CBSoft2013 - Tutorial Coding By Example
CBSoft2013 - Tutorial Coding By ExampleCBSoft2013 - Tutorial Coding By Example
CBSoft2013 - Tutorial Coding By Example
 
AgileBrazil 2013 - Baby Steps Game
AgileBrazil 2013 - Baby Steps GameAgileBrazil 2013 - Baby Steps Game
AgileBrazil 2013 - Baby Steps Game
 
AgileDay2012 - Resumo Coding By Example
AgileDay2012 - Resumo Coding By ExampleAgileDay2012 - Resumo Coding By Example
AgileDay2012 - Resumo Coding By Example
 

IPA Conhecendo XP

  • 2. Quem sou eu? Guilherme Lacerda guilhermeslacerda@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 anos de 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-Coordenador do GUMA (Grupo de Usuários de Metodologias Ágeis) vinculado a SUCESU-RS Editor do Portal InfoQ Brasil Membro do IASA e da Scrum Alliance
  • 3. Quem faz programa? Por que 80% a 90% dos projetos de SW fracassam? Fonte: Standish Group
  • 4. 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 processos complexos
  • 5. Principais Problemas Desenvolvedores trabalham muitas horas! Desenvolvedores relaxam na disciplina Desenvolvedores perdem o foco Processos prescritivos são atrativos para a gerência mas não para os desenvolvedores Baseados no paradigma do comando e controle Tenta minimizar o papel do cliente Foco em tecnologia e não no negócio
  • 8. O que é ser Ágil? Ágil é ser rápido, ligeiro (dicionário) Eficaz: produz o resultado esperado Eficiente: produz o resultado esperado, mas com qualidade Características importantes: 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!)
  • 9. Direitos do Cliente (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 idéia, substituir funcionalidades, sem pagar custos exorbitantes Ser informado de mudanças 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
  • 10. Direitos do Desenvolvedor (Ron Jeffries) Saber o que é necessário, com declarações claras de prioridade Produzir trabalho de qualidade o tempo todo 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
  • 11. Processos de Software 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
  • 12. Manifesto Ágil “Estamos evidenciando maneiras melhores de desenvolver software 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. Colaboração com o cliente MAIS QUE negociação de contratos; 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 Utah – Fevereiro de 2001
  • 15. Riscos Riscos de Planejamento Será que conseguiremos terminar até outubro? Riscos de Custo Será que conseguiremos comprar o servidor pelo preço definido anteriormente? Riscos de Requisitos Será que temos todas as informações para começar o trabalho?
  • 16. Risco X Valor Alto Risco Alto Risco Baixo Valor Alto Valor Risco Baixo Risco Baixo Risco Baixo Valor Alto Valor Valor Evitar Fazer Primeiro Risco Fazer por último Fazer depois Valor
  • 20. XP Criado por Kent Beck, Ron Jeffries e Ward Cunningham Disciplina de desenvolvimento de SW, voltada para equipes pequenas e médias, com requisitos vagos ou que mudam freqüentemente Principal tarefa é a codificação
  • 21. XP
  • 22. 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
  • 26. Variáveis de um Projeto Processos Tradicionais Tempo Escopo Manipula-se a Custo Qualidade eXtreme Programming Tempo Manipula-se a Qualidade Escopo Custo
  • 27. XP Práticas organizacionais Práticas de equipe Práticas de pares
  • 28. 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 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)
  • 30. 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 desenvolvedores avaliam) Planejamento da iteração (define as funcionalidades da iteração e os desenvolvedores 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
  • 31. 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
  • 32. 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 2 3 7 4 5 4 5 2 6 4 2 5 6
  • 33. 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 e quanto falta
  • 34. 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 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
  • 35. 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 e refinamento de código (refactoring) Em XP, é levado ao extremo Não é permitido implementar qualquer funcionalidade adicional que não será usada na iteração atual Implementação ideal é aquela que Passa por todos os testes Expressa todas as idéias definidas no planejamento Não contém código duplicado ou que “cheire” Prever o futuro é impossível e é “anti-XP”
  • 36. 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 Benefícios Melhor qualidade de código (refactoring, testes) Revisão constante do código Nivelamento da equipe Maior comunicação “Um” pelo preço de “Dois”?? Pesquisas demonstram que duplas produzem código de melhor qualidade em aproximadamente o mesmo tempo que programadores que trabalham sozinhos
  • 37. 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 de desenvolvimento Produtividade a curto prazo X longo prazo Pressão do Par Concentração, incentivo, responsabilidade Revezamentos Disseminação do conhecimento Desafios Organização do escritório, visão gerencial, relacionamento humano, competição
  • 38. Desenvolvimento Dirigido por Testes (Test-Driven Development) XP valoriza o desenvolvimento dirigido por testes São automatizados, executados o tempo todo Testes “puxam” o desenvolvimento Cada unidade de código só tem valor se o teste funcionar 100% Testes dão coragem para mudar De que adianta a OO isolar a interface da implementação se o desenvolvedor tem medo de mudar a implementação?
  • 39. Desenvolvimento Dirigido por Testes (Test-Driven Development) TDD Obter tarefa Criar Código de Codificar Fazer Teste para a tarefa Refactoring Passou nos testes? Sim: Nova tarefa Não: Revisar código
  • 40. 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 desta prática (elimina o medo dos desenvolvedores de adotar a mudança) “Software é como a nossa casa” Organizados X desorganizados XP enfatiza código de alta qualidade
  • 41. 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
  • 42. 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 os riscos de dependência de indivíduos Todos compartilham a responsabilidade pelas alterações Ideal que se troque os pares periodicamente “Todos conhecem tudo” Testes e integração contínua são essenciais e dão segurança
  • 43. 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 Práticas e valores favorecidos Posse coletiva Comunicação Programação em Pares Refactoring Projeto Simples
  • 44. 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 as estimativas Pattern de alto nível
  • 45. Ritmo Saudável (Sustainable Pace) XP está na arena para ganhar 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
  • 46. Reuniões em Pé (StandUp Mettings) A maioria dos desenvolvedores odeiam reuniões Assuntos demorados e desgastantes Impedem os desenvolvedores de codificar As reuniões são valiosas quando Não perdem o foco São breves São abordadas tarefas realizadas e a realizar
  • 47. Spikes de Planejamento (Spike Solution) São investigações de tecnologias que podem ser utilizadas no projeto Auxiliam nas estimativas e na especificação do projeto Podem durar horas ou dias, porém devem ser curtos Englobam Avaliações de arquiteturas Algoritmos componentes e frameworks BDs Servidores de aplicação, Web Utilização de artefatos e ferramentas
  • 48. Ambiente de Trabalho O ambiente deve apoiar a aplicação das práticas Tem importância vital para um projeto de software Trabalhar próximo dos colegas Facilitar a comunicação Equipamentos Mesas e cadeiras Equipamentos tecnológicos Telefones Mural Quadro Branco Calendário Comida ☺ Isolamento (equipes e projetos)
  • 49. Documentação Ágil Complexidade do Software Tempo de desenvolvimento Equipes Futuras manutenções Até que ponto documentar? Uso incorreto da documentação Quando documentar? Documentos que compõem a documentação User stories, testes de aceitação, testes de unidade, documentação de código fonte, Modelo de Classes, Modelo de Dados, Processos de Negócio, Manual de usuário, Acompanhamento diário, Acompanhamento do Projeto
  • 50. Ferramentas de Apoio Mais em http://xprogramming.com/software.htm
  • 51. IDEs
  • 52. IDEs
  • 70. Mercado HP Objective Solutions Ford ImproveIt Symantec Brasil Telecom Motorola Embrapa Chrysler Qualiti BMW Trevisan Tecnologia Borland Argonavis IBM CETIP First National Bank Secretaria da Fazenda SP Thought Works Smart Tech Consulting CC Pace Systems iQualy Industrial Logic IME-USP Moore EverSystems Workshare PowerLogic Consultoria Xerox UFRJ Siemens PUC-Rio Object Mentor Surya Tecnologia
  • 72. 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 Â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
  • 73. 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 Não é um ataque à documentação e sim a criação de documentos que tem valor Não são para todos O segredo está na sinergia de suas práticas Menos formalidade, mais diversão
  • 74. 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 de práticas simples, obtendo feedback e reajustando estas práticas para cada situação particular XP pode ser implementada aos poucos, porém, a maior parte das prá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
  • 75. Combinando Lean + SCRUM + XP
  • 76. Combinando Lean + SCRUM + XP
  • 77. 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
  • 78. Apoio