Caminhos do Scrum

1.031 visualizações

Publicada em

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

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

Nenhuma nota no slide

Caminhos do Scrum

  1. 1. SCRUM Caminhos do Por Jonas Beto Rompkovski [email_address]
  2. 2. <ul><li>Problemas </li></ul><ul><li>Agillidade </li></ul><ul><li>Papéis do Scrum </li></ul><ul><li>Processo do Scrum </li></ul><ul><li>Resultados </li></ul>
  3. 3. PROBLEMAS <ul><li>Com desenvolvimento tradicional de software </li></ul>
  4. 4. Tradicional <ul><li>Desenvolvimento em Fases </li></ul><ul><li>Resultados Antecipados </li></ul><ul><li>Alto valor do Planejamento </li></ul><ul><li>Pouca Visibilidade </li></ul>
  5. 5. Requisitos não são claros <ul><li>Medo de ir para próxima fase </li></ul><ul><li>Paralisia da Análise (Analysis paralysis) </li></ul>
  6. 6. Mudança nos Requisitos <ul><li>Mudanças se tornam mais e mais caras... </li></ul><ul><li>Clientes não sabem o que querem... </li></ul>
  7. 7. Projetos demoram muito <ul><li>SUCESSO em apenas 34% dos projetos entregues </li></ul><ul><li>Longa duração ADIA retorno financeiro para empresa </li></ul><ul><li>Fonte: Standish Report 2003 </li></ul>
  8. 8. Não há tempo para testes <ul><li>Garantia de Qualidade é Reduzida </li></ul><ul><li>Integração tardia significa falhas mais tarde </li></ul>
  9. 9. Tempo jogado no LIXO <ul><li>52% dos requisitos entregues </li></ul><ul><li>64% das funcionalidades são raramente usadas </li></ul><ul><li>Fonte: Standish Report 2003 </li></ul>
  10. 10. Ágil <ul><li>Desenvolvimento </li></ul>De Software
  11. 11. Valores do Manifesto Ágil <ul><li>Indivíduos e interações , ao invés de processos e ferramentas; </li></ul><ul><li>Software funcional , ao invés de documentação compreensiva; </li></ul><ul><li>Colaboração do cliente , ao invés de negociação de contrato; </li></ul><ul><li>Resposta a mudanças , ao invés de seguir um plano. </li></ul>
  12. 12. Princípios do Manifesto Ágil <ul><li>Nossa maior prioridade é satisfazer o cliente através de entregas rápidas e contínuas de software usual. </li></ul><ul><li>Seja bem-vindo à mudança de requisitos, mesmo que tarde no desenvolvimento. Processos ágeis aproveitam a mudança para a vantagem competitiva do cliente. </li></ul><ul><li>Entregar software utilizável frequentemente, de algumas semanas a alguns meses, com preferência a menores escalas de tempo. </li></ul><ul><li>Executivos e desenvolvedores devem trabalhar juntos diariamente durante o projeto. </li></ul>
  13. 13. Princípios do Manifesto Ágil <ul><li>Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e a ajuda que eles precisam e confie neles para ter o trabalho concluído. </li></ul><ul><li>O método mais eficiente e eficaz de transmitir informações para uma equipe de desenvolvimento e dentro dela é conversa face-a-face. </li></ul><ul><li>Software funcional é a medida primordial do progresso. </li></ul><ul><li>Processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários deveriam ser aptos a manter um ritmo constante indefinidamente. </li></ul>
  14. 14. Princípios do Manifesto Ágil <ul><li>Atenção contínua à excelência técnica e bom design aumenta a agilidade. </li></ul><ul><li>Simplicidade – a arte de maximizar a quantidade de trabalho não feito – é essencial. </li></ul><ul><li>As melhores arquiteturas, requisitos e design surgem de um time auto-organizado. </li></ul><ul><li>Em intervalos regulares, o time reflete em como tornar-se mais eficiente, então sintoniza e ajusta seu comportamento. </li></ul>
  15. 15. SCRUM
  16. 16. Objetivo <ul><li>Entregar software funcional e de alto valor agregado para o cliente o mais rápido possível </li></ul>
  17. 17. Papéis
  18. 18. Product Owner Dono da Visão do Projeto Representa o Cliente
  19. 19. Product Owner <ul><li>Define funcionalidades </li></ul><ul><li>Prioriza as funcionalidade </li></ul><ul><li>Escolhe datas de lançamento </li></ul><ul><li>Dá Feedback </li></ul><ul><li>Gerencia as partes interessadas </li></ul><ul><li>Aceita ou Rejeita resultados </li></ul>
  20. 20. TEAM <ul><li>Pequeno </li></ul><ul><li>5-9 pessoas </li></ul><ul><li>Auto-organizado </li></ul><ul><li>Multi-disciplinar </li></ul><ul><li>Dedicado </li></ul>
  21. 21. TEAM <ul><li>Define as tarefas </li></ul><ul><li>Estima o Esforço </li></ul><ul><li>Desenvolve o produto </li></ul><ul><li>Garante a Qualidade </li></ul><ul><li>Segrega os Processos </li></ul>
  22. 22. SCRUM MASTER <ul><li>Líder Servidor </li></ul><ul><li>Protetor do Time </li></ul><ul><li>Quebra-galho </li></ul><ul><li>Guia Scrum </li></ul>
  23. 23. SCRUM MASTER <ul><li>Remove Impedimentos </li></ul><ul><li>Previne Interrupções </li></ul><ul><li>Facilitador do Time </li></ul><ul><li>Suporta o Processo </li></ul><ul><li>Faz a Gestão </li></ul>
  24. 24. Dream Pig Team Product Owner Scrum Master Membros do Time Usuários Gerentes Vendas X
  25. 25. Processo Scrum
  26. 26. Product Backlog Expressa Valor Adia decisões precipitadas
  27. 27. Product Backlog
  28. 28. Pr oduct Backlog Propriedade do Product Owner Requisitos de alto nível Expressa o valor de negócio Não completo, não perfeito Espera-se que mude e evolua Visão limitada para o recurso
  29. 29. Product Backlog Item de BackLog: Número sequencial a ser adicionado na linha após a criação do Sprint Backlog Título do Baygon(s): caso o baygon seja relacionado com mais de um baygon, inserir o número e título dos outros baygons nesta coluna. Tema ou Módulo ou Sistema para o qual o Baygon se refere. Sprint ao qual o baygon será atendido Benefício de se ter a funcionalidade Penalidade de não se ter a funcionalidade entregue Valor de Negócio = Soma dos Benefícios e das Penalidades O Valor de Negócio é divido pela Estimativa (dificuldade / complexidade para se entregar aquela determinada funcionalidade), resultando no Benefício Relativo.
  30. 30. Estórias do Usuário Como um papel [usuário final], eu quero [a vontade] para que [a razão]
  31. 31. Sprints Time Box – Recursos Congelados Escopo Variável – Software Funcionando
  32. 32. Sprint Planning Capacidade do Time, Product Backlog, Produto Atual, Negócio, Tecnologias + = GOAL - OBJETIVO
  33. 33. Sprint Planning Comunicação Face a Face Pequenos Passos Reversíveis Perspectiva do Usuário
  34. 34. Sprint Planning 1 Planejamento de Nível Estratégico Prioriza e seleciona as funcionalidades Discute os Critérios de Aceitação Tira dúvidas 1/2 – 1 hora por Sprint
  35. 35. Sprint Planning 2 Planejamento de Nível Tático Define os itens do Sprint Backlog Estima-se os itens do Sprint Backlog Velocidade do Sprint (baseado no anterior) Comprometimento entre as partes 1/2 – 1 hora por Sprint
  36. 36. Sprint Backlog Repartição do Valor de Negócio em Tarefas Atribuíveis
  37. 37. Sprint Backlog
  38. 38. Sprint Backlog Propriedade da Equipe Aloca trabalho ao Time Sem adições de outros
  39. 39. Daily Scrum O coração do Scrum
  40. 40. D aily Sc rum Compromisso e Responsabilidade Fala-se: O que fiz, o que vou fazer e quais dificuldades estou sentindo
  41. 41. D aily Sc rum O que eu fiz desde a última reunião? O que vou fazer até a próxima? Que coisas estão atrapalhando meu trabalho? Todos podem participar Apenas o Time fala Não se resolvem problemas Máximo de 15 minutos De pé
  42. 42. Quadro de Tarefas Detalhes: http:// blogdojonas .com. br / blog /?p=915
  43. 43. Definição de Evitar síndrome dos 90% Codificado, Comitado, Testado, Publicado em Ambiente de Testes, documentado e funcionando = DONE DONE
  44. 44. Sprint Burn Down
  45. 45. Sprint Review Satisfação do Product Owner Feedback do Produto
  46. 46. Sprint Review Informal, nada de slides Todo o time participa O mundo é convidado
  47. 47. Sprint Review Necessária preparação Mostrar funcionalidades prontas Aceitação ou Rejeição dos Resultados 1 – 2 horas por Sprint
  48. 48. Retrospectiva Evolução do Processo
  49. 49. Retrospectiva Reflexo do processo e do produto Todos do Time Participam
  50. 50. Retrospectiva
  51. 51. Sprints Foco no valor de negócio Inspeção e Adaptação
  52. 52. Sprints Dirigido pelo Product Owner Passos pequenos reversíveis Bem vindo à mudança Time multi-funcional Inclue projeto e testes Passos constantes Compromisso entre as partes Qualidade Alta, DONE Feedback “ Fail Fast”
  53. 53. Resultados Efeitos da Aplicação do Scrum
  54. 54. Gestão Planejamento Sucessivo e Constante Mini-projetos de baixo risco
  55. 55. Escopo Flexível Permite mudanças em intervalos fixos Aprendizagem a cada liberação
  56. 56. Entrega Rápida Time to Market Valor entregue de forma incremental
  57. 57. Maior Qualidade Testes acontecem continuamente Melhoria do Processo
  58. 58. Maior Visibilidade Os problemas são visíveis Progresso visto a cada teste de software
  59. 59. Times mais felizes e divertidos!
  60. 60. Pré-condições Força Disciplina Coragem Vigor Paixão Coaching Times Estáveis Multi-funcional Cliente disponível
  61. 61. Renúncia Não há práticas de Engenharia Parece simples É difícil Bala de Prata Não está completo Leva tempo
  62. 62. Dúvidas?
  63. 63. Tradução e Adaptação The Zen of Scrum http://www.slideshare.net/jurgenappelo/the-zen-of-scrum-10 Jurgen Appelo
  64. 64. Sobre o Palestrante Blog do Jonas blogdojonas.com.br Currículo curriculodojonas.blogger.com Twitter @jonastlc E-Mail [email_address]

×