SlideShare uma empresa Scribd logo
Scrum
Gestão ágil de projetos
          Autores:
    Fábio Abrantes Diniz

    Íthalo Bruno de Moura

    Thiago Reis da Silva

     Diego Grosmanniz
Scrum
Gestão ágil de projetos
      Apresentadores:

    Fábio Abrantes Diniz

    Íthalo Bruno de Moura
31% são   cancelados
53% custam o   dobro do estimado
Apenas    16% são completados no
prazo e custo estimados
                       * dados do CHAOS report
Mas por que?
Falta de envolvimento   do usuário

Requisitos e especificações incompletas

      Falta de suporte   da direção

     Falta de Pessoas    e Recursos

       Falta de ESTIMATIVAS!!!
Falhar é uma maneira muito
forte de aprendizado, mas é
   preciso parar de
 apontar culpados
Olá,           Scrum!
Por que o nome Scrum?

O nome é proveninente de uma jogada do Rugby, onde
é demostrada a força de trabalho em equipe.

O Scrum do Rugby é formado por até 8 pessoas de
cada equipe.

O objetivo do Scrum no Rugby é avançar a bola oval no
campo adversário o máximo possível. Para isso é
necessário um ótimo trabalho em equipe.
Scrum é também um meio de
        evidenciar os
           problemas
Mas Scrum não
            é bala de
        prata*

                     * Não mata vampiros & afins
       * Exige trabalho duro e comprometimento
PDCA
Plan, Do, Check, Act
Planejamento
Execução
Checagem
Exatamente o
que Scrum faz!
Quem usa o Scrum

•   Microsoft
•   Yahoo
•   Google
•   Lockheed Martin
•   Philips
•   Siemens
•   Nokia
•   BBC
Scrum tem sido usado para

•   Software comercial
•   Desenvolvimento interno (empresa)
•   Desenvolvimento contratado (terceirização)
•   Aplicações financeiras
•   Sistemas embarcados
•   Jogos
•   Sistemas para controle de satélites
•   Websites
•   Telefones celulares
Características do Scrum

• As equipes se auto-organizam

• O produto evolui em uma série de “Sprints”
  mensais

• Os requerimentos são listados em um “Product
  Backlog”

• Não há prática de engenharia prescrita (o Scrum
  adequa-se a todas)

• É uma das “metodologias ágeis”
Papeis no
 scrum
Product Owner




• O representante do cliente
Scrum Master




• O Scrum Master lidera o time de
  desenvolvimento
Scrum Team




• Scrum Team São os membros que
  formam o time de desenvolvedores,
  designers, consiste de 5 a 9 pessoas.
Papéis e Responsabilidades

                       ► Define as funcionalidades do produto assim como conteúdo e
                         data das liberações;
Product Owner
                       ► Responsável pela rentabilidade do produto;
                       ► Prioriza as funcionalidades de acordo com o valor do mercado;
                       ► Pode mudar as funcionalidades e priorizar a cada 30 dias;
                       ► Aceita ou rejeita os resultados do trabalho.

                       ► Garante que a equipe está completamente funcional e produtiva;
Scrum Master           ► Facilita comunicação entre papéis e remove impedimentos;
                       ► Protege a equipe contra interferências externas;
                       ► Assegura que o processo é seguido;
                       ► Coordena os encontros diários, revisão e planejamento da
                         iteração.
                       ►Estimar      itens do backlog
Team                   ► Tem o direito de realizar quaisquer atividades para alcançar
                         o objetivo da iteração desde que respeite os guidelines do
                         projeto;
                       ► Auto organizados para entregar o que o PO quer.



  © 2006 BenQ Mobile                                                                     26
Ciclo de Vida




       Ciclo de vida do Scrum
Fonte: Adaptado de Improve It (2008)
Ciclo de Vida




       Ciclo de vida do Scrum
Fonte: Adaptado de Improve It (2008)
Ciclo de Vida




       Ciclo de vida do Scrum
Fonte: Adaptado de Improve It (2008)
O Product Backlog é uma lista de
  todas as funcionalidades desejadas no
produto, estimadas pelo time e priorizadas
                   pelo
              Product Owner.
Exemplo de   Product Backlog
O Product Backlog
       Emergente
      Priorizado e estimado
 Maior prioridade, mais detalhes
    Priorização é tarefa do PO
 Alinhado ao plano de negócios
O Product Backlog
           Emergente
Priorizado e estimado
 Maior prioridade, mais detalhes
    Priorização é tarefa do PO
 Alinhado ao plano de negócios
O Product Backlog
                Emergente
          Priorizado e estimado
Maior prioridade, mais detalhes
         Priorização é tarefa do PO
      Alinhado ao plano de negócios
O Product Backlog
             Emergente
       Priorizado e estimado
   Maior prioridade, mais detalhes
Priorização é tarefa do PO
   Alinhado ao plano de negócios
O Product Backlog
               Emergente
         Priorizado e estimado
     Maior prioridade, mais detalhes
      Qualquer um pode contribuir
       Priorização é tarefa do PO
Alinhado ao plano de negócios
Sprints

• Representa um Time Box (uma iteração), dentro do
  qual um conjunto de atividades deve ser executado

• Ocorre em um período de duas a quatro semanas

• Baseia-se na idéia de que um período constante
  leva a um melhor “ritmo”

• O produto é projetado, codificado e testado durante
  o Sprint

• No início de cada Sprint, faz-se um Sprint
  Planning Meeting
Sprints
          - Sprint Planning Meeting -
• É uma reunião de planejamento na qual:
   o O Product Owner prioriza os itens do Product
     Backlog
   o O Scrum Team determina que atividades será
     capaz de implementar durante o novo Sprint e
     cria o Sprint Backlog
   o O Scrum Team e o Product Owner definem um
     objetivo para o Sprint
• O sucesso do Sprint será avaliado mais adiante no
  Sprint Review Meeting em relação ao objetivo
  traçado para o Sprint
Sprints
                 - Sprint Backlog -
• É uma lista de tarefas que o Scrum Team se
  compromete a fazer em um Sprint

• Seus itens são extraídos do Product Backlog com
  base nas prioridades definidas pelo Product
  Owner
  • Uma estimativa do tempo necessário para a
    implementação das funcionalidades

• O Scrum Master mantém o Sprint Backlog
  atualizado
Sprints
                   - Daily Scrum -
– É uma reúnião diária da equipe dentro do Sprint, que
  tem por objetivo:
   o Disseminar conhecimento sobre o que foi feito no
     dia anterior
   o Identificar impedimentos
   o Priorizar o trabalho a ser realizado no dia que se
     inicia
– Os impedimentos identificados devem ser tratados
  pelo Scrum Master o mais rapidamente possível

Obs: o Daily Scrum não deve ser usado
como uma reunião para resolução de
problemas
Sprints
                 - Daily Scrum -
• Três Questões para todos:

  • O que fizeste ontem?
  • O que vais fazer Hoje?
  • Há Algum obstáculo?



• Obs: As respostas não são um
  relatório para o Scrum Master. Elas
  são comprimissos dentro do Scrum
  Team.
Sprints
       - Sprint Review Meeting -
O ScrumTeam e o SCRUM Master
apresentam ao Product Owner os resultados
alcançados durante o sprint.
Sprints
         - Sprint Retrospective -
O Sprint Retrospective ocorre ao final
de um Sprint e serve para identificar o
que funcionou bem, o que pode ser
melhorado e que ações serão tomadas
para melhorar.

Todos participam:
 –Scrum Master
 –Product Owner
 –Scrum Team
Sprints
           - Sprint Retrospective -
Em uma das maneiras de se conduzir
um Sprint Retrospective, a equipe
discute o que gostaria de:

– Iniciar a fazer
– Parar de fazer
– Continuar fazendo
Estudo de Caso: O Projeto XMPM (1)
Características do Projeto

  • Software desktop destinado a usuários finais de celulares BenQ-
  Siemens
  • Projeto complexo com 300,000 LOC possuindo um ciclo de vida
  médio

   → Interação complexa com o ambiente físico (celular)
  → O software deve suportar diferentes modelos de celulares e rodar em
     diferentes distribuições do Linux
 → Uma série de versões intermediárias (builds) precisam ser
 desenvolvidas e testadas.
 → Desenvolvido por três parceiros situados fisicamente em localidades
   diferentes.
 → Necessidade de        boa   comunicação   entre   as   equipes   de
 desenvolvimento.
 → Definição clara de papéis e responsabilidades.

  © 2006 BenQ Mobile                                                 45
Estudo de Caso: O Projeto XMPM (2)
Características do Produto
 → Suporte a 9 (nove) diferentes idiomas;
 → Possui instalador gráfico para as seguintes
   distribuições (supporte oficial):
    - Suse 10
    - Ubuntu 5.10
    - Mandriva 2006
                                                            XMPM



 → Algumas das funcionalidades do XMPM incluem:
    - Sincromização de contatos, tarefas, notas e calendário entre o
    telefone celular BenQ-Siemens e KDE-Kontact.
    - Acesso à internet através de uma conexão GPRS.
    - Acessa ao sistema de arquivos e suporte a diferentes formatos de
    música.


  © 2006 BenQ Mobile                                                   46
Estudo de Caso: O Projeto XMPM (3)
Práticas adaptadas para o contexto do projeto

  Sprint:
  - No projeto XMPM foram usados 5 sprints e cada sprint com duração
   de aproximadamente 30 dias.




  - Sprints de 30 dias fornecem uma melhor visibilidade dos objetivos do pro
   e comprometimento da equipe.
  - Iterações mais curtas podem melhorar a visibilidade do projeto
   e permitir que riscos e incertezas sejam eliminados
   o mais rápido possível.

  © 2006 BenQ Mobile                                                 47
Estudo de Caso: O Projeto XMPM (4)
Práticas adaptadas para o contexto do projeto
 Planejamento do Sprint:

  - Duas reuniões são conduzidas no ínicio de cada iteração.
  - A primeira é realizada internamente com o product owner e visa refinar e
    priorizar o backlog do produto.




  - A segunda é realizada com os parceiros e visa criar o backlog do sprint
    de modo a atender os objetivos da iteração.


  © 2006 BenQ Mobile                                                   48
Estudo de Caso: O Projeto XMPM (5)

Práticas adaptadas para o contexto do projeto

 Revisão do Sprint:
    - A equipe apresenta no final de cada iteração os resultados
    obtidos (software funcionando) para o product owner e parceiros.




  - Esta prática impõe que a equipe trabalhe arduamente para alcançar os
    objetivos prometidos para a iteração.



  © 2006 BenQ Mobile                                                   49
Estudo de Caso: O Projeto XMPM (6)
 Reunião de Retrospectiva:


 - O Scrum master e a
  equipe participam desta
  reunião.

- O que deu certo durante
 o sprint e o que poderia
 ser melhorado.




  © 2006 BenQ Mobile                       50
Estudo de Caso: O Projeto XMPM (7)
Práticas adaptadas para o contexto do projeto
 Reuniões Diárias do Scrum:
  - As reuniões diárias ajudam a saber o quê cada membro da
  equipe está fazendo, compartilhar conhecimento e fornece uma
   boa visão para o Scrum Master.




                       - O quê você fez desde o último report?
                       - O quê você irá fazer até a próxima reunião?
                       -Existe algum bloqueio para alcançar os objetivos
                       da iteração?
                       - Alguma lição aprendida ou decisão tomada?


  © 2006 BenQ Mobile                                                       51
Estudo de Caso: O Projeto XMPM (8)
Práticas adaptadas para o contexto do projeto

  Builds Diários:
  - Builds diários no branch de cada parceiro e um build semanal
  no ramo principal do projeto (uso de padrões de gerência de
  configuração).




   © 2006 BenQ Mobile                                           52
Estudo de Caso: O Projeto XMPM (9)
Práticas sendo adaptadas para o contexto do projeto

  Teste antes do desenvolvimento:
 - Esta prática força o desenvolvedor pensar
 sobre o que o código deveria fazer antes de
 realmente implementá-lo.
 - Caso o desenvolvedor não seja capaz de
 escrever o caso de teste para o código então
 provavelmente existem problemas de projeto.
  - Depois de criar e executar o teste unitário, o
  mesmo torna-se apenas uma instância de testes
  de regressão.

 - Esta prática é simples em conceito, mas
 requer intensa preparação técnica.



  © 2006 BenQ Mobile                                  53
Resumo e Perspectiva
Resumo

 • O fator terceirização adiciona mais complexidade ao uso do
 Scrum.
  • As práticas melhoram a visibilidade do projeto e reduzem riscos e
  incertezas no início do ciclo de desenvolvimento.
  • A prática “revisão do sprint” exige que a equipe se esforce para
  cumprir com os objetivos prometidos da iteração.
  • A prática “teste antes do desenvolvimento” evita a criação de
  classes complexas e assegura a qualidade do código.

Perspectiva



 • Adaptação dos métodos ágeis para desenvolvimento de
 sistemas embarcados.



© 2006 BenQ Mobile                                                     54
Conclusão

Scrum é uma metodologia de gerenciamento de projetos que está se
tornando cada vez mais comum na industria de software. É bastante
eficiente quando utilizado por equipes pequenas, mas pode
tranquilamente ser usado em projetos com grandes equipes.

O Scrum tem como vantagens a velocidade, um bom controle do
cronograma, diminuição dos riscos e incertezas e a visibilidade -
graças às constantes reuniões.

Por outro lado, a grande desvantagem do Scrum é a sensação de
informalidade, devida a falta de documentação formal do
software.
?
• http://br.groups.yahoo.com/group/scrum-brasil/
• http://blogdoabu.blogspot.com/2008/11/planning-poker.html
• http://planningpoker.com/
• http://netfeijao.blogspot.com/2008/10/estimativas-geis-
  planning-poker.html
• Ken Schwaber. Agile Project Management with Scrum. Ed.
  Microsoft Press 2004
• Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta,
  Juhani. Agile Software Development Method, Review and
  Analysis. Espoo 2002. VTT Publications 478. 107p
• Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed.
  Enterprise Software Development Community, 2007.
Planning Poker
  An agile estimating
technique for agile and
     Scrum teams
    Gestão ágil de projetos
           Apresentadores:
         Fábio Abrantes Diniz
        Íthalo Bruno de Moura
31% são   cancelados
53% custam o   dobro do estimado
Apenas    16% são completados no
prazo e custo estimados
                       * dados do CHAOS report
Mas por que?
Falta de envolvimento   do usuário

Requisitos e especificações incompletas

      Falta de suporte   da direção

     Falta de Pessoas    e Recursos

      Falta de ESTIMATIVAS!!!
É difícil estimar tempos
              de execução
Time*

        *Tudo eu! Tudo eu!
2±9
7
Responsabilidades:
     • Estimar itens do backlog

• Se comprometer a entregar um incremento
funcional de software
• Gerenciar o próprio progresso

• Auto organizados para entregar o que o PO quer
As cerimônias
 do SCRUM
Reunião de Estimativa:
• Preparação para o Sprint Planning
• Estimar baseado no tamanho, nunca
em tempo
• Atualizar Product Backlog com as
estimativas
• Importante para o PO criar o release
plan
O Product Backlog
           Emergente
Priorizado e estimado
 Maior prioridade, mais detalhes
  Qualquer um pode contribuir
    Priorização é tarefa do PO
          Sempre visível
 Alinhado ao plano de negócios
Scrum foca em

tamanho e
não em duração
Estimar em tamanho
relativo é mais simples
Planning Poker
• É um método eficiente que estima o
  tamanho dos requisitos em times que
  adotam métodos ágeis (SCRUM, XP).1

• O método foi primeiramente descrito por
  James Grenning em 2002 e, mais tarde
  popularizado por Mike Cohn no livro Agile
  Estimating and Planning.

 1 – É uma variação do método de estimativa Wideband Delphi (1940)
Planning Poker
• As estimativas acontecem em reuniões:
  – Geralmente 4 ou 8 horas.
  – Paticipantes:
    • Todos os membros do time do Scrum;
    • O PO somente esclarece os requisitos e não
      estima junto a equipe;
    • O Scrum Master registra os resultados, não
      interferindo nas estimativas do time;
    • A equipe não deve ser superior a dez pessoas.
O Processo
1. Cada membro do time recebe um deck
   de cartas:
   0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? e
   “pausa”.




              http://en.wikipedia.org/wiki/Planning_poker
O Processo
2. Os itens a serem estimados são lidos pelo
   PO ou SM
    A equipe decide qual o menor item de backlog
     disponível.




             http://blogdoabu.blogspot.com/2008/11/planning-poker.html
O Processo
3. Após a estimativa inicial, esse item é
   marcado como “2” pontos
        Serve para definir uma referência de tamanho
         e complexidade para ser usada nas demais
         estimativas.
        E deve ficar registrado para uso nas futuras
         reuniões.
          Em casos excepcionais o time pode decidir mudar
           esta estória de referência por uma outra.
O Processo
4. Para cada estória o SM ou PO lê a
   descrição e os critérios da aceitação da
   mesma.
   São    respondidos        questionamentos        a
    respeito da estória;
       Manter a discussão em alto nível, não entrar em
        detalhes.
       Tempo prefixado (timebox) nesta etapa.
O Processo
5. Cada desenvolvedor escolhe em silêncio
   a carta que representa sua estimativa.
   O moderador pede para todos mostrarem
    as cartas.




          http://blogdoabu.blogspot.com/2008/11/planning-poker.html
O Processo
6. Se todas as estimativas convergirem, a
   estimativa está feita e o processo volta
   ao início, para um novo item.
   Se houver uma grande variação na
    estimativa, aqueles que apresentaram o(s)
    maior(es) e o(s) menor(es) valor(es) se
    justificam.
   O processo se repete até todas as
    estimativas convergirem.
Dinâmica
• Grupo

•   São Paulo
•   Rio Grande do Norte
•   Paraíba
•   Goiás
•   Amazonas
•   Sergipe
•   Paraná
Conclusões
• O Planning Poker é uma prática eficiente de
  estimação de requisitos
• Por ser uma técnica bastante flexível, se
  enquadra
• É uma prática que envolve todo o time
  – Ajuda times novos a se conhecerem
• Realmente funciona!!!
?
Referências
• http://br.groups.yahoo.com/group/scrum-brasil/
• http://blogdoabu.blogspot.com/2008/11/planning-poker.html
• http://planningpoker.com/
• http://netfeijao.blogspot.com/2008/10/estimativas-geis-planning-
  poker.html
• Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft
  Press 2004
• Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta, Juhani.
  Agile Software Development Method, Review and Analysis. Espoo
  2002. VTT Publications 478. 107p
• Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed. Enterprise
  Software Development Community, 2007.

Mais conteúdo relacionado

Mais procurados

Treinamento de Scrum
Treinamento de ScrumTreinamento de Scrum
Treinamento de Scrum
Luiz Duarte
 
Apresentação sobre metodologia Scrum
Apresentação sobre metodologia ScrumApresentação sobre metodologia Scrum
Apresentação sobre metodologia Scrum
IsaacBessa
 
Scrum
ScrumScrum
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de Scrum
Pyxis Technologies
 
Scrum Process
Scrum ProcessScrum Process
Scrum Process
Rodrigo Paolucci
 
Metodologia agil scrum
Metodologia agil scrumMetodologia agil scrum
Metodologia agil scrum
Pablo Juan ஃ
 
Métodos Ágeis e Scrum - Introdução
Métodos Ágeis e Scrum - IntroduçãoMétodos Ágeis e Scrum - Introdução
Métodos Ágeis e Scrum - Introdução
Yuri Morais
 
Story point
Story pointStory point
Story point
Yannick Quenec'hdu
 
Agile Estimating & Planning
Agile Estimating & PlanningAgile Estimating & Planning
Agile Estimating & Planning
AgileDad
 
Lean software
Lean software Lean software
Lean software
Sergio Crespo
 
Kanban
KanbanKanban
O Time Scrum e suas responsabilidades - Papéis do Scrum
O Time Scrum e suas responsabilidades - Papéis do ScrumO Time Scrum e suas responsabilidades - Papéis do Scrum
O Time Scrum e suas responsabilidades - Papéis do Scrum
ScrumHalf Tool
 
Lean Kanban BR17
Lean Kanban BR17Lean Kanban BR17
Lean Kanban BR17
Mariana Zaparolli Martins
 
Gestao agil de projetos com Scrum
Gestao agil de projetos com ScrumGestao agil de projetos com Scrum
Gestao agil de projetos com Scrum
Igor Macaubas
 
Agile - Scrum
Agile - ScrumAgile - Scrum
Agile - Scrum
Samir Chitkara
 
Scrum Experience
Scrum ExperienceScrum Experience
Scrum Experience
Rildo (@rildosan) Santos
 
Iniciativa - 6.o Pilar das Atitudes para o Sucesso
Iniciativa - 6.o Pilar das Atitudes para o SucessoIniciativa - 6.o Pilar das Atitudes para o Sucesso
Iniciativa - 6.o Pilar das Atitudes para o Sucesso
Fred Graef
 
Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)
CollectiveKnowledge
 
Advanced JIRA and Confluence
Advanced JIRA and ConfluenceAdvanced JIRA and Confluence
Advanced JIRA and Confluence
Ashish Jain, CSM, Prince2 Practitioner
 
Jira
JiraJira

Mais procurados (20)

Treinamento de Scrum
Treinamento de ScrumTreinamento de Scrum
Treinamento de Scrum
 
Apresentação sobre metodologia Scrum
Apresentação sobre metodologia ScrumApresentação sobre metodologia Scrum
Apresentação sobre metodologia Scrum
 
Scrum
ScrumScrum
Scrum
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de Scrum
 
Scrum Process
Scrum ProcessScrum Process
Scrum Process
 
Metodologia agil scrum
Metodologia agil scrumMetodologia agil scrum
Metodologia agil scrum
 
Métodos Ágeis e Scrum - Introdução
Métodos Ágeis e Scrum - IntroduçãoMétodos Ágeis e Scrum - Introdução
Métodos Ágeis e Scrum - Introdução
 
Story point
Story pointStory point
Story point
 
Agile Estimating & Planning
Agile Estimating & PlanningAgile Estimating & Planning
Agile Estimating & Planning
 
Lean software
Lean software Lean software
Lean software
 
Kanban
KanbanKanban
Kanban
 
O Time Scrum e suas responsabilidades - Papéis do Scrum
O Time Scrum e suas responsabilidades - Papéis do ScrumO Time Scrum e suas responsabilidades - Papéis do Scrum
O Time Scrum e suas responsabilidades - Papéis do Scrum
 
Lean Kanban BR17
Lean Kanban BR17Lean Kanban BR17
Lean Kanban BR17
 
Gestao agil de projetos com Scrum
Gestao agil de projetos com ScrumGestao agil de projetos com Scrum
Gestao agil de projetos com Scrum
 
Agile - Scrum
Agile - ScrumAgile - Scrum
Agile - Scrum
 
Scrum Experience
Scrum ExperienceScrum Experience
Scrum Experience
 
Iniciativa - 6.o Pilar das Atitudes para o Sucesso
Iniciativa - 6.o Pilar das Atitudes para o SucessoIniciativa - 6.o Pilar das Atitudes para o Sucesso
Iniciativa - 6.o Pilar das Atitudes para o Sucesso
 
Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)
 
Advanced JIRA and Confluence
Advanced JIRA and ConfluenceAdvanced JIRA and Confluence
Advanced JIRA and Confluence
 
Jira
JiraJira
Jira
 

Semelhante a Minicurso SCRUM

Introdução ao desenvolvimento ágil com Scrum
Introdução ao desenvolvimento ágil com ScrumIntrodução ao desenvolvimento ágil com Scrum
Introdução ao desenvolvimento ágil com Scrum
Inove
 
Trabalho scrum
Trabalho scrumTrabalho scrum
Trabalho scrum
Jarbas Pereira
 
Scrum
ScrumScrum
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
William Lima
 
Introdução ao scrum
Introdução ao scrumIntrodução ao scrum
Introdução ao scrum
Fernando Palma
 
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumFerramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
Thiago Barros, PSM
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUM
Lucas Vinícius
 
Workshop Scrum 2017 - Michele Tavares
Workshop Scrum 2017 - Michele TavaresWorkshop Scrum 2017 - Michele Tavares
Workshop Scrum 2017 - Michele Tavares
Michele Tavares
 
Portuguese scrum
Portuguese scrumPortuguese scrum
Portuguese scrum
Denise Vieira
 
Uma introdução ao SCRUM
Uma introdução ao SCRUMUma introdução ao SCRUM
Uma introdução ao SCRUM
elliando dias
 
Scrum - Metodologia Ágil
Scrum - Metodologia ÁgilScrum - Metodologia Ágil
Scrum - Metodologia Ágil
Biblioteca Etec de Rgs
 
Cenartec 2014 - FPF Tech - SCRUM - Framework para desenvolver projetos
Cenartec 2014 - FPF Tech - SCRUM - Framework para desenvolver projetosCenartec 2014 - FPF Tech - SCRUM - Framework para desenvolver projetos
Cenartec 2014 - FPF Tech - SCRUM - Framework para desenvolver projetos
João Clineu - CTFL, CSM, CSD
 
FPF Tech - SCRUM - Framework para desenvolver projetos - Cenartec 2014
FPF Tech - SCRUM - Framework para desenvolver projetos - Cenartec 2014FPF Tech - SCRUM - Framework para desenvolver projetos - Cenartec 2014
FPF Tech - SCRUM - Framework para desenvolver projetos - Cenartec 2014
Vanilton Pinheiro
 
Scrum agil
Scrum agilScrum agil
Scrum - Visão Geral
Scrum - Visão GeralScrum - Visão Geral
Scrum - Visão Geral
Leonardo Melo Santos
 
Visão Macro do SCRUM
Visão Macro do SCRUMVisão Macro do SCRUM
Visão Macro do SCRUM
Ricardo Moura
 
SCRUM
SCRUMSCRUM
Método Ágil Scrum
Método Ágil ScrumMétodo Ágil Scrum
Método Ágil Scrum
Fernando Vargas
 
Scrum
ScrumScrum
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
Audasi Tecnologia e Inovação
 

Semelhante a Minicurso SCRUM (20)

Introdução ao desenvolvimento ágil com Scrum
Introdução ao desenvolvimento ágil com ScrumIntrodução ao desenvolvimento ágil com Scrum
Introdução ao desenvolvimento ágil com Scrum
 
Trabalho scrum
Trabalho scrumTrabalho scrum
Trabalho scrum
 
Scrum
ScrumScrum
Scrum
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
Introdução ao scrum
Introdução ao scrumIntrodução ao scrum
Introdução ao scrum
 
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com ScrumFerramentas Livres para a Gestão de Projetos Ágeis com Scrum
Ferramentas Livres para a Gestão de Projetos Ágeis com Scrum
 
Gerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUMGerenciamento ágil de processos - SCRUM
Gerenciamento ágil de processos - SCRUM
 
Workshop Scrum 2017 - Michele Tavares
Workshop Scrum 2017 - Michele TavaresWorkshop Scrum 2017 - Michele Tavares
Workshop Scrum 2017 - Michele Tavares
 
Portuguese scrum
Portuguese scrumPortuguese scrum
Portuguese scrum
 
Uma introdução ao SCRUM
Uma introdução ao SCRUMUma introdução ao SCRUM
Uma introdução ao SCRUM
 
Scrum - Metodologia Ágil
Scrum - Metodologia ÁgilScrum - Metodologia Ágil
Scrum - Metodologia Ágil
 
Cenartec 2014 - FPF Tech - SCRUM - Framework para desenvolver projetos
Cenartec 2014 - FPF Tech - SCRUM - Framework para desenvolver projetosCenartec 2014 - FPF Tech - SCRUM - Framework para desenvolver projetos
Cenartec 2014 - FPF Tech - SCRUM - Framework para desenvolver projetos
 
FPF Tech - SCRUM - Framework para desenvolver projetos - Cenartec 2014
FPF Tech - SCRUM - Framework para desenvolver projetos - Cenartec 2014FPF Tech - SCRUM - Framework para desenvolver projetos - Cenartec 2014
FPF Tech - SCRUM - Framework para desenvolver projetos - Cenartec 2014
 
Scrum agil
Scrum agilScrum agil
Scrum agil
 
Scrum - Visão Geral
Scrum - Visão GeralScrum - Visão Geral
Scrum - Visão Geral
 
Visão Macro do SCRUM
Visão Macro do SCRUMVisão Macro do SCRUM
Visão Macro do SCRUM
 
SCRUM
SCRUMSCRUM
SCRUM
 
Método Ágil Scrum
Método Ágil ScrumMétodo Ágil Scrum
Método Ágil Scrum
 
Scrum
ScrumScrum
Scrum
 
Gerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrumGerenciamento ágil de projetos com scrum
Gerenciamento ágil de projetos com scrum
 

Mais de Thiago Reis da Silva

Apostila de Introdução a Programação
Apostila de Introdução a ProgramaçãoApostila de Introdução a Programação
Apostila de Introdução a Programação
Thiago Reis da Silva
 
Introdução a Programação
Introdução a ProgramaçãoIntrodução a Programação
Introdução a Programação
Thiago Reis da Silva
 
The use of games on the teaching of programming: a systematic review
The use of games on the teaching of programming: a systematic reviewThe use of games on the teaching of programming: a systematic review
The use of games on the teaching of programming: a systematic review
Thiago Reis da Silva
 
Desenvolvendo plug-in do Moodle em forma de módulo
Desenvolvendo plug-in do Moodle em forma de móduloDesenvolvendo plug-in do Moodle em forma de módulo
Desenvolvendo plug-in do Moodle em forma de módulo
Thiago Reis da Silva
 
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
Thiago Reis da Silva
 
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagemO uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
Thiago Reis da Silva
 
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagem
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagemIntegrando o network simulator 2.0 a um ambiente virtual de aprendizagem
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagem
Thiago Reis da Silva
 
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
Thiago Reis da Silva
 
Survey e Análise Estatística
Survey e Análise Estatística Survey e Análise Estatística
Survey e Análise Estatística
Thiago Reis da Silva
 
Um modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
Um modelo de objeto de aprendizagem com ênfase no planejamento para o MoodleUm modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
Um modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
Thiago Reis da Silva
 
Aplicação de uma técnica de visualização de dados baseado em árvores para au...
Aplicação de uma técnica de visualização de dados baseado  em árvores para au...Aplicação de uma técnica de visualização de dados baseado  em árvores para au...
Aplicação de uma técnica de visualização de dados baseado em árvores para au...
Thiago Reis da Silva
 
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
Thiago Reis da Silva
 
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
Thiago Reis da Silva
 
Ampliando o aprendizado na TV digital com MCD-TV e ginga
Ampliando o aprendizado na TV digital com MCD-TV e gingaAmpliando o aprendizado na TV digital com MCD-TV e ginga
Ampliando o aprendizado na TV digital com MCD-TV e ginga
Thiago Reis da Silva
 
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
Thiago Reis da Silva
 
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
Thiago Reis da Silva
 
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
Thiago Reis da Silva
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Thiago Reis da Silva
 
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE COM O USO D...
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE  COM O USO D...ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE  COM O USO D...
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE COM O USO D...
Thiago Reis da Silva
 

Mais de Thiago Reis da Silva (20)

Apostila de Introdução a Programação
Apostila de Introdução a ProgramaçãoApostila de Introdução a Programação
Apostila de Introdução a Programação
 
Introdução a Programação
Introdução a ProgramaçãoIntrodução a Programação
Introdução a Programação
 
The use of games on the teaching of programming: a systematic review
The use of games on the teaching of programming: a systematic reviewThe use of games on the teaching of programming: a systematic review
The use of games on the teaching of programming: a systematic review
 
Desenvolvendo plug-in do Moodle em forma de módulo
Desenvolvendo plug-in do Moodle em forma de móduloDesenvolvendo plug-in do Moodle em forma de módulo
Desenvolvendo plug-in do Moodle em forma de módulo
 
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
Facilitando o aprendizado na tv digital interativa com a utilização de mapa d...
 
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagemO uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
O uso de ferramentas pedagógicas no desenvolvimento de objetos de aprendizagem
 
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagem
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagemIntegrando o network simulator 2.0 a um ambiente virtual de aprendizagem
Integrando o network simulator 2.0 a um ambiente virtual de aprendizagem
 
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
Ensino de programação utilizando jogos digitais: uma revisão sistemática da l...
 
Survey e Análise Estatística
Survey e Análise Estatística Survey e Análise Estatística
Survey e Análise Estatística
 
Um modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
Um modelo de objeto de aprendizagem com ênfase no planejamento para o MoodleUm modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
Um modelo de objeto de aprendizagem com ênfase no planejamento para o Moodle
 
Aplicação de uma técnica de visualização de dados baseado em árvores para au...
Aplicação de uma técnica de visualização de dados baseado  em árvores para au...Aplicação de uma técnica de visualização de dados baseado  em árvores para au...
Aplicação de uma técnica de visualização de dados baseado em árvores para au...
 
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
OBA-MC: um modelo de objeto de aprendizagem centrado no processo de ensino-ap...
 
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
Ferramentas avaliativas disponíveis em um ambiente virtual de aprendizagem us...
 
Ampliando o aprendizado na TV digital com MCD-TV e ginga
Ampliando o aprendizado na TV digital com MCD-TV e gingaAmpliando o aprendizado na TV digital com MCD-TV e ginga
Ampliando o aprendizado na TV digital com MCD-TV e ginga
 
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
MCD-TV - aprendizagem significativa com objeto de aprendizagem OBA-MC na tv d...
 
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
Análise espacial do perfil dos alunos do ifpi – campus floriano usando técnica...
 
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
Uma proposta de padronização de objetos de aprendizagem com base em objetivos...
 
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de softwareScrum uma metodologia ágil paragestão e planejamento de projetos de software
Scrum uma metodologia ágil paragestão e planejamento de projetos de software
 
Artigo
ArtigoArtigo
Artigo
 
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE COM O USO D...
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE  COM O USO D...ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE  COM O USO D...
ANÁLISE ESPACIAL DOS ÍNDICES EDUCACIONAIS DO RIO GRANDE DO NORTE COM O USO D...
 

Minicurso SCRUM

  • 1. Scrum Gestão ágil de projetos Autores: Fábio Abrantes Diniz Íthalo Bruno de Moura Thiago Reis da Silva Diego Grosmanniz
  • 2. Scrum Gestão ágil de projetos Apresentadores: Fábio Abrantes Diniz Íthalo Bruno de Moura
  • 3. 31% são cancelados 53% custam o dobro do estimado Apenas 16% são completados no prazo e custo estimados * dados do CHAOS report
  • 5. Falta de envolvimento do usuário Requisitos e especificações incompletas Falta de suporte da direção Falta de Pessoas e Recursos Falta de ESTIMATIVAS!!!
  • 6.
  • 7.
  • 8.
  • 9. Falhar é uma maneira muito forte de aprendizado, mas é preciso parar de apontar culpados
  • 10. Olá, Scrum! Por que o nome Scrum? O nome é proveninente de uma jogada do Rugby, onde é demostrada a força de trabalho em equipe. O Scrum do Rugby é formado por até 8 pessoas de cada equipe. O objetivo do Scrum no Rugby é avançar a bola oval no campo adversário o máximo possível. Para isso é necessário um ótimo trabalho em equipe.
  • 11.
  • 12. Scrum é também um meio de evidenciar os problemas
  • 13. Mas Scrum não é bala de prata* * Não mata vampiros & afins * Exige trabalho duro e comprometimento
  • 19. Quem usa o Scrum • Microsoft • Yahoo • Google • Lockheed Martin • Philips • Siemens • Nokia • BBC
  • 20. Scrum tem sido usado para • Software comercial • Desenvolvimento interno (empresa) • Desenvolvimento contratado (terceirização) • Aplicações financeiras • Sistemas embarcados • Jogos • Sistemas para controle de satélites • Websites • Telefones celulares
  • 21. Características do Scrum • As equipes se auto-organizam • O produto evolui em uma série de “Sprints” mensais • Os requerimentos são listados em um “Product Backlog” • Não há prática de engenharia prescrita (o Scrum adequa-se a todas) • É uma das “metodologias ágeis”
  • 23. Product Owner • O representante do cliente
  • 24. Scrum Master • O Scrum Master lidera o time de desenvolvimento
  • 25. Scrum Team • Scrum Team São os membros que formam o time de desenvolvedores, designers, consiste de 5 a 9 pessoas.
  • 26. Papéis e Responsabilidades ► Define as funcionalidades do produto assim como conteúdo e data das liberações; Product Owner ► Responsável pela rentabilidade do produto; ► Prioriza as funcionalidades de acordo com o valor do mercado; ► Pode mudar as funcionalidades e priorizar a cada 30 dias; ► Aceita ou rejeita os resultados do trabalho. ► Garante que a equipe está completamente funcional e produtiva; Scrum Master ► Facilita comunicação entre papéis e remove impedimentos; ► Protege a equipe contra interferências externas; ► Assegura que o processo é seguido; ► Coordena os encontros diários, revisão e planejamento da iteração. ►Estimar itens do backlog Team ► Tem o direito de realizar quaisquer atividades para alcançar o objetivo da iteração desde que respeite os guidelines do projeto; ► Auto organizados para entregar o que o PO quer. © 2006 BenQ Mobile 26
  • 27. Ciclo de Vida Ciclo de vida do Scrum Fonte: Adaptado de Improve It (2008)
  • 28. Ciclo de Vida Ciclo de vida do Scrum Fonte: Adaptado de Improve It (2008)
  • 29. Ciclo de Vida Ciclo de vida do Scrum Fonte: Adaptado de Improve It (2008)
  • 30. O Product Backlog é uma lista de todas as funcionalidades desejadas no produto, estimadas pelo time e priorizadas pelo Product Owner.
  • 31. Exemplo de Product Backlog
  • 32. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Priorização é tarefa do PO Alinhado ao plano de negócios
  • 33. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Priorização é tarefa do PO Alinhado ao plano de negócios
  • 34. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Priorização é tarefa do PO Alinhado ao plano de negócios
  • 35. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Priorização é tarefa do PO Alinhado ao plano de negócios
  • 36. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Alinhado ao plano de negócios
  • 37. Sprints • Representa um Time Box (uma iteração), dentro do qual um conjunto de atividades deve ser executado • Ocorre em um período de duas a quatro semanas • Baseia-se na idéia de que um período constante leva a um melhor “ritmo” • O produto é projetado, codificado e testado durante o Sprint • No início de cada Sprint, faz-se um Sprint Planning Meeting
  • 38. Sprints - Sprint Planning Meeting - • É uma reunião de planejamento na qual: o O Product Owner prioriza os itens do Product Backlog o O Scrum Team determina que atividades será capaz de implementar durante o novo Sprint e cria o Sprint Backlog o O Scrum Team e o Product Owner definem um objetivo para o Sprint • O sucesso do Sprint será avaliado mais adiante no Sprint Review Meeting em relação ao objetivo traçado para o Sprint
  • 39. Sprints - Sprint Backlog - • É uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint • Seus itens são extraídos do Product Backlog com base nas prioridades definidas pelo Product Owner • Uma estimativa do tempo necessário para a implementação das funcionalidades • O Scrum Master mantém o Sprint Backlog atualizado
  • 40. Sprints - Daily Scrum - – É uma reúnião diária da equipe dentro do Sprint, que tem por objetivo: o Disseminar conhecimento sobre o que foi feito no dia anterior o Identificar impedimentos o Priorizar o trabalho a ser realizado no dia que se inicia – Os impedimentos identificados devem ser tratados pelo Scrum Master o mais rapidamente possível Obs: o Daily Scrum não deve ser usado como uma reunião para resolução de problemas
  • 41. Sprints - Daily Scrum - • Três Questões para todos: • O que fizeste ontem? • O que vais fazer Hoje? • Há Algum obstáculo? • Obs: As respostas não são um relatório para o Scrum Master. Elas são comprimissos dentro do Scrum Team.
  • 42. Sprints - Sprint Review Meeting - O ScrumTeam e o SCRUM Master apresentam ao Product Owner os resultados alcançados durante o sprint.
  • 43. Sprints - Sprint Retrospective - O Sprint Retrospective ocorre ao final de um Sprint e serve para identificar o que funcionou bem, o que pode ser melhorado e que ações serão tomadas para melhorar. Todos participam: –Scrum Master –Product Owner –Scrum Team
  • 44. Sprints - Sprint Retrospective - Em uma das maneiras de se conduzir um Sprint Retrospective, a equipe discute o que gostaria de: – Iniciar a fazer – Parar de fazer – Continuar fazendo
  • 45. Estudo de Caso: O Projeto XMPM (1) Características do Projeto • Software desktop destinado a usuários finais de celulares BenQ- Siemens • Projeto complexo com 300,000 LOC possuindo um ciclo de vida médio → Interação complexa com o ambiente físico (celular) → O software deve suportar diferentes modelos de celulares e rodar em diferentes distribuições do Linux → Uma série de versões intermediárias (builds) precisam ser desenvolvidas e testadas. → Desenvolvido por três parceiros situados fisicamente em localidades diferentes. → Necessidade de boa comunicação entre as equipes de desenvolvimento. → Definição clara de papéis e responsabilidades. © 2006 BenQ Mobile 45
  • 46. Estudo de Caso: O Projeto XMPM (2) Características do Produto → Suporte a 9 (nove) diferentes idiomas; → Possui instalador gráfico para as seguintes distribuições (supporte oficial): - Suse 10 - Ubuntu 5.10 - Mandriva 2006 XMPM → Algumas das funcionalidades do XMPM incluem: - Sincromização de contatos, tarefas, notas e calendário entre o telefone celular BenQ-Siemens e KDE-Kontact. - Acesso à internet através de uma conexão GPRS. - Acessa ao sistema de arquivos e suporte a diferentes formatos de música. © 2006 BenQ Mobile 46
  • 47. Estudo de Caso: O Projeto XMPM (3) Práticas adaptadas para o contexto do projeto Sprint: - No projeto XMPM foram usados 5 sprints e cada sprint com duração de aproximadamente 30 dias. - Sprints de 30 dias fornecem uma melhor visibilidade dos objetivos do pro e comprometimento da equipe. - Iterações mais curtas podem melhorar a visibilidade do projeto e permitir que riscos e incertezas sejam eliminados o mais rápido possível. © 2006 BenQ Mobile 47
  • 48. Estudo de Caso: O Projeto XMPM (4) Práticas adaptadas para o contexto do projeto Planejamento do Sprint: - Duas reuniões são conduzidas no ínicio de cada iteração. - A primeira é realizada internamente com o product owner e visa refinar e priorizar o backlog do produto. - A segunda é realizada com os parceiros e visa criar o backlog do sprint de modo a atender os objetivos da iteração. © 2006 BenQ Mobile 48
  • 49. Estudo de Caso: O Projeto XMPM (5) Práticas adaptadas para o contexto do projeto Revisão do Sprint: - A equipe apresenta no final de cada iteração os resultados obtidos (software funcionando) para o product owner e parceiros. - Esta prática impõe que a equipe trabalhe arduamente para alcançar os objetivos prometidos para a iteração. © 2006 BenQ Mobile 49
  • 50. Estudo de Caso: O Projeto XMPM (6) Reunião de Retrospectiva: - O Scrum master e a equipe participam desta reunião. - O que deu certo durante o sprint e o que poderia ser melhorado. © 2006 BenQ Mobile 50
  • 51. Estudo de Caso: O Projeto XMPM (7) Práticas adaptadas para o contexto do projeto Reuniões Diárias do Scrum: - As reuniões diárias ajudam a saber o quê cada membro da equipe está fazendo, compartilhar conhecimento e fornece uma boa visão para o Scrum Master. - O quê você fez desde o último report? - O quê você irá fazer até a próxima reunião? -Existe algum bloqueio para alcançar os objetivos da iteração? - Alguma lição aprendida ou decisão tomada? © 2006 BenQ Mobile 51
  • 52. Estudo de Caso: O Projeto XMPM (8) Práticas adaptadas para o contexto do projeto Builds Diários: - Builds diários no branch de cada parceiro e um build semanal no ramo principal do projeto (uso de padrões de gerência de configuração). © 2006 BenQ Mobile 52
  • 53. Estudo de Caso: O Projeto XMPM (9) Práticas sendo adaptadas para o contexto do projeto Teste antes do desenvolvimento: - Esta prática força o desenvolvedor pensar sobre o que o código deveria fazer antes de realmente implementá-lo. - Caso o desenvolvedor não seja capaz de escrever o caso de teste para o código então provavelmente existem problemas de projeto. - Depois de criar e executar o teste unitário, o mesmo torna-se apenas uma instância de testes de regressão. - Esta prática é simples em conceito, mas requer intensa preparação técnica. © 2006 BenQ Mobile 53
  • 54. Resumo e Perspectiva Resumo • O fator terceirização adiciona mais complexidade ao uso do Scrum. • As práticas melhoram a visibilidade do projeto e reduzem riscos e incertezas no início do ciclo de desenvolvimento. • A prática “revisão do sprint” exige que a equipe se esforce para cumprir com os objetivos prometidos da iteração. • A prática “teste antes do desenvolvimento” evita a criação de classes complexas e assegura a qualidade do código. Perspectiva • Adaptação dos métodos ágeis para desenvolvimento de sistemas embarcados. © 2006 BenQ Mobile 54
  • 55. Conclusão Scrum é uma metodologia de gerenciamento de projetos que está se tornando cada vez mais comum na industria de software. É bastante eficiente quando utilizado por equipes pequenas, mas pode tranquilamente ser usado em projetos com grandes equipes. O Scrum tem como vantagens a velocidade, um bom controle do cronograma, diminuição dos riscos e incertezas e a visibilidade - graças às constantes reuniões. Por outro lado, a grande desvantagem do Scrum é a sensação de informalidade, devida a falta de documentação formal do software.
  • 56. ?
  • 57. • http://br.groups.yahoo.com/group/scrum-brasil/ • http://blogdoabu.blogspot.com/2008/11/planning-poker.html • http://planningpoker.com/ • http://netfeijao.blogspot.com/2008/10/estimativas-geis- planning-poker.html • Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft Press 2004 • Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta, Juhani. Agile Software Development Method, Review and Analysis. Espoo 2002. VTT Publications 478. 107p • Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed. Enterprise Software Development Community, 2007.
  • 58. Planning Poker An agile estimating technique for agile and Scrum teams Gestão ágil de projetos Apresentadores: Fábio Abrantes Diniz Íthalo Bruno de Moura
  • 59. 31% são cancelados 53% custam o dobro do estimado Apenas 16% são completados no prazo e custo estimados * dados do CHAOS report
  • 61. Falta de envolvimento do usuário Requisitos e especificações incompletas Falta de suporte da direção Falta de Pessoas e Recursos Falta de ESTIMATIVAS!!!
  • 62. É difícil estimar tempos de execução
  • 63. Time* *Tudo eu! Tudo eu!
  • 65. Responsabilidades: • Estimar itens do backlog • Se comprometer a entregar um incremento funcional de software • Gerenciar o próprio progresso • Auto organizados para entregar o que o PO quer
  • 67.
  • 68. Reunião de Estimativa: • Preparação para o Sprint Planning • Estimar baseado no tamanho, nunca em tempo • Atualizar Product Backlog com as estimativas • Importante para o PO criar o release plan
  • 69. O Product Backlog Emergente Priorizado e estimado Maior prioridade, mais detalhes Qualquer um pode contribuir Priorização é tarefa do PO Sempre visível Alinhado ao plano de negócios
  • 70. Scrum foca em tamanho e não em duração
  • 71. Estimar em tamanho relativo é mais simples
  • 72. Planning Poker • É um método eficiente que estima o tamanho dos requisitos em times que adotam métodos ágeis (SCRUM, XP).1 • O método foi primeiramente descrito por James Grenning em 2002 e, mais tarde popularizado por Mike Cohn no livro Agile Estimating and Planning. 1 – É uma variação do método de estimativa Wideband Delphi (1940)
  • 73. Planning Poker • As estimativas acontecem em reuniões: – Geralmente 4 ou 8 horas. – Paticipantes: • Todos os membros do time do Scrum; • O PO somente esclarece os requisitos e não estima junto a equipe; • O Scrum Master registra os resultados, não interferindo nas estimativas do time; • A equipe não deve ser superior a dez pessoas.
  • 74. O Processo 1. Cada membro do time recebe um deck de cartas:  0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? e “pausa”. http://en.wikipedia.org/wiki/Planning_poker
  • 75. O Processo 2. Os itens a serem estimados são lidos pelo PO ou SM  A equipe decide qual o menor item de backlog disponível. http://blogdoabu.blogspot.com/2008/11/planning-poker.html
  • 76. O Processo 3. Após a estimativa inicial, esse item é marcado como “2” pontos  Serve para definir uma referência de tamanho e complexidade para ser usada nas demais estimativas.  E deve ficar registrado para uso nas futuras reuniões.  Em casos excepcionais o time pode decidir mudar esta estória de referência por uma outra.
  • 77. O Processo 4. Para cada estória o SM ou PO lê a descrição e os critérios da aceitação da mesma.  São respondidos questionamentos a respeito da estória;  Manter a discussão em alto nível, não entrar em detalhes.  Tempo prefixado (timebox) nesta etapa.
  • 78. O Processo 5. Cada desenvolvedor escolhe em silêncio a carta que representa sua estimativa.  O moderador pede para todos mostrarem as cartas. http://blogdoabu.blogspot.com/2008/11/planning-poker.html
  • 79. O Processo 6. Se todas as estimativas convergirem, a estimativa está feita e o processo volta ao início, para um novo item.  Se houver uma grande variação na estimativa, aqueles que apresentaram o(s) maior(es) e o(s) menor(es) valor(es) se justificam.  O processo se repete até todas as estimativas convergirem.
  • 80. Dinâmica • Grupo • São Paulo • Rio Grande do Norte • Paraíba • Goiás • Amazonas • Sergipe • Paraná
  • 81. Conclusões • O Planning Poker é uma prática eficiente de estimação de requisitos • Por ser uma técnica bastante flexível, se enquadra • É uma prática que envolve todo o time – Ajuda times novos a se conhecerem • Realmente funciona!!!
  • 82. ?
  • 83. Referências • http://br.groups.yahoo.com/group/scrum-brasil/ • http://blogdoabu.blogspot.com/2008/11/planning-poker.html • http://planningpoker.com/ • http://netfeijao.blogspot.com/2008/10/estimativas-geis-planning- poker.html • Ken Schwaber. Agile Project Management with Scrum. Ed. Microsoft Press 2004 • Abrahamsson, Pekka, Salo, Outi, Ronkainen, Jussi &Warsta, Juhani. Agile Software Development Method, Review and Analysis. Espoo 2002. VTT Publications 478. 107p • Henrik Kniberg. Scrum and XP Direto das trincheiras. Ed. Enterprise Software Development Community, 2007.