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.

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

4. Origem do Scrum

5. Metodologias ágeis

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

35. Reuniões do Scrum

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

44. Desperdício de tempo

45. Maior valor primeiro!

46. Melhor comunicação

47. Que Venham as Mudanças!

48. Cliente satisfeito

49. Equipe satisfeita

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