O documento fornece uma introdução ao framework Scrum, descrevendo seus princípios e práticas. É destacado que Scrum é usado para gerenciar projetos de software de forma ágil, entregando valor ao cliente a cada Sprint curta. Os papéis de Product Owner, Scrum Master e Time são definidos, assim como as cerimônias como Planning, Daily Meeting, Review e Retrospectiva.
4. Sobre mim
Fabio A. Dalonso é Certified Scrum Master (CSM) e Certified Scrum Product
Owner (CSPO) pela Scrum Alliance (http://www.scrumalliance.org).
Atua na área de Desenvolvimento de Sistemas a mais de 15 anos, tendo
participado como analista e coordenador de diversos tipos de projeto em
diversas plataformas e ambientes.
Após alguns anos ajudando equipes de Desenvolvimento de Sistemas obterem
sucesso em seus respectivos projetos, encontrou nas Metodologias Ágeis,
especialmente em Scrum, o perfeito alinhamento entre times e clientes.
Blog :
http://www.scrumadventures.wordpress.com
Emails:
fdalonso@gpti.com.br
fabio.dalonso@ideiaagil.com.br
5. Antes de Falar de Scrum...
Funcionalidades em Sistemas de Softwares
Standish Group - 2002
64% das funcionalidades NUNCA ou RARAMENTE são usadas
6. Antes de Falar de Scrum...
Índice de Sucesso nos Projetos de Software
Chaos Report 2004 / 2006 / 2009 - Standish Group
Sucesso: Projeto finalizado no prazo, no orçamento e totalmente funcional
Desafio: Projeto finalizado com atraso, com estouro de orçamento e/ou não totalmente funcional
Falha: Projeto cancelado ou nunca utilizado
9. História
O Scrum não teve um criador propriamente dito. Sua primeira “aparição” foi registrada
na Harward Bussines Review (Jan/86) em um artigo escrito por Takeuchi e Nonaka
direcionado para a indústria automobilística e baseado no Sistema Toyota de
Produção (Lean). Em 1993, o framework começou a ser moldado por Jeff Sutherland
(PhD) e sua documentação foi formalizada por Ken Schwaber em 1995.
Artigo: “The New New Documentação formalizada
Sistema Toyota de Product Development Game” IRobot – Projeto que
Produção (Lean) influenciou Sutherland por Schwaber
(HBR)
1948 1986 1993 1995
10. O Manifesto Ágil
“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o
nós mesmos e ajudando outros a fazê-lo. Através desse trabalho, passamos a
valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas
Produto em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens
à esquerda."
11. Scrum: O que é e para que Serve ?
Scrum é um Framework que pode ser utilizado e aplicado para o
gerenciamento de qualquer tipo de Projeto.
Sua principal característica é realizar entregas (produto pronto) em um espaço
de tempo curto, agregando o máximo possível de valor ao negócio do Cliente
ou Parceiro.
14. Os Papeis do Scrum
Treinamento – Iniciando com Scrum – DEDIC GPTI
14
15. Os 3 Papeis – PO, SM e Time (Equipe)
Product Owner
Responsável por garantir o ROI (Return of Investment) do(s) Projeto(s).
Conhecedor do negócio. Deve ser o próprio cliente ou representado por
profissional capacitado e envolvido com a visão do(s) Produto(s).
Scrum Master
Responsável por remover os impedimentos do Time e garantir o uso de
Scrum. O Scrum Master deve também proteger o time de interferências
externas e ajudar o Product Owner a maximizar o ROI.
Time (Equipe)
Responsável pela produção do Produto. Deve ser Multidisciplinar e Auto-
Gerenciado.
16. Posicionando os Papeis
Responsável pelo
Projeto. Deve Projeto
preocupar-se com
o Macro
Product Owner
Responsável por
fazer o ambiente
Scrum Funcionar.
Deve preocupar-se
Scrum Master com o Processo
Responsável pelo
andamento do
Projeto Devem
preocupar-se com
o Micro
Time
Macro Processo Micro
17. Product Owner - Responsabilidades
Ser a Voz do Cliente
Garantir o ROI do Projeto
Definir as Funcionalidades Chave
Gerenciar Stakeholders
Escrever User Stories e Testes de Aceitação
Definir Metas
18. Iniciando o Projeto: Pré-Game
Visão do Produto – Product Vision Box
Pasta do Projeto
Planejamento de Releases
19. Scrum Master - Responsabilidades
Garantir a Correta Utilização do Processo
Remover Impedimentos do Time e da Organização
Ajudar o Product Owner na Administração do PB, etc.
Facilitar Reuniões e Cerimônias
Proteger o Time de Interferências Externas
20. Garantindo o Projeto: Game
Fazer Scrum Funcionar;
Inspecionar e Melhorar o Processo a cada Ciclo de Desenvolvimento
21. Time (Equipe) - Responsabilidades
Auto-Organizado
Multi-Disciplinar
Pequeno e Compacto (no máximo até 9 Integrantes)
Transformar Metas em Produto Pronto
22. Entregando, Finalizando: Post-Game
Apresentando Resultados
Time Comprometido durante toda a Sprint
Revisando o passado “curto” e
melhorando o Processo
24. O Fluxo do Scrum
Treinamento – Iniciando com Scrum – DEDIC GPTI
24
25. O Fluxo
Fluxo do Scrum
O Scrum possuí um fluxo / processo simples e pode ser facilmente demonstrado no
gráfico acima. Os pontos chave estão representados por: Papéis, Cerimônias e
Artefatos.
29. Desmistificando Especificações
Especificações
A forma atual como se
especifica software, não
casa com a filosofia de
trabalho do Scrum, pois:
• Assumem que há um nível
avançado de conhecimento
de tudo
• Alto consumo de tempo
para escrever e ler; um
tédio para escrever
• Trata o aprendizado do
cliente como “mudança de
escopo”
• Difíceis de se adequar ao
desenvolvimento iterativo e
incremental
30. Trabalhando com User Stories
Quem
O que
Para Que ?
Como um <PERFIL>, eu Como um COMPRADOR, eu quero
posso/quero/desejo/devo <FUNÇÃO> ESCOLHER UM PRODUTO DE UMA
para <VALOR DE NEGÓCIO> LISTA para REALIZAR UMA
COTAÇÃO E COMPARAÇÃO DE
PREÇOS
31. Teste de Aceitação de Negócio
Como um COMPRADOR, eu quero
ESCOLHER PRODUTOS DE UMA
LISTA para REALIZAR UMA
COTAÇÃO E COMPARAÇÃO DE
PREÇOS
• Exibir uma lista de Produtos ordenada
alfabeticamente;
• Permitir seleção múltipla de
Produtos;
• Ordenar resultado da comparação
pelo menor preço;
34. Itens “Ready” e Itens “Done”
... se transforma em ...
Requisitos / Itens “Ready” Funcionalidades “Done”
Product Owner e Time devem conversar e combinar durante o Pré-Projeto ou
durante a primeira Planning Meeting o que será considerado “Ready” e “Done”
35. Principais Objetivos do Planning
Product Owner define para Time a Meta do Sprint
Primeira Parte da Meeting Segunda Parte da Meeting
Estimar o Product Backlog Elaborar o Sprint Backlog
36. Planning Poker
Por que o Planning Poker funciona ?
• Porque apresenta múltiplas opiniões quanto a estimativa de um item;
• Porque estimula o dialogo entre os membros do Time durante as rodadas;
• Porque estudos mostram que estimativas feitas em grupo são mais bem sucedidas
que estimativas individuais;
41. Características da Daily Meeting
O que fiz desde a ultima
reunião ?
O que pretendo fazer até a
Próxima ?
Existe algum
impedimento ?
A meta está
comprometida ?
46. Scrum Board - KanBan
O quadro branco é uma importante ferramenta low-tec que tem o objetivo de
integrar os profissionais que trabalharão no projeto, além de ser uma ótima
forma de visualizar rapidamente, o andamento do Sprint.
47. Gráficos de Burndown
Gráfico que mostra a evolução Gráfico que mostra a evolução
da equipe dentro de um do Projeto ao longo de
determinado Sprint. Mede-se: finalizações de Sprints. Mede-
quantidade de horas em tarefas se: quantidade de pontos de
X dias úteis do Sprint Sprint X Sprints finalizados.