Palestra de SCRUM em Juazeiro

1.844 visualizações

Publicada em

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

Sem downloads
Visualizações
Visualizações totais
1.844
No SlideShare
0
A partir de incorporações
0
Número de incorporações
9
Ações
Compartilhamentos
0
Downloads
125
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Palestra de SCRUM em Juazeiro

  1. 1. Gerenciamento de Projetos de TI com SCRUM<br />Paulo Roberto Furtado Serra, CSM<br />2009<br />
  2. 2. Objetivos<br /><ul><li>Relembrar os principais problemas do Gerenciamento de Projetos
  3. 3. Repassar os princípios que norteiam as Metodologias Ágeis
  4. 4. Introduzir os principais conceitos do Scrum, bem como seus principais artefatos, papéis e cerimônias (reuniões)</li></li></ul><li>Apresentação do Instrutor<br /><ul><li>Paulo Furtado Serra trabalha a mais de 10 anos na área de desenvolvimento de Software
  5. 5. A 3 anos vem se especializando em Metodologias de Gerenciamento e Desenvolvimento Ágeis
  6. 6. Mestre em Engenharia de Teleinformática pela Universidade Federal do Ceará
  7. 7. É CertifiedScrumMaster(CSM) pela ScrumAlliance</li></li></ul><li>Projetos...<br />
  8. 8. Os três “Quem”<br />- Quem já participou de algum projeto de software do Início ao Fim... <br /> ... que tenha terminado no prazo?<br />- Quem participa de algum projeto de software hoje?<br /> Se sim, esse projeto já têm algo em produção?<br />- Quem já participou de algum projeto de software onde os requisitos não mudaram? <br />Se sim, então NÃO era um projeto de Software!<br />
  9. 9. Estatísticas ChaosReport<br />Fonte: The Standish Group<br /> http://www.infoq.com/articles/chaos-1998-failure-stats<br />
  10. 10. Estatísticas Uso de Funcionalidades<br />Standish Group, 2002<br />
  11. 11. Problemas ...<br />Doenças do Gerenciamento de Projetos<br />Muita gente envolvida e pouca gente comprometida<br />Muitas barreiras de comunicação entre cliente e desenvolvedor<br />
  12. 12. Doenças do Gerenciamento de Projetos<br />Multi-tarefa nociva<br />Equipes enfrentam constantemente prioridades que mudam, fazendo com que interrompam uma tarefa e trabalhem em outra<br />Lei de Parkinson<br />Mais tempo de segurança, mais tempo de projeto<br />Síndrome do Estudante<br />O trabalho quase sempre é adiado<br />Dependência entre tarefas<br />O atraso é passado adiante, mas o adiantamento não<br />
  13. 13. Comprometimento vs Envolvimento<br />O porcoestáCOMPROMETIDO<br />A galinhaestáapenasENVOLVIDA<br />
  14. 14. Vocês conhecem essa?<br />Continua fazendosentido?<br />
  15. 15. Então, o que fazer?<br />Em 2001, um grupo de profissionais veteranos na área de software decidiu se reunir em uma estação de esqui, nos EUA. <br />O objetivo seria discutir formas de melhorar o desempenho de seus projetos. <br />Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado quando os projetos davam certo;<br />O grupo era composto de grandes nomes do mundo do software, tais como: Kent Beck, Jim Highsmith, Alistair Cockburn, Martin Fowler, Ken Schwaber e Jeff Sutherland;<br />O encontro deu origem ao <br />MANIFESTO ÁGIL<br />
  16. 16. O Manifesto Ágil<br />“Estamos descobrindo melhores maneiras de desenvolver software, fazendo software e ajudando outros a fazê-lo. Através deste trabalho passamos a valorizar:<br />Processos e ferramentas<br />Indivíduos e interações<br />Maisque<br />Documentação abrangente<br />Software quefunciona<br />Maisque<br />Negociação de contrato<br />Colaboração do cliente<br />Maisque<br />Seguir um plano<br />Resposta à mudanças<br />Maisque<br />Isto é, embora haja valor nos itens do lado direito, nós valorizamos mais os do lado esquerdo.”<br />http://www.agilemanifesto.org<br />
  17. 17. Desenvolvimento em CascataPor que mudar isso?<br />
  18. 18. Desenvolvimento Incremental e IterativoPensando um pouco...<br />Planejamento<br />Por Fase<br />Requisitos<br />Especific.<br />Desenvolv<br />Testes<br />Produção<br />Isso não é do jeito que eu queria !!!<br />Iteração 1<br />Iteração 2<br />Iteração N<br />Por que não...<br />Iterações?<br />...<br />Entrega 1<br />Entrega 2<br />
  19. 19. Empresas/Instituções que estão tendo sucesso com Agile<br />e outras ...<br />
  20. 20. SCRUM<br />
  21. 21. O que é Scrum?Algumas definições<br />Scrum é um processo iterativo e incremental para o desenvolvimento de qualquer produto e gerenciamento de qualquer trabalho.<br />Scrum é um processo ágil para o gerenciamento e controle de projetos;<br />Scrum é uma abordagem para desenvolvimento de sistemas e produtos onde os requisitos sofrem constantes mudanças;<br />Scrum é um processo que controla o caos dos conflitos de interesses;<br />
  22. 22. A Dinâmica do Scrum<br />Sprint<br />
  23. 23. Artefatos<br />ProductBacklog<br />SprintBacklog<br />BurndownChart<br />
  24. 24. ProductBacklog<br />Criado a partir de uma Visão do Projeto<br />Lista de funcionalidades priorizadas<br />Maior<br />prioridade<br />Menor Prioridade<br />
  25. 25. SprintBacklog<br />Parte do ProductBacklog que vai ser feita numa iteração (Sprint)<br />Montado a partir das funcionalidade que estão no topo do ProductBacklog<br />Maior<br />prioridade<br />Sprint<br />Backlog<br />Menor Prioridade<br />
  26. 26. Mas o que é um Sprint?<br />Um período de Tempo entre 2 a 4 semanas<br />Sempre deve ter um objetivo a ser atingidao pela equipe<br />É normal que o tempo de duração dos Sprints possam variar no início do projeto, mas o ideal é que se chegue num tempo único para todos os sprints<br />Todos os Sprints devem pessuir uma estrutura exatamente igual<br />
  27. 27. Estrutura de um Sprint<br />dias<br />1º<br />2º<br />3º<br />4º<br />5º<br />6º<br />7º<br />8º<br />9º<br />10º<br />Apresentação<br />SprintX<br />Planejamento – Sprint X<br />Planejamento – Sprint X+1<br />Retrospectiva<br />Reunião diária<br />Reunião diária<br />Reunião diária<br />Reunião diária<br />Reunião diária<br />Reunião diária<br />Reunião diária<br />Reunião diária<br />Sprint X<br />
  28. 28. Dinâmica do ProductBacklog<br />Histórias<br />Alta<br />A<br />O que está dentro do Sprint<br />Não pode ser alterado.<br />B<br />Sprint 1<br />C<br />D<br />E<br />- O que está fora do Sprint pode <br /> Ser alterado de acordo com a <br /> necessidade do cliente. <br />- Ele pode alterar prioridades,<br /> inserir novas tarefas ou retirar<br /> tarefas existentes.<br />- Algumas tarefas podem ser <br /> inseridas pela equipe. <br /> Ex: Montar ambiente para <br /> Integração contínua<br />F<br />ProductBacklog<br />Prioridade<br />G<br />H<br />I<br />Baixa<br />
  29. 29. Papéis no Scrum<br />ProductOwner<br />ScrumMaster<br /> Equipe<br />
  30. 30. ProductOwner<br />Define as funcionalidades do produto<br />Decide datas de lançamento e conteúdo<br />Responsávelpelarentabilidade (Return Of Investiment - ROI)‏<br />Priorizafuncionalidades de acordo com seuvalorpara o negócio<br />Gerencia a entrada de novosrequisitos e suasprioridades<br />Aceitaourejeita o resultado dos trabalhos<br />$$$$$$$$$$<br />
  31. 31. Interação do PO com os Usuários<br />Usuários<br />Product<br />Owner<br />Isso não impede<br />Equipe de desenvolvimento<br />
  32. 32. ScrumMaster<br />Representa a gerênciapara o projeto<br />Responsávelpelaaplicação dos valores e práticas do Scrum<br />Remove obstáculos<br />Garante a plenafuncionalidade e produtividadedaequipe<br />Garante a colaboração entre osdiversospapéis e funções<br />Escudoparainterferênciasexternas<br />
  33. 33. Equipe<br />Tamanhovariável , é aconcelhávelnãomaisque 9 pessoas e nãomenosque 4<br />Multi-funcional<br />Programadores, testadores, desenvolvedores...<br />Aconcelháveltrocassónamudança de Sprints<br />Faz o que for precisoparaalcançar a Meta do Sprint, umavezque se compromete com o quevai ser entregue<br />Apresentaaosinteressados o resultado do Sprint<br />
  34. 34. Cerimônias<br />Planejamento do Sprint<br />Reunião Diária<br />Demonstração<br />Retrospectiva<br />
  35. 35. Planejamento do Sprint(SprintPlanning Meeting)<br />Reunião que define<br />O objetivo (meta) do Sprint<br />Uma lista dos membros da equipe que estarão comprometidos com a meta<br />Um SprintBacklog (lista com todas as funcionalidades incluídas no sprint)<br />Uma Data para demonstrar que foi produzido durante o sprint<br />Hora e lugar definido para acontecerem as reuniões diárias<br />Dependendo do projeto, esta reunião pode durar de 4 a 16 horas<br />
  36. 36. Planejamento do SprintESTIMATIVAS<br />Como estimar?<br />StoryPoints<br />Um “peso” dado para cada história<br />Indica quanto uma história é maior ou mais complexa que outra<br />Horas<br />Tempo estimado por cada tarefa<br />
  37. 37. Planejamento do SprintESTIMATIVAS em StoryPoints<br />PlanningPoker<br />
  38. 38. Reunião de planejamento de Sprint<br />Reunião de Planejamento<br />Scrum<br />Master<br />Product<br />Owner<br />Time de Desenvolvimento<br />
  39. 39. Reunião Diária(ScrumDaily Meeting)<br /><ul><li>Objetivo
  40. 40. Cada membro deve responder as seguintes perguntas:</li></ul>O que você fez desde a última reunião diária?<br />O que você pretende fazer até a próxima reunião diária?<br />Existe algum problema que o impeça de realizar suas atividades?<br /><ul><li>Duração
  41. 41. 15 minutos (não mais que isso)
  42. 42. Sugestão: Todos em Pé
  43. 43. Qualquer pessoa pode participar, mas apenas o ScrumMaster e os Membros da Equipe pedem falar</li></li></ul><li>Reunião de Demonstração(SprintReview)<br />Objetivo<br />Mostrar o que foi produzido no Sprint<br />Duração<br />30 a 60 minutos<br />Participantes<br />Product Owner, Scrum Master, membros do time, clientes, Usuários, Stakeholders e qualquer pessoa que esteja interessada no resultado da Sprint<br />Qualquer participante pode falar, fazer perguntas ou observações<br />
  44. 44. Retrospectiva(SprintRetrospective)<br />Objetivo<br />Enumerar o que funcionou e o que não funcionou durante o Sprint<br />Duração<br />30 a 60 minutos<br />Participantes<br />Product Owner, Scrum Master e os membros do time<br />Esta reunião pode ser feita à frente de um quadro branco onde membro cola post its dizendo o que funcionou e o que não funcionou<br />Feita após cada Sprint<br />
  45. 45. RetrospectivaExemplo<br />Testes<br />Comunicação entre os membros<br />Reuniões Diárias<br />Faltou melhor planejamento do Sprint<br />Usuário <br />Distante<br />Alguns membros chegam tarde<br />
  46. 46. Quatro KanBan<br />
  47. 47. Artefatos do Scrum<br />ProductBacklog<br />SprintBacklog<br />BurndownChart<br />
  48. 48. BurndownChart<br />
  49. 49. Paradigmas a serem quebrados<br />Equipes auto-gerenciáveis<br />Equipes multi-disciplinares<br />Até onde a documentação é último<br />Comunicação<br />Referência<br />Desenvolvimento por iterações<br />Zonas de conforto<br />
  50. 50. Referências<br />www.mountaingoatsoftware.com/scrum<br />www.scrumalliance.org<br />www.controlchaos.com<br />scrumdevelopment@yahoogroups.com<br />Agile Software Development with Scrum by Ken Schwaber and Mike Beedle<br />Agile Project Management with Scrum by Ken Schwaber<br />Scrum and the Enterprise by Ken Schwaber<br />Scrum and XP from the trenches<br />
  51. 51. Dúvidas ?<br />

×