Fazendo acontecer com Scrum e a Filosofia Ágil.

508 visualizações

Publicada em

Apresentação realizada em um encontro do GDG - Google Developers Group (16/05), sobre Scrum e a filosofia ágil. Lançamos também neste dia a versão open-beta de nossa plataforma aberta à comunidade de gestão de projetos, o Jaked (http://jaked.ninja).

1 comentário
3 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
508
No SlideShare
0
A partir de incorporações
0
Número de incorporações
8
Ações
Compartilhamentos
0
Downloads
12
Comentários
1
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Fazendo acontecer com Scrum e a Filosofia Ágil.

  1. 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. 2. Great companies are built, not launched.
  3. 3. 1. O que temos feito 3
  4. 4. 4
  5. 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. 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. 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. 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. 9 E extrapolam seu prazo em: https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think/
  10. 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. 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. 12 Falham. http://www.mckinsey.com/insights/business_technology/delivering_large- scale_it_projects_on_time_on_budget_and_on_value
  13. 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. 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. 15. 2. Scrum 15
  16. 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. 17 Resumo
  18. 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. 19 Fuck it. Ship it.
  20. 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. 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. 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. 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. 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. 25. 3. Novo fluxo de trabalho 25
  26. 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. 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. 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. 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. 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. 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. 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. 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. 34. 4. Conclusão (and a grain of salt) 34
  35. 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. 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. 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. 38. Conclusão 38 Grandes poderes, Grandes responsabilidades. PARKER, Benjamin (Tio Ben)
  39. 39. Conclusão 39 Como você deve imaginar...
  40. 40. Conclusão 40 O resto é com vocês!
  41. 41. Obrigado! 41

×