Agilidade:
SCRUM e XP
Facilitador
Fernando Costa
formado em Redes de Computadores
Sócio da 3LJ Tecnologia – www.3lj.com.br

  Agenda SCRUM:
    ...
Paradoxo de Cobb
We know why projects fail, we know
 how to prevent their failure – so why
 do they still fail?
          ...
Reflexão do Caranguejo
   Todos os caranguejos
    ficam amarrados a um barbante que fica
    solto.
   Não é preciso am...
Valores do Manifesto Ágil
Indivíduos e interações              Processos e ferramentas

                                  ...
Princípios do Manifesto Ágil
1 - O principal compromisso é com a satisfação
  do cliente, por meio da entrega mais rápida ...
Princípios do Manifesto Ágil
4 - Mantenha pessoas ligadas ao negócio (cliente) e
  desenvolvedores trabalhandos juntos a m...
Princípios do Manifesto Ágil
7 - Produto funcionando é a principal medida
   de progresso de um projeto

8 - Processos áge...
Princípios do Manifesto Ágil
10 - Simplicidade é essencial e deve ser
  assumida em todos os aspectos do projeto

11 - As ...
SCRUM
Em resumo...




     Imagem disponível em:
www.mountangoatsoftware.com/scrum
Cliente (ou Product Owner)
            Quem é o nosso cliente?
            Funcionalidades do
             produto
     ...
Scrum Master
      Remove obstáculos
      Não tem autoridade
      Produtividade da equipe
      Conduz eventos
    ...
Equipe
   5 a 9 pessoas
   Multi-funcional
   Auto-organizável
   Sugere funcionalidades
    do produto
Product Backlog
   Lista de funcionalidades desejadas no projeto
   Os itens que compõe a lista são chamados de
    hist...
Nosso Product Backlog
ID Nome               Importância Estimativa Observação

1   Catálogo de
    produtos
2   Cesta de
 ...
Planning Poker
   Vamos estimar os itens de Backlog?
Nosso Product Backlog
ID Nome               Importância Estimativa Observação

1   Catálogo de                       3
   ...
Qual a importância dos itens de
backlog para o Product Owner?
Must          Should          Could           Want
(tem que      (deveria ter)   (poderia ter)   (interessante)
   ter)


...
Nosso Product Backlog
ID Nome               Importância Estimativa Observação

1   Catálogo de           1           3
   ...
Sprint

   Deve ter um objetivo
   Período de 2 a 4 semanas
   Nenhuma mudança no sprint
   Processo baseado em uma sé...
Product Burnup Chart
Planejamento do Sprint
   Cliente, ScrumMaster e Equipe
   Cliente seleciona itens do Product backlog
   O Sprint backl...
Planejamento do Sprint
                               ID – 1.1
ID - 1                         Administrador dos
          ...
Scrum diário
    Tempo de 15 minutos
    Todos em pé
    Não é para a solução de problemas
   −   Todos são convidados
...
Gerenciando o Sprint backlog
   Cada membro da equipe escolhe a tarefa
    que fará
    −   Trabalhos nunca são atribuído...
Scrum board
Revisão do Sprint
   Informal
   Todos participam
   Hora do feedback
   Resultados do Sprint


Comunicação eficaz:
 (...
Retrospectiva do Sprint
   Feita após cada Sprint
   Periodicamente observe pontos
    positivos e negativos
   Tipicam...
Inicia, Pára, Continua
   A equipe discute o que gostaria de:

          Iniciar a fazer

                   Parar de faz...
Agora vocês explicam!!!
Resumo: Gerenciamento ágil
Tópico               Características
Objetivo principal   Orientado ao produto e centrado nas p...
Dúvidas?
                    Fernando Costa
                  fernando@3lj.com.br
               www.fernandocosta.com.br
...
Agenda do XP
Desenvolvimento
tradicional

   Valores

   Princípios

   Práticas
Fazer software é dureza
Boa
                    Má notícia
    notícia
Cases de sucesso:   • Seus colegas não vão
Google
                     acr...
Não é assim que se faz
            software
Principais falhas:

a) Não entregam o acordado

b) Orçamento

c) Prazo

d) Tod...
Utilização de funcionalidades




Pesquisado em 280 mil projetos de software nos EUA pela
empresa Standish Group
64% de desperdício

   Podem gerar algumas horas extras para a equipe



   Cliente paga por lixo
Utilização de funcionalidades




Pesquisado em 280 mil projetos de software nos EUA pela
               empresa Standish ...
20% muito útil
   Geram pelo menos 80% do valor do
    produto

   20%? desconhecido no início do projeto



     “XP é ...
Análise




 Pai(cliente): 1 dia de projeto
Mãe(desenv.): 9 meses de projeto
Análise




Cliente: “Não era nada disso que eu
             queria...”
Mentalidade
Cascata
Custo da Mudança
 por Barry Bohem
Problemas e mudanças




Patente do VELCRO:

em 1941 por Georges
         de Mestral
Meio digital
   Fluidez
   Maleabilidade
   Invisibilidade
   Complexibilidade (elementos distintos)
   Baixo custo d...
Nova mentalidade
• Chef
• Escritor
eXtreme Programming
Valores do XP

                    ão
                 aç
              ic                          em
            un     ...
Uma pergunta



“Como você programaria se tivesse
       tempo suficiente?”

                          Kent Beck
Possíveis respostas
   Mais testes?

   Mais projeto e arquitetura?

   Menos pessoas?

   Mais qualidade?
Programando ao Extremo
− Testar   toda hora!!

− Seprojetar é bom, vamos fazer
 disso parte do trabalho diário de
 cada pe...
Práticas                      Cliente
                             Presente



                 Código
                 Co...
Jogo do Planejamento

   Reunião semanal onde todos participam

   Escopo reavaliado

   Cliente prioriza e seleciona a...
Reunião em pé
       10/15 minutos
       Todos em pé
       Não é para a solução de problemas
    −     Todo mundo é c...
Cliente presente e envolvido
• Responsabilidade do
  projeto:
  – Equipe
  – Cliente


• Comprometimento
Ritmo sustentável


   Semana de 40 horas (8hr/dia)

Sem hora extra:
   Baixa produtividade
   Código de má qualidade
...
Programação em
           par



   Forneça suporte e ferramentas

   Experimente, você vai se surpreender

   Alterne ...
Código Padronizado
Código Coletivo
   Inibe ilhas de
    conhecimento

   Padrão de codificação

   Membro da equipe pode
    ter férias

...
Integração Contínua

   Divergências aparecem antes de virar
    um problema

   “Isso funcionava na minha máquina”
Projeto Simples



   Faça o essencial

   Tudo pode mudar
Refatoração
   “Time que está ganhando não se mexe” –
    FALSO
   Ex.: Empresas estáveis quebram se não
    mudarem
  ...
Desenvolvimento
       Orientado
     a Testes (TDD)


   Início é um pouco demorado

   Primeiro o teste, depois a func...
Releases curtos
Papéis



                                        Tracker
               Coach     Goal Donnor

Manager



               ...
Equipe nivelada
Dúvidas?

Fernando Costa
fernando@3lj.com.br
www.fernandocosta.com.br


3LJ Tecnologia
www.3lj.com.br


Agradecimento:
Vin...
Agilidade: Scrum e Xp
Agilidade: Scrum e Xp
Agilidade: Scrum e Xp
Agilidade: Scrum e Xp
Próximos SlideShares
Carregando em…5
×

Agilidade: Scrum e Xp

7.548 visualizações

Publicada em

Apresentação feita na phpconf2008 sobre agilidade usando SCRUM e eXtreme Programming

Publicada em: Tecnologia
1 comentário
10 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
7.548
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4.996
Ações
Compartilhamentos
0
Downloads
183
Comentários
1
Gostaram
10
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Agilidade: Scrum e Xp

  1. 1. Agilidade: SCRUM e XP
  2. 2. Facilitador Fernando Costa formado em Redes de Computadores Sócio da 3LJ Tecnologia – www.3lj.com.br Agenda SCRUM: Contexto de projetos Valores ágeis Princípios ágeis Scrum
  3. 3. Paradoxo de Cobb We know why projects fail, we know how to prevent their failure – so why do they still fail? Martin Cobb Treasury Board of Canada Secretariat Nós sabemos porque os projetos falham, sabemos como previnir – Porque eles continuam falhando?
  4. 4. Reflexão do Caranguejo  Todos os caranguejos ficam amarrados a um barbante que fica solto.  Não é preciso amarrar pois todos querem fugir mas cada um que ir para um lado diferente.  Ficam no mesmo lugar
  5. 5. Valores do Manifesto Ágil Indivíduos e interações Processos e ferramentas Documentação Software que funciona ao invés abrangente de Colaboração do cliente Negociação de contrato Resposta à mudanças Seguir um plano www.agilemanifesto.org - 2001
  6. 6. Princípios do Manifesto Ágil 1 - O principal compromisso é com a satisfação do cliente, por meio da entrega mais rápida e contínua de produto com valor 2 - Receba bem as mudanças de requisitos(mesmo em estágios tardios do projeto). Processos ágeis devem admitir mudanças que trazem vantagens competitivas ao cliente 3 - Libere produto frequentemente (de 2 a 4 semanas), dando preferência para uma escala de tempo curta
  7. 7. Princípios do Manifesto Ágil 4 - Mantenha pessoas ligadas ao negócio (cliente) e desenvolvedores trabalhandos juntos a maior parte do tempo do projeto 5 - Construa projetos com indivíduos motivados, dê a eles o ambiente e suporte que precisam e confie neles para ter o trabalho realizado 6 - O método mais eficiente e efetivo para repassar a informação entre a equipe é pela comunicação face a face
  8. 8. Princípios do Manifesto Ágil 7 - Produto funcionando é a principal medida de progresso de um projeto 8 - Processos ágeis promovem o desenvolvimento sustentado. Patrocinadores, desenvolvedores e usuários devem ser capazes de manter conversação pacífica indefinidamente 9 - Atenção contínua para excelência técnica e bom projeto (planejamento) aprimoram a agilidade
  9. 9. Princípios do Manifesto Ágil 10 - Simplicidade é essencial e deve ser assumida em todos os aspectos do projeto 11 - As melhores arquiteturas, requisitos e projetos emergem de equipes auto- organizadas 12 - Em intervalos regulares, as equipes devem refletir sobre como se tornarem mais efetivas, e então refinarem e ajustarem seu comportamento
  10. 10. SCRUM
  11. 11. Em resumo... Imagem disponível em: www.mountangoatsoftware.com/scrum
  12. 12. Cliente (ou Product Owner)  Quem é o nosso cliente?  Funcionalidades do produto  Decide as datas e conteúdo  Rentabilidade (ROI)  Ajusta e prioriza funcionalidades e prioridades  Aceita o rejeita resultados
  13. 13. Scrum Master  Remove obstáculos  Não tem autoridade  Produtividade da equipe  Conduz eventos  Escudo da equipe
  14. 14. Equipe  5 a 9 pessoas  Multi-funcional  Auto-organizável  Sugere funcionalidades do produto
  15. 15. Product Backlog  Lista de funcionalidades desejadas no projeto  Os itens que compõe a lista são chamados de histórias ou itens de backlog  Todos podem incluir histórias  Somente o Product Owner pode priorizá-las  Product Owner pode priorizar novamente no início de cada Sprint
  16. 16. Nosso Product Backlog ID Nome Importância Estimativa Observação 1 Catálogo de produtos 2 Cesta de compras 3 Cadastro do cliente 4 Boleto bancário 5 Cartão de crédito
  17. 17. Planning Poker  Vamos estimar os itens de Backlog?
  18. 18. Nosso Product Backlog ID Nome Importância Estimativa Observação 1 Catálogo de 3 produtos 2 Cesta de 5 compras 3 Cadastro do 2 cliente 4 Boleto bancário 4 5 Cartão de 3 crédito
  19. 19. Qual a importância dos itens de backlog para o Product Owner?
  20. 20. Must Should Could Want (tem que (deveria ter) (poderia ter) (interessante) ter) Catálogo de Boleto Controle de Videos dos produtos bancário estoque produtos Cadastro de Cartão de Regras de clientes crédito promoção Cesta de Fotos dos compras produtos Registro do Pedido e entrega
  21. 21. Nosso Product Backlog ID Nome Importância Estimativa Observação 1 Catálogo de 1 3 produtos 2 Cesta de 1 5 compras 3 Cadastro do 1 2 cliente 4 Boleto bancário 2 4 BB e CEF 5 Cartão de 3 3 Visa e crédito Mastercard
  22. 22. Sprint  Deve ter um objetivo  Período de 2 a 4 semanas  Nenhuma mudança no sprint  Processo baseado em uma série de iterações  Produto é desenvolvido no sprint
  23. 23. Product Burnup Chart
  24. 24. Planejamento do Sprint  Cliente, ScrumMaster e Equipe  Cliente seleciona itens do Product backlog  O Sprint backlog − Tarefas identificadas e estimadas (1 a 16 horas) − De forma colaborativa (por todos) − Equipe compromete-se a concluir as tarefas
  25. 25. Planejamento do Sprint ID – 1.1 ID - 1 Administrador dos Produtos Catálogo de produtos 10 horas ID – 1.2 Busca fonética de ID – 1.3 produtos Front-end da Loja 2 horas 15 horas
  26. 26. Scrum diário  Tempo de 15 minutos  Todos em pé  Não é para a solução de problemas − Todos são convidados − Apenas a Equipe, ScrumMaster e Product Owner podem falar  Sincronização do conhecimento  Atualização do burnup chart 1. O que fiz desde a última reunião? 2. O que farei até a próxima reunião? 3. Existe algum obstáculo?
  27. 27. Gerenciando o Sprint backlog  Cada membro da equipe escolhe a tarefa que fará − Trabalhos nunca são atribuídos  Atualização diária da estimativa do trabalho restante  Equipe pode adicionar, apagar ou mudar tarefas (não itens de backlog)
  28. 28. Scrum board
  29. 29. Revisão do Sprint  Informal  Todos participam  Hora do feedback  Resultados do Sprint Comunicação eficaz: (bala / bombom)
  30. 30. Retrospectiva do Sprint  Feita após cada Sprint  Periodicamente observe pontos positivos e negativos  Tipicamente de 15 a 30 minutos  Todos participam
  31. 31. Inicia, Pára, Continua  A equipe discute o que gostaria de: Iniciar a fazer Parar de fazer Esta é uma das várias maneiras Continuar fazendo de se conduzir uma retrospectiva do Sprint
  32. 32. Agora vocês explicam!!!
  33. 33. Resumo: Gerenciamento ágil Tópico Características Objetivo principal Orientado ao produto e centrado nas pessoas Tipo do projeto Projetos com mudanças constantes e que necessitam de respostas rápidas Tamanho Mais efetivo em projeto pequenos(5 a 9 pessoas) Gerente do projeto Papel de facilitador ou coordenador Equipe do projeto Atuação colaborativa em todas as atividades do projeto Cliente Essencial. Deve ser parte integrante da equipe do projeto Planejamento Curto e com a participação de todos os envolvidos na elaboração do planejamento Arquitetura Aplicação de design simples. Evolui junto com o projeto e baseia-se na refatoração Modelo de Iterativo e Incremental desenvolvimento Comunicação Informal Tópico Características
  34. 34. Dúvidas? Fernando Costa fernando@3lj.com.br www.fernandocosta.com.br Patrocínio: Agradecimento: www.3lj.com.br www.innovit.com.br
  35. 35. Agenda do XP Desenvolvimento tradicional  Valores  Princípios  Práticas
  36. 36. Fazer software é dureza
  37. 37. Boa Má notícia notícia Cases de sucesso: • Seus colegas não vão Google  acreditar Microsoft  • O seu chefe não vai aceitar Philips  • O chefe do seu chefe não pode nem pensar FAB (BR)  Oi Paggo 
  38. 38. Não é assim que se faz software Principais falhas: a) Não entregam o acordado b) Orçamento c) Prazo d) Todas alternativas
  39. 39. Utilização de funcionalidades Pesquisado em 280 mil projetos de software nos EUA pela empresa Standish Group
  40. 40. 64% de desperdício  Podem gerar algumas horas extras para a equipe  Cliente paga por lixo
  41. 41. Utilização de funcionalidades Pesquisado em 280 mil projetos de software nos EUA pela empresa Standish Group
  42. 42. 20% muito útil  Geram pelo menos 80% do valor do produto  20%? desconhecido no início do projeto “XP é a arte de maximizar a quantidade de software que você não vai fazer “ Vinícius Manhães Teles
  43. 43. Análise Pai(cliente): 1 dia de projeto Mãe(desenv.): 9 meses de projeto
  44. 44. Análise Cliente: “Não era nada disso que eu queria...”
  45. 45. Mentalidade
  46. 46. Cascata
  47. 47. Custo da Mudança por Barry Bohem
  48. 48. Problemas e mudanças Patente do VELCRO: em 1941 por Georges de Mestral
  49. 49. Meio digital  Fluidez  Maleabilidade  Invisibilidade  Complexibilidade (elementos distintos)  Baixo custo de manufatura  Rapidez evolução
  50. 50. Nova mentalidade • Chef • Escritor
  51. 51. eXtreme Programming
  52. 52. Valores do XP ão aç ic em un ag om Cor C Respeito de ck ida ba ic ed pl im Fe S
  53. 53. Uma pergunta “Como você programaria se tivesse tempo suficiente?” Kent Beck
  54. 54. Possíveis respostas  Mais testes?  Mais projeto e arquitetura?  Menos pessoas?  Mais qualidade?
  55. 55. Programando ao Extremo − Testar toda hora!! − Seprojetar é bom, vamos fazer disso parte do trabalho diário de cada pessoa! − Integrar a maior quantidade de vezes possível! − Iterações realmente curtas!
  56. 56. Práticas Cliente Presente Código Coletivo Test-Driven Coding Development Standard Testes de Programação Planning Aceitação em pares Refactoring Game Integração Design Ritmo Contínua Simples Sustentável Metáfora Releases Curtas Adaptado de xprogramming.com
  57. 57. Jogo do Planejamento  Reunião semanal onde todos participam  Escopo reavaliado  Cliente prioriza e seleciona as histórias que serão desenvolvidas  Ao fim da semana o cliente recebe produto funcionando
  58. 58. Reunião em pé  10/15 minutos  Todos em pé  Não é para a solução de problemas − Todo mundo é convidado − Apenas a Equipe pode falar  Sincronização do conhecimento 1. O que fiz desde a última reunião? 2. O que farei até a próxima reunião? 3. Existe algum obstáculo?
  59. 59. Cliente presente e envolvido • Responsabilidade do projeto: – Equipe – Cliente • Comprometimento
  60. 60. Ritmo sustentável  Semana de 40 horas (8hr/dia) Sem hora extra:  Baixa produtividade  Código de má qualidade  Aumento de BUGs
  61. 61. Programação em par  Forneça suporte e ferramentas  Experimente, você vai se surpreender  Alterne os pares para não ficar cansativo e nivelar o time  Respeite a individualidade das pessoas
  62. 62. Código Padronizado
  63. 63. Código Coletivo  Inibe ilhas de conhecimento  Padrão de codificação  Membro da equipe pode ter férias  Direito de ficar doente
  64. 64. Integração Contínua  Divergências aparecem antes de virar um problema  “Isso funcionava na minha máquina”
  65. 65. Projeto Simples  Faça o essencial  Tudo pode mudar
  66. 66. Refatoração  “Time que está ganhando não se mexe” – FALSO  Ex.: Empresas estáveis quebram se não mudarem  Melhoria contínua
  67. 67. Desenvolvimento Orientado a Testes (TDD)  Início é um pouco demorado  Primeiro o teste, depois a funcionalidade para passar no teste  Testes automatizados: Unitários, Interface e Aceitação  RETORNO: Salvação no FIM do projeto
  68. 68. Releases curtos
  69. 69. Papéis Tracker Coach Goal Donnor Manager Gold Owner Programador Analista de Testes
  70. 70. Equipe nivelada
  71. 71. Dúvidas? Fernando Costa fernando@3lj.com.br www.fernandocosta.com.br 3LJ Tecnologia www.3lj.com.br Agradecimento: Vinícius Manhães Teles Improve It

×