por Jonas Beto Rompkovski
Expectativas
Grupo Scrum CuritibaGrupo direcionado aos profissionais de TI de Curitiba que trabalham com Scrum.Este grupo foi criado pa...
Onde estão os projetos?                     Quanto já foi gasto?                      Quanto ainda será?                ...
Desenvolvimento em FasesResultados AntecipadosAlto valor do PlanejamentoPouca Visibilidade
Mudanças se tornam mais                e mais caras Clientes não sabem o que                    querem
SUCESSO em apenas 34% dos projetos entreguesLonga duração  ADIA retorno  financeiro para  empresa  Fonte: Standish Report ...
   52% dos    requisitos    entregues   64% das    funcionalidades    são raramente    usadas        Fonte: Standish Rep...
Watts Humphrey – Pai do CMMI                       “O usuário não                        saberá o que                     ...
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             ...
Manifesto ÁgilIndivíduos e Interações            Processos e ferramentasProduto Funcionando         MAIS   Documentação ab...
Origem do SCRUM
Modelo do Ciclo de Vida
Fluxo do SCRUM
Papéis do SCRUM
Product Owner (PO)Dono da Visãodo ProjetoRepresenta oCliente
Product Owner (PO)Define funcionalidadesPrioriza as funcionalidadeEscolhe datas delançamentoDá FeedbackGerencia as partesi...
Time               Pequeno           5-9 pessoas       Auto-organizado       Multi-disciplinar              Dedicado
TimeDefine as tarefasEstima o EsforçoDesenvolve o produtoGarante a QualidadeSegrega os Processos
Scrum Master   Líder ServidorProtetor do Time   Quebra-galho      Guia Scrum
Scrum MasterRemove 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   Pla...
Visão do ProdutoPara <público alvo> que <oportunidade ou necessidade>, o <nomedo produto> é um <categoria do produto> que ...
Product Backlog   Lista de funcionalidade que o cliente    necessita   Os itens da lista = itens do backlog   1 Product...
Product Backlog (Exemplo)ID   Descrição1    Como jornalista, gostaria de pré publicar as minhas matérias via smartyphone  ...
Histórias (User Stories)   Funcionalidade que terá valor tanto aos usuários    quanto a quem estiver adquirindo o sistema...
Padrões de História                                  Como jornalista, gostaria de pré publicar asComo um <usuário>, gostar...
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 agrup...
ID Descrição                                                              Estimativa1   Como jornalista, gostaria de pré p...
   É o total de story points entregues    em uma iteração pela equipe.   Exemplo... Velocidade em conjunto com o  total...
   Velocidade da Equipe: 20   Total de Story Points: 200   Total de Iterações do Projeto: 200/20 = 10   Duração da Ite...
   Priorização baseada em números   Permite encaixe de funcionalidades “sem alterar” prioridades estabelecidas    anteri...
   Duas a quatro semanas   Timebox   Nenhuma mudança   Objetivo   Local definido para reunião diária   Disponibilida...
   SP 1: PO seleciona o que    será feito   SP 2: Equipe decompõe o    que será feito   Fornece informações    suficien...
   Estabelecer o objetivo do Sprint   Não esquecer da velocidade da equipe   O PO seleciona itens do Product Backlog  ...
QUALIDADE EXTERNAÉ percebida pelo cliente e pode sernegociável.QUALIDADE INTERNAAfeta manutenibilidade e nuncapoderá ser n...
Tarefas identificadas e estimadas (1 a 8 horas)De forma colaborativa, não é feito pelo Scrum                              ...
Evitar síndrome dos 90%Codificado, Comitado, Testado,Publicado em Ambiente deTestes, documentado efuncionando= 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?    T...
Satisfação doProduct Owner  Feedback do      Produto
Reflete, aprende e planeja melhorardentro de 3 questionamentosbásicos:1. O que aconteceu durante o Sprint   que deve conti...
Planejamento    Sucessivo e     ConstanteMini-projetos de     baixo risco
Permite          mudanças emintervalos fixos   Aprendizagem           a cada        liberação
Time to MarketValor entregue de forma incremental
Testes acontecem     continuamenteMelhoria do Processo
Força        Disciplina        Coragem            Vigor           Paixão        Coaching   Times Estáveis  Multi-funcional...
   Não há práticas de Engenharia   Parece simples, mas...   Não é Bala de Prata   Não está completo   Leva tempo
Blog do Jonas      blogdojonas.com.br                Twitter               @jonastlc                 E-Mailjonas@blogdojon...
1º Curitiba Scrum Day
1º Curitiba Scrum Day
1º Curitiba Scrum Day
1º Curitiba Scrum Day
1º Curitiba Scrum Day
1º Curitiba Scrum Day
1º Curitiba Scrum Day
1º Curitiba Scrum Day
1º Curitiba Scrum Day
1º Curitiba Scrum Day
Próximos SlideShares
Carregando em…5
×

1º Curitiba Scrum Day

1.076 visualizações

Publicada em

Palestra realizada por Jonas Beto Rompkovski no 1º Curitiba Scrum Day. Evento realizado pelo grupo Scrum Curitiba no dia 07/12/2010 na OPET

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.076
No SlideShare
0
A partir de incorporações
0
Número de incorporações
116
Ações
Compartilhamentos
0
Downloads
13
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

1º Curitiba Scrum Day

  1. 1. por Jonas Beto Rompkovski
  2. 2. Expectativas
  3. 3. Grupo Scrum CuritibaGrupo 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 quecada um tem na sua empresa. @ScrumCuritiba http://scrumcuritiba.com.br
  4. 4. Onde estão os projetos?  Quanto já foi gasto?  Quanto ainda será?  Quando termina?  O que será entregue?
  5. 5. Desenvolvimento em FasesResultados AntecipadosAlto valor do PlanejamentoPouca Visibilidade
  6. 6. Mudanças se tornam mais e mais caras Clientes não sabem o que querem
  7. 7. SUCESSO em apenas 34% dos projetos entreguesLonga duração ADIA retorno financeiro para empresa Fonte: Standish Report 2003
  8. 8.  52% dos requisitos entregues 64% das funcionalidades são raramente usadas Fonte: Standish Report 2003
  9. 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. 10. Paradoxo de COBB“We know why projects fail, we know how to prevent their failure –so why do they still fail?”Martin Cobb
  11. 11. Guiados pelo atraso?
  12. 12. Telefone sem fio
  13. 13. Saia da Caixa
  14. 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. 15. Manifesto ÁgilIndivíduos e Interações Processos e ferramentasProduto Funcionando MAIS Documentação abrangente DOResponder a Mudanças Seguir um plano QUEColaboração com o Cliente Negociação de contratoswww.manifestoagil.com.br
  16. 16. Origem do SCRUM
  17. 17. Modelo do Ciclo de Vida
  18. 18. Fluxo do SCRUM
  19. 19. Papéis do SCRUM
  20. 20. Product Owner (PO)Dono da Visãodo ProjetoRepresenta oCliente
  21. 21. Product Owner (PO)Define funcionalidadesPrioriza as funcionalidadeEscolhe datas delançamentoDá FeedbackGerencia as partesinteressadasAceita ou Rejeitaresultados
  22. 22. Time Pequeno 5-9 pessoas Auto-organizado Multi-disciplinar Dedicado
  23. 23. TimeDefine as tarefasEstima o EsforçoDesenvolve o produtoGarante a QualidadeSegrega os Processos
  24. 24. Scrum Master Líder ServidorProtetor do Time Quebra-galho Guia Scrum
  25. 25. Scrum MasterRemove Impedimentos Previne Interrupções Facilitador do Time Suporta o Processo Faz a Gestão
  26. 26. Visão do Produto Preparação do ambiente Identificar usuários Levantar requisitos Criar visão do projeto Planejar Releases
  27. 27. Visão do ProdutoPara <público alvo> que <oportunidade ou necessidade>, o <nomedo produto> é um <categoria do produto> que <benefícios dousuário>. Ao contrário <produtos concorrentes>, nosso produto<diferenciais>.Para um jornal que precisa necessidade disponibilizar seus serviçosna web, o sistema AgilePublisher é uma aplicação web quedisponibiliza publicadores de notícias, customização de templates,agenda de compromissos (etc.). Ao contrário produtos dos produtosconcorrentes que o jornalista precisa retornar à redação para assimter sua notícia publicada, nosso produto permite ao jornanista quepré-publique a notícia diretamente do seu smartyphone ou notebookpara que a redação aprove disponibilizando mais tempo para que elepossa realizar mais matérias.
  28. 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. 29. Product Backlog (Exemplo)ID Descrição1 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. 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. 31. Padrões de História Como jornalista, gostaria de pré publicar asComo 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 asnegócio>. matérias saiam mais rapidamente na internet. Para que eu não tenha que retornar aPara obter/alcançar <valor de redação para que as matérias saiam maisnegócio>, como um <usuario> eu rapidamente na internet, como jornalistagostaria da <funcionalidade>. eu gostaria de pré publicar as minhas matérias via smartyphone.Idéia Corretor Ortográfico
  32. 32. E as estimativas?Estimativa Compromisso
  33. 33. E as estimativas? Tamanho x tempo
  34. 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
  35. 35. ID Descrição Estimativa1 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.
  36. 36.  É 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?
  37. 37.  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.
  38. 38.  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.
  39. 39.  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.
  40. 40.  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.
  41. 41.  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.
  42. 42. QUALIDADE EXTERNAÉ percebida pelo cliente e pode sernegociável.QUALIDADE INTERNAAfeta manutenibilidade e nuncapoderá ser negociada.
  43. 43. 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
  44. 44. Evitar síndrome dos 90%Codificado, Comitado, Testado,Publicado em Ambiente deTestes, documentado efuncionando= DONE DONE
  45. 45. 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é
  46. 46. Satisfação doProduct Owner Feedback do Produto
  47. 47. Reflete, aprende e planeja melhorardentro de 3 questionamentosbá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?
  48. 48. Planejamento Sucessivo e ConstanteMini-projetos de baixo risco
  49. 49. Permite  mudanças emintervalos fixos Aprendizagem a cada liberação
  50. 50. Time to MarketValor entregue de forma incremental
  51. 51. Testes acontecem continuamenteMelhoria do Processo
  52. 52. Força Disciplina Coragem Vigor Paixão Coaching Times Estáveis Multi-funcionalCliente disponível
  53. 53.  Não há práticas de Engenharia Parece simples, mas... Não é Bala de Prata Não está completo Leva tempo
  54. 54. Blog do Jonas blogdojonas.com.br Twitter @jonastlc E-Mailjonas@blogdojonas.com.br

×