fazendo acontecer com scrum e a filosofia Ágil

Scrume a filosofia Ágil

Dionisio Chiuratto AgourakisFounder/CEO – J!Quant

Certified Scrum Master (CSM) – Scrum [email protected]

http://jaked.ninja

Great companies are built,

not launched.

3

1. O que temos feito

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:


8

1 a cada 6 (16,6%) extrapolam seu custo em:


200%

Custo inicial: 100

Custo real: 300

9

E extrapolam seu prazo em:


10

E extrapolam seu prazo em:


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.


13

Mas falham tanto!


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.

15

2. Scrum

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

17

Resumo

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

19

Fuck it.Ship it.

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


Scrum Master


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


Product Owner


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


Dev Team


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

25

3. Novo fluxo de trabalho

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



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



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

34

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

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


O Scrum vai:

Ser como a sua sogra:Vai jogar todos os seus problemas na sua cara.

Alexandre Magno – Instrutor da Adaptworks

37


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.

38

Conclusão

Grandes poderes,Grandes responsabilidades.

PARKER, Benjamin (Tio Ben)

39

Conclusão

Como você deve imaginar...

40

Conclusão

O resto é com vocês!

41

Obrigado!

fazendo acontecer com scrum e a filosofia Ágil

Small Business & Entrepreneurship