Palestra scrum

1.304 visualizações

Publicada em

Palestra sobre Metodologias Ágeis focado em Scrum no evento do Prodap de Macapá - AP.

Publicada em: Tecnologia, Negócios
0 comentários
2 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.304
No SlideShare
0
A partir de incorporações
0
Número de incorporações
28
Ações
Compartilhamentos
0
Downloads
45
Comentários
0
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Palestra scrum

  1. 1. Metodologias Ágeis e o  SCRUM  [“Thinking Different”]  Paulo Igor  piagodinho@gmail.com  @pigodinho  hDp://blog.pigor.net 
  2. 2. Um pouco sobre mim...  •  Bacharel em Sistemas de Informação pelo CESUPA  •  Mestre em Ciência da Computação pela UFPA  •  ScrumMaster CerPfied (2008)  •  Analista Especialista e Arquiteto de SoXware  –  Cobra Tecnologia S.A. (ScrumMaster ‐ Piloto)  –  Pródiga Sistemas (Líder Técnico / ScrumMaster)  •  Professor de Pós‐graduação do CESUPA  •  Membro aPvo de comunidades regionais e nacionais  –  Beljug, TáSafo, Dojo‐Pa (Fundador), Scrum‐PA, ... 
  3. 3. Meus Contatos  •  piagodinho@gmail.com  •  pigodinho (TwiDer)  •  hDp://blog.pigor.net 
  4. 4. A essência dos Projetos  Conceitos 
  5. 5. O que é um projeto?  Quais são as suas caracterísicas? 
  6. 6. ...projeto é um esforço temporário  para criar um serviço, ou produto,  ou resultado exclusivo. 
  7. 7. Projetos são... 
  8. 8. Temporários 
  9. 9. Temporários 
  10. 10. Planejados, Executados e Controlados 
  11. 11. Entregam produto, serviço, ou  resultado exclusivo 
  12. 12. Desenvolvido em  etapas 
  13. 13. Realizado por pessoas 
  14. 14. Com recursos limitados 
  15. 15. Metodologias Ágeis  Scrum, XP, FDD, Lean, ... 
  16. 16. Já ouviu falar? 
  17. 17. Chaos Report 
  18. 18. Chaos Report  •  Segundo o Standish Group os principais  fatores são:  –  Falta de clareza sobre funções pessoais,  responsabilidades e requisitos.  –  Falta de habilidade para acompanhar os passos do  ciclo de vida da aplicação. 
  19. 19. Uso das funcionalidades 
  20. 20. 80% das funcionalidades  desenvolvidas NÃO serão usadas 
  21. 21. 80% de DESPERDÍCIO 
  22. 22. O cliente fica saPsfeito? 
  23. 23. Início dos conflitos... 
  24. 24. Falhas na Comunicação 
  25. 25. Resumindo...  •  A comunicação entre as partes envolvidas nos  projetos é muito fraca;  •  A visibilidade do andamento real e dos  problemas existentes nos projetos é muito fraca;  •  Clientes pedem sempre mais do que realmente  precisam;  •  Os projetos são caros e, ainda em sua maioria,  não alcançam sucesso;  •  Os conflitos existentes entre TI e negócios  durante os projetos são muitos; 
  26. 26. O Problema do Cliente  •  Clientes sabem que fornecedores odeiam  mudanças de requisitos;  •  Clientes são “forçados” a definir tudo que  precisam na fase inicial do projeto;  •  Clientes no início de um projeto estão  inseguros quanto ao que precisam; 
  27. 27. A solução do Cliente  •  Colocar o máximo possível de requisitos na  lista inicial;  •  Entende‐se por “o máximo possível” tudo que  lhe vier à cabeça naquele momento;  •  Desta forma a possibilidade de “faltar”  requisitos no produto final é menor; 
  28. 28. O Problema do Fornecedor  •  Fornecedores sabem que os requisitos  fornecidos pelo cliente são vagos;  •  Fornecedores sabem que no decorrer do  projeto o cliente precisará mudar os  requisitos;  •  Fornecedores sabem que sempre ao validar o  produto o cliente surgirão novas idéias para o  produto; 
  29. 29. A solução do Fornecedor  •  Documentar ao máximo tudo que foi passado  pelo cliente para que o fornecedor possa estar  protegido;  •  Colocar margens de tempo por todo o projeto;  •  Entregar o produto para o cliente apenas no  final do projeto; 
  30. 30. Resultado  Quem mais perde?  Conflito entre as partes!  A EMPRESA 
  31. 31. A “solução”  Qualidade e  ProduPvidade  Pessoas 
  32. 32. ...ignorou a cultura! 
  33. 33. Tradicional X Ágil 
  34. 34. Análise Tradicional 
  35. 35. Big Design Up Front 
  36. 36. Cascata 
  37. 37. Pobre Winston Royce!!! 
  38. 38. Por que não da certo? 
  39. 39. Por que não se faz soXware assim!!! 
  40. 40. Tradicional (Cascata)  •  Orientado a  documentação  •  Feedback no final do  projeto  •  Mudanças são  prejudiciais 
  41. 41. Ágil  •  Desenvolve‐se em ciclos pequenos  –  Aprende‐se do negócio e da solução  iteraPvamente  •  Ataca os riscos do projeto mais rapidamente  •  As mudanças não são tão problemáPcas  •  O cliente da feedback durante todo o projeto 
  42. 42. Mundo Real ≠ Mundo Digital 
  43. 43. Pede pra fazer uma alteração brusca  no meio da construção de um prédio 
  44. 44. Manifesto Ágil  hDp://agilemanifesto.org/ 
  45. 45. Manifesto Ágil  •  “Estamos descobrindo maneiras melhores de desenvolver soXware  fazendo‐o nós mesmos e ajudando outros a fazê‐lo. Através desse  trabalho, passamos a valorizar:  –  Indivíduos e interações entre eles mais que processos e ferramentas  –  Produto 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  •  Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os  itens à esquerda”.  Fonte: hDp://agilemanifesto.org 
  46. 46. Você conseguiria comer??? 
  47. 47. Incremental X InteraPvo 
  48. 48. IteraPvo e Incremental 
  49. 49. Ciclo PDCA 
  50. 50. Quem adota métodos ágeis?    MicrosoB    Sea Tecnologia (Brasil)    Yahoo    Nielsen Media    Google    ThoughtWorks    Electronic Arts    BMC SoXware    Stefanini IT SoluIons (Brasil)    Serpro (Brasil)    Philips    Lexis Nexis    Siemens    Sabre    Nokia    Salesforce.com    Alterdata (Brasil)    Time Warner    BBC    Globo.com (Brasil) 
  51. 51. E o SCRUM???? 
  52. 52. Scrum é...  •  Um processo iteraPvo e incremental para o  desenvolvimento de qualquer produto e  gerenciamento de qualquer projeto;  •  É mais um framework que uma metodologia,  mais aPtude que um processo; 
  53. 53. Scrum também é...  •  Processo empírico de gerenciamento e controle  •  Inspeção e adaptação em ciclos e feedback  •  Usado para gerenciar projetos desde 1990  •  Entrega frequente de funcionalidade com valor  para o cliente (ROI)  •  Escalável a projetos distribuídos, grandes e largos  •  Processos compa{veis com CMMI nível 3 e  ISO9001  •  Extremamente simples, mas resistente 
  54. 54. A Origem do Scrum  Jeff Sutherland, PhD  Desenvolvimento IteraPvo e  Incremental  SCRUM  Ken Schwaber 
  55. 55. hDp://www.infoq.com/ presentaPons/The‐Roots‐of‐Scrum 
  56. 56. Processos Ágeis e Scrum  XP  Crystal  FDD  SCRUM  DSDM 
  57. 57. Mapeando algumas caracterísPcas  Processos: Reunião Diária, Reunião  de Planejamento, Review,  RetrospecPva, Planejamento de  Release, ...  Ferramentas: Quadro Kanban, Post‐ it, Burndown, ...  Pessoas: Líder de equipe, Cliente ou  representante do produto, Time, ...  Cultura: Time mulP‐disciplinar, auto‐ gerenciamente, valores,  envolvimento do cliente, entrega  frequente, liderança‐colaboraPva,  RESPEITO, ... 
  58. 58. Scrum é...  Empresa A  Empresa B  Empresa C 
  59. 59. “Simples de entender, mas di~cil  de adotar e praPcar” 
  60. 60. “Modelo Empírico” 
  61. 61. “Altamente Ajustável” 
  62. 62. “Esse modelo trata de pessoas” 
  63. 63. O SCRUM é assim... 
  64. 64. ParPcipação do Cliente 
  65. 65. Planejamento Ágil 
  66. 66. Planejamento Constante 
  67. 67. A cada iteração é entregue um  incremento do soXware 
  68. 68. Itens técnicos, arquitetura, infra‐estrutura, ...  Sempre entregar valor!  Itens com RoI visível 
  69. 69. Planejamento de Releases 
  70. 70. Planejamento de Releases  2 semanas cada  8 semanas para o primeiro release 
  71. 71. Product Owner  Papéis no Scrum  ScrumMaster  Time 
  72. 72. Envolvidos X CompromePdos 
  73. 73. Comando‐Controle   X   Auto‐Gerenciamento 
  74. 74. Comando‐Controle não!  ApáIco: “Não tenho nada pra fazer hoje,  ninguém me passou nada e nem sei também  o por que eu faço essas coisas!”  Pró‐aIvo: “Quando o chefe voltar eu vejo o  que ele tem pra me passar, estou sem nada  pra fazer”  Auto‐gerenciado: “Quando terminar essa  aPvidade vou aproveitar o tempo restante pra  discuPr melhorias no projeto com a equipe,  para atender melhor as necessidades” 
  75. 75. Ciclo SCRUM 
  76. 76. Ciclo SCRUM 
  77. 77. Manutenção do  Product Backlog  Quais seriam as suas  prioridades?  O que pode influenciar a sua  decisão? 
  78. 78. Time EsPma... 
  79. 79. Cliente Prioriza! 
  80. 80. Planeja a Sprint 
  81. 81. Hora de executar 
  82. 82. Reunião Diária 
  83. 83. Ambiente ColaboraPvo 
  84. 84. Hora da Review 
  85. 85. RetrospecPva 
  86. 86. RetrospecPva 
  87. 87. ...e começa tudo de novo!!! 
  88. 88. Valore Ágeis 
  89. 89. Melhoria Con{nua 
  90. 90. Adaptabilidade 
  91. 91. CompromePmento e Confiança 
  92. 92. HonesPdade 
  93. 93. Respeito 
  94. 94. Coragem 
  95. 95. Sucesso será o Resultado! 
  96. 96. Times que aPngem meta devem celebrar! 
  97. 97. ?  Obrigado!!!  [piagodinho@gmail.com] 

×