O documento descreve a transição de uma empresa para práticas ágeis de Scrum. A empresa passará a priorizar a entrega de valor ao cliente em incrementos curtos ao invés de longos contratos e especificações. Isso será feito através da adoção de papéis como Product Owner e Scrum Master, além de reuniões como Sprint Planning e Review para planejar e avaliar o progresso a cada Sprint. A filosofia ágil visa melhorar continuamente os processos para maior satisfação do cliente.

1. Scrum
e a filosofia Ágil
Dionisio Chiuratto Agourakis
Founder/CEO – J!Quant
Certified Scrum Master (CSM) – Scrum Alliance
dionisio@jquant.com.br
http://jaked.ninja

2. Great companies
are built,
not launched.

3. 1. O que temos feito
3

4. 4

5. Nosso passado
A J!Quant tem gerenciado seus projetos da maneira tradicional, levantando requisitos e fazendo
estimativas de tempo e custo para o cliente.
Nossas práticas e resultados obtidos
5
Prática Resultados Obtidos Problema
Levantamento extenso de
requisitos
Requisitos sempre incompletos ou
míopes
Desperdício de tempo e dinheiro –
insatisfação do cliente
Estimativas Estimativas incorretas Desperdício de tempo e dinheiro
Microgerenciamento Incerteza da completude do
projeto – ineficiência
Falso senso de tranquilidade ou de
emergência – não sabemos onde
estamos pisando
Auto-defesa com contrato Falsa segurança de que o contrato
protege a empresa contra o cliente
insatisfeito
A empresa tem de optar entre
desagradar o cliente ou tomar
prejuízo
Papéis mal definidos Comunicação falha, objetivos mal
alinhados
Bagunça

6. 6
Segundo um estudo da Harvard Business Review,
com 1.471 projetos
https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/

7. 7
1 a cada 6 (16,6%) extrapolam seu custo em:
https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/

8. 8
1 a cada 6 (16,6%) extrapolam seu custo em:
https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/
200%
Custo inicial: 100
Custo real: 300

9. 9
E extrapolam seu prazo em:
https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/

10. 10
E extrapolam seu prazo em:
https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/
75%
Tempo inicial: 100
Tempo real: 175

11. 11
17% dos projetos de TI ...
http://www.mckinsey.com/insights/business_technology/delivering_large-
scale_it_projects_on_time_on_budget_and_on_value

12. 12
Falham.
http://www.mckinsey.com/insights/business_technology/delivering_large-
scale_it_projects_on_time_on_budget_and_on_value

13. 13
Mas falham tanto!
http://www.mckinsey.com/insights/business_technology/delivering_large-
scale_it_projects_on_time_on_budget_and_on_value

14. 14
http://www.mckinsey.com/insights/business_technology/delivering_large-
scale_it_projects_on_time_on_budget_and_on_value
Que se tornam uma ameaça para a existência
da organização.

15. 2. Scrum
15

16. Como Funciona
O Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar
valor ao cliente.
Estrutura Geral
16
D.o.R
Sprint Planning
D.o.D
Sprint Review
Sprint Retrospective

17. 17
Resumo

18. Filosofia Ágil
O manifesto ágil se baseia nestes 4 valores principais.
18
• Indivíduos e interação entre eles mais que processos e
ferramentas
• Software 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

19. 19
Fuck it.
Ship it.

20. Papéis
O Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar
valor ao cliente.
Estrutura Geral
20
Papel Objetivo Como é medido Perfil
Scrum Master Pessoas e Processos
Melhorias nas
pessoas e nos
processos
Humano / Facilitador
Product Owner Produto
ROI – Return on
Investment e
satisfação do cliente
Negócio – cuidar do
produto e do dinheiro
Dev Team Desenvolvimento Meta da Sprint Técnico

21. Papéis
O Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar
valor ao cliente.
Scrum Master
21
Papel Objetivo Como é medido Perfil
Scrum Master Pessoas e Processos
Melhorias nas
pessoas e nos
processos
Humano / Facilitador
O Scrum Master (SM) não é gerente de projeto, não é coordenador do projeto, não
produz cronogramas, documentação, etc.
O Scrum Master (SM) deve ser um facilitador, alguém que trabalha pro-ativamente
para ajudar o time a atingir a meta da Sprint, removendo quaisquer impedimentos,
melhorando processos e pessoas.
O SM não é chefe do Dev Team.

22. Papéis
O Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar
valor ao cliente.
Product Owner
22
Papel Objetivo Como é medido Perfil
Product Owner Produto
ROI – Return on
Investment e
satisfação do cliente
Negócio – cuidar do
produto e do dinheiro
O Product Owner (PO) é o único dono do produto, ele é responsável pela visão e por
construir junto ao cliente o Product Backlog. Também é responsável pela definição
das METAS da sprint e pelo retorno (e orçamento) do projeto.
O Product Owner (PO) não é coordenador do projeto, gerente do projeto. Faz
cronogramas macro, para sua orientação e para interface sadia com o cliente. É o
responsável por escrever e produzir material palatável para o dev team.
O PO não é chefe do Dev Team.

23. Papéis
O Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar
valor ao cliente.
Dev Team
23
Papel Objetivo Como é medido Perfil
Dev Team Desenvolvimento Meta da Sprint Técnico
Dev Team é o conjunto de pessoas com competências interdisciplinares que irá
buscar a meta da sprint.
O Dev Team deve se auto organizar, e reportar imediatamente: ao PO qualquer
dúvida que tiver sobre as tarefas designadas e ao SM qualquer impedimento de
pessoas ou processos.
O Dev Team é chefe do Dev Team.

24. Reuniões
O Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar
valor ao cliente.
Estrutura de Reuniões e seus participantes
24
Reunião Objetivo Agenda Duração Max. Participantes
Sprint Planning
Planejar a Sprint: Sprint
Backlog e Metas
Primeiro dia da Sprint
pela manhã
4 hrs.
Dev Team, PO e SM
(facilitador)
Daily Meeting
3 perguntas: O que foi
feito hoje, o que será
feito amanhã e quais os
impedimentos
Todo santo dia. Sempre. 15 min.
Dev Team + SM
(facilitador)
Sprint Review
Mostrar ao PO o
incremento do produto
entregue para que ele
seja aceito ou rejeitado
Último dia da Sprint 2 hrs.
Dev Team, PO e SM
(facilitador)
Sprint Retrospective Melhorar processos Último dia da Sprint 2hrs. Dev Team + SM

25. 3. Novo fluxo de trabalho
25

26. Novo fluxo
A J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe
comprometida e alinhada.
1 – Contratação do projeto
26
Cliente PO/Vendas
Visão do Projeto
A visão do projeto norteará o PO e o Dev
Team para atuar nos pontos que geram
mais valor para o cliente. É um
levantamento de requisito de alto nível e
teoricamente imutável
Custo Fixo Prazo Fixo
Escopo Variável
(backlog!)

27. Início da Sprint
A J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe
comprometida e alinhada.
2 – Preparação e Início da Sprint
27
PO Product Backlog
O DoR – Definition of Ready, deverá ser
combinado entre o Dev Team e o PO.
Trata-se do contrato que estabelece o
mínimo que uma
tarefa/funcionalidade/estória deve
possuir para que possa entrar em
desenvolvimento.
DoR
User Story
+ Descrição
detalhada
Wireframe
de baixa
fidelidade
...

28. Início da Sprint
A J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe
comprometida e alinhada.
2 – Preparação e Início da Sprint
28
PO Product Backlog
O PO estabelece a meta da sprint e monta
o Sprint Backlog junto com o Dev Team.
Tudo isso ocorre durante o Sprint
Planning.
DoR
Meta da Sprint
Sprint Backlog
Dev Team

29. Durante a Sprint
A J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe
comprometida e alinhada.
3 – Durante a Sprint
29
O Dev Team deve se auto organizar
durante a Sprint para atingir a Meta
estabelecida.
SM não cobra o dev team. PO não cobra o
dev team.
PO tira todas as dúvidas e ajuda a validar
se o caminho esta correto.
SM resolve tudo que impede o time de
atingir a meta.
Dev Team
Daily
SM

30. Durante a Sprint
A J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe
comprometida e alinhada.
3 – Durante a Sprint
30
O Dev Team só poderá considerar uma
tarefa realizada se ela atender a 100% dos
critérios da Definition of Done.
Exemplo:
Tarefa codificada, testada e online no
ambiente de homologação
Dev Team
DoD

31. Durante a Sprint
A J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe
comprometida e alinhada.
3 – Durante a Sprint
31
O PO sempre tem a autoridade de mudar
o Product Backlog. O escopo é mutável. É
Product Owner. Owner.
A visão do projeto é imutável.
A meta da sprint é imutável.
Dev Team
SM
Read-Only
Read-Only
PO
Acesso total
Product Backlog

32. Final da Sprint
A J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe
comprometida e alinhada.
4 – Fim da Sprint (review)
32
A Sprint Review é a reunião oficial onde o
Dev Team mostra ao PO o incremento de
produto que produziu durante a Sprint.
Cabe ao PO determinar se o time atingiu
ou não a meta.
Atingir todas as metas = Sprint foi um
sucesso
Falhar em alguma meta = Sprint foi um
fracasso
Não é necessário “zerar” o sprint
backlog, desde que as metas tenham
sido atingidas.
Dev Team
SM
Read-Only
PO
Meta da Sprint
Incremento

33. Final da Sprint
A J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe
comprometida e alinhada.
4 – Fim da Sprint (retrospective)
33
Cabe ao Dev Team e principalmente ao
SM avaliar quais processos podem ser
melhorados para Sprints futuras.
A Sprint Retrospective é a reunião que
garante que a empresa melhore com o
tempo.
Dev Team
SM
Read-Only
Processos

34. 4. Conclusão (and a grain of salt)
34

35. Conclusão
Nenhum framework vai resolver seus problemas. Mas se você estiver disposto a encará-los de
frente, a filosofia ágil vai te ajudar.
O Scrum NÃO vai:
35
• Resolver os problemas de recrutamento e seleção;
• Fazer mais em menos tempo;
• Aumentar a qualidade do código;
• Fazer seu cliente pagar mais;
• Te eximir da responsabilidade de gerir a empresa;
• Aumentar suas vendas;
• Garantir o sucesso dos seus projetos;
(projetos ágeis também falham!)

36. Conclusão
Nenhum framework vai resolver seus problemas. Mas se você estiver disposto a encará-los de
frente, a filosofia ágil vai te ajudar.
O Scrum vai:
36
Ser como a sua sogra:
Vai jogar todos os seus problemas na sua cara.
Alexandre Magno – Instrutor da Adaptworks

37. Conclusão
Nenhum framework vai resolver seus problemas. Mas se você estiver disposto a encará-los de
frente, a filosofia ágil vai te ajudar.
O Scrum vai:
37
Ser como a sua sogra:
Vai jogar todos os seus problemas na sua cara.
Alexandre Magno – Instrutor da Adaptworks
E vai ajudar você a priorizar aquilo que realmente
importa a nível de negócio, aqui que realmente
gera valor.

38. Conclusão
38
Grandes poderes,
Grandes responsabilidades.
PARKER, Benjamin (Tio Ben)

39. Conclusão
39
Como você deve imaginar...

40. Conclusão
40
O resto é com vocês!

41. Obrigado!
41