Circuito de Treinamentos ADDTECH
www.addtech.com.br | 2016.1
Scrum com Práticas Ágeis e Design Thinking
Apresentação
NEGÓCIOS
Design Estratégico
GESTÃO
Ágil e Lean
TECNOLOGIA
Planejamento de
Sistemas
Desenho de
Processos
Planejamento
Estra...
Wagner Pontes Líder do Delivery de Projetos Lean
e Ágil na ADDTECH, Certificado
International Scrum Master,
International ...
Timebox
•02 encontros (cerimônias)
•SCRUM/Ágil – 4 horas
•18:00 – 22:00
•SCRUM/Ágil – 4 horas
•18:00 – 22:00
Visão de pronto
•Definir o que é o Scrum e a teoria empírica.
•Ter a visão do Scrum através dos seus valores, princípios e...
Prática
Imersão
Temos dúvida do tempo e custo
Falhamos na comunicação
Não entregamos valor
Falhamos em projetos
Desperdício de trabalho
Insatisfação do cliente
Solução
Qual a solução ?
Cliente x TIME
Abordagens ágeis
Scrum
Fundamentos
Scrum é um framework para desenvolver e manter
produtos complexos.
Um framework dentro do qual pessoas podem
tratar e reso...
Manisfesto
Ágil
O Scrum é utilizado em Gestão de Projetos.
As raízes do Scrum
Artigo intitulado
“The New New Product Development Game”
na conceituada revista Harvard Business Review...
Histórico
Desenvolveram o Scrum. O Guia do
Scrum é escrito e fornecido por eles.
Jogada rugby (Scrum)
Usada em jogada irregular ou penalidade
Teorias empíricas
Empirismo
• Conhecimento vem da
experiência e de tomada de
decisão ;
• Baseado no que é conhecido ;
• Vi...
Pilaresdo Scrum
Pilaresdo Scrum
Pilaresdo Scrum
Scrum
Valores
Valores
Scrum
Comprometimento
Coragem
FocoTransparência
Respeito
Quando esses valores
são assumidos e
vividos pelo Time
Sc...
Scrum
Manifesto Ágil
Manisfesto
Ágil
Manisfesto
Ágil
TIME Scrum
Scrum Master • Encontra técnicas para
gerenciamento do backlog do
produto ;
• Comunica Visão, objetivo e itens
de backlog ...
Product Owner
• Gerencia o backlog do produto ;
• Ordena itens de backlog ;
• Garante o valor do trabalho
realizado pelo T...
Time Dev
• Auto-organizados ;
• Multifuncionais ;
• Não possui títulos. Somente
Dev;
• A responsabilidade é do TIME ;
• Nã...
Dinâmica
Construção de TIMES
Combinação de habilidades
Scrum Master
Nome do TIME / Diária
C O que será praticado :
Scrum
Eventos
Visão Geral do SCRUM
3.2. O time trata como
transformar o backlog
em incremento de
produto: decompõe as
tarefas e se auto
...
Scrum
Visão do produto
Visão do Produto
Uma visão é uma clara imagem que gera uma
atração emocional entre pessoas e produto.
O que é o Produto? X...
Visão do Produto
Uma visão efetiva deve responder às seguintes perguntas:
Quem irá comprar este Produto? Quem é o cliente ...
Product Roadmap
O sucesso de um projeto SCRUM é determinado pela Visão. Se
foi atingida ou não. Mesmo que não cumpra todo ...
Visão do produto
Scrum
Backlog do produto
Product Backlog
PRODUCT
BACKLOG
MEIO
VISÃO DO
PRODUTO
FIM
Podem ser inseridos
itens técnicos a
pedido da equipe
O Product
...
Product Backlog – stories, temas e epics
EPIC
STORY STORY STORY
STORY STORY STORY
STORY STORY
TEMA
Podem ser entregues
ind...
Product Backlog - Iceberg
SPRINT ATUAL
RELEASE
PRÓXIMA RELEASE
+ PRIORIDADE + DETALHADO
- DETALHADO
Mínimo Viável do Produto
Estratégia para validar seu produto ou modelo de negócio.
Uma ideia somente vale algo quando levo...
Mínimo Viável do Produto
Dinâmica
Visão do produto
Definição do PO
Construção da Visão
Construção do Backlog do produto inicial
C O que será pratic...
Scrum
Plano de Entrega
Scrum
Product Backlog
Priorização e Valor
Engenharia de valor : É uma abordagem utilizada
para atingir um ótimo valor do produto com o menor
custo possível. Isto si...
Product Backlog – Priorização
Priorização requer a decisão do quão importante é um item do Product
Backlog. Se tudo é prio...
Product Backlog – Técnicas de Priorização
KANO: Composta por entrevistas com os
usuários e opiniões de experts.
Theme Scre...
Product Backlog – KANO
Uma das técnicas mais interessantes de priorização é a KANO MODEL, nela você
classifica as funciona...
Product Backlog – Theme Screening
Você deve selecionar entre 5 a 9 critérios
(aproximadamente) para avaliar o que é
mais i...
Product Backlog – Priorização de Valor
Grooming do Product Backlog
 Significa PREPARAR.... Outros
significados : Cuidar da aparência,
manter limpo e arrumado.
...
Dinâmica
Product Backlog
Priorização PB
Valor, Domínio e Simplex
C O que será praticado :
Scrum
Product Backlog
Estimativa (Relativa)
Backlog
Estimativa Relativa
Scrum
Plano de entrega
Planejamento – Resultado do planejamento
SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 - 6
Menos precisão
Scrum
Backlog do Sprint
Planejamento do Sprint
Detalhamento das estórias
Quebra de tarefas
Estimativa da estórias – Backlog Sprint
Tarefas + Pontos e estória
Scrum
Uso do Kanban
Kanban
Impedimento
Dinâmica
Kanban
Quebra tarefas
Melhoria
Impedimento
C O que será praticado :
Scrum
Artefatos
Artefatos do Scrum
Basilares
Backlog do
produto
Backlog do
Sprint
DoD
Apoio
(Não oficial)
Estórias
Burndown
Kanban
Visão de pronto (DoD)
• Definition of Done
como “DoD”.
• A DoD é um acordo
formal do TIME
Scrum que define
claramente quai...
Scrum
Review e Retrospectiva
Reunião de revisão de sprint • A equipe
apresenta o que foi
produzido para o
PO ;
• Duração de 1 a 4
horas ;
• Apresenta
i...
Reunião de retrospectiva • Duração de 2 a 3
horas ;
• Inspecionar a
última Sprint e
relações entre
pessoas.
• Identificar ...
Dinâmica
Retrospectiva
Dinâmica
Melhoria
C O que será praticado :
Próximos SlideShares
Carregando em…5
×

Treinamento de Scrum com Praticas Ágeis e Design thinking

75 visualizações

Publicada em

#Addtech #Gestão Ágil

Publicada em: Internet
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
75
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Treinamento de Scrum com Praticas Ágeis e Design thinking

  1. 1. Circuito de Treinamentos ADDTECH www.addtech.com.br | 2016.1 Scrum com Práticas Ágeis e Design Thinking
  2. 2. Apresentação
  3. 3. NEGÓCIOS Design Estratégico GESTÃO Ágil e Lean TECNOLOGIA Planejamento de Sistemas Desenho de Processos Planejamento Estratégico Gestão do Desenvolvimento de Sistemas Mentoring em Processos de Gestão Sustentação de Serviços e Sistemas OUTSOURCING CONSULTORIA Mobile (iOS, Android e Windows) Sharepoint e .NET SOA ARIS (Software AG)
  4. 4. Wagner Pontes Líder do Delivery de Projetos Lean e Ágil na ADDTECH, Certificado International Scrum Master, International Product Owner, Inovação e Tecnologia pelo Sebrae. Formado em Tecnologia da informação e especialista em gestão de projetos baseados em Agile Thinking, Lean Thinking, Design Thinking, PNL e TCC. Possui mais de 20 anos no mercado de tecnologia da informação e gestão de projetos tendo trabalho em diversos clientes tais como: SulAmérica, Seguradora Líder DPVAT, Mongeral, ONS, Natura, Prefeitura do Rio de Janeiro, Secretaria de Segurança do Rio de Janeiro e outros.
  5. 5. Timebox •02 encontros (cerimônias) •SCRUM/Ágil – 4 horas •18:00 – 22:00 •SCRUM/Ágil – 4 horas •18:00 – 22:00
  6. 6. Visão de pronto •Definir o que é o Scrum e a teoria empírica. •Ter a visão do Scrum através dos seus valores, princípios e pilares. •Entender o Ciclo de vida Ágil através do Scrum. •Conhecer papéis, regras, eventos e artefatos do Scrum. •Conhecer técnicas de priorização, MVP e plano de entrega. •Decomposição de itens de backlog e estimativas relativa. •Conhecer o uso do Kanban. •Entender o comportamento de um TIME Ágil. •Conhecer casos práticos do uso do Scrum.
  7. 7. Prática
  8. 8. Imersão
  9. 9. Temos dúvida do tempo e custo
  10. 10. Falhamos na comunicação
  11. 11. Não entregamos valor
  12. 12. Falhamos em projetos
  13. 13. Desperdício de trabalho
  14. 14. Insatisfação do cliente
  15. 15. Solução
  16. 16. Qual a solução ?
  17. 17. Cliente x TIME
  18. 18. Abordagens ágeis
  19. 19. Scrum Fundamentos
  20. 20. Scrum é um framework para desenvolver e manter produtos complexos. Um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. Leve Simples de manter Difícil de dominar O queé Scrum
  21. 21. Manisfesto Ágil O Scrum é utilizado em Gestão de Projetos.
  22. 22. As raízes do Scrum Artigo intitulado “The New New Product Development Game” na conceituada revista Harvard Business Review Takeuchi e Nonaka Iterativo e incremental Timebox
  23. 23. Histórico Desenvolveram o Scrum. O Guia do Scrum é escrito e fornecido por eles.
  24. 24. Jogada rugby (Scrum) Usada em jogada irregular ou penalidade
  25. 25. Teorias empíricas Empirismo • Conhecimento vem da experiência e de tomada de decisão ; • Baseado no que é conhecido ; • Visão ; • Termina quando as metas forem alcançadas;
  26. 26. Pilaresdo Scrum
  27. 27. Pilaresdo Scrum
  28. 28. Pilaresdo Scrum
  29. 29. Scrum Valores
  30. 30. Valores Scrum Comprometimento Coragem FocoTransparência Respeito Quando esses valores são assumidos e vividos pelo Time Scrum, os pilares do Scrum de transparência, inspeção e adaptação tornam-se vivos e constroem a confiança para todos.
  31. 31. Scrum Manifesto Ágil
  32. 32. Manisfesto Ágil
  33. 33. Manisfesto Ágil
  34. 34. TIME Scrum
  35. 35. Scrum Master • Encontra técnicas para gerenciamento do backlog do produto ; • Comunica Visão, objetivo e itens de backlog para o TIME Dev. • Ensina o TIME Scrum a criar itens de backlog ; • Facilita os eventos Scrum ; • Treina o TIME Dev no Framework ; • Remove impedimentos ; • Ensina o que é valor ; • Planeja a implementação do Scrum na organização. Responsável por garantir que o Scrum seja entendido e aplicado.
  36. 36. Product Owner • Gerencia o backlog do produto ; • Ordena itens de backlog ; • Garante o valor do trabalho realizado pelo TIME Dev ; • Garante que o Backlog do produto seja visível, transparente e deixa claro o que o TIME Dev trabalhará ; • O PO pode delegar o trabalho acima para o TIME Dev ; • É uma pessoa e não um comitê. • A organização deve respeitar as decisões do PO ; • O TIME Dev deve agir baseado somente no que o PO informa. Responsável por maximizar o valor do produto e do trabalho do Time de Dev.
  37. 37. Time Dev • Auto-organizados ; • Multifuncionais ; • Não possui títulos. Somente Dev; • A responsabilidade é do TIME ; • Não possui sub-times. Ex : Teste ou analise de negócio. Consiste de profissionais que realizam o trabalho de entregar uma versão usável que incrementa o produto. • Pequenos para se manter ágeis ; • Entre 3 e 9 integrantes ;
  38. 38. Dinâmica Construção de TIMES Combinação de habilidades Scrum Master Nome do TIME / Diária C O que será praticado :
  39. 39. Scrum Eventos
  40. 40. Visão Geral do SCRUM 3.2. O time trata como transformar o backlog em incremento de produto: decompõe as tarefas e se auto organiza. 3.1. O time trata o quê deverá ser desenvolvido na próxima Sprint a partir da prioridade dos itens informada pelo Product Owner. 1. O Product Owner define a visão do produto, que representa a sua necessidade, o que deve ser satisfeito ao fim do projeto. 2. O Product Owner cria uma lista inicial de necessidades priorizadas que precisam ser produzidas para que a visão seja atingida. 4. Contém os itens selecionados, suas respectivas tarefas e a meta da Sprint. 5.2. Durante a execução da Sprint, o Scrum Master com sua capacidade de liderança e colaboração, facilita o trabalho removendo impedimentos e garantindo a boa aplicação do SCRUM. 5.1. Reunião de 15m em que cada membro deve responder o que fez desde a última reunião, o que pretende até a próxima e se há algum impedimento. 6. O Product Owner aceita ou rejeita o que foi feito. O grupo inteiro colabora com o que viu do produto e fornece inputs de valor para as próximas reuniões de planejamento de Sprint. 7. Reunião de inspeção / adaptação do SCRUM. Os membros do time são convidados a escrever post its citando os pontos que acreditam que foram bons nesta Sprint e quais deveriam ser melhorados.
  41. 41. Scrum Visão do produto
  42. 42. Visão do Produto Uma visão é uma clara imagem que gera uma atração emocional entre pessoas e produto. O que é o Produto? X Como é o Produto? Garantir o alinhamento da equipe O Product Owner é o responsável pela criação da visão Ele compartilha essa visão com o time Ele refina essa visão com o time
  43. 43. Visão do Produto Uma visão efetiva deve responder às seguintes perguntas: Quem irá comprar este Produto? Quem é o cliente alvo? Quem irá usar o produto? Quem são os usuários alvo? Quais “dores” do cliente (ou usuários) o produto pretende aliviar? Qual valor o produto adicionará? Quais atributos (grandes pedaços) o produto precisa possuir para aliviar estas “dores” e quais garantirão o sucesso do produto? Como o produto pode ser comparado a produtos ou alternativas existentes? Quais são os pontos diferenciais deste produto? (se aplicável) Qual será o preço alvo do produto? Como a empresa pretende ganhar dinheiro com este produto? Quais serão as fontes de faturamento e qual seu modelo de negócio?
  44. 44. Product Roadmap O sucesso de um projeto SCRUM é determinado pela Visão. Se foi atingida ou não. Mesmo que não cumpra todo o escopo. Modelo Watterfall: Primeiro define-se o escopo. Para então determinar o tempo e o budget.  Modelo aplicável para a engenharia, mas não para a TI;  TI não deveria vender empreitada, mas solução de problemas;  Em um ambiente de constantes mudanças, é necessário manter o foco na geração de valor. Métodos Ágeis: Primeiro define-se o tempo e o budget. Para então determinar o escopo.  Para determinar o tempo e o budget deve se considerar:  A Visão do Produto;  As limitações orçamentárias;  Aspectos mercadológicos;  A estratégia da área de negócio.  Projetos SCRUM nunca atrasam ou estouram orçamento se o método for corretamente aplicado.
  45. 45. Visão do produto
  46. 46. Scrum Backlog do produto
  47. 47. Product Backlog PRODUCT BACKLOG MEIO VISÃO DO PRODUTO FIM Podem ser inseridos itens técnicos a pedido da equipe O Product Backlog existe para alcançar a visão! Lista de funcionalidades, necessidades, desejos, ... Emergentes, priorizados e estimados. Mais detalhes nos itens do topo. Uma única lista para múltiplos times. Product Owner é o responsável por sua priorização. Todos podem contribuir. Mantido e postado visivelmente. Derivado de um Plano de Negócios ou de uma Visão de Produto. Pode ser escrito no formato de sua preferência: user stories, use cases...
  48. 48. Product Backlog – stories, temas e epics EPIC STORY STORY STORY STORY STORY STORY STORY STORY TEMA Podem ser entregues individualmente Fazer sentido como grupo pós refinamento Uma estória muito grande Para estórias de cadastro, fatiar por operações (inserir, alterar etc); Por opções de busca; Produtos com muitas dependências com outros produtos/integrações. Dividir a estória por time: em coisas menores; Os critérios de aceitação, se muito grande, podem virar uma estória Divide por plataforma (mobile/desktop/etc); Dividi por variação de interface (ex: imposto de renda simples/completo). DICAS PARA FATIAR
  49. 49. Product Backlog - Iceberg SPRINT ATUAL RELEASE PRÓXIMA RELEASE + PRIORIDADE + DETALHADO - DETALHADO
  50. 50. Mínimo Viável do Produto Estratégia para validar seu produto ou modelo de negócio. Uma ideia somente vale algo quando levo para o mercado, tem aceitação e alguém paga por isto... Produto feito no menor custo possível Não precisa estar 100% Ter feedback rápido Aprender com o cliente Ver se tem aceitação pelo mercado Iterativo
  51. 51. Mínimo Viável do Produto
  52. 52. Dinâmica Visão do produto Definição do PO Construção da Visão Construção do Backlog do produto inicial C O que será praticado :
  53. 53. Scrum Plano de Entrega
  54. 54. Scrum Product Backlog Priorização e Valor
  55. 55. Engenharia de valor : É uma abordagem utilizada para atingir um ótimo valor do produto com o menor custo possível. Isto significa produzir um produto com a mesma qualidade e características, porém a com custo mais baixo. O requisito é importante ? Podemos implementar de forma diferente ? Podemos substituir o requisito por outro ? A metodologia é a mais aplicada para a situação ? Nosso processo de qualidade esta adequado ? Valor
  56. 56. Product Backlog – Priorização Priorização requer a decisão do quão importante é um item do Product Backlog. Se tudo é prioritário, significa que na verdade nada é prioritário; A priorização por temas deve ser considerada visto que muitas vezes uma estória não pode ser priorizada sem as outras; Por mais que boas estórias devam ser independentes (I de INVEST), quando falamos em valor do negócio elas normalmente se complementam. Valor: um item de Product Backlog é valioso se é necessário para que o produto seja lançado. Conhecimento, incerteza e risco: como esses itens influenciam o sucesso do produto, eles devem ser sempre considerados como de alta prioridade. Capacidade para lançamento (Releasability): itens que nos permitam mais rapidamente lançar um Release do produto devem possuir boa prioridade. Dependência: gostemos ou não, dependência de itens em um Product Backlog é um fato, e deve ser considerada na priorização dos itens.
  57. 57. Product Backlog – Técnicas de Priorização KANO: Composta por entrevistas com os usuários e opiniões de experts. Theme Screening: Composta apenas por opiniões de experts baseadas em comparações realizadas com um tema importante Priorização por Valor: Permite que envolvidos comparem através de valor + domínio + simplicidade.
  58. 58. Product Backlog – KANO Uma das técnicas mais interessantes de priorização é a KANO MODEL, nela você classifica as funcionalidades em três principais tipos: EMPOLGANTES: Funcionalidades que o usuário acredita desejar, mas não tem certeza se seu custo-benefício compensa. (Inovadoras/diferenciais). PERFORMÁTICAS: Quando mais destas tiver, melhor. Não chega a ser um diferencial. MANDATÓRIAS: Deve estar presente para que o cliente esteja satisfeito. Realizar as perguntas direcionadas para um grupo de 10 a 30 usuários de perfis variados. Realizar uma pergunta funcional: Como você se sentirá se a funcionalidade estiver presente? Realiza uma pergunta disfuncional: Como você se sentirá se a funcionalidade estiver ausente? Para saber se uma funcionalidade é desejada, linear ou mandatória você deve:
  59. 59. Product Backlog – Theme Screening Você deve selecionar entre 5 a 9 critérios (aproximadamente) para avaliar o que é mais importante para o próximo sprint; Selecione um tema que servirá como base para os fatores de comparação; Um tema que seja visualizado como algo que deveria entrar no próximo sprint; Um tema que seja do conhecimento de grande parte do time; Compare cada tema candidato com o tema base.
  60. 60. Product Backlog – Priorização de Valor
  61. 61. Grooming do Product Backlog  Significa PREPARAR.... Outros significados : Cuidar da aparência, manter limpo e arrumado.  Responsabilidade do PO ;  Quem pode participar : PO, Scrum Master e TIME Dev ;  Tem que ter Timebox ;  As atividade de criar e de refinar os itens do product backlog, estimando o tamanho e esforço de cada item, é chamada de Grooming.
  62. 62. Dinâmica Product Backlog Priorização PB Valor, Domínio e Simplex C O que será praticado :
  63. 63. Scrum Product Backlog Estimativa (Relativa)
  64. 64. Backlog Estimativa Relativa
  65. 65. Scrum Plano de entrega
  66. 66. Planejamento – Resultado do planejamento SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 - 6 Menos precisão
  67. 67. Scrum Backlog do Sprint
  68. 68. Planejamento do Sprint
  69. 69. Detalhamento das estórias
  70. 70. Quebra de tarefas
  71. 71. Estimativa da estórias – Backlog Sprint
  72. 72. Tarefas + Pontos e estória
  73. 73. Scrum Uso do Kanban
  74. 74. Kanban
  75. 75. Impedimento
  76. 76. Dinâmica Kanban Quebra tarefas Melhoria Impedimento C O que será praticado :
  77. 77. Scrum Artefatos
  78. 78. Artefatos do Scrum Basilares Backlog do produto Backlog do Sprint DoD Apoio (Não oficial) Estórias Burndown Kanban
  79. 79. Visão de pronto (DoD) • Definition of Done como “DoD”. • A DoD é um acordo formal do TIME Scrum que define claramente quais são os passos mínimos para a conclusão de um item potencialmente entregável.
  80. 80. Scrum Review e Retrospectiva
  81. 81. Reunião de revisão de sprint • A equipe apresenta o que foi produzido para o PO ; • Duração de 1 a 4 horas ; • Apresenta informações valiosas para os próximos sprints ;
  82. 82. Reunião de retrospectiva • Duração de 2 a 3 horas ; • Inspecionar a última Sprint e relações entre pessoas. • Identificar pontos de melhorias;
  83. 83. Dinâmica Retrospectiva Dinâmica Melhoria C O que será praticado :

×