O documento apresenta os principais conceitos e práticas do framework Scrum. Resume que Scrum foi criado na década de 1990 para gerenciar projetos de software de forma ágil. Detalha os papéis de Product Owner, Scrum Master e time auto-organizado, assim como os conceitos de Sprints, estimativas, métricas, entregas contínuas e melhoria contínua por meio de retrospectivas.

1. Scrum
Conceitos, Práticas e Experiências
Por Manoel Pimentel Medeiros, CSP
Engenheiro de Software
1

2. Autor
Manoel Pimentel Medeiros, CSP
É Engenheiro de Software, com 15 anos na área de TI, atualmente
trabalha como Agile Coach para importantes empresas da área de serviço,
indústria e bancária.
Também é Diretor Editorial da Revista Visão Ágil e da InfoQ Brasil, Possui as
certificações CSM e CSP da Scrum Alliance e foi um dos pioneiros na
utilização e divulgação de métodos ágeis no Brasil.
E já escreveu para importantes portais e revistas (nacionais e internacionais)
ligados ao desenvolvimento de software.
Maiores informações em: http://manoelpimentel.blogspot.com
2
MA

3. Essência Ágil
Você comeria toda essa carne?
Ciclos Ágeis
(Inspeção e Adaptação)
3
MA

4. A metodologia Scrum
4

5. Origens
● Scrum foi criado no início da década de 1990 por Jeff Sutherland e Ken
Schwaber, nos EUA
o
er ativ
t o it l
im en nta
v olv reme
sen e inc
De Scrum
5
MA

6. Fases do Scrum
● Pregame
– Planejamento
– Desenho e alto nível da
Arquitetura
– Modelo Abrangente
● Game
– Sprints (Modelagem incremental,
desenvolvimento, revisões e
ajustes)
● Postgame
– Fechamento (Agrupamento da
Documentação, Treinamento,
Lições Aprendidas)
6
MA

7. Papéis
Sou o responsável por garantir o
ROI (Retorno sobre o
Investimento) do projeto. Também
conheço as necessidades dos
clientes (StakeHolders)
Nós aplicamos o auto-
gerenciamento para definir as
metas das Sprints, visando
produzir produtos com alta
qualidade e valor para o cliente.
Product Owner
Minha missão é garantir o uso do
Scrum. Também devo ser um
lider/facilitador, pois preciso ScrumMaster
remover os impedimentos e
proteger o time das interferências
externas.
7
MA Time

8. Princípios Ágeis sobre os Papéis
● “Pessoal de negócio e desenvolvedores devem trabalhar juntos
efetivamente por todo o projeto.”
● “Construa projetos em torno de indivíduos motivados. Dê-lhes o
ambiente e o apoio necessários e confie neles para realizarem o
trabalho.”
● “O método mais eficiente e eficaz de transmitir informação é a
conversação face-a-face.”
Fonte: http://agilemanifesto.org/principles.html
8
MA

9. Equipe Multi-Disciplinar
e Auto-Organizada
9
MA

10. Engenharia de Requisitos para
um bom Product Backlog
10

11. FBS: Feature Breakdown
Structure(FDD)
Sistema ou
Aplicação
Área de Negócio Área de Negócio Área de Negócio
Atividade de Negócio Atividade de Negócio Atividade de Negócio
Atividade de Negócio Atividade de Negócio Atividade de Negócio
Atividade de Negócio Funcionalidade Atividade de Negócio
Funcionalidade
11
Fonte: Adail Muniz Retamal - www.heptagon.com
MA

12. O Que é Feature ? Pela visão da FDD
Funcionalidade (ou característica)
Pequena o suficiente para ser implementada no
máximo em 01 iteração
Oferece valor para o cliente
Mapeia passos em uma atividade de negócio
– Pode ser um passo de um caso de uso (ou user stories)
– Às vezes pode ser o próprio caso de uso (ou user stories)
Conceito muito próximo ao de um requisito funcional
Modelo: <ação> <resultado> <objeto>
– Calcular o total de uma venda
– Autorizar uma transação com cartão de um cliente
– Enviar uma nota fiscal para um cliente
12
Fonte: Adail Muniz Retamal - www.heptagon.com
MA

13. Gerenciado ROI com Business Value
● Business Value será uma moeda de troca durante o projeto e o
cliente empresta um determinado valor dessa moeda para a equipe
e esta por sua vez, terá que devolver o valor correspondente em
forma de software, ou seja, é uma dívida que a equipe assume com
o cliente e que deverá ser amortizada a cada ciclo(Sprint), até que a
mesma seja totalmente liquidada (zerada).
13
MA

14. Product BackLog
Exemplo de Product BackLog
Área Atividade Item Business Value
Gerenciamento de
Sec. Acadêmica Controlar os cursos disponíveis pela instituição 100
cursos
Gerenciamento de
Sec. Acadêmica Definir as vagas disponíveis por cursos 90
cursos
Sec. Acadêmica Vestibular Realizar a Inscrição de canditados ao vestibular 80
Sec. Acadêmica Finanças Emitir boleto para pagamento taxas de inscrição ao vestibular 70
Sec. Acadêmica Vestibular Fornecer o controle de resultados e aprovações do vestibular 60
Emitir boleto para pagamento da matrícula ao curso que o
Sec. Acadêmica Finanças 50
candidato foi aprovado
Realizar a matrícula em um curso por um novo aluno aprovado
Sec. Acadêmica Vestibular 40
pelo vestibular.
14
MA

15. Planejamento
15

16. O Conceito de Sprint
– A Sprint é um timebox de 1 a 4 semanas no qual o time do projeto irá produzir uma
parte do produto definida pelo cliente
– Cada Sprint deve ter uma meta específica que represente o desejo do cliente em
incremento de software para aquele timebox específico
– Os membros do time da Sprint são os responsáveis por estimar os itens que
compõem o desejo do cliente e dar a palavra final do que será possível ser
desenvolvido naquele timebox
16
MA

17. Fluxo de Sprint
17 Daily Meeting
MA

18. Sprint Backlog (Lista da Sprint)
● Lista de funcionalidades a serem desenvolvidas nesta Sprint
● Pode conter o desdobramento em tarefas
● Estimada pela equipe
● Imutável (durante a Sprint)
Exemplo de Sprint BackLog - 01
Esforço
Item Business Value Size Tarefas Estimado Realizado Status Impedimento
Tarefa 1 4 4 Feito
Impedido
Controlar os cursos disponíveis Em
100 8 Tarefa 2 4 2 devido a falta de
pela instituição progresso
tal coisa
Tarefa 3 2 0 Pendente
Tarefa 1 5 0 Pendente
Definir as vagas disponíveis por
90 5
cursos
Tarefa 2 6 0 Pendente
18
MA

19. Estimativas
19

20. O cone da incerteza
PreGame Sprint 1 Sprint 2 Sprint 4 Sprint 5 Sprint 6
20
MA

21. Fluxo de Estimativas
Dias / horas
Aplicar fator
de duração
Funcionalidades
Desejadas
Estimar o Estimar a Sprint BackLog
tamanho duração
Usar escalas não-lineares (pontos):
• Fibonnacci: 1, 2, 3, 5, 8, 13, ...
• Exponencial: 1, 2, 4, 8, 16, ...
Item de referência em
Sprints Anteriotes
1 2 3
Planning
Poker
21
MA

22. Métricas e
Acompanhamentos
22

23. Status e Gestão de Impedimentos
Backlog Pendentes Iniciadas Inspeção/Teste Finalizadas
N N I
E N N N I N N
Item
N N N
N N
N N
E N I E N
Exemplo de Comunicação com Kanban (Lean)
23
MA

24. Ferramentas
Sprint DashBoard 01
Total BV Estimados 190 Dias Tarefas a Fazer
1 2 3 4 5 6 7 8 9 10
2
Dias Total BV Entregues BV Restante Esforço Restante 18 14 8 7 9 4 3 2 2 0
Dia 1 0 190
Dia 2 100 90 Tarefas Finalizadas
Dia 3 0 90 Impedimentos 1
1
Dia 4 0 90
Dia 5 0 90
Dia 6 0 90
Dia 7 0 90
Dia 8 0 90
Dia 9 90 0
Dia 10 0 0
Burn-Down Chart Burn-Up Chart
200 20
150 15
Business Value
100 10
Horas
50 5
0 0
Dia 1 Dia 2 Dia 3 Dia 4 Dia 5 Dia 6 Dia 7 Dia 8 Dia 9 Dia 10 1 2 3 4 5 6 7 8 9 10
Dias Dias
BV Restante Esf orço Restante
24
MA

25. Entregas
25

26. Princípios Ágeis sobre as Entregas
● “Nossa maior prioridade é satisfazer o cliente através da entrega
antecipada e contínua de software com valor.”
● “Entregar freqüentemente software que funciona, desde poucas
semanas até poucos meses, com uma preferência pela menor”
escala de tempo.
● “Software que funciona é a medida primordial de progresso.”
Fonte: http://agilemanifesto.org/principles.html
26
MA

27. Teste de Aceitação
Exemplo de Product BackLog com Caso de Teste
Área Atividade Item Business Value Caso de Teste
- Ao informar o ano letivo,
Gerenciamento
Sec. Acadêmica Controlar os cursos disponíveis pela instituição 100 mostrar os cursos
de cursos
disponíveis;
- Ao informar o ano letivo,
mostrar as vagas
disponíveis por curso;
Gerenciamento
Sec. Acadêmica Definir as vagas disponíveis por cursos 90
de cursos
- Ao informar um curso,
informar quais vagas estão
disponíveis no ano atual.
27
MA

28. Melhoria contínua
28

29. Princípios Ágeis da Melhoria Contínua
● “Em intervalos regulares a equipe reflete sobre como se tornar mais
eficaz, e então ajusta seu comportamento de acordo.”
Fonte: http://agilemanifesto.org/principles.html
29
MA

30. Sprint Retrospective
● É a oportunidade que o time tem para discutir sobre o que funcionou e o
que não funcionou durante a Sprint
● Scrum Master e os membros do time devem participar da retrospectiva (A
participação do Product Owner, é bem-vinda).
● A estrutura da Sprint Restrospective é bem simples:
– Divida um quadro branco ou poster em duas áreas com os seguintes títulos: “O
que funcionou bem?” e “O que pode ser melhorado?”
– Após isso, cada membro deve colocar post-its em cada uma das áreas
indicando os itens que, em sua opinião, merecem estar ali;
● Então, o time visualiza os itens citados, debatem sobre e planejam ações
a serem tomadas para a próxima Sprint
Funcionou bem? Precisa Melhorar?
x x x x
x x x
30
x
MA

31. Obrigado!
www.visaoagil.com
31