SlideShare uma empresa Scribd logo
SCRUM
Transformando equipes em TIMES COM
CONSTANTE ENTREGA DE VALOR AO CLIENTE




                            ©2009 - Hélio Medeiros e Germano Carvalho
Quem somos ?



    Hélio Medeiros
        Analista de Sistemas
          SINFO - UFRN




   Blog: http://heliomedeiros.com
Email: helio.cabralmedeiros@gmail.com   ©2009 - Hélio Medeiros e Germano Carvalho
Quem somos ?



           Germano Carvalho
               Analista de Sistemas
                  Unimed Natal




                        ©2009 - Hélio Medeiros e Germano Carvalho
NOSSO SOFTWARE
  FUNCIONA ?




            ©2009 - Hélio Medeiros e Germano Carvalho
Será
       mes    ?
           mo ?




                  ©2009 - Hélio Medeiros e Germano Carvalho
ENTÃO OS PROJETOS DE
SOFTWARE FUNCIONAM ?




                ©2009 - Hélio Medeiros e Germano Carvalho
?                         !

    ©2009 - Hélio Medeiros e Germano Carvalho
O MODELO ANTIGO NÃO
    FUNCIONA !!!

               ©2009 - Hélio Medeiros e Germano Carvalho
QUE TAL UM NOVO MODELO ?
     PRONTO PARA A PROPOSTA !!!



                                  ©2009 - Hélio Medeiros e Germano Carvalho
JET OS     TRE SS !!!
PRO       OS S
      MEN
COM




                ©2009 - Hélio Medeiros e Germano Carvalho
QUE REALM ENTE FUNCIONEM !




                      ©2009 - Hélio Medeiros e Germano Carvalho
ONDIZEM COM AS NECESSIDADES
QUE C




                      ©2009 - Hélio Medeiros e Germano Carvalho
DE FORM A ÁGIL E PRODUTIVA




                       ©2009 - Hélio Medeiros e Germano Carvalho
Nossa Product Backlog


Parte 1 - Metodologias Ágeis
Parte 2 - Conhecendo o Scrum
Parte 3 - Experimentando agilidade com Scrum




                                      ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog



           1   Metodologias Ágeis




                       ©2009 - Hélio Medeiros e Germano Carvalho
Realidade da AGILE ?

Será que vai vingar ?
Será que não vai vingar ?
Vale a pena investir nisso?
Caso eu invista, conseguirei aproveitar algum
conhecimento ?




                                         ©2009 - Hélio Medeiros e Germano Carvalho
Realidade da AGILE ?



                                    200 equipes

entrevista fornecida para o Application Development Trends, Gabrielle Benefield - diretora de métodos e práticas do Yahoo!




                                                                                              ©2009 - Hélio Medeiros e Germano Carvalho
a
          a rlos Silveir
Antônio C
                            ©2009 - Hélio Medeiros e Germano Carvalho
Realidade da AGILE ?




                   ©2009 - Hélio Medeiros e Germano Carvalho
Realidade da AGILE ?




                   ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog


Parte 1 - Metodologias Ágeis

  Realidade da AGILE;

  Por que precisamos de uma metodologia?

  Introdução às metodologias ágeis;




                                       ©2009 - Hélio Medeiros e Germano Carvalho
Precisamos de metodologia ?
Como escolher uma ?




             Gato de Cheshire.
             Alice no país das maravilhas, de Lewis Carroll
                                                              ©2009 - Hélio Medeiros e Germano Carvalho
Precisamos de metodologia ?
Como escolher uma ?




    ONDE se aplica
    O QUE influencia
    Quais as visões históricas empregadas aos projetos;
    Qual o propósito de um processo de desenvolvimento;
    Quais a estatísticas caóticas para projetos de software;


                                           ©2009 - Hélio Medeiros e Germano Carvalho
O que é projeto ?
Apenas 3 décadas... mais várias visões diferentes


                                   “Um projeto é um problema
                                    agendado para solução”

 Dr. Joseph M. Juran
O "pai" da qualidade, criador do
  princípio de pareto (80-20)




          “Um projeto é uma coleção de valor
             agendada para realização”
                                                             David J. Anderson
                                                        Criador do FDD e uma das maiores
                                                             mentes de Agile mundial

                                                    ©2009 - Hélio Medeiros e Germano Carvalho
O que é projeto ?
Composição de um ambiente de um projeto de software




                                             ©2009 - Hélio Medeiros e Germano Carvalho
O que é projeto ?
Composição de um ambiente de um projeto de software




                                             ©2009 - Hélio Medeiros e Germano Carvalho
O que é projeto ?
Exemplo de influência causada pelos itens do ambiente de projeto




                                             2ª
                                     SEXTA-FEIRA

       CULTURA
         {


     ESPOSA JAPONESA
     CARDÁPIO JAPONÊS
   TRADIÇÕES JAPONESAS
                            >       MANTER SO COSTUMES


                                                ©2009 - Hélio Medeiros e Germano Carvalho
O que é projeto ?
 Exemplo de influência causada pelos itens do ambiente de projeto




                                           encontrar seu amigo
                                          Steve... vegetariano...
                                     na 2ª sexta e pedir emprego em
                                      um jantar... NA SUA CASA...
FICAR DESEMPREGADO                      PODE SER BEM DIFÍCIL?
      acontece...
                                                 ©2009 - Hélio Medeiros e Germano Carvalho
O que é projeto ?
Exemplo de influência causada pelos itens do ambiente de projeto




                                                ©2009 - Hélio Medeiros e Germano Carvalho
O que é projeto ?
Exemplo de influência causada pelos itens do ambiente de projeto


    Eu conheço algum prato vegetariano ?
    Eu tenho utensílios para preparar estes pratos ?
    Será que minha esposa possui as técnicas
    necessárias ao preparo dos pratos ?
    O que será que minha família está pensando
    enquanto a estas mudanças ? Estão felizes ?
    Receptivos ? Colaborativos ?


                                                ©2009 - Hélio Medeiros e Germano Carvalho
O que é projeto ?
Características dos componentes


           Pessoas
     - Conhecimento e habilidades
   - Motivação e comprometimento
          -Reconhecimento
                                         Processos
                                    - Disciplina e coordenação
            -Crescimento
                                          - Gerenciamento
                                           - Padronização
                                        - Institucionalização

            Cultura
       - Personalidade coletiva
         - Risco X Segurança          Ferramentas
                - Ética                 - Produtividade
    - O “jeito de ser” da empresa          - Controle
                                          - Eficiência
                                         - Automação

                                                      ©2009 - Hélio Medeiros e Germano Carvalho
Atividade
Analisando os componentes de um contexto qualquer



  Escolha um contexto qualquer e
  descreva resumidamente:

  1. Que pessoas estão envolvidas ?
  2. Quais processos são observáveis ?
  3. Quais tecnologias são aplicadas ?
  4. Como a cultura influencia ou é
  influenciada ?



                                              ©2009 - Hélio Medeiros e Germano Carvalho
Precisamos de metodologia ?
Como categorizar a complexidade de um projeto de software ?




Ogunnaike and Ray:
Process Dynamics, Modeling and Control




                                               ©2009 - Hélio Medeiros e Germano Carvalho
Precisamos de metodologia ?
O Chaos Report

                    Falhou   Necessitou adequações         Bem sucedido

     100%
                 33%         35%            33%

      75%

                 43%         46%            52%
      50%


      25%
                 24%
                             19%            15%
       0%
                 2004        2006           2009


                                                     ©2009 - Hélio Medeiros e Germano Carvalho
Precisamos de metodologia ?
O Chaos Report

                                          Aumento nos custos
                                          Aumento no tempo
                                          Alteração de funcionalidades
      70




      35




       0
                 Adequações necessárias

                                                      ©2009 - Hélio Medeiros e Germano Carvalho
Precisamos de metodologia ?
O Chaos Report

  Isso significa que, se fabricássemos aviões...

                                            32%
                                            pousariam sem
                                            problemas


                                            44%
                                            pousariam com
                                            problemas



                                            24%
                                            cairiam

                                           ©2009 - Hélio Medeiros e Germano Carvalho
Precisamos de metodologia ?
Quais itens analisar na escolha ?


                   COMO lidar com REQUISITOS;

                COMO melhorar a COMUNICAÇÃO;

                   COMO estimar as ATIVIDADES;

                COMO entregarmos os PRODUTOS;

                 COMO difundir o CONHECIMENTO;

                QUAL o ciclo de vida do PRODUTO;

                COMO organizar nossa PRODUÇÃO;

                COMO conseguiremos QUALIDADE;
                                                 ©2009 - Hélio Medeiros e Germano Carvalho
Atividade
Por que precisamos de uma metodologia?


  Cite quais são os principais
  p ro b l e m a s n o p ro c e s s o d e
  desenvolvimento de software que
  você esteja envolvido.


  Cite o que você espera de uma
  metodologia para desenvolvimento
  de software.


                                            ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog


Parte 1 - Metodologias Ágeis

  Realidade da AGILE;

  Por que precisamos de uma metodologia?

  Introdução às metodologias ágeis;




                                           ©2009 - Hélio Medeiros e Germano Carvalho
Introdução às abordagens ágeis
O que NÃO é agilidade?




                         ©2009 - Hélio Medeiros e Germano Carvalho
Introdução às abordagens ágeis
O que é agilidade?



                                     “Agilidade é a habilidade para criar e responder à
                                     mudança, para lucrar num ambiente turbulento de
                                                          negócios.”


                                          “Agilidade é a habilidade para equilibrar
                                                 flexibilidade e estabilidade.”
    Jim Highsmith
Um dos principais escritores sobre
    AGILE e criador da ASD.




                                                                    ©2009 - Hélio Medeiros e Germano Carvalho
Introdução às abordagens ágeis
Os princípios




                      ©2009 - Hélio Medeiros e Germano Carvalho
Introdução às abordagens ágeis
O manifesto Ágil




                   Kent Beck, Jim Highsmith, Alistair
                    Cockburn, Martin Fowlor, Ken
                     Shwaber e Jeff Sutherland;




                                                        ©2009 - Hélio Medeiros e Germano Carvalho
Introdução às abordagens ágeis
        O manifesto Ágil


       Indivíduos e a interação
                                  mais que   processos e ferramentas
              entre eles


    Produto em funcionamento      mais que   documentação abrangente



    Colaboração com o cliente     mais que   negociação de contratos



       Responder a mudanças       mais que       seguir um plano

http://agilemanifesto.org                           ©2009 - Hélio Medeiros e Germano Carvalho
Introdução às abordagens ágeis
Desenvolvimento iterativo


  custo fixo

  conjunto de funcionalidades;

  priorizado pelo cliente

  podemos perder funcionalidades, nunca
  datas;

  prioridades no “final da lista” podem ficar
  de fora;

  Flexibilidade está nas funcionalidades,
  não no prazo ou no custo;

                                              ©2009 - Hélio Medeiros e Germano Carvalho
Introdução às abordagens ágeis
Desenvolvimento iterativo


                                Produto

    release 1 release 2 release 3              ... release n
               novo release a cada X meses



      iteração 1   iteração 2     iteração 3   iteração 4        ...
                   novo iteracao a cada X semanas


                                                            ©2009 - Hélio Medeiros e Germano Carvalho
Introdução às abordagens ágeis
Desenvolvimento iterativo

                                              O Release 1 terá as seguintes
     Produto                                  funcionalidades:

                                              - Funcionalidade A    - Funcionalidade G
                                              - Funcionalidade B    - Funcionalidade H
     release 1                                - Funcionalidade C    - Funcionalidade I
                                              - Funcionalidade D    - Funcionalidade J
                                              - Funcionalidade E    - Funcionalidade L
                                              - Funcionalidade F    - Funcionalidade Z




       iteração 1   iteração 2   iteração 3    iteração 4          ...
                     Func. B
        Func. A                   Func. C        Func. D
                     Func. F
        Func. E                   Func. H        Func. I
                     Func. J
        Func. G                   Func. L
                     Func. Z
                                                           ©2009 - Hélio Medeiros e Germano Carvalho
Introdução às abordagens ágeis
O ciclo de vida de projetos ágeis

                                         Exploração
   Visão



                                       Funcionalidades Prontas

                     Especulação
                                         Adaptação

  Visão do Produto


                                    Fechamento
                                                                       Produto Final
                                                ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog



           2   Conhecendo o Scrum




                       ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog
Parte 2 - Conhecendo o Scrum
O que é Scrum?
O ciclo de vida do Scrum;
Os papéis no Scrum;
O conceito de Sprint: Entregando frequentemente software de valor;
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em
primeiro plano;
Sprint Planning Meeting: Planejamento na medida certa;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que se
tornem grandes;
Sprint Review: Apresentando o resultado;
Sprint Retropective: Avaliando pontos positivos e negativos e se
preparando para reiniciar;

                                                     ©2009 - Hélio Medeiros e Germano Carvalho
O que é Scrum ?
Depende de onde você está




                            ©2009 - Hélio Medeiros e Germano Carvalho
O que é Scrum ?
O origem do Scrum


  Criada no início da década de 1990
  Estados Unidos.




                               TA  nt
                            YO eme
                         TO nag
                             a
                          nM
                      Lea




                                        ©2009 - Hélio Medeiros e Germano Carvalho
O que é Scrum ?
Scrum NÃO é uma bala de prata!




                                 ©2009 - Hélio Medeiros e Germano Carvalho
O que é Scrum ?
A objetividade do Scrum

  papéis bem difinidos, e é de fácil adaptação;
  SCRUM APONTA OS ERROS !
  Um dos aspectos positivos do Scrum é a sua adaptabilidade,
  portanto, o conhecimento das suas práticas é extremamente
  importante, por permitir a aplicação das mesmas de forma
  variada.




                                             ©2009 - Hélio Medeiros e Germano Carvalho
O que é Scrum ?
Problemas com a adaptabilidade



                    Sprint Planning Meeting
                          Um dia inteiro sem produção ?


                                      Daily Meeting
                                          Horários ? Para que?




                                             ©2009 - Hélio Medeiros e Germano Carvalho
O que é Scrum ?
  Liderança-colaboração SIM ! Comando-controle NÃO !


                 Comando - Controle



               Liderança - Colaboração

Comando-Controle é muito lento porque:
✓Não permite processar informações rapidamente;
✓Não permite tomar decisões rapidamente;
✓Não envolve ou motiva ao trabalho;
✓Não propicia responsabilidade diária sobre o andamento à equipe;
                                                ©2009 - Hélio Medeiros e Germano Carvalho
Atividade
A arte do possível

  Explore a diferencça entre planejar uma viagem se
  cada sentença começa com:


      “ Sim, mas ”


       “ Sim, e ”




                                          ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog
Parte 2 - Conhecendo o Scrum
O que é Scrum?
O ciclo de vida do Scrum;
Os papéis no Scrum;
O conceito de Sprint: Entregando frequentemente software de valor;
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em
primeiro plano;
Sprint Planning Meeting: Planejamento na medida certa;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que se
tornem grandes;
Sprint Review: Apresentando o resultado;
Sprint Retropective: Avaliando pontos positivos e negativos e se
preparando para reiniciar;

                                                     ©2009 - Hélio Medeiros e Germano Carvalho
O ciclo de vida do SCRUM?

© 2007 Alexandre Magno - As Armadilhas do Scrum




                                                  ©2009 - Hélio Medeiros e Germano Carvalho
O ciclo de vida do SCRUM?

 O ciclo de vida do Scrum é baseado em iterações bem
 definidas de duas a quatro semanas, chamadas SPRINTS.
 Antes de cada Sprint, realiza-se uma reunião de
 planejamento ( Sprint Planning Meeting ) em que o time
 (Team Members) de desenvolvimento tem contato com o
 cliente ( Product Owner ) para priorizar o trabalho que
 precisa ser feito, selecionar e estimar as tarefas que o time
 pode realizar dentro da Sprint.
 A próxima fase é a execução da Sprint.



                                                ©2009 - Hélio Medeiros e Germano Carvalho
O ciclo de vida do SCRUM?

 Durante a execução da Sprint, o time controla o andamento
 do desenvolvimento realizando Reuniões Diárias ( Daily
 Meeting ) de não mais de 15 minutos de duração, e
 observando o seu progresso usando um gráfico chamado
 Sprint Burndown.
 Ao final de cada Sprint, deve-se realizar uma Reunião de
 Revisão ( Sprint Review ), em que o time demonstra o
 produto gerado na Sporint e valida se o objetivo foi atingido.
 Logo em seguida, realiza-se a Reunião de Retrospectiva
 ( Sprint Retrospective ), uma reunião de lições aprendidas,
 com o objetivo de melhorar o processo, time eou produto
 para a próxima Sprint.
                                                ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog
Parte 2 - Conhecendo o Scrum
O que é Scrum?
O ciclo de vida do Scrum;
Os papéis no Scrum;
O conceito de Sprint: Entregando frequentemente software de valor;
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em
primeiro plano;
Sprint Planning Meeting: Planejamento na medida certa;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que se
tornem grandes;
Sprint Review: Apresentando o resultado;
Sprint Retropective: Avaliando pontos positivos e negativos e se
preparando para reiniciar;

                                                     ©2009 - Hélio Medeiros e Germano Carvalho
Os papéis no Scrum
Pigs e chickens são papéis no Scrum ?




                                        ©2009 - Hélio Medeiros e Germano Carvalho
Os papéis no Scrum
Pigs e chickens são papéis no Scrum ?

  Os termos pig ( porco ) e chicken ( galinha ) são utilizados
  em Scrum de forma informal.
  Pig: Alguém que ocupa um dos três papéis do Scrum ( Team
  memeber, Product owner, Scrum Master) e tem um total
  comprometimento com o projeto.
  Chicken: Alguém que tem interesse no produto a ser gerado,
  mas não ocupa nenhum papel formal do Scrum.




                                                ©2009 - Hélio Medeiros e Germano Carvalho
Os papéis no Scrum
O Product Owner (PO)




 O Product Owner representa o cliente ou
 patrocinador do projeto, e faz parte do time
 que entregará o produto.




                                                ©2009 - Hélio Medeiros e Germano Carvalho
Os papéis no Scrum
O Product Owner (PO)



  Define funcionalidades
  Faz o plano de Release
  Product vision
  ROI
  Priorização
  Ajusta escopo
  Aceita ou rejeita um Sprint
  Disponibilização técnicos de domínio


                                         ©2009 - Hélio Medeiros e Germano Carvalho
Os papéis no Scrum
O Scrum Master (SM)


  O Scrum Master, diferentemente dos
  gerentes de projeto na maioria das práticas
  e metodologias, difere do tradicional
  “comando e controle”. Em Scrum, um SM
  trabalha com e, principalmente, para o
  time.




                                                ©2009 - Hélio Medeiros e Germano Carvalho
Os papéis no Scrum
O Scrum Master (SM)



  Responsável pelo processo
  Gerenciamento
  Valores e princípios
  Remove impediemntos
  Garante a produtividade
  Colaboração entre papéis
  Protege o time de Interferências




                                     ©2009 - Hélio Medeiros e Germano Carvalho
Os papéis no Scrum
Os membros do time

  Os membros do time são pessoas que
  estão comprometidos a fazer o trabalho
  necessário para atingir a meta de uma
  Sprint.
  Em Scrum não temos arquitetos,
  testers ou programadores, temos sim,
  membros com perfis de arquiteto, de
  tester ou de programador... mas que
  podem atuar em papeis secundários
  para garantir o alcance da meta.



                                           ©2009 - Hélio Medeiros e Germano Carvalho
Os papéis no Scrum
Os membros do time


Suas responsabilidades são:

 Definir a meta do Sprint;
 Estar comprometido com o trabalho
 Colaborar com outros membros do time
 e ajudar a torná-lo auto-gerenciado;
 Estimar itens do backlog de forma
 realista;
 Participar das reuniões diárias;
 Compartilhar conhecimento com a equipe
 Manifestar impedimentos;

                                          ©2009 - Hélio Medeiros e Germano Carvalho
Os papéis no Scrum
Fluxo simples


                 Coloca itens
                 (priorizados)                               Pega itens



Product owner
                                                                                         Time
                                    Product Backlog
                                                                                 Coloca

                                 Serve                O que sobrar...
                                                         devolve




                Scrum Master                                                  Sprint Backlog
                                                                ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog
Parte 2 - Conhecendo o Scrum
O que é Scrum?
O ciclo de vida do Scrum;
Os papéis no Scrum;
O conceito de Sprint: Entregando frequentemente software de
valor;
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em
primeiro plano;
Sprint Planning Meeting: Planejamento na medida certa;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que se
tornem grandes;
Sprint Review: Apresentando o resultado;
Sprint Retropective: Avaliando pontos positivos e negativos e se
preparando para reiniciar;
                                                     ©2009 - Hélio Medeiros e Germano Carvalho
O conceito de Sprint
Característivas

  2, 3 ou 4 semanas;
  Frequentemente entregando algo de valor para o cliente;
  Time multi-funcional com não mais que oito membros;
  Cada Sprint deve ter uma meta específica que represente o
  desejo do cliente para aquele time-box específico;
  Os membros do time da Sprint são os responsáveis por
  estimar os itens que compõem o desejo do cliente e dar a
  palavra final sobre o que será possível ser desenvolvido
  naquele time-box;




                                             ©2009 - Hélio Medeiros e Germano Carvalho
O conceito de Sprint
Composição

 Planejamento ( Sprint Planning Meeting ):
 Daily Scrum
 Execução ( The Sprint ):
 Revisão ( Sprint Review ):
 Retrospectiva ( Sprint Retrospective ):




                                             ©2009 - Hélio Medeiros e Germano Carvalho
O conceito de Sprint
Cancelamento

 O cancelamento de um Sprint antes de seu termino acontece
 nas seguintes condições:
   O time pode cancelar se sentir que não conseguirá atingir a
   sua meta, lembrando que cancelamentos consecutivos são
   falhas apontadas pelo Scrum, qual o problema ?
    Gerentes podem cancelar um Sprint caso fatores externos
    influenciem diretamente no valor da meta do Sprint;
    Caso um Sprint seja cancelado deve ser iniciado o
    planejamento do próximo Sprint imediatamente;




                                               ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog
Parte 2 - Conhecendo o Scrum
O que é Scrum?
O ciclo de vida do Scrum;
Os papéis no Scrum;
O conceito de Sprint: Entregando frequentemente software de valor;
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente
em primeiro plano;
Sprint Planning Meeting: Planejamento na medida certa;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que se
tornem grandes;
Sprint Review: Apresentando o resultado;
Sprint Retropective: Avaliando pontos positivos e negativos e se
preparando para reiniciar;

                                                 ©2009 - Hélio Medeiros e Germano Carvalho
Product Backlog
Entendendo

  O Product Backlog representa em ítens a visão do produto
  e é o primeiro passo a ser dado em todo projeto Scrum;
  O Product Backlog existirá por todo o ciclo de vida do
  projeto, e não da Sprint.
  Este é regularmente atualizado pelo Product Owner para
  refletir mudanças e necessidades do cliente, mudanças
  estratégicas ou tecnológicas, novas idéias...
  O Product Backlog pode ser composto por diferentes tipos
  de itens: funcionalidades, exploração técnica, estudo,
  documentação, bugs, requisitos de desenvolvimento...
  Só exisite um Product Backlog durante todo o projeto.
                                             ©2009 - Hélio Medeiros e Germano Carvalho
Product Backlog
 A física do Product Backlog

Alta Prioridade

                               Cada Sprint implementa os requisitos
                               de prioridade mais alta

                                           Cada novo item é priorizado e
                                           inserido pelo PO a qualquer
                                           momento

                                Todos os itens podem ser
                                repriorizados pelo PO

                                           Itens podem ser removidos
                                           pelo PO a qualquer momento
Baixa Prioridade
                                                  ©2009 - Hélio Medeiros e Germano Carvalho
Product Backlog
Exemplo

                                    PRODUCT BACKLOG
                                          P R OD U C T BAC K L OG

   Id                              Item                             Estimativa Prioridade
   1      Refatorar o banco de dados                                   32               10
   2      Relatório de Vendas por unidade e período                     8                8

   3      Suporte a cartão de crédito Visa no processo de Vendas       13                9
   4      Relatório Gerencial com Estatísticas de Vendas                5                7

   5      Alterações na tela de entrada do sistema                      5                6

   6      Estudar nova versão da framework de mapeamento O/R            5                5

   7      Consulta parametrizada de Vendas                              3                4

   8      Criação do Help                                              13                4

   9      Implementar internacionalização                               8                2
  Total                                                                 92               6



                                                                        ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog
Parte 2 - Conhecendo o Scrum
O que é Scrum?
O ciclo de vida do Scrum;
Os papéis no Scrum;
O conceito de Sprint: Entregando frequentemente software de valor;
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em
primeiro plano;
Sprint Planning Meeting: Planejamento na medida certa;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que se
tornem grandes;
Sprint Review: Apresentando o resultado;
Sprint Retropective: Avaliando pontos positivos e negativos e se
preparando para reiniciar;

                                                     ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
Regras

  A Sprint Planning Meeting ou Reunião de Planejamento, é dividida
  em duas partes, e entra em cena no início de cada Sprint.

  Além de todos os comprometidos (PO, SM e Time), alguns
  envolvidos podem ser convidados a participar em determinados
  momentos da reunião, desde que agreguem valor à mesa e
  tenham seu convite aprovado pelo Product Owner.




                                                  ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
Regras

  Pela prática, é percebido que a duração desta reunião segue
  a seguinte tabela:


                           DURAÇÃO
             Sprint       SPM #1           SPM #2
          4 semanas       4 horas          4 horas
          3 semanas       3 horas          3 horas
          2 semanas       2 horas          2 horas




                                                ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
        SPM #1

           Na primeira parte, o Product Owner e o time, sendo facilitados
           pelo Scrum Master, realizamuma revisão no Product Baklog,
           discutindo sobre o propósito e metas de cada item e dando a
           oportunidade para que o PO exponha seus desejos. O time
           seleciona os itens que acredita que possam ser desenvolvidos
           na próxima Sprint e define a meta.
                    PRODUCT BACKLOG
                         P R ODUCT B AC K L OG

Id                    Item                       Estimati Priorida
                                                    va       de
                                                                     Meta do Sprint:
 1 Refatorar o banco de dados                       32       10
 2 Relatório de Vendas por unidade e período        8        8       Refatorar o banco de dados e
                                                                     implementar relaórios de vendas
 3 Suporte a cartão de crédito Visa no             13        9
   processo de Vendas                                                necessáirios para as tomadas de
 4 Relatório Gerencial com Estatísticas de          5        7
                                                                     decisões finais.
        Vendas
Total                                               58       9

                                                                            ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
SPM #1


 Velocidade é uma medida de
 produtividade do time;
 Esta medida representa a taxa de trabalho
 que o time conseguiu completar durante
 um Sprint;
 E serve de guia para o planejamento de Sprints. Por exemplo,
 se na Sprint anterior o time foi capaz de completar 55 pontos,
 esta quantidade de trabalho realizado passa a ser a velocidade
 do time e contribuirá durante o planejamento do próximo sprint;
 Serve de guia para o planejamento de Releases e progresso de
 projeto. Ex.: Temos um Product Backlog de 165 pontos.
                                              ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
SPM #1


   Product Backlog



                               Selecionar Sprint Backlog
                               Como? Não sei nossa velocidade




                Executado com 13
                                                Mini-Sprint Backlog
                pontos ( ou X horas)


               Sprint Backlog
               Velocaidade Inicial: 34
               pontos ( ou x * 3 horas )
                                                     ©2009 - Hélio Medeiros e Germano Carvalho
Atividade
Jogo da Velocidade


  Quantas bolas de tênis você e
  seu time conseguem colocar
  no mochila em 2 minutos ?




                                  ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
SPM #1


 Durante esta reunião o Product
 Owner ainda pode realizar alterações
 na priorização de itens;
 Deve se discutir também sobre
 estimativas iniciais ou revisão/
 adaptação da estimativa dos itens;
 O esforço estimado entre os itens
 selecionados deve ser negociado
 entre o time e o PO, sempre
 praticando o bom senso;

                                        ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
SPM #1




 Existem diversas técnicas de
 estimativas que podem ser utilizadas
 em projetos Scrum. O Planning Poker
 é uma das mais populares, onde
 utilizam-se cartas numeradas
 seguindo a tabela de fibonacci.




                                        ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
Planning Poker...?

  O Planning Poker:
     vem sendo a melhor técnica utilizada em projetos que
     utilizam processos ágeis;
     combina opinião de especialistas, analogias, bom senso e
     uma forma agradável para se gerar estimativas;
     envolve todos os perfis de membros (programadores,testers,
     DBAs, analistas, designers entre outros);
     utiliza-se dos números da sequência de Fibonacci;
     deve ser aplicado para qualquer novo Item;

                                                  ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
Como funciona o Planning Poker ?

  Cada participante deve possuir o seu conjunto de cartas
  contendo os valores válidos, de acordo com a escala adotada;
  Para cada Product Backlog Item a ser estimado, o facilitador
  (normalmente o Product Owner ou Especialista de Négocio)
  deve realizar uma breve descrição;
  Após todas as dúvidas sobre o item serem respondidas, cada
  membro do time deve escolher uma carta representando a sua
  estimativa. A carta selecionada não deve ser vista pelos outros
  membros do time enquanto todos ainda não tenham
  selecionado a sua;

                                               Estimating & Planning - Mike Cohn
                                                 ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
Como funciona o Planning Poker ?

  Todos devem, ao mesmo tempo,
  mostrar sua carta de estimativa;
  Se as estimativas divergem, os
  participantes que apresentaram carta
  com maior e menor valor devem
  explicar o motivo que o levaram a
  escolhê-la. Isto não deve de forma
  alguma ser feita de forma agrssiva,
  ou mesmo defensiva, mas apenas
  como uma troca de conhecimento
  entre visões diferentes sobre o
  esforço necessário para a conclusão
  do item.                               Estimating & Planning - Mike Cohn
                                           ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
Como funciona o Planning Poker ?


  Após as devidas explicações, inicie um novo Round repetindo o
  ciclo, até que haja um consenso quanto ao tamanho do item;
  Normalmente, as estimativas entram em convergência já no
  segundo round, ou no máxima no terceiro. Mas caso isso não
  aconteça, o ciclo deve ser continuado.




    1         2          3         5                             13



                                              ©2009 - Hélio Medeiros e Germano Carvalho
Vídeo
Experiências com Planning Poker




                                  ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
Por que o Planning Poker funciona ?


  Apresenta múltiplas opniões de especialistas quanto à
  estimativa de um item, e como Scrum trabalha com times
  multi-perfis temos praticamente todas as áreas de
  conhecimento cobertas;
  Porque Planning Poker estimula o dialogo durante os rounds, e
  cada membro do time tem que explicar o porque de sua
  estimativa, ampliando o compartilhamento de conhecimento;
  Estudos mostram que estimativas feitas em grupo vem sendo
  mas bem sucedidas que estimativas individuais;


                                             Estimating & Planning - Mike Cohn
                                               ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
SPM #2



 A segunda parte da reunião de planejamento deve ocorrer
 imediatamente após a finalizar da primeira, sendo nela :
   criada a lista de tarefas, por meio da decomposição dos itens
   do Product Backlog, chamada Sprint Backlog;
   detalhada algum item ou removevida dúvidas quanto ao
   objetivo do mesmo, pelo PO ou especialista convidado;
   elaborada a estratégia de desenvolvimento que será utilizada
   para que a meta da Sprint seja atingida. Sendo necessário
   responder como construirão as funcionalidades do produto
   durante o Sprint;
                                              ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
SPM #2

 Os membros do time devem escolher suas tarefas e então
 estimá-las em horas;
 Tarefas devem ter de 1 a 16 horas de duração. Tarefas maiores
 deverão ser quebradas em duas ou mais.




                                              ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
Características do Sprint Backlog

  Itens do Product Backlog devem ser decompostos em tarefas
  (Tasks);
  As tarefas devem ter estimativas de 1 a 16 horas;
  Qualquer membro do time pode adicionar, remover ou alterar
  tarefas do Sprint Backlog;
  As tarefas são escolhidas pelos membros do time, e não
  designadas a eles;




                                                ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Planning Meeting
Características do Sprint Backlog


                                     SPRINT BACKLOG
                                         SP R IN T BAC K L OG

        Id                               Item                    Estimativa
        1      Refatorar o banco de dados                              32
               Mapear as tabelas que serão refatoradas                6hrs
               Definir estratégias de refatoração                      2hrs
               Montar/Gerar script de refatoração                     8hrs
               Aplicar script de refatoração                          2hrs
               Avaliar eficiência da refatoração                       6hrs
       Total                                                          24 hrs




                                                                ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog
Parte 2 - Conhecendo o Scrum
O que é Scrum?
O ciclo de vida do Scrum;
Os papéis no Scrum;
O conceito de Sprint: Entregando frequentemente software de valor;
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em
primeiro plano;
Sprint Planning Meeting: Planejamento na medida certa;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que
se tornem grandes;
Sprint Review: Apresentando o resultado;
Sprint Retropective: Avaliando pontos positivos e negativos e se
preparando para reiniciar;

                                                   ©2009 - Hélio Medeiros e Germano Carvalho
Scrum Daily Meeting
Se reunir todo dia ? Impossível!

  Uma vez iniciado o Sprint, inicia-se a
  realização das reuniões diárias (Scrum
  Daily Meeting);
  Uma Daily Meeting é uma reunião com:
     duração exata de 15 minutos
     realizadas no mesmo local e horário
     com participação do SM e membros
     do time;
     não havendo um SM presente, deve
     ser definido o facilitador;
                                           ©2009 - Hélio Medeiros e Germano Carvalho
Scrum Daily Meeting
Se reunir todo dia ? Impossível!

  Cada membro deve relatar ao time sobre
  os progressos e obstáculos que encontrou
  em seu caminho. Em suma, três perguntas
  devem ser respondidas por cada um
  deles:
  1. O que fiz (quanto andei) desde a última
     reunião diária ?
  2. O que pretendo fazer ( quanto andarei )
     até a próxima reunião diária ?
  3. Estou encontrando impedimentos ?
     Quais ?

                                               ©2009 - Hélio Medeiros e Germano Carvalho
Atividade
Armadilhas das Reuniões !


  Você está preparado para enfrentar as
  armadilhas das reuniões diárias ?




                                          ©2009 - Hélio Medeiros e Germano Carvalho
Scrum Daily Meeting
     O quadro de acompanhamento


                 Tarefas   Em                      Em         Em
   Item                                                            Conluído Horas
                desejadas análise            desenvolvimento Teste
                Aplicar
                Script de      Montar           Definir
Refatorar
                refatoração    script de        estratégia
banco de
                               refatoração      refatoração
dados                   02                                                                    24
                                       08               02
13              Avaliar
Estimativa em   eficiência                       Mapear as
complexidade    da                              tabelas
                refatoração                     que serão
                        06                      refatoradas
                         Estimativa                     06
                         em tempo


                                                               ©2009 - Hélio Medeiros e Germano Carvalho
Scrum Daily Meeting
O quadro de acompanhamento




                             ©2009 - Hélio Medeiros e Germano Carvalho
Scrum Daily Meeting
O quadro de acompanhamento




                             ©2009 - Hélio Medeiros e Germano Carvalho
Scrum Daily Meeting
O quadro de acompanhamento




                             ©2009 - Hélio Medeiros e Germano Carvalho
Scrum Daily Meeting
O quadro de acompanhamento




                             ©2009 - Hélio Medeiros e Germano Carvalho
Scrum Daily Meeting
Sprint Backlog


                                     SPRINT BACKLOG
                                             SP R I N T BAC K L OG

    Id                        Item
                                                                                        julho/09
    1 Refatorar o banco de dados                                               11           12          13
          Mapear as tabelas que serão refatoradas                    6hrs       6            0           0
          Definir estratégias de refatoração                          2hrs       2            0           0
          Montar/Gerar script de refatoração                         8hrs       0            8           0
          Aplicar script de refatoração                              2hrs       0            0           2
          Avaliar eficiência da refatoração                           6hrs       0            0           6
   Tota                                                              24 hrs   16 hrs       8 hrs       0 hrs
     l




                                                                                       ©2009 - Hélio Medeiros e Germano Carvalho
Scrum Daily Meeting
Sprint Burndown

                                        Ideal               Real
  Após a reunião diária, os
  membros atualizam o         100
  montante de tempo que        90
  resta para o cumprimento     80
  de cada tarefa no Sprint     70
                               60
  Backlog.
                               50
                               40
  Esta informação é
                               30
  acrescida a um gráfico        20
  chamado Sprint Burndown.     10
                                0
  Este gráfico mostra o           11/7   12/7    13/7       14/7          15/7
  projeto dia-a-dia

                                                ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog
Parte 2 - Conhecendo o Scrum
O que é Scrum?
O ciclo de vida do Scrum;
Os papéis no Scrum;
O conceito de Sprint: Entregando frequentemente software de valor;
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em
primeiro plano;
Sprint Planning Meeting: Planejamento na medida certa;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que se
tornem grandes;
Sprint Review: Apresentando o resultado;
Sprint Retropective: Avaliando pontos positivos e negativos e se
preparando para reiniciar;

                                                     ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Review
E o resultado foi...

  Durante o Sprint Review devemos:
     avaliar que esta sendo entregue ?
     realizar uma apresentação do produto
     que foi gerado durante a Sprint.
  Devem participar do Sprint Review o PO,
  o SM e os membros do time, clientes e
  executivos desde que convidados pelo
  PO.
  A apresentação dura 30 minutos


                                            ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog
Parte 2 - Conhecendo o Scrum
O que é Scrum?
O ciclo de vida do Scrum;
Os papéis no Scrum;
O conceito de Sprint: Entregando frequentemente software de valor;
Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em
primeiro plano;
Sprint Planning Meeting: Planejamento na medida certa;
Scrum Daily Meeting: Descobrindo pequenos problemas antes que se
tornem grandes;
Sprint Review: Apresentando o resultado;
Sprint Retropective: Avaliando pontos positivos e negativos e se
preparando para reiniciar;

                                                     ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Retrospective
Aprendendo com os acertos... mas principalmente com os erros


  A Sprint Retrospective é uma das
  ferramentas mais importantes para que você
  obtenha sucesso com Scrum;
  Esta é a oportunidade que o time tem para
  discutir sobre o que funcionou e o que não
  durante a Sprint;
  Product Owner, Scrum Master e os membros
  do time devem participar da retrospectiva.
  Uma boa estratégia é convidar alguém neutro
  para facilitar a reunião;


                                                ©2009 - Hélio Medeiros e Germano Carvalho
Sprint Retrospective
Aprendendo com os acertos... mas principalmente com os erros

  A estrutura da Sprint Retrospective é bem
  simples. Divida um quadro branco ou poster
  em duas áreas com os seguintes títulos: “O
  que funcionou bem ?” e “O que pode ser
  melhorado ?”. Após isso, cada membro deve
  colocar post-its em cada uma das áreas
  indicando os itens que, em sua opnião,
  merecem estar ali;
  Então, o time visualiza os itens citados,
  discute sobre e planeja ações a serem
  tomadas para a próxima Sprint.


                                               ©2009 - Hélio Medeiros e Germano Carvalho
Nosso Sprint Backlog



           3   Experimentando
               agilidade com Scrum




                       ©2009 - Hélio Medeiros e Germano Carvalho
Atividade
Jogo do Planejamento


  O Product Owner deverá entregar a cada equipe um
  Product backlog priorizado representando os desejos de
  seu cliente;

  Planejamento (15 minutos)

  1. O time deve estimar os itens do Product backlog ;
  2. O time deve selecionar os itens do Product backlog
  que poderão ser entregues no final do Sprint.

  Execução (30 minutos)

  1. O time deve executar as atividades da Sprint.

  Revisão (2 minutos)

  1. O time deve apresentar o que foi definido para o Sprint.

                                                               ©2009 - Hélio Medeiros e Germano Carvalho
VOCES PODEM FAZER SOFTWARE
       QUE FUNCIONA
COM MENOS STRESS
EM UM AMBIENTE ÁGIL E PRODUTIVO
SE VOCÊS ACHAVAM QUE ISSO SERIA IMPOSSÍVEL...
EXISTEM MUITOS QUE JÁ O ESTÃO FAZENDO
Indivíduos e a                  processos e
            interação entre eles   mais que    ferramentas

               Produto em                 documentação
           “Estamos descobrindo maneiras melhores
                              mais que
             funcionamento                 abrangente
              de desenvolver software fazendo-o nós
           mesmos ecom o
           Colaboração ajudando outros a fazê-lo. Através
                                          negociação de
                              mais que
                desse trabalho, passamos a contratos
                 cliente                    valorizar:

                  Responder a
                                   mais que   seguir um plano
                   mudanças


http://agilemanifesto.org                         ©2009 - Hélio Medeiros e Germano Carvalho
PERGUNTAS ?




              ©2009 - Hélio Medeiros e Germano Carvalho
ISSO é TUDO PESSOAL !!


Hélio Cabral Medeiros            Germano Carvalho
helio.cabralmedeiros@gmail.com
                                 germano.carv@gmail.com
http://heliomedeiros.com/

                                        ©2009 - Hélio Medeiros e Germano Carvalho

Mais conteúdo relacionado

Semelhante a Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE

UnP Eng. Software - Aula 4
UnP Eng. Software - Aula 4UnP Eng. Software - Aula 4
UnP Eng. Software - Aula 4
Hélio Medeiros
 
UnP Eng. Software - Aula 3
UnP Eng. Software - Aula 3UnP Eng. Software - Aula 3
UnP Eng. Software - Aula 3
Hélio Medeiros
 
Teamware Desmistificando Agile E Scrum V2
Teamware   Desmistificando Agile E Scrum V2Teamware   Desmistificando Agile E Scrum V2
Teamware Desmistificando Agile E Scrum V2
Teamware do Brasil
 
Palestra Sobre Modelo de Negócios Canvas
Palestra Sobre Modelo de Negócios CanvasPalestra Sobre Modelo de Negócios Canvas
Palestra Sobre Modelo de Negócios Canvas
EloGroup
 
Beta talk Pedro Soares (Portimão 16/7/2012)
Beta talk Pedro Soares (Portimão 16/7/2012)Beta talk Pedro Soares (Portimão 16/7/2012)
Beta talk Pedro Soares (Portimão 16/7/2012)
Solar One
 
UnP Eng. Software - Aula 1
UnP Eng. Software - Aula 1UnP Eng. Software - Aula 1
UnP Eng. Software - Aula 1
Hélio Medeiros
 
FGVcenn and I2P Presentation @ Embrapa
FGVcenn and I2P Presentation @ EmbrapaFGVcenn and I2P Presentation @ Embrapa
FGVcenn and I2P Presentation @ Embrapa
Rene Jose Rodrigues Fernandes
 
BPM Global Trends 2012 - ELO Group
BPM Global Trends 2012 - ELO GroupBPM Global Trends 2012 - ELO Group
BPM Global Trends 2012 - ELO Group
EloGroup
 
UnP Eng. Software - Aula 5
UnP Eng. Software - Aula 5UnP Eng. Software - Aula 5
UnP Eng. Software - Aula 5
Hélio Medeiros
 
Curso Scrum
Curso ScrumCurso Scrum
Curso Scrum
Paulo Furtado
 
Uma abordagem às Metodologias Ágeis em Gerência de Projetos
Uma abordagem às Metodologias Ágeis em Gerência de ProjetosUma abordagem às Metodologias Ágeis em Gerência de Projetos
Uma abordagem às Metodologias Ágeis em Gerência de Projetos
Giovani Elísio Silva
 
Criar modelos de negócio
Criar modelos de negócioCriar modelos de negócio
Criar modelos de negócio
Hugo Ribeiro
 
Leandro Jesus_Processos como um elo entre a TI e a estratégia Recurso
Leandro Jesus_Processos como um elo entre a TI e a estratégia RecursoLeandro Jesus_Processos como um elo entre a TI e a estratégia Recurso
Leandro Jesus_Processos como um elo entre a TI e a estratégia Recurso
EloGroup
 
Road Show 2013 - Leandro Jesus_Processos como um elo entre a TI e a estratégi...
Road Show 2013 - Leandro Jesus_Processos como um elo entre a TI e a estratégi...Road Show 2013 - Leandro Jesus_Processos como um elo entre a TI e a estratégi...
Road Show 2013 - Leandro Jesus_Processos como um elo entre a TI e a estratégi...
EloGroup
 
Zero como conceito ótimo
Zero como conceito ótimoZero como conceito ótimo
Zero como conceito ótimo
Jose Donizetti Moraes
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
Mauricio Cesar Santos da Purificação
 
Design at scale - lições aprendidas ao conectar design em uma empresa global
Design at scale - lições aprendidas ao conectar design em uma empresa globalDesign at scale - lições aprendidas ao conectar design em uma empresa global
Design at scale - lições aprendidas ao conectar design em uma empresa global
UXConf BR
 
Extreme Programming - XP
Extreme Programming - XPExtreme Programming - XP
Extreme Programming - XP
Paulo César M Jeveaux
 
Ipt fev/2006
Ipt fev/2006Ipt fev/2006
Ipt fev/2006
kleber.torres
 
Ipt processo de inovação 02.06
Ipt processo de inovação 02.06Ipt processo de inovação 02.06
Ipt processo de inovação 02.06
kleber.torres
 

Semelhante a Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE (20)

UnP Eng. Software - Aula 4
UnP Eng. Software - Aula 4UnP Eng. Software - Aula 4
UnP Eng. Software - Aula 4
 
UnP Eng. Software - Aula 3
UnP Eng. Software - Aula 3UnP Eng. Software - Aula 3
UnP Eng. Software - Aula 3
 
Teamware Desmistificando Agile E Scrum V2
Teamware   Desmistificando Agile E Scrum V2Teamware   Desmistificando Agile E Scrum V2
Teamware Desmistificando Agile E Scrum V2
 
Palestra Sobre Modelo de Negócios Canvas
Palestra Sobre Modelo de Negócios CanvasPalestra Sobre Modelo de Negócios Canvas
Palestra Sobre Modelo de Negócios Canvas
 
Beta talk Pedro Soares (Portimão 16/7/2012)
Beta talk Pedro Soares (Portimão 16/7/2012)Beta talk Pedro Soares (Portimão 16/7/2012)
Beta talk Pedro Soares (Portimão 16/7/2012)
 
UnP Eng. Software - Aula 1
UnP Eng. Software - Aula 1UnP Eng. Software - Aula 1
UnP Eng. Software - Aula 1
 
FGVcenn and I2P Presentation @ Embrapa
FGVcenn and I2P Presentation @ EmbrapaFGVcenn and I2P Presentation @ Embrapa
FGVcenn and I2P Presentation @ Embrapa
 
BPM Global Trends 2012 - ELO Group
BPM Global Trends 2012 - ELO GroupBPM Global Trends 2012 - ELO Group
BPM Global Trends 2012 - ELO Group
 
UnP Eng. Software - Aula 5
UnP Eng. Software - Aula 5UnP Eng. Software - Aula 5
UnP Eng. Software - Aula 5
 
Curso Scrum
Curso ScrumCurso Scrum
Curso Scrum
 
Uma abordagem às Metodologias Ágeis em Gerência de Projetos
Uma abordagem às Metodologias Ágeis em Gerência de ProjetosUma abordagem às Metodologias Ágeis em Gerência de Projetos
Uma abordagem às Metodologias Ágeis em Gerência de Projetos
 
Criar modelos de negócio
Criar modelos de negócioCriar modelos de negócio
Criar modelos de negócio
 
Leandro Jesus_Processos como um elo entre a TI e a estratégia Recurso
Leandro Jesus_Processos como um elo entre a TI e a estratégia RecursoLeandro Jesus_Processos como um elo entre a TI e a estratégia Recurso
Leandro Jesus_Processos como um elo entre a TI e a estratégia Recurso
 
Road Show 2013 - Leandro Jesus_Processos como um elo entre a TI e a estratégi...
Road Show 2013 - Leandro Jesus_Processos como um elo entre a TI e a estratégi...Road Show 2013 - Leandro Jesus_Processos como um elo entre a TI e a estratégi...
Road Show 2013 - Leandro Jesus_Processos como um elo entre a TI e a estratégi...
 
Zero como conceito ótimo
Zero como conceito ótimoZero como conceito ótimo
Zero como conceito ótimo
 
Aula - Metodologias Ágeis
Aula - Metodologias ÁgeisAula - Metodologias Ágeis
Aula - Metodologias Ágeis
 
Design at scale - lições aprendidas ao conectar design em uma empresa global
Design at scale - lições aprendidas ao conectar design em uma empresa globalDesign at scale - lições aprendidas ao conectar design em uma empresa global
Design at scale - lições aprendidas ao conectar design em uma empresa global
 
Extreme Programming - XP
Extreme Programming - XPExtreme Programming - XP
Extreme Programming - XP
 
Ipt fev/2006
Ipt fev/2006Ipt fev/2006
Ipt fev/2006
 
Ipt processo de inovação 02.06
Ipt processo de inovação 02.06Ipt processo de inovação 02.06
Ipt processo de inovação 02.06
 

Mais de Hélio Medeiros

Team building - Workshop - ThoughtWorks Away Day 2018
Team building - Workshop - ThoughtWorks Away Day 2018Team building - Workshop - ThoughtWorks Away Day 2018
Team building - Workshop - ThoughtWorks Away Day 2018
Hélio Medeiros
 
Team building praticas e atividades
Team building   praticas e atividadesTeam building   praticas e atividades
Team building praticas e atividades
Hélio Medeiros
 
Historias, hipoteses e metricas aprendendo no dia a dia
Historias, hipoteses e metricas   aprendendo no dia a diaHistorias, hipoteses e metricas   aprendendo no dia a dia
Historias, hipoteses e metricas aprendendo no dia a dia
Hélio Medeiros
 
Team building - Software depende de relacionamento
Team building  - Software depende de relacionamentoTeam building  - Software depende de relacionamento
Team building - Software depende de relacionamento
Hélio Medeiros
 
Continuidade de times - quando os relacionamentos contam?
Continuidade de times - quando os relacionamentos contam?Continuidade de times - quando os relacionamentos contam?
Continuidade de times - quando os relacionamentos contam?
Hélio Medeiros
 
Historias sao suposicoes: build:measure:learn no kanban e livro de possibilid...
Historias sao suposicoes: build:measure:learn no kanban e livro de possibilid...Historias sao suposicoes: build:measure:learn no kanban e livro de possibilid...
Historias sao suposicoes: build:measure:learn no kanban e livro de possibilid...
Hélio Medeiros
 
Faça Frameworks, Não faça refens
Faça Frameworks, Não faça refensFaça Frameworks, Não faça refens
Faça Frameworks, Não faça refens
Hélio Medeiros
 
Feature injection - descobrindo e entregando valor testável
Feature injection - descobrindo e entregando valor testávelFeature injection - descobrindo e entregando valor testável
Feature injection - descobrindo e entregando valor testável
Hélio Medeiros
 
Growth hacking - customer lifecycle na pratica
Growth hacking - customer lifecycle na praticaGrowth hacking - customer lifecycle na pratica
Growth hacking - customer lifecycle na pratica
Hélio Medeiros
 
Tdc growth hacking-customer lifecycle na pratica
Tdc   growth hacking-customer lifecycle na praticaTdc   growth hacking-customer lifecycle na pratica
Tdc growth hacking-customer lifecycle na pratica
Hélio Medeiros
 
A Jornada de um desenvolvedor de Princípios SOLID em um mundo de micro-services
A Jornada de um desenvolvedor de Princípios SOLID em um mundo de micro-servicesA Jornada de um desenvolvedor de Princípios SOLID em um mundo de micro-services
A Jornada de um desenvolvedor de Princípios SOLID em um mundo de micro-services
Hélio Medeiros
 
Feature Injection - Descobrindo e entregando valor testável
Feature Injection - Descobrindo e entregando valor testávelFeature Injection - Descobrindo e entregando valor testável
Feature Injection - Descobrindo e entregando valor testável
Hélio Medeiros
 
Um desenvolvedor com princípios SOLID
Um desenvolvedor com princípios SOLIDUm desenvolvedor com princípios SOLID
Um desenvolvedor com princípios SOLID
Hélio Medeiros
 
RBS QCon São Paulo 2014 REVIEW
RBS QCon São Paulo 2014 REVIEWRBS QCon São Paulo 2014 REVIEW
RBS QCon São Paulo 2014 REVIEW
Hélio Medeiros
 
Git that like a boss - Colaborando com GITHUB
Git that like a boss - Colaborando com GITHUBGit that like a boss - Colaborando com GITHUB
Git that like a boss - Colaborando com GITHUB
Hélio Medeiros
 
Git that like a boss - Dos comandos básicos aos branches.
Git that like a boss - Dos comandos básicos aos branches.Git that like a boss - Dos comandos básicos aos branches.
Git that like a boss - Dos comandos básicos aos branches.
Hélio Medeiros
 
Treinamento git - Papos RBSDev
Treinamento git - Papos RBSDevTreinamento git - Papos RBSDev
Treinamento git - Papos RBSDev
Hélio Medeiros
 
RBS Agile Brazil Review - Managing dojo
RBS Agile Brazil Review - Managing dojoRBS Agile Brazil Review - Managing dojo
RBS Agile Brazil Review - Managing dojo
Hélio Medeiros
 
RBS Agile Brazil 2013 Review - HotSpot
RBS Agile Brazil 2013 Review - HotSpotRBS Agile Brazil 2013 Review - HotSpot
RBS Agile Brazil 2013 Review - HotSpot
Hélio Medeiros
 
Agile brazil 2013 - Laboratório Experimental refinando ideias e lançando prod...
Agile brazil 2013 - Laboratório Experimental refinando ideias e lançando prod...Agile brazil 2013 - Laboratório Experimental refinando ideias e lançando prod...
Agile brazil 2013 - Laboratório Experimental refinando ideias e lançando prod...
Hélio Medeiros
 

Mais de Hélio Medeiros (20)

Team building - Workshop - ThoughtWorks Away Day 2018
Team building - Workshop - ThoughtWorks Away Day 2018Team building - Workshop - ThoughtWorks Away Day 2018
Team building - Workshop - ThoughtWorks Away Day 2018
 
Team building praticas e atividades
Team building   praticas e atividadesTeam building   praticas e atividades
Team building praticas e atividades
 
Historias, hipoteses e metricas aprendendo no dia a dia
Historias, hipoteses e metricas   aprendendo no dia a diaHistorias, hipoteses e metricas   aprendendo no dia a dia
Historias, hipoteses e metricas aprendendo no dia a dia
 
Team building - Software depende de relacionamento
Team building  - Software depende de relacionamentoTeam building  - Software depende de relacionamento
Team building - Software depende de relacionamento
 
Continuidade de times - quando os relacionamentos contam?
Continuidade de times - quando os relacionamentos contam?Continuidade de times - quando os relacionamentos contam?
Continuidade de times - quando os relacionamentos contam?
 
Historias sao suposicoes: build:measure:learn no kanban e livro de possibilid...
Historias sao suposicoes: build:measure:learn no kanban e livro de possibilid...Historias sao suposicoes: build:measure:learn no kanban e livro de possibilid...
Historias sao suposicoes: build:measure:learn no kanban e livro de possibilid...
 
Faça Frameworks, Não faça refens
Faça Frameworks, Não faça refensFaça Frameworks, Não faça refens
Faça Frameworks, Não faça refens
 
Feature injection - descobrindo e entregando valor testável
Feature injection - descobrindo e entregando valor testávelFeature injection - descobrindo e entregando valor testável
Feature injection - descobrindo e entregando valor testável
 
Growth hacking - customer lifecycle na pratica
Growth hacking - customer lifecycle na praticaGrowth hacking - customer lifecycle na pratica
Growth hacking - customer lifecycle na pratica
 
Tdc growth hacking-customer lifecycle na pratica
Tdc   growth hacking-customer lifecycle na praticaTdc   growth hacking-customer lifecycle na pratica
Tdc growth hacking-customer lifecycle na pratica
 
A Jornada de um desenvolvedor de Princípios SOLID em um mundo de micro-services
A Jornada de um desenvolvedor de Princípios SOLID em um mundo de micro-servicesA Jornada de um desenvolvedor de Princípios SOLID em um mundo de micro-services
A Jornada de um desenvolvedor de Princípios SOLID em um mundo de micro-services
 
Feature Injection - Descobrindo e entregando valor testável
Feature Injection - Descobrindo e entregando valor testávelFeature Injection - Descobrindo e entregando valor testável
Feature Injection - Descobrindo e entregando valor testável
 
Um desenvolvedor com princípios SOLID
Um desenvolvedor com princípios SOLIDUm desenvolvedor com princípios SOLID
Um desenvolvedor com princípios SOLID
 
RBS QCon São Paulo 2014 REVIEW
RBS QCon São Paulo 2014 REVIEWRBS QCon São Paulo 2014 REVIEW
RBS QCon São Paulo 2014 REVIEW
 
Git that like a boss - Colaborando com GITHUB
Git that like a boss - Colaborando com GITHUBGit that like a boss - Colaborando com GITHUB
Git that like a boss - Colaborando com GITHUB
 
Git that like a boss - Dos comandos básicos aos branches.
Git that like a boss - Dos comandos básicos aos branches.Git that like a boss - Dos comandos básicos aos branches.
Git that like a boss - Dos comandos básicos aos branches.
 
Treinamento git - Papos RBSDev
Treinamento git - Papos RBSDevTreinamento git - Papos RBSDev
Treinamento git - Papos RBSDev
 
RBS Agile Brazil Review - Managing dojo
RBS Agile Brazil Review - Managing dojoRBS Agile Brazil Review - Managing dojo
RBS Agile Brazil Review - Managing dojo
 
RBS Agile Brazil 2013 Review - HotSpot
RBS Agile Brazil 2013 Review - HotSpotRBS Agile Brazil 2013 Review - HotSpot
RBS Agile Brazil 2013 Review - HotSpot
 
Agile brazil 2013 - Laboratório Experimental refinando ideias e lançando prod...
Agile brazil 2013 - Laboratório Experimental refinando ideias e lançando prod...Agile brazil 2013 - Laboratório Experimental refinando ideias e lançando prod...
Agile brazil 2013 - Laboratório Experimental refinando ideias e lançando prod...
 

Minicurso Scrum - Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE

  • 1. SCRUM Transformando equipes em TIMES COM CONSTANTE ENTREGA DE VALOR AO CLIENTE ©2009 - Hélio Medeiros e Germano Carvalho
  • 2. Quem somos ? Hélio Medeiros Analista de Sistemas SINFO - UFRN Blog: http://heliomedeiros.com Email: helio.cabralmedeiros@gmail.com ©2009 - Hélio Medeiros e Germano Carvalho
  • 3. Quem somos ? Germano Carvalho Analista de Sistemas Unimed Natal ©2009 - Hélio Medeiros e Germano Carvalho
  • 4. NOSSO SOFTWARE FUNCIONA ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 5. Será mes ? mo ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 6. ENTÃO OS PROJETOS DE SOFTWARE FUNCIONAM ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 7. ? ! ©2009 - Hélio Medeiros e Germano Carvalho
  • 8. O MODELO ANTIGO NÃO FUNCIONA !!! ©2009 - Hélio Medeiros e Germano Carvalho
  • 9. QUE TAL UM NOVO MODELO ? PRONTO PARA A PROPOSTA !!! ©2009 - Hélio Medeiros e Germano Carvalho
  • 10. JET OS TRE SS !!! PRO OS S MEN COM ©2009 - Hélio Medeiros e Germano Carvalho
  • 11. QUE REALM ENTE FUNCIONEM ! ©2009 - Hélio Medeiros e Germano Carvalho
  • 12. ONDIZEM COM AS NECESSIDADES QUE C ©2009 - Hélio Medeiros e Germano Carvalho
  • 13. DE FORM A ÁGIL E PRODUTIVA ©2009 - Hélio Medeiros e Germano Carvalho
  • 14. Nossa Product Backlog Parte 1 - Metodologias Ágeis Parte 2 - Conhecendo o Scrum Parte 3 - Experimentando agilidade com Scrum ©2009 - Hélio Medeiros e Germano Carvalho
  • 15. Nosso Sprint Backlog 1 Metodologias Ágeis ©2009 - Hélio Medeiros e Germano Carvalho
  • 16. Realidade da AGILE ? Será que vai vingar ? Será que não vai vingar ? Vale a pena investir nisso? Caso eu invista, conseguirei aproveitar algum conhecimento ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 17. Realidade da AGILE ? 200 equipes entrevista fornecida para o Application Development Trends, Gabrielle Benefield - diretora de métodos e práticas do Yahoo! ©2009 - Hélio Medeiros e Germano Carvalho
  • 18. a a rlos Silveir Antônio C ©2009 - Hélio Medeiros e Germano Carvalho
  • 19. Realidade da AGILE ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 20. Realidade da AGILE ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 21. Nosso Sprint Backlog Parte 1 - Metodologias Ágeis Realidade da AGILE; Por que precisamos de uma metodologia? Introdução às metodologias ágeis; ©2009 - Hélio Medeiros e Germano Carvalho
  • 22. Precisamos de metodologia ? Como escolher uma ? Gato de Cheshire. Alice no país das maravilhas, de Lewis Carroll ©2009 - Hélio Medeiros e Germano Carvalho
  • 23. Precisamos de metodologia ? Como escolher uma ? ONDE se aplica O QUE influencia Quais as visões históricas empregadas aos projetos; Qual o propósito de um processo de desenvolvimento; Quais a estatísticas caóticas para projetos de software; ©2009 - Hélio Medeiros e Germano Carvalho
  • 24. O que é projeto ? Apenas 3 décadas... mais várias visões diferentes “Um projeto é um problema agendado para solução” Dr. Joseph M. Juran O "pai" da qualidade, criador do princípio de pareto (80-20) “Um projeto é uma coleção de valor agendada para realização” David J. Anderson Criador do FDD e uma das maiores mentes de Agile mundial ©2009 - Hélio Medeiros e Germano Carvalho
  • 25. O que é projeto ? Composição de um ambiente de um projeto de software ©2009 - Hélio Medeiros e Germano Carvalho
  • 26. O que é projeto ? Composição de um ambiente de um projeto de software ©2009 - Hélio Medeiros e Germano Carvalho
  • 27. O que é projeto ? Exemplo de influência causada pelos itens do ambiente de projeto 2ª SEXTA-FEIRA CULTURA { ESPOSA JAPONESA CARDÁPIO JAPONÊS TRADIÇÕES JAPONESAS > MANTER SO COSTUMES ©2009 - Hélio Medeiros e Germano Carvalho
  • 28. O que é projeto ? Exemplo de influência causada pelos itens do ambiente de projeto encontrar seu amigo Steve... vegetariano... na 2ª sexta e pedir emprego em um jantar... NA SUA CASA... FICAR DESEMPREGADO PODE SER BEM DIFÍCIL? acontece... ©2009 - Hélio Medeiros e Germano Carvalho
  • 29. O que é projeto ? Exemplo de influência causada pelos itens do ambiente de projeto ©2009 - Hélio Medeiros e Germano Carvalho
  • 30. O que é projeto ? Exemplo de influência causada pelos itens do ambiente de projeto Eu conheço algum prato vegetariano ? Eu tenho utensílios para preparar estes pratos ? Será que minha esposa possui as técnicas necessárias ao preparo dos pratos ? O que será que minha família está pensando enquanto a estas mudanças ? Estão felizes ? Receptivos ? Colaborativos ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 31. O que é projeto ? Características dos componentes Pessoas - Conhecimento e habilidades - Motivação e comprometimento -Reconhecimento Processos - Disciplina e coordenação -Crescimento - Gerenciamento - Padronização - Institucionalização Cultura - Personalidade coletiva - Risco X Segurança Ferramentas - Ética - Produtividade - O “jeito de ser” da empresa - Controle - Eficiência - Automação ©2009 - Hélio Medeiros e Germano Carvalho
  • 32. Atividade Analisando os componentes de um contexto qualquer Escolha um contexto qualquer e descreva resumidamente: 1. Que pessoas estão envolvidas ? 2. Quais processos são observáveis ? 3. Quais tecnologias são aplicadas ? 4. Como a cultura influencia ou é influenciada ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 33. Precisamos de metodologia ? Como categorizar a complexidade de um projeto de software ? Ogunnaike and Ray: Process Dynamics, Modeling and Control ©2009 - Hélio Medeiros e Germano Carvalho
  • 34. Precisamos de metodologia ? O Chaos Report Falhou Necessitou adequações Bem sucedido 100% 33% 35% 33% 75% 43% 46% 52% 50% 25% 24% 19% 15% 0% 2004 2006 2009 ©2009 - Hélio Medeiros e Germano Carvalho
  • 35. Precisamos de metodologia ? O Chaos Report Aumento nos custos Aumento no tempo Alteração de funcionalidades 70 35 0 Adequações necessárias ©2009 - Hélio Medeiros e Germano Carvalho
  • 36. Precisamos de metodologia ? O Chaos Report Isso significa que, se fabricássemos aviões... 32% pousariam sem problemas 44% pousariam com problemas 24% cairiam ©2009 - Hélio Medeiros e Germano Carvalho
  • 37. Precisamos de metodologia ? Quais itens analisar na escolha ? COMO lidar com REQUISITOS; COMO melhorar a COMUNICAÇÃO; COMO estimar as ATIVIDADES; COMO entregarmos os PRODUTOS; COMO difundir o CONHECIMENTO; QUAL o ciclo de vida do PRODUTO; COMO organizar nossa PRODUÇÃO; COMO conseguiremos QUALIDADE; ©2009 - Hélio Medeiros e Germano Carvalho
  • 38. Atividade Por que precisamos de uma metodologia? Cite quais são os principais p ro b l e m a s n o p ro c e s s o d e desenvolvimento de software que você esteja envolvido. Cite o que você espera de uma metodologia para desenvolvimento de software. ©2009 - Hélio Medeiros e Germano Carvalho
  • 39. Nosso Sprint Backlog Parte 1 - Metodologias Ágeis Realidade da AGILE; Por que precisamos de uma metodologia? Introdução às metodologias ágeis; ©2009 - Hélio Medeiros e Germano Carvalho
  • 40. Introdução às abordagens ágeis O que NÃO é agilidade? ©2009 - Hélio Medeiros e Germano Carvalho
  • 41. Introdução às abordagens ágeis O que é agilidade? “Agilidade é a habilidade para criar e responder à mudança, para lucrar num ambiente turbulento de negócios.” “Agilidade é a habilidade para equilibrar flexibilidade e estabilidade.” Jim Highsmith Um dos principais escritores sobre AGILE e criador da ASD. ©2009 - Hélio Medeiros e Germano Carvalho
  • 42. Introdução às abordagens ágeis Os princípios ©2009 - Hélio Medeiros e Germano Carvalho
  • 43. Introdução às abordagens ágeis O manifesto Ágil Kent Beck, Jim Highsmith, Alistair Cockburn, Martin Fowlor, Ken Shwaber e Jeff Sutherland; ©2009 - Hélio Medeiros e Germano Carvalho
  • 44. Introdução às abordagens ágeis O manifesto Ágil Indivíduos e a interação mais que processos e ferramentas entre eles Produto em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano http://agilemanifesto.org ©2009 - Hélio Medeiros e Germano Carvalho
  • 45. Introdução às abordagens ágeis Desenvolvimento iterativo custo fixo conjunto de funcionalidades; priorizado pelo cliente podemos perder funcionalidades, nunca datas; prioridades no “final da lista” podem ficar de fora; Flexibilidade está nas funcionalidades, não no prazo ou no custo; ©2009 - Hélio Medeiros e Germano Carvalho
  • 46. Introdução às abordagens ágeis Desenvolvimento iterativo Produto release 1 release 2 release 3 ... release n novo release a cada X meses iteração 1 iteração 2 iteração 3 iteração 4 ... novo iteracao a cada X semanas ©2009 - Hélio Medeiros e Germano Carvalho
  • 47. Introdução às abordagens ágeis Desenvolvimento iterativo O Release 1 terá as seguintes Produto funcionalidades: - Funcionalidade A - Funcionalidade G - Funcionalidade B - Funcionalidade H release 1 - Funcionalidade C - Funcionalidade I - Funcionalidade D - Funcionalidade J - Funcionalidade E - Funcionalidade L - Funcionalidade F - Funcionalidade Z iteração 1 iteração 2 iteração 3 iteração 4 ... Func. B Func. A Func. C Func. D Func. F Func. E Func. H Func. I Func. J Func. G Func. L Func. Z ©2009 - Hélio Medeiros e Germano Carvalho
  • 48. Introdução às abordagens ágeis O ciclo de vida de projetos ágeis Exploração Visão Funcionalidades Prontas Especulação Adaptação Visão do Produto Fechamento Produto Final ©2009 - Hélio Medeiros e Germano Carvalho
  • 49. Nosso Sprint Backlog 2 Conhecendo o Scrum ©2009 - Hélio Medeiros e Germano Carvalho
  • 50. Nosso Sprint Backlog Parte 2 - Conhecendo o Scrum O que é Scrum? O ciclo de vida do Scrum; Os papéis no Scrum; O conceito de Sprint: Entregando frequentemente software de valor; Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em primeiro plano; Sprint Planning Meeting: Planejamento na medida certa; Scrum Daily Meeting: Descobrindo pequenos problemas antes que se tornem grandes; Sprint Review: Apresentando o resultado; Sprint Retropective: Avaliando pontos positivos e negativos e se preparando para reiniciar; ©2009 - Hélio Medeiros e Germano Carvalho
  • 51. O que é Scrum ? Depende de onde você está ©2009 - Hélio Medeiros e Germano Carvalho
  • 52. O que é Scrum ? O origem do Scrum Criada no início da década de 1990 Estados Unidos. TA nt YO eme TO nag a nM Lea ©2009 - Hélio Medeiros e Germano Carvalho
  • 53. O que é Scrum ? Scrum NÃO é uma bala de prata! ©2009 - Hélio Medeiros e Germano Carvalho
  • 54. O que é Scrum ? A objetividade do Scrum papéis bem difinidos, e é de fácil adaptação; SCRUM APONTA OS ERROS ! Um dos aspectos positivos do Scrum é a sua adaptabilidade, portanto, o conhecimento das suas práticas é extremamente importante, por permitir a aplicação das mesmas de forma variada. ©2009 - Hélio Medeiros e Germano Carvalho
  • 55. O que é Scrum ? Problemas com a adaptabilidade Sprint Planning Meeting Um dia inteiro sem produção ? Daily Meeting Horários ? Para que? ©2009 - Hélio Medeiros e Germano Carvalho
  • 56. O que é Scrum ? Liderança-colaboração SIM ! Comando-controle NÃO ! Comando - Controle Liderança - Colaboração Comando-Controle é muito lento porque: ✓Não permite processar informações rapidamente; ✓Não permite tomar decisões rapidamente; ✓Não envolve ou motiva ao trabalho; ✓Não propicia responsabilidade diária sobre o andamento à equipe; ©2009 - Hélio Medeiros e Germano Carvalho
  • 57. Atividade A arte do possível Explore a diferencça entre planejar uma viagem se cada sentença começa com: “ Sim, mas ” “ Sim, e ” ©2009 - Hélio Medeiros e Germano Carvalho
  • 58. Nosso Sprint Backlog Parte 2 - Conhecendo o Scrum O que é Scrum? O ciclo de vida do Scrum; Os papéis no Scrum; O conceito de Sprint: Entregando frequentemente software de valor; Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em primeiro plano; Sprint Planning Meeting: Planejamento na medida certa; Scrum Daily Meeting: Descobrindo pequenos problemas antes que se tornem grandes; Sprint Review: Apresentando o resultado; Sprint Retropective: Avaliando pontos positivos e negativos e se preparando para reiniciar; ©2009 - Hélio Medeiros e Germano Carvalho
  • 59. O ciclo de vida do SCRUM? © 2007 Alexandre Magno - As Armadilhas do Scrum ©2009 - Hélio Medeiros e Germano Carvalho
  • 60. O ciclo de vida do SCRUM? O ciclo de vida do Scrum é baseado em iterações bem definidas de duas a quatro semanas, chamadas SPRINTS. Antes de cada Sprint, realiza-se uma reunião de planejamento ( Sprint Planning Meeting ) em que o time (Team Members) de desenvolvimento tem contato com o cliente ( Product Owner ) para priorizar o trabalho que precisa ser feito, selecionar e estimar as tarefas que o time pode realizar dentro da Sprint. A próxima fase é a execução da Sprint. ©2009 - Hélio Medeiros e Germano Carvalho
  • 61. O ciclo de vida do SCRUM? Durante a execução da Sprint, o time controla o andamento do desenvolvimento realizando Reuniões Diárias ( Daily Meeting ) de não mais de 15 minutos de duração, e observando o seu progresso usando um gráfico chamado Sprint Burndown. Ao final de cada Sprint, deve-se realizar uma Reunião de Revisão ( Sprint Review ), em que o time demonstra o produto gerado na Sporint e valida se o objetivo foi atingido. Logo em seguida, realiza-se a Reunião de Retrospectiva ( Sprint Retrospective ), uma reunião de lições aprendidas, com o objetivo de melhorar o processo, time eou produto para a próxima Sprint. ©2009 - Hélio Medeiros e Germano Carvalho
  • 62. Nosso Sprint Backlog Parte 2 - Conhecendo o Scrum O que é Scrum? O ciclo de vida do Scrum; Os papéis no Scrum; O conceito de Sprint: Entregando frequentemente software de valor; Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em primeiro plano; Sprint Planning Meeting: Planejamento na medida certa; Scrum Daily Meeting: Descobrindo pequenos problemas antes que se tornem grandes; Sprint Review: Apresentando o resultado; Sprint Retropective: Avaliando pontos positivos e negativos e se preparando para reiniciar; ©2009 - Hélio Medeiros e Germano Carvalho
  • 63. Os papéis no Scrum Pigs e chickens são papéis no Scrum ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 64. Os papéis no Scrum Pigs e chickens são papéis no Scrum ? Os termos pig ( porco ) e chicken ( galinha ) são utilizados em Scrum de forma informal. Pig: Alguém que ocupa um dos três papéis do Scrum ( Team memeber, Product owner, Scrum Master) e tem um total comprometimento com o projeto. Chicken: Alguém que tem interesse no produto a ser gerado, mas não ocupa nenhum papel formal do Scrum. ©2009 - Hélio Medeiros e Germano Carvalho
  • 65. Os papéis no Scrum O Product Owner (PO) O Product Owner representa o cliente ou patrocinador do projeto, e faz parte do time que entregará o produto. ©2009 - Hélio Medeiros e Germano Carvalho
  • 66. Os papéis no Scrum O Product Owner (PO) Define funcionalidades Faz o plano de Release Product vision ROI Priorização Ajusta escopo Aceita ou rejeita um Sprint Disponibilização técnicos de domínio ©2009 - Hélio Medeiros e Germano Carvalho
  • 67. Os papéis no Scrum O Scrum Master (SM) O Scrum Master, diferentemente dos gerentes de projeto na maioria das práticas e metodologias, difere do tradicional “comando e controle”. Em Scrum, um SM trabalha com e, principalmente, para o time. ©2009 - Hélio Medeiros e Germano Carvalho
  • 68. Os papéis no Scrum O Scrum Master (SM) Responsável pelo processo Gerenciamento Valores e princípios Remove impediemntos Garante a produtividade Colaboração entre papéis Protege o time de Interferências ©2009 - Hélio Medeiros e Germano Carvalho
  • 69. Os papéis no Scrum Os membros do time Os membros do time são pessoas que estão comprometidos a fazer o trabalho necessário para atingir a meta de uma Sprint. Em Scrum não temos arquitetos, testers ou programadores, temos sim, membros com perfis de arquiteto, de tester ou de programador... mas que podem atuar em papeis secundários para garantir o alcance da meta. ©2009 - Hélio Medeiros e Germano Carvalho
  • 70. Os papéis no Scrum Os membros do time Suas responsabilidades são: Definir a meta do Sprint; Estar comprometido com o trabalho Colaborar com outros membros do time e ajudar a torná-lo auto-gerenciado; Estimar itens do backlog de forma realista; Participar das reuniões diárias; Compartilhar conhecimento com a equipe Manifestar impedimentos; ©2009 - Hélio Medeiros e Germano Carvalho
  • 71. Os papéis no Scrum Fluxo simples Coloca itens (priorizados) Pega itens Product owner Time Product Backlog Coloca Serve O que sobrar... devolve Scrum Master Sprint Backlog ©2009 - Hélio Medeiros e Germano Carvalho
  • 72. Nosso Sprint Backlog Parte 2 - Conhecendo o Scrum O que é Scrum? O ciclo de vida do Scrum; Os papéis no Scrum; O conceito de Sprint: Entregando frequentemente software de valor; Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em primeiro plano; Sprint Planning Meeting: Planejamento na medida certa; Scrum Daily Meeting: Descobrindo pequenos problemas antes que se tornem grandes; Sprint Review: Apresentando o resultado; Sprint Retropective: Avaliando pontos positivos e negativos e se preparando para reiniciar; ©2009 - Hélio Medeiros e Germano Carvalho
  • 73. O conceito de Sprint Característivas 2, 3 ou 4 semanas; Frequentemente entregando algo de valor para o cliente; Time multi-funcional com não mais que oito membros; Cada Sprint deve ter uma meta específica que represente o desejo do cliente para aquele time-box específico; Os membros do time da Sprint são os responsáveis por estimar os itens que compõem o desejo do cliente e dar a palavra final sobre o que será possível ser desenvolvido naquele time-box; ©2009 - Hélio Medeiros e Germano Carvalho
  • 74. O conceito de Sprint Composição Planejamento ( Sprint Planning Meeting ): Daily Scrum Execução ( The Sprint ): Revisão ( Sprint Review ): Retrospectiva ( Sprint Retrospective ): ©2009 - Hélio Medeiros e Germano Carvalho
  • 75. O conceito de Sprint Cancelamento O cancelamento de um Sprint antes de seu termino acontece nas seguintes condições: O time pode cancelar se sentir que não conseguirá atingir a sua meta, lembrando que cancelamentos consecutivos são falhas apontadas pelo Scrum, qual o problema ? Gerentes podem cancelar um Sprint caso fatores externos influenciem diretamente no valor da meta do Sprint; Caso um Sprint seja cancelado deve ser iniciado o planejamento do próximo Sprint imediatamente; ©2009 - Hélio Medeiros e Germano Carvalho
  • 76. Nosso Sprint Backlog Parte 2 - Conhecendo o Scrum O que é Scrum? O ciclo de vida do Scrum; Os papéis no Scrum; O conceito de Sprint: Entregando frequentemente software de valor; Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em primeiro plano; Sprint Planning Meeting: Planejamento na medida certa; Scrum Daily Meeting: Descobrindo pequenos problemas antes que se tornem grandes; Sprint Review: Apresentando o resultado; Sprint Retropective: Avaliando pontos positivos e negativos e se preparando para reiniciar; ©2009 - Hélio Medeiros e Germano Carvalho
  • 77. Product Backlog Entendendo O Product Backlog representa em ítens a visão do produto e é o primeiro passo a ser dado em todo projeto Scrum; O Product Backlog existirá por todo o ciclo de vida do projeto, e não da Sprint. Este é regularmente atualizado pelo Product Owner para refletir mudanças e necessidades do cliente, mudanças estratégicas ou tecnológicas, novas idéias... O Product Backlog pode ser composto por diferentes tipos de itens: funcionalidades, exploração técnica, estudo, documentação, bugs, requisitos de desenvolvimento... Só exisite um Product Backlog durante todo o projeto. ©2009 - Hélio Medeiros e Germano Carvalho
  • 78. Product Backlog A física do Product Backlog Alta Prioridade Cada Sprint implementa os requisitos de prioridade mais alta Cada novo item é priorizado e inserido pelo PO a qualquer momento Todos os itens podem ser repriorizados pelo PO Itens podem ser removidos pelo PO a qualquer momento Baixa Prioridade ©2009 - Hélio Medeiros e Germano Carvalho
  • 79. Product Backlog Exemplo PRODUCT BACKLOG P R OD U C T BAC K L OG Id Item Estimativa Prioridade 1 Refatorar o banco de dados 32 10 2 Relatório de Vendas por unidade e período 8 8 3 Suporte a cartão de crédito Visa no processo de Vendas 13 9 4 Relatório Gerencial com Estatísticas de Vendas 5 7 5 Alterações na tela de entrada do sistema 5 6 6 Estudar nova versão da framework de mapeamento O/R 5 5 7 Consulta parametrizada de Vendas 3 4 8 Criação do Help 13 4 9 Implementar internacionalização 8 2 Total 92 6 ©2009 - Hélio Medeiros e Germano Carvalho
  • 80. Nosso Sprint Backlog Parte 2 - Conhecendo o Scrum O que é Scrum? O ciclo de vida do Scrum; Os papéis no Scrum; O conceito de Sprint: Entregando frequentemente software de valor; Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em primeiro plano; Sprint Planning Meeting: Planejamento na medida certa; Scrum Daily Meeting: Descobrindo pequenos problemas antes que se tornem grandes; Sprint Review: Apresentando o resultado; Sprint Retropective: Avaliando pontos positivos e negativos e se preparando para reiniciar; ©2009 - Hélio Medeiros e Germano Carvalho
  • 81. Sprint Planning Meeting Regras A Sprint Planning Meeting ou Reunião de Planejamento, é dividida em duas partes, e entra em cena no início de cada Sprint. Além de todos os comprometidos (PO, SM e Time), alguns envolvidos podem ser convidados a participar em determinados momentos da reunião, desde que agreguem valor à mesa e tenham seu convite aprovado pelo Product Owner. ©2009 - Hélio Medeiros e Germano Carvalho
  • 82. Sprint Planning Meeting Regras Pela prática, é percebido que a duração desta reunião segue a seguinte tabela: DURAÇÃO Sprint SPM #1 SPM #2 4 semanas 4 horas 4 horas 3 semanas 3 horas 3 horas 2 semanas 2 horas 2 horas ©2009 - Hélio Medeiros e Germano Carvalho
  • 83. Sprint Planning Meeting SPM #1 Na primeira parte, o Product Owner e o time, sendo facilitados pelo Scrum Master, realizamuma revisão no Product Baklog, discutindo sobre o propósito e metas de cada item e dando a oportunidade para que o PO exponha seus desejos. O time seleciona os itens que acredita que possam ser desenvolvidos na próxima Sprint e define a meta. PRODUCT BACKLOG P R ODUCT B AC K L OG Id Item Estimati Priorida va de Meta do Sprint: 1 Refatorar o banco de dados 32 10 2 Relatório de Vendas por unidade e período 8 8 Refatorar o banco de dados e implementar relaórios de vendas 3 Suporte a cartão de crédito Visa no 13 9 processo de Vendas necessáirios para as tomadas de 4 Relatório Gerencial com Estatísticas de 5 7 decisões finais. Vendas Total 58 9 ©2009 - Hélio Medeiros e Germano Carvalho
  • 84. Sprint Planning Meeting SPM #1 Velocidade é uma medida de produtividade do time; Esta medida representa a taxa de trabalho que o time conseguiu completar durante um Sprint; E serve de guia para o planejamento de Sprints. Por exemplo, se na Sprint anterior o time foi capaz de completar 55 pontos, esta quantidade de trabalho realizado passa a ser a velocidade do time e contribuirá durante o planejamento do próximo sprint; Serve de guia para o planejamento de Releases e progresso de projeto. Ex.: Temos um Product Backlog de 165 pontos. ©2009 - Hélio Medeiros e Germano Carvalho
  • 85. Sprint Planning Meeting SPM #1 Product Backlog Selecionar Sprint Backlog Como? Não sei nossa velocidade Executado com 13 Mini-Sprint Backlog pontos ( ou X horas) Sprint Backlog Velocaidade Inicial: 34 pontos ( ou x * 3 horas ) ©2009 - Hélio Medeiros e Germano Carvalho
  • 86. Atividade Jogo da Velocidade Quantas bolas de tênis você e seu time conseguem colocar no mochila em 2 minutos ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 87. Sprint Planning Meeting SPM #1 Durante esta reunião o Product Owner ainda pode realizar alterações na priorização de itens; Deve se discutir também sobre estimativas iniciais ou revisão/ adaptação da estimativa dos itens; O esforço estimado entre os itens selecionados deve ser negociado entre o time e o PO, sempre praticando o bom senso; ©2009 - Hélio Medeiros e Germano Carvalho
  • 88. Sprint Planning Meeting SPM #1 Existem diversas técnicas de estimativas que podem ser utilizadas em projetos Scrum. O Planning Poker é uma das mais populares, onde utilizam-se cartas numeradas seguindo a tabela de fibonacci. ©2009 - Hélio Medeiros e Germano Carvalho
  • 89. Sprint Planning Meeting Planning Poker...? O Planning Poker: vem sendo a melhor técnica utilizada em projetos que utilizam processos ágeis; combina opinião de especialistas, analogias, bom senso e uma forma agradável para se gerar estimativas; envolve todos os perfis de membros (programadores,testers, DBAs, analistas, designers entre outros); utiliza-se dos números da sequência de Fibonacci; deve ser aplicado para qualquer novo Item; ©2009 - Hélio Medeiros e Germano Carvalho
  • 90. Sprint Planning Meeting Como funciona o Planning Poker ? Cada participante deve possuir o seu conjunto de cartas contendo os valores válidos, de acordo com a escala adotada; Para cada Product Backlog Item a ser estimado, o facilitador (normalmente o Product Owner ou Especialista de Négocio) deve realizar uma breve descrição; Após todas as dúvidas sobre o item serem respondidas, cada membro do time deve escolher uma carta representando a sua estimativa. A carta selecionada não deve ser vista pelos outros membros do time enquanto todos ainda não tenham selecionado a sua; Estimating & Planning - Mike Cohn ©2009 - Hélio Medeiros e Germano Carvalho
  • 91. Sprint Planning Meeting Como funciona o Planning Poker ? Todos devem, ao mesmo tempo, mostrar sua carta de estimativa; Se as estimativas divergem, os participantes que apresentaram carta com maior e menor valor devem explicar o motivo que o levaram a escolhê-la. Isto não deve de forma alguma ser feita de forma agrssiva, ou mesmo defensiva, mas apenas como uma troca de conhecimento entre visões diferentes sobre o esforço necessário para a conclusão do item. Estimating & Planning - Mike Cohn ©2009 - Hélio Medeiros e Germano Carvalho
  • 92. Sprint Planning Meeting Como funciona o Planning Poker ? Após as devidas explicações, inicie um novo Round repetindo o ciclo, até que haja um consenso quanto ao tamanho do item; Normalmente, as estimativas entram em convergência já no segundo round, ou no máxima no terceiro. Mas caso isso não aconteça, o ciclo deve ser continuado. 1 2 3 5 13 ©2009 - Hélio Medeiros e Germano Carvalho
  • 93. Vídeo Experiências com Planning Poker ©2009 - Hélio Medeiros e Germano Carvalho
  • 94. Sprint Planning Meeting Por que o Planning Poker funciona ? Apresenta múltiplas opniões de especialistas quanto à estimativa de um item, e como Scrum trabalha com times multi-perfis temos praticamente todas as áreas de conhecimento cobertas; Porque Planning Poker estimula o dialogo durante os rounds, e cada membro do time tem que explicar o porque de sua estimativa, ampliando o compartilhamento de conhecimento; Estudos mostram que estimativas feitas em grupo vem sendo mas bem sucedidas que estimativas individuais; Estimating & Planning - Mike Cohn ©2009 - Hélio Medeiros e Germano Carvalho
  • 95. Sprint Planning Meeting SPM #2 A segunda parte da reunião de planejamento deve ocorrer imediatamente após a finalizar da primeira, sendo nela : criada a lista de tarefas, por meio da decomposição dos itens do Product Backlog, chamada Sprint Backlog; detalhada algum item ou removevida dúvidas quanto ao objetivo do mesmo, pelo PO ou especialista convidado; elaborada a estratégia de desenvolvimento que será utilizada para que a meta da Sprint seja atingida. Sendo necessário responder como construirão as funcionalidades do produto durante o Sprint; ©2009 - Hélio Medeiros e Germano Carvalho
  • 96. Sprint Planning Meeting SPM #2 Os membros do time devem escolher suas tarefas e então estimá-las em horas; Tarefas devem ter de 1 a 16 horas de duração. Tarefas maiores deverão ser quebradas em duas ou mais. ©2009 - Hélio Medeiros e Germano Carvalho
  • 97. Sprint Planning Meeting Características do Sprint Backlog Itens do Product Backlog devem ser decompostos em tarefas (Tasks); As tarefas devem ter estimativas de 1 a 16 horas; Qualquer membro do time pode adicionar, remover ou alterar tarefas do Sprint Backlog; As tarefas são escolhidas pelos membros do time, e não designadas a eles; ©2009 - Hélio Medeiros e Germano Carvalho
  • 98. Sprint Planning Meeting Características do Sprint Backlog SPRINT BACKLOG SP R IN T BAC K L OG Id Item Estimativa 1 Refatorar o banco de dados 32 Mapear as tabelas que serão refatoradas 6hrs Definir estratégias de refatoração 2hrs Montar/Gerar script de refatoração 8hrs Aplicar script de refatoração 2hrs Avaliar eficiência da refatoração 6hrs Total 24 hrs ©2009 - Hélio Medeiros e Germano Carvalho
  • 99. Nosso Sprint Backlog Parte 2 - Conhecendo o Scrum O que é Scrum? O ciclo de vida do Scrum; Os papéis no Scrum; O conceito de Sprint: Entregando frequentemente software de valor; Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em primeiro plano; Sprint Planning Meeting: Planejamento na medida certa; Scrum Daily Meeting: Descobrindo pequenos problemas antes que se tornem grandes; Sprint Review: Apresentando o resultado; Sprint Retropective: Avaliando pontos positivos e negativos e se preparando para reiniciar; ©2009 - Hélio Medeiros e Germano Carvalho
  • 100. Scrum Daily Meeting Se reunir todo dia ? Impossível! Uma vez iniciado o Sprint, inicia-se a realização das reuniões diárias (Scrum Daily Meeting); Uma Daily Meeting é uma reunião com: duração exata de 15 minutos realizadas no mesmo local e horário com participação do SM e membros do time; não havendo um SM presente, deve ser definido o facilitador; ©2009 - Hélio Medeiros e Germano Carvalho
  • 101. Scrum Daily Meeting Se reunir todo dia ? Impossível! Cada membro deve relatar ao time sobre os progressos e obstáculos que encontrou em seu caminho. Em suma, três perguntas devem ser respondidas por cada um deles: 1. O que fiz (quanto andei) desde a última reunião diária ? 2. O que pretendo fazer ( quanto andarei ) até a próxima reunião diária ? 3. Estou encontrando impedimentos ? Quais ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 102. Atividade Armadilhas das Reuniões ! Você está preparado para enfrentar as armadilhas das reuniões diárias ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 103. Scrum Daily Meeting O quadro de acompanhamento Tarefas Em Em Em Item Conluído Horas desejadas análise desenvolvimento Teste Aplicar Script de Montar Definir Refatorar refatoração script de estratégia banco de refatoração refatoração dados 02 24 08 02 13 Avaliar Estimativa em eficiência Mapear as complexidade da tabelas refatoração que serão 06 refatoradas Estimativa 06 em tempo ©2009 - Hélio Medeiros e Germano Carvalho
  • 104. Scrum Daily Meeting O quadro de acompanhamento ©2009 - Hélio Medeiros e Germano Carvalho
  • 105. Scrum Daily Meeting O quadro de acompanhamento ©2009 - Hélio Medeiros e Germano Carvalho
  • 106. Scrum Daily Meeting O quadro de acompanhamento ©2009 - Hélio Medeiros e Germano Carvalho
  • 107. Scrum Daily Meeting O quadro de acompanhamento ©2009 - Hélio Medeiros e Germano Carvalho
  • 108. Scrum Daily Meeting Sprint Backlog SPRINT BACKLOG SP R I N T BAC K L OG Id Item julho/09 1 Refatorar o banco de dados 11 12 13 Mapear as tabelas que serão refatoradas 6hrs 6 0 0 Definir estratégias de refatoração 2hrs 2 0 0 Montar/Gerar script de refatoração 8hrs 0 8 0 Aplicar script de refatoração 2hrs 0 0 2 Avaliar eficiência da refatoração 6hrs 0 0 6 Tota 24 hrs 16 hrs 8 hrs 0 hrs l ©2009 - Hélio Medeiros e Germano Carvalho
  • 109. Scrum Daily Meeting Sprint Burndown Ideal Real Após a reunião diária, os membros atualizam o 100 montante de tempo que 90 resta para o cumprimento 80 de cada tarefa no Sprint 70 60 Backlog. 50 40 Esta informação é 30 acrescida a um gráfico 20 chamado Sprint Burndown. 10 0 Este gráfico mostra o 11/7 12/7 13/7 14/7 15/7 projeto dia-a-dia ©2009 - Hélio Medeiros e Germano Carvalho
  • 110. Nosso Sprint Backlog Parte 2 - Conhecendo o Scrum O que é Scrum? O ciclo de vida do Scrum; Os papéis no Scrum; O conceito de Sprint: Entregando frequentemente software de valor; Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em primeiro plano; Sprint Planning Meeting: Planejamento na medida certa; Scrum Daily Meeting: Descobrindo pequenos problemas antes que se tornem grandes; Sprint Review: Apresentando o resultado; Sprint Retropective: Avaliando pontos positivos e negativos e se preparando para reiniciar; ©2009 - Hélio Medeiros e Germano Carvalho
  • 111. Sprint Review E o resultado foi... Durante o Sprint Review devemos: avaliar que esta sendo entregue ? realizar uma apresentação do produto que foi gerado durante a Sprint. Devem participar do Sprint Review o PO, o SM e os membros do time, clientes e executivos desde que convidados pelo PO. A apresentação dura 30 minutos ©2009 - Hélio Medeiros e Germano Carvalho
  • 112. Nosso Sprint Backlog Parte 2 - Conhecendo o Scrum O que é Scrum? O ciclo de vida do Scrum; Os papéis no Scrum; O conceito de Sprint: Entregando frequentemente software de valor; Produto Backlog: Conhecendo o caminho a seguir para ter o cliente em primeiro plano; Sprint Planning Meeting: Planejamento na medida certa; Scrum Daily Meeting: Descobrindo pequenos problemas antes que se tornem grandes; Sprint Review: Apresentando o resultado; Sprint Retropective: Avaliando pontos positivos e negativos e se preparando para reiniciar; ©2009 - Hélio Medeiros e Germano Carvalho
  • 113. Sprint Retrospective Aprendendo com os acertos... mas principalmente com os erros A Sprint Retrospective é uma das ferramentas mais importantes para que você obtenha sucesso com Scrum; Esta é a oportunidade que o time tem para discutir sobre o que funcionou e o que não durante a Sprint; Product Owner, Scrum Master e os membros do time devem participar da retrospectiva. Uma boa estratégia é convidar alguém neutro para facilitar a reunião; ©2009 - Hélio Medeiros e Germano Carvalho
  • 114. Sprint Retrospective Aprendendo com os acertos... mas principalmente com os erros A estrutura da Sprint Retrospective é bem simples. Divida um quadro branco ou poster em duas áreas com os seguintes títulos: “O que funcionou bem ?” e “O que pode ser melhorado ?”. Após isso, cada membro deve colocar post-its em cada uma das áreas indicando os itens que, em sua opnião, merecem estar ali; Então, o time visualiza os itens citados, discute sobre e planeja ações a serem tomadas para a próxima Sprint. ©2009 - Hélio Medeiros e Germano Carvalho
  • 115. Nosso Sprint Backlog 3 Experimentando agilidade com Scrum ©2009 - Hélio Medeiros e Germano Carvalho
  • 116. Atividade Jogo do Planejamento O Product Owner deverá entregar a cada equipe um Product backlog priorizado representando os desejos de seu cliente; Planejamento (15 minutos) 1. O time deve estimar os itens do Product backlog ; 2. O time deve selecionar os itens do Product backlog que poderão ser entregues no final do Sprint. Execução (30 minutos) 1. O time deve executar as atividades da Sprint. Revisão (2 minutos) 1. O time deve apresentar o que foi definido para o Sprint. ©2009 - Hélio Medeiros e Germano Carvalho
  • 117. VOCES PODEM FAZER SOFTWARE QUE FUNCIONA
  • 119. EM UM AMBIENTE ÁGIL E PRODUTIVO
  • 120. SE VOCÊS ACHAVAM QUE ISSO SERIA IMPOSSÍVEL...
  • 121. EXISTEM MUITOS QUE JÁ O ESTÃO FAZENDO
  • 122. Indivíduos e a processos e interação entre eles mais que ferramentas Produto em documentação “Estamos descobrindo maneiras melhores mais que funcionamento abrangente de desenvolver software fazendo-o nós mesmos ecom o Colaboração ajudando outros a fazê-lo. Através negociação de mais que desse trabalho, passamos a contratos cliente valorizar: Responder a mais que seguir um plano mudanças http://agilemanifesto.org ©2009 - Hélio Medeiros e Germano Carvalho
  • 123. PERGUNTAS ? ©2009 - Hélio Medeiros e Germano Carvalho
  • 124. ISSO é TUDO PESSOAL !! Hélio Cabral Medeiros Germano Carvalho helio.cabralmedeiros@gmail.com germano.carv@gmail.com http://heliomedeiros.com/ ©2009 - Hélio Medeiros e Germano Carvalho