SlideShare a Scribd company logo
1 of 64
Download to read offline
por Jonas Beto Rompkovski
Expectativas
Grupo Scrum Curitiba




Grupo direcionado aos profissionais de TI de Curitiba que trabalham com Scrum.
Este grupo foi criado para discutirmos sobre o Scrum e sobre as experiências que
cada um tem na sua empresa.



                      @ScrumCuritiba
           http://scrumcuritiba.com.br
Onde estão os projetos?
                     Quanto já foi gasto?
                      Quanto ainda será?
                        Quando termina?
                    O que será entregue?
Desenvolvimento em Fases
Resultados Antecipados
Alto valor do Planejamento
Pouca Visibilidade
Mudanças se tornam mais
                e mais caras
 Clientes não sabem o que
                    querem
SUCESSO em
 apenas 34%
 dos projetos
 entregues

Longa duração
  ADIA retorno
  financeiro para
  empresa
  Fonte: Standish Report 2003
   52% dos
    requisitos
    entregues

   64% das
    funcionalidades
    são raramente
    usadas


        Fonte: Standish Report 2003
Watts Humphrey – Pai do CMMI


                       “O usuário não
                        saberá o que
                        ele quer até
                          utilizar o
                        sistema real
                        (talvez nem
                          assim).”
Paradoxo de COBB

“We know why projects fail, we know how to prevent
  their failure –so why do they still fail?”

Martin Cobb
Guiados pelo atraso?
Telefone sem fio
Saia da Caixa
Princípios
                Satisfação do cliente
                Mudança
                Entregas Constantes
                Colaboração
                Motivação
                Ambiente adequado
                Comunicação face a face
                Software funcionando
                Ritmo sustentável
                Simplicidade
                Melhoria Contínua
Manifesto Ágil
Indivíduos e Interações            Processos e ferramentas


Produto Funcionando         MAIS   Documentação abrangente

                             DO
Responder a Mudanças               Seguir um plano
                            QUE
Colaboração com o Cliente          Negociação de contratos




www.manifestoagil.com.br
Origem do SCRUM
Modelo do Ciclo de Vida
Fluxo do SCRUM
Papéis do SCRUM
Product Owner (PO)

Dono da Visão
do Projeto
Representa o
Cliente
Product Owner (PO)

Define funcionalidades
Prioriza as funcionalidade
Escolhe datas de
lançamento



Dá Feedback
Gerencia as partes
interessadas
Aceita ou Rejeita
resultados
Time




               Pequeno
           5-9 pessoas
       Auto-organizado
       Multi-disciplinar
              Dedicado
Time




Define as tarefas
Estima o Esforço
Desenvolve o produto
Garante a Qualidade
Segrega os Processos
Scrum Master

   Líder Servidor
Protetor do Time
   Quebra-galho
      Guia Scrum
Scrum Master

Remove Impedimentos
  Previne Interrupções
    Facilitador do Time
   Suporta o Processo
           Faz a Gestão
Visão do Produto


   Preparação do ambiente
   Identificar usuários
   Levantar requisitos
   Criar visão do projeto
   Planejar Releases
Visão do Produto
Para <público alvo> que <oportunidade ou necessidade>, o <nome
do produto> é um <categoria do produto> que <benefícios do
usuário>. Ao contrário <produtos concorrentes>, nosso produto
<diferenciais>.

Para um jornal que precisa necessidade disponibilizar seus serviços
na web, o sistema AgilePublisher é uma aplicação web que
disponibiliza publicadores de notícias, customização de templates,
agenda de compromissos (etc.). Ao contrário produtos dos produtos
concorrentes que o jornalista precisa retornar à redação para assim
ter sua notícia publicada, nosso produto permite ao jornanista que
pré-publique a notícia diretamente do seu smartyphone ou notebook
para que a redação aprove disponibilizando mais tempo para que ele
possa realizar mais matérias.
Product Backlog

   Lista de funcionalidade que o cliente
    necessita
   Os itens da lista = itens do backlog
   1 Product Backlog = 1 PO
   Todos podem incluir itens de backlog
   Somente o PO pode priorizá-las
   PO deve entender cada história
   PO pode priorizar novamente
    no início de cada Sprint.
Product Backlog (Exemplo)
ID   Descrição
1    Como jornalista, gostaria de pré publicar as minhas matérias via smartyphone
     para que eu não tenha que retornar a redação para que as matérias saiam mais
     rapidamente na internet.
2    Como redator chefe, gostaria de aprovar ou não as notícias pré publicadas pelos
     jornalistas para que tenhamos a garantia de que as notícias encaminhadas sejam
     adequadas e não tenham erros de português.
3    Como gerente do recursos humanos, gostaria de um relatório dos jornalistas que
     mais encaminham notícias com erros de português para que eu possa
     providenciar cursos de reforço para nossos profissionais.
Histórias (User Stories)

   Funcionalidade que terá valor tanto aos usuários
    quanto a quem estiver adquirindo o sistema.
   As histórias têm 3 aspectos (3C) segundo Ron Jeffries
     Cards – histórias são escritas em cartões ou post-its
      (cards), naturalmente forçando as histórias a serem
      pequenas.
     Conversation – A história escrita no cartão serve como um
      lembrete, tornando-se um convite ao diálogo
      (conversation).
     Confirmation – O cliente define (implícita ou
      explicitamente) uma maneira de validar (Confirmation)
      esse pedido. Geralmente com testes de aceitação.
Padrões de História
                                  Como jornalista, gostaria de pré publicar as
Como um <usuário>, gostaria de    minhas matérias via smartyphone para que eu
<funcionalidade> para <valor de   não tenha que retornar a redação para que as
negócio>.                         matérias saiam mais rapidamente na internet.




                                  Para que eu não tenha que retornar a
Para obter/alcançar <valor de     redação para que as matérias saiam mais
negócio>, como um <usuario> eu    rapidamente na internet, como jornalista
gostaria da <funcionalidade>.     eu gostaria de pré publicar as minhas
                                  matérias via smartyphone.


Idéia                                        Corretor Ortográfico
E as estimativas?

Estimativa




                    Compromisso
E as estimativas?




   Tamanho x tempo
Tamanho

   Story Points
     Medida relativa do tamanho de uma história.
     Não existe fórmula
     É resultado do agrupamento de fatores: esforço
     envolvido no desenvolvimento da funcionalidade,
     a complexidade, riscos, etc.
   Ideal Days
     A história estimada será o seu único trabalho
     Tudo que você precisar estará disponível
     Não haverão interrupções
1º Curitiba Scrum Day
ID Descrição                                                              Estimativa

1   Como jornalista, gostaria de pré publicar as minhas matérias via          3
    smartyphone para que eu não tenha que retornar a redação para
    que as matérias saiam mais rapidamente na internet.
2   Como redator chefe, gostaria de aprovar ou não as notícias pré            5
    publicadas pelos jornalistas para que tenhamos a garantia de que as
    notícias encaminhadas sejam adequadas e não tenham erros de
    português.
3   Como gerente do recursos humanos, gostaria de um relatório dos            5
    jornalistas que mais encaminham notícias com erros de português
    para que eu possa providenciar cursos de reforço para nossos
    profissionais.
1º Curitiba Scrum Day
   É o total de story points entregues
    em uma iteração pela equipe.

   Exemplo...

 Velocidade em conjunto com o
  total de story points do projeto,
  pode gerar um cronograma.
 Como vou descobrir a velocidade
  da 1ª iteração?
   Velocidade da Equipe: 20
   Total de Story Points: 200

   Total de Iterações do Projeto: 200/20 = 10
   Duração da Iteração: 2 semanas

   Pode ser que eu tenha o produto em: 20
    semanas.
1º Curitiba Scrum Day
1º Curitiba Scrum Day
   Priorização baseada em números
   Permite encaixe de funcionalidades “sem alterar” prioridades estabelecidas
    anteriormente.

ID Descrição                                                           Estimativa   Import.

1   Como jornalista, gostaria de pré publicar as minhas matérias via       3           8
    smartyphone para que eu não tenha que retornar a redação para
    que as matérias saiam mais rapidamente na internet.
2   Como redator chefe, gostaria de aprovar ou não as notícias pré         5           4
    publicadas pelos jornalistas para que tenhamos a garantia de que
    as notícias encaminhadas sejam adequadas e não tenham erros de
    português.
3   Como gerente do recursos humanos, gostaria de um relatório dos         5           6
    jornalistas que mais encaminham notícias com erros de português
    para que eu possa providenciar cursos de reforço para nossos
    profissionais.
1º Curitiba Scrum Day
   Duas a quatro semanas
   Timebox
   Nenhuma mudança
   Objetivo
   Local definido para reunião diária
   Disponibilidade de cada membro da equipe
   Data definida para apresentação do Sprint.
   SP 1: PO seleciona o que
    será feito
   SP 2: Equipe decompõe o
    que será feito

   Fornece informações
    suficientes para equipe.

   Proporciona ao PO
    confiança suficiente na
    equipe.
   Estabelecer o objetivo do Sprint
   Não esquecer da velocidade da equipe
   O PO seleciona itens do Product Backlog
   O PO tira dúvidas sobre os itens
    selecionados.
QUALIDADE EXTERNA

É percebida pelo cliente e pode ser
negociável.



QUALIDADE INTERNA

Afeta manutenibilidade e nunca
poderá ser negociada.
Tarefas identificadas e estimadas (1 a 8 horas)
De forma colaborativa, não é feito pelo Scrum
                                       Master
  Equipe compromete-se a concluir as tarefas
               Construção do Sprint Burndown
1º Curitiba Scrum Day
1º Curitiba Scrum Day
Evitar síndrome dos 90%


Codificado, Comitado, Testado,
Publicado em Ambiente de
Testes, documentado e
funcionando




= DONE DONE
O que eu fiz
 desde a última
      reunião?
O que vou fazer
 até a próxima?
Que coisas estão
   atrapalhando
  meu trabalho?

    Todos podem
       participar
   Apenas o Time
             fala
 Não se resolvem
      problemas
   Máximo de 15
        minutos
           De pé
Satisfação do
Product Owner
  Feedback do
      Produto
Reflete, aprende e planeja melhorar
dentro de 3 questionamentos
básicos:

1. O que aconteceu durante o Sprint
   que deve continuar?
2. O que aconteceu durante o Sprint
   que precisa ser melhorado?
3. O que deve Parar?
1º Curitiba Scrum Day
Planejamento
    Sucessivo e
     Constante
Mini-projetos de
     baixo risco
Permite
        
  mudanças em
intervalos fixos
   Aprendizagem
           a cada
        liberação
Time to Market
Valor entregue de forma incremental
Testes acontecem
     continuamente
Melhoria do Processo
1º Curitiba Scrum Day
Força
        Disciplina
        Coragem
            Vigor
           Paixão
        Coaching
   Times Estáveis
  Multi-funcional
Cliente disponível
   Não há práticas de Engenharia
   Parece simples, mas...
   Não é Bala de Prata
   Não está completo
   Leva tempo
1º Curitiba Scrum Day
Blog do Jonas
      blogdojonas.com.br
                Twitter
               @jonastlc

                 E-Mail
jonas@blogdojonas.com.br

More Related Content

Similar to 1º Curitiba Scrum Day

Desenvolvendo produtos de forma ágil com scrum
Desenvolvendo produtos de forma ágil com scrumDesenvolvendo produtos de forma ágil com scrum
Desenvolvendo produtos de forma ágil com scrumRômulo Gomes
 
Workshop Agilizando Projetos com SCRUM
Workshop Agilizando Projetos com SCRUMWorkshop Agilizando Projetos com SCRUM
Workshop Agilizando Projetos com SCRUMElumini Outdoing IT
 
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...Luiz Lemos
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosWilliam Lima
 
EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito d...
EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito d...EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito d...
EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito d...Fabiano Milani
 
Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To ScrumJuan Bernabó
 
Desenvolvimento Ágil com Scrum - Palestra Digitalks
Desenvolvimento Ágil com Scrum - Palestra DigitalksDesenvolvimento Ágil com Scrum - Palestra Digitalks
Desenvolvimento Ágil com Scrum - Palestra DigitalksRômulo Gomes
 
Scrum Overview - uma introdução ao Scrum
Scrum Overview - uma introdução ao ScrumScrum Overview - uma introdução ao Scrum
Scrum Overview - uma introdução ao ScrumCompanyWeb
 
Seminario Scrum
Seminario ScrumSeminario Scrum
Seminario ScrumFingerTips
 
Apresentação Scrum 2012
Apresentação Scrum 2012Apresentação Scrum 2012
Apresentação Scrum 2012Libia Boss
 
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixModelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixCris Fidelix
 
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)André Dias
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPaulo Furtado
 
Gerenciando Projetos com Scrum - FEI
Gerenciando Projetos com Scrum - FEIGerenciando Projetos com Scrum - FEI
Gerenciando Projetos com Scrum - FEIDanilo Ferreira
 

Similar to 1º Curitiba Scrum Day (20)

Desenvolvendo produtos de forma ágil com scrum
Desenvolvendo produtos de forma ágil com scrumDesenvolvendo produtos de forma ágil com scrum
Desenvolvendo produtos de forma ágil com scrum
 
Workshop Agilizando Projetos com SCRUM
Workshop Agilizando Projetos com SCRUMWorkshop Agilizando Projetos com SCRUM
Workshop Agilizando Projetos com SCRUM
 
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À       Demanda...
Scrum: Uma Nova Abordagem No Desenvolvimento De Software Face À Demanda...
 
Portuguese Scrum
Portuguese ScrumPortuguese Scrum
Portuguese Scrum
 
Scrum - Gerenciamento de Projetos
Scrum - Gerenciamento de ProjetosScrum - Gerenciamento de Projetos
Scrum - Gerenciamento de Projetos
 
EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito d...
EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito d...EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito d...
EDTED Aprenda, ensine e melhores os resultados com seus clientes. Requisito d...
 
Aula 3 - Engenharia de Software
Aula 3 - Engenharia de SoftwareAula 3 - Engenharia de Software
Aula 3 - Engenharia de Software
 
Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To Scrum
 
SETIC Scrum & XP
SETIC Scrum & XPSETIC Scrum & XP
SETIC Scrum & XP
 
Desenvolvimento Ágil com Scrum - Palestra Digitalks
Desenvolvimento Ágil com Scrum - Palestra DigitalksDesenvolvimento Ágil com Scrum - Palestra Digitalks
Desenvolvimento Ágil com Scrum - Palestra Digitalks
 
Scrum Overview - uma introdução ao Scrum
Scrum Overview - uma introdução ao ScrumScrum Overview - uma introdução ao Scrum
Scrum Overview - uma introdução ao Scrum
 
Scrum 8
Scrum 8Scrum 8
Scrum 8
 
Prototipagem
PrototipagemPrototipagem
Prototipagem
 
Seminario Scrum
Seminario ScrumSeminario Scrum
Seminario Scrum
 
Apresentação Scrum 2012
Apresentação Scrum 2012Apresentação Scrum 2012
Apresentação Scrum 2012
 
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane FidelixModelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
Modelos de Processo de Desenvolvimento de Software 2 - Prof.ª Cristiane Fidelix
 
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
Utilizando metologias ágeis com VSTS: Scrum e XP, YES WE CAN! (ALM204)
 
Palestra de SCRUM em Juazeiro
Palestra de SCRUM em JuazeiroPalestra de SCRUM em Juazeiro
Palestra de SCRUM em Juazeiro
 
Gerenciando Projetos com Scrum - FEI
Gerenciando Projetos com Scrum - FEIGerenciando Projetos com Scrum - FEI
Gerenciando Projetos com Scrum - FEI
 
Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008Tudo são Dados - PHP Conference 2008
Tudo são Dados - PHP Conference 2008
 

1º Curitiba Scrum Day

  • 1. por Jonas Beto Rompkovski
  • 3. Grupo Scrum Curitiba Grupo direcionado aos profissionais de TI de Curitiba que trabalham com Scrum. Este grupo foi criado para discutirmos sobre o Scrum e sobre as experiências que cada um tem na sua empresa. @ScrumCuritiba http://scrumcuritiba.com.br
  • 4. Onde estão os projetos?  Quanto já foi gasto?  Quanto ainda será?  Quando termina?  O que será entregue?
  • 5. Desenvolvimento em Fases Resultados Antecipados Alto valor do Planejamento Pouca Visibilidade
  • 6. Mudanças se tornam mais e mais caras  Clientes não sabem o que querem
  • 7. SUCESSO em apenas 34% dos projetos entregues Longa duração ADIA retorno financeiro para empresa Fonte: Standish Report 2003
  • 8. 52% dos requisitos entregues  64% das funcionalidades são raramente usadas Fonte: Standish Report 2003
  • 9. Watts Humphrey – Pai do CMMI “O usuário não saberá o que ele quer até utilizar o sistema real (talvez nem assim).”
  • 10. Paradoxo de COBB “We know why projects fail, we know how to prevent their failure –so why do they still fail?” Martin Cobb
  • 14. Princípios  Satisfação do cliente  Mudança  Entregas Constantes  Colaboração  Motivação  Ambiente adequado  Comunicação face a face  Software funcionando  Ritmo sustentável  Simplicidade  Melhoria Contínua
  • 15. Manifesto Ágil Indivíduos e Interações Processos e ferramentas Produto Funcionando MAIS Documentação abrangente DO Responder a Mudanças Seguir um plano QUE Colaboração com o Cliente Negociação de contratos www.manifestoagil.com.br
  • 17. Modelo do Ciclo de Vida
  • 20. Product Owner (PO) Dono da Visão do Projeto Representa o Cliente
  • 21. Product Owner (PO) Define funcionalidades Prioriza as funcionalidade Escolhe datas de lançamento Dá Feedback Gerencia as partes interessadas Aceita ou Rejeita resultados
  • 22. Time Pequeno 5-9 pessoas Auto-organizado Multi-disciplinar Dedicado
  • 23. Time Define as tarefas Estima o Esforço Desenvolve o produto Garante a Qualidade Segrega os Processos
  • 24. Scrum Master Líder Servidor Protetor do Time Quebra-galho Guia Scrum
  • 25. Scrum Master Remove Impedimentos Previne Interrupções Facilitador do Time Suporta o Processo Faz a Gestão
  • 26. Visão do Produto  Preparação do ambiente  Identificar usuários  Levantar requisitos  Criar visão do projeto  Planejar Releases
  • 27. Visão do Produto Para <público alvo> que <oportunidade ou necessidade>, o <nome do produto> é um <categoria do produto> que <benefícios do usuário>. Ao contrário <produtos concorrentes>, nosso produto <diferenciais>. Para um jornal que precisa necessidade disponibilizar seus serviços na web, o sistema AgilePublisher é uma aplicação web que disponibiliza publicadores de notícias, customização de templates, agenda de compromissos (etc.). Ao contrário produtos dos produtos concorrentes que o jornalista precisa retornar à redação para assim ter sua notícia publicada, nosso produto permite ao jornanista que pré-publique a notícia diretamente do seu smartyphone ou notebook para que a redação aprove disponibilizando mais tempo para que ele possa realizar mais matérias.
  • 28. Product Backlog  Lista de funcionalidade que o cliente necessita  Os itens da lista = itens do backlog  1 Product Backlog = 1 PO  Todos podem incluir itens de backlog  Somente o PO pode priorizá-las  PO deve entender cada história  PO pode priorizar novamente no início de cada Sprint.
  • 29. Product Backlog (Exemplo) ID Descrição 1 Como jornalista, gostaria de pré publicar as minhas matérias via smartyphone para que eu não tenha que retornar a redação para que as matérias saiam mais rapidamente na internet. 2 Como redator chefe, gostaria de aprovar ou não as notícias pré publicadas pelos jornalistas para que tenhamos a garantia de que as notícias encaminhadas sejam adequadas e não tenham erros de português. 3 Como gerente do recursos humanos, gostaria de um relatório dos jornalistas que mais encaminham notícias com erros de português para que eu possa providenciar cursos de reforço para nossos profissionais.
  • 30. Histórias (User Stories)  Funcionalidade que terá valor tanto aos usuários quanto a quem estiver adquirindo o sistema.  As histórias têm 3 aspectos (3C) segundo Ron Jeffries  Cards – histórias são escritas em cartões ou post-its (cards), naturalmente forçando as histórias a serem pequenas.  Conversation – A história escrita no cartão serve como um lembrete, tornando-se um convite ao diálogo (conversation).  Confirmation – O cliente define (implícita ou explicitamente) uma maneira de validar (Confirmation) esse pedido. Geralmente com testes de aceitação.
  • 31. Padrões de História Como jornalista, gostaria de pré publicar as Como um <usuário>, gostaria de minhas matérias via smartyphone para que eu <funcionalidade> para <valor de não tenha que retornar a redação para que as negócio>. matérias saiam mais rapidamente na internet. Para que eu não tenha que retornar a Para obter/alcançar <valor de redação para que as matérias saiam mais negócio>, como um <usuario> eu rapidamente na internet, como jornalista gostaria da <funcionalidade>. eu gostaria de pré publicar as minhas matérias via smartyphone. Idéia Corretor Ortográfico
  • 33. E as estimativas?  Tamanho x tempo
  • 34. Tamanho  Story Points  Medida relativa do tamanho de uma história.  Não existe fórmula  É resultado do agrupamento de fatores: esforço envolvido no desenvolvimento da funcionalidade, a complexidade, riscos, etc.  Ideal Days  A história estimada será o seu único trabalho  Tudo que você precisar estará disponível  Não haverão interrupções
  • 36. ID Descrição Estimativa 1 Como jornalista, gostaria de pré publicar as minhas matérias via 3 smartyphone para que eu não tenha que retornar a redação para que as matérias saiam mais rapidamente na internet. 2 Como redator chefe, gostaria de aprovar ou não as notícias pré 5 publicadas pelos jornalistas para que tenhamos a garantia de que as notícias encaminhadas sejam adequadas e não tenham erros de português. 3 Como gerente do recursos humanos, gostaria de um relatório dos 5 jornalistas que mais encaminham notícias com erros de português para que eu possa providenciar cursos de reforço para nossos profissionais.
  • 38. É o total de story points entregues em uma iteração pela equipe.  Exemplo...  Velocidade em conjunto com o total de story points do projeto, pode gerar um cronograma.  Como vou descobrir a velocidade da 1ª iteração?
  • 39. Velocidade da Equipe: 20  Total de Story Points: 200  Total de Iterações do Projeto: 200/20 = 10  Duração da Iteração: 2 semanas  Pode ser que eu tenha o produto em: 20 semanas.
  • 42. Priorização baseada em números  Permite encaixe de funcionalidades “sem alterar” prioridades estabelecidas anteriormente. ID Descrição Estimativa Import. 1 Como jornalista, gostaria de pré publicar as minhas matérias via 3 8 smartyphone para que eu não tenha que retornar a redação para que as matérias saiam mais rapidamente na internet. 2 Como redator chefe, gostaria de aprovar ou não as notícias pré 5 4 publicadas pelos jornalistas para que tenhamos a garantia de que as notícias encaminhadas sejam adequadas e não tenham erros de português. 3 Como gerente do recursos humanos, gostaria de um relatório dos 5 6 jornalistas que mais encaminham notícias com erros de português para que eu possa providenciar cursos de reforço para nossos profissionais.
  • 44. Duas a quatro semanas  Timebox  Nenhuma mudança  Objetivo  Local definido para reunião diária  Disponibilidade de cada membro da equipe  Data definida para apresentação do Sprint.
  • 45. SP 1: PO seleciona o que será feito  SP 2: Equipe decompõe o que será feito  Fornece informações suficientes para equipe.  Proporciona ao PO confiança suficiente na equipe.
  • 46. Estabelecer o objetivo do Sprint  Não esquecer da velocidade da equipe  O PO seleciona itens do Product Backlog  O PO tira dúvidas sobre os itens selecionados.
  • 47. QUALIDADE EXTERNA É percebida pelo cliente e pode ser negociável. QUALIDADE INTERNA Afeta manutenibilidade e nunca poderá ser negociada.
  • 48. Tarefas identificadas e estimadas (1 a 8 horas) De forma colaborativa, não é feito pelo Scrum Master Equipe compromete-se a concluir as tarefas Construção do Sprint Burndown
  • 51. Evitar síndrome dos 90% Codificado, Comitado, Testado, Publicado em Ambiente de Testes, documentado e funcionando = DONE DONE
  • 52. O que eu fiz desde a última reunião? O que vou fazer até a próxima? Que coisas estão atrapalhando meu trabalho? Todos podem participar Apenas o Time fala Não se resolvem problemas Máximo de 15 minutos De pé
  • 53. Satisfação do Product Owner Feedback do Produto
  • 54. Reflete, aprende e planeja melhorar dentro de 3 questionamentos básicos: 1. O que aconteceu durante o Sprint que deve continuar? 2. O que aconteceu durante o Sprint que precisa ser melhorado? 3. O que deve Parar?
  • 56. Planejamento Sucessivo e Constante Mini-projetos de baixo risco
  • 57. Permite  mudanças em intervalos fixos  Aprendizagem a cada liberação
  • 58. Time to Market Valor entregue de forma incremental
  • 59. Testes acontecem continuamente Melhoria do Processo
  • 61. Força Disciplina Coragem Vigor Paixão Coaching Times Estáveis Multi-funcional Cliente disponível
  • 62. Não há práticas de Engenharia  Parece simples, mas...  Não é Bala de Prata  Não está completo  Leva tempo
  • 64. Blog do Jonas blogdojonas.com.br Twitter @jonastlc E-Mail jonas@blogdojonas.com.br