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.
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
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
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
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
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
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.