Your SlideShare is downloading. ×
Minicurso SCRUM
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Minicurso SCRUM

222
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
222
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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