Introdução ao desenvolvimento ágil com Scrum
Transferir como PPTX, PDF0 gostou717 visualizações
O documento introduz o framework Scrum para desenvolvimento ágil de software, descrevendo seus conceitos, práticas e artefatos principais, incluindo Product Backlog, Sprints e reuniões. Apresenta um caso de sucesso da adoção de Scrum na Globo.com para entregar funcionalidades mais rapidamente.
Introdução ao desenvolvimento ágil com Scrum
- 1. Introdução ao Desenvolvimento Ágil com Scrum Lorena Lopes Analista de Requisitos na Inove Informática lorena.lopes@inoveinformatica.net
- 2. Agenda • Conceito geral • Scrum Framework • Por que utilizar Scrum? • Estudo de caso: Globo.com
- 3. O Scrum é um metodologia de desenvolvimento iterativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software
- 6. Engenharia de Software tradicional Documentação
- 7. Engenharia de Software tradicional Documentação
- 8. Engenharia de Software tradicional Documentação
- 9. Engenharia de Software tradicional Documentação
- 10. • O mercado exige cada vez mais demanda por software rápidos • Faltava interação com os clientes • Muita burocracia
- 11. Manifesto Ágil
- 12. Princípios Manifesto Ágil Indivíduos e interação Software funcionando Colaboração do cliente Mudança Processos e ferramentas Documentação abrangente Negociação de contratos Seguir um plano
- 13. Valor Tempo
- 15. Scrum é um Framework! valores, princípios e pilares. Práticas Regras Papéis Artefatos
- 16. Scrum e a cultura empresarial
- 17. Os pilares do Scrum Scrum Transparência Inspeção Adaptação
- 18. Ciclo de trabalho do Scrum
- 19. Ciclo de trabalho do Scrum O PO define a visão com base nas informações escolhidas junto ao usuário final, equipe, stakeholders e gerentes.
- 20. Ciclo de trabalho do Scrum O PO junto com o Scrum Master cria o Product Backlog, uma lista inicia de necessidades que precisam ser produzidas para que a visão do projeto seja bem sucedida.
- 21. Ciclo de trabalho do Scrum O Scrum Master, PO e a equipe planejam o Sprint, essa reunião chama-se Planning Meeting e é dividida em duas partes. Na primeira o objetivo é gerar o Selected Product Backlog.
- 22. Na segunda parte do Planning Meeting o Ciclo de trabalho do Scrum objetivo é decompor as informações do Selected Product Backlog em tarefas, onde cada membro da equipe irá estimá-la. Tais tarefas irão gerar o Sprint Backlog.
- 23. Ciclo de trabalho do Scrum A equipe irá iniciar o trabalho do Sprint, de acordo com o tempo estimado, realizando o Daily Scrum todos os dias.
- 24. Ciclo de trabalho do Scrum Ao término do Sprint é realizada um reunião de Review. Seu objetivo é apresentar o que foi realizado ao PO.
- 25. Ciclo de trabalho do Scrum Por último é realizada a reunião de Retrospectiva. O seu objetivo é levantar pontos bons e ruins do Sprint.
- 26. Artefatos do Scrum • Product Backlog e Selected Backlog – Lista contendo todas as funcionalidades desejadas para um produto e para o sprint, respectivamente. • Impedment Backlog – Listas de impedimentos da equipe. • Taskboard – Quadro de acompanhamento diário.
- 27. Product Backlog
- 28. Taskboard
- 29. Taskboard
- 30. Papéis do Scrum • Product Owner – Representante do cliente e responsável pelo aspecto funcional do produto. • Scrum Master – Líder que atua como facilitador do processo. • Scrum Team – Responsável pelo desenvolvimento do produto
- 31. Product Owner • Define as funcionalidades do produto • Decide datas de lançamento e conteúdo • Responsável pela rentabilidade (ROI) • Prioriza funcionalidades de acordo com o valor de mercado • Ajusta funcionalidades e prioridades • Aceita ou rejeita o resultado dos trabalhos
- 32. Scrum Master • Representa a gerência para o projeto • Responsável pela aplicação dos valores e práticas do Scrum • Remove obstáculos • Garante a plena funcionalidade e produtividade da equipe • Garante a colaboração entre os diversos papéis e funções • Escudo para interferências externas
- 33. Scrum Team • Foco em entregar o produto • Equipe multidisciplinar e auto suficiente
- 34. Gráficos de Acompanhamento • Sprint Burndown
- 36. Sprint Planning • A equipe seleciona itens do Product Backlog com os quais compromete-se a concluir • O Sprint Backlog é criado • Planejamento de alto nível é considerado
- 37. Daily Meeting • Todos em pé! • Não é para a solução de problemas • Ajuda a evitar reuniões adicionais desnecessárias
- 38. Sprint Review • Equipe apresenta os resultados obtidos durante o Sprint • Demonstração de novas funcionalidades • Informal • Todo o time participa
- 39. Sprint Retrospective • Periodicamente, observe o que funciona e o que não funciona • Feita após cada Sprint • Toda a equipe participa
- 40. Scrum pode falhar? • Achar que é possível “Implantar” Scrum. • Achar que Scrum é só mais um conjunto de praticas a ser seguidas e que seguir as praticas é suficiente e que não requer uma mudança organizacional profunda. • Não estar consciente do nível de mudança que a tentativa de adotar ira gerar • Achar que se tem competência sobre como fazer uma mudança de paradigma, sem ter fracassado pelo menos três vezes tentando. • Achar que Scrum é a solução de todos os problemas.
- 41. Por que Scrum?
- 42. Cenários atuais • As empresas querem aumentar sua competitividade para não perder clientes. • Os diretores precisam reduzir custos operacionais para sua organização sobreviver. • Os clientes tem que reduzir custos dos projetos para torná-los viáveis.
- 43. Cenário atuais • Ambientes mudam rapidamente • Maximizar o retorno do investimento (ROI) do cliente • Reduzir o tempo de entrada em produção • Entregar valor para o cliente • Priorizar a comunicação e feedback entre as pessoas do projeto
- 47. Que Venham as Mudanças!
- 50. GLOBO.COM • Inscrições para o BBB8 • Ótima idéia, mas com prazo impraticável • Cenário – Estrutura departamentalizada – Burocracia – Equipes distintas
- 51. Benefícios • Maior velocidade • Resposta mais rápidas a mudanças • Maior qualidade • Distribuição do conhecimento • Motivação
- 52. Principais dificuldades • Muitos impedimentos • Resistência de quem acha que está perdendo poder • Síndrome do PO virtual • Não treinar as equipes antes de começar
- 53. Conclusões • É possível escrever software de qualidade sem burocracia. É possível escrever software de qualidade sem burocracia!
- 54. Introdução ao Desenvolvimento Ágil com Scrum Obrigado! Lorena Lopes Analista de Requisitos na Inove Informática lorena.lopes@inoveinformatica.net