fazendo acontecer com scrum e a filosofia Ágil
TRANSCRIPT
Scrume a filosofia Ágil
Dionisio Chiuratto AgourakisFounder/CEO – J!Quant
Certified Scrum Master (CSM) – Scrum [email protected]
http://jaked.ninja
5
Nosso passadoA 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
Prática Resultados Obtidos ProblemaLevantamento 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
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
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
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
E extrapolam seu prazo em:
https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/
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
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
Falham.
http://www.mckinsey.com/insights/business_technology/delivering_large-scale_it_projects_on_time_on_budget_and_on_value
13
Mas falham tanto!
http://www.mckinsey.com/insights/business_technology/delivering_large-scale_it_projects_on_time_on_budget_and_on_value
14http://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.
16
Como FuncionaO Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar valor ao cliente.
Estrutura Geral
D.o.R
Sprint Planning
D.o.D
Sprint ReviewSprint Retrospective
18
Filosofia ÁgilO manifesto ágil se baseia nestes 4 valores principais.
• 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éisO Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar valor ao cliente.
Estrutura Geral
Papel Objetivo Como é medido Perfil
Scrum Master Pessoas e ProcessosMelhorias nas pessoas e nos
processosHumano / Facilitador
Product Owner ProdutoROI – 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éisO Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar valor ao cliente.
Scrum Master
Papel Objetivo Como é medido Perfil
Scrum Master Pessoas e ProcessosMelhorias nas pessoas e nos
processosHumano / 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éisO Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar valor ao cliente.
Product Owner
Papel Objetivo Como é medido Perfil
Product Owner ProdutoROI – 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éisO Scrum é um framework para gestão de projetos ágeis, que tem como principal objetivo entregar valor ao cliente.
Dev Team
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õesO 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
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 Meeting3 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 ReviewMostrar 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 fluxoA J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe comprometida e alinhada.
1 – Contratação do projeto
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 SprintA 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
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 SprintA 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
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 SprintA J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe comprometida e alinhada.
3 – Durante a Sprint
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 SprintA J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe comprometida e alinhada.
3 – Durante a Sprint
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 SprintA J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe comprometida e alinhada.
3 – Durante a Sprint
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 SprintA J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe comprometida e alinhada.
4 – Fim da Sprint (review)
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 SprintA J!Quant passará a agir orientada a criar valor para seus clientes, tendo uma equipe comprometida e alinhada.
4 – Fim da Sprint (retrospective)
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ãoNenhum 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:
• 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ãoNenhum framework vai resolver seus problemas. Mas se você estiver disposto a encará-los de frente, a filosofia ágil vai te ajudar.
O Scrum vai:
Ser como a sua sogra:Vai jogar todos os seus problemas na sua cara.
Alexandre Magno – Instrutor da Adaptworks
37
ConclusãoNenhum framework vai resolver seus problemas. Mas se você estiver disposto a encará-los de frente, a filosofia ágil vai te ajudar.
O Scrum vai:
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.