Agile Tour 2010

528 visualizações

Publicada em

Application of Agile Methods in Outsourcing

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

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

Nenhuma nota no slide

Agile Tour 2010

  1. 1. Adoção dos Métodos Ágeis em Outsourcing Paulo Rebelo phrebelo@yahoo.com 25 de Outubro 2010 São Paulo
  2. 2. Biografia • Mestre em Engenharia de Computação pelo IPTComputação pelo IPT • Formado em Licenciatura e Bacharelado em Matemática • Gerente de Projetos Ágil – Abril www.agiletour.com25/10/10
  3. 3. Meta #1 É possível aplicarmos Agile em Outsourcing?
  4. 4. Meta #2 Como podemos adotar Agile em Outsourcing?
  5. 5. OutsourcingOutsourcing ?? www.agiletour.com25/10/10 AgileAgile ??
  6. 6. A sua empresa já está preparada em desenvolvimento de software e www.agiletour.com25/10/10 desenvolvimento de software e gestão de projetos ágeis?
  7. 7. Se não está, os desafios são grandes! www.agiletour.com25/10/10
  8. 8. www.agiletour.com05/05/09
  9. 9. PARCERIA e não ADVERSÁRIOS! www.agiletour.com25/10/10
  10. 10. Parceria Ágil? • Nem todos estão dispostos, assim como na adoção de Agile em equipes internas www.agiletour.com25/10/10
  11. 11. Contratos Tradicionais • Inflexíveis e não permitem mudança de escopo www.agiletour.com25/10/10
  12. 12. Triângulação Perversa Tempo www.agiletour.com25/10/10 Tempo EscopoCusto
  13. 13. Contrato Ágil www.agiletour.com05/05/09
  14. 14. Ao invés de escopo fixo… www.agiletour.com25/10/10
  15. 15. …custo fixo www.agiletour.com25/10/10
  16. 16. -Time-boxing é uma prática ágil comum. - Limitar o custo faz com que o time- boxing trabalhe até melhor! www.agiletour.com25/10/10
  17. 17. Portanto: • User stories, ao invés de uma Especificação de Requisitos detalhada (elas são orientadas a features, podem ser criadas e destruídasfeatures, podem ser criadas e destruídas facilmente, provém uma boa visão do escopo e podem ser comparadas pelo tamanho ou esforço). • Pontos, ao invés de horas, pois são relativos e não expressam necessariamente o esforço. • DONE: confiança e entendimento comum. www.agiletour.com25/10/10
  18. 18. Desta forma, fixando o escopo em termos de pontos, conseguimos, no decorrer do projeto, abraçar mudanças, pois conseguimos trocar histórias por outras de mesmo valor. www.agiletour.com25/10/10 de mesmo valor. Assim, temos a tríplice: custo, prazo e escopo fixos, da forma ágil!
  19. 19. Como? Estimativa Inicial Estimativa Inicial Obter histórias Pontuar histórias www.agiletour.com25/10/10
  20. 20. Business Value “Uma abordagem de melhoria de aprendizado e incremental, com a finalidade de oferecer aos www.agiletour.com25/10/10 finalidade de oferecer aos clientes mais do que eles realmente querem, observando o processo como um todo.”
  21. 21. www.agiletour.com25/10/10
  22. 22. Como? Estimativa Inicial Estimativa Inicial Obter histórias Pontuar histórias TempoTempo Velocidade Time Quantidade Pontos www.agiletour.com25/10/10
  23. 23. Como? Estimativa Inicial Estimativa Inicial Obter histórias Pontuar histórias TempoTempo Velocidade Time Quantidade Pontos CustoCusto Quantidade Horas Quantidade Pessoas www.agiletour.com25/10/10
  24. 24. Velocidade do Time Total de Pontos 100 Velocidade Baixa 5Velocidade Baixa 5 VelocidadeAlta 15 www.agiletour.com25/10/10 100 ÷ 5 = 100 ÷ 15 =
  25. 25. TEMPO f = (total de pontos ÷ velocidade) ×f = (total de pontos ÷ velocidade) × tamanho do sprint (100 ÷ 10) × 2 semanas = 20 semanas www.agiletour.com25/10/10
  26. 26. CUSTO f = horas sprint × qtde. sprints × qtde.f = horas sprint × qtde. sprints × qtde. pessoas × valor/hora 80h × 10 sprints × 4 pessoas × R$ 100,00 = R$ 320.000,00 www.agiletour.com25/10/10
  27. 27. Flexibilidade • Número de pontos a serem entregues já sabemos! • Abrace mudanças, levando em consideração a• Abrace mudanças, levando em consideração a quantidade de pontos! • Se cliente quiser mais 1 sprint, sem problema! Faça um aditivo ao contrato com esse sprint adicional. www.agiletour.com25/10/10
  28. 28. MAS… www.agiletour.com25/10/10
  29. 29. Acompanhe a cada sprint!!! www.agiletour.com25/10/10
  30. 30. www.agiletour.com25/10/10 noop.nl
  31. 31. Confiança! www.agiletour.com25/10/10
  32. 32. ESTUDO DE CASO www.agiletour.com25/10/10
  33. 33. ANTES DE TUDO… www.agiletour.com25/10/10
  34. 34. www.agiletour.com25/10/10
  35. 35. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA• QA • Time • Arquiteto de Software • Sysadmin www.agiletour.com25/10/10
  36. 36. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA • Define uma visão clara do produto • Define as características• QA • Time • Arquiteto de Software • Sysadmin www.agiletour.com25/10/10 • Define as características do produto • Planeja e organiza o backlog • Pontua o valor de negócio das histórias • Responsável pelo ROI
  37. 37. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA • Remove os impedimentos • Responsável pelo processo• QA • Time • Arquiteto de Software • Sysadmin www.agiletour.com25/10/10 processo • Facilita a colaboração entre todos • Garante que o time esteja sempre funcionando e produzindo
  38. 38. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA • Planeja e executa os testes de aceitação do usuário• QA • Time • Arquiteto de Software • Sysadmin www.agiletour.com25/10/10 usuário • Apóia time • Trabalha com todos para garantir a qualidade do software a ser lançado
  39. 39. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA • Desenvolve as features planejadas pelo PO • Define como será• QA • Time • Arquiteto de Software • Sysadmin www.agiletour.com25/10/10 • Define como será realizado o trabalho • Auto-gerenciado e auto- organizado • Apresenta o que foi feito ao PO
  40. 40. Definir as responsabilidades com clareza • Product Owner • ScrumMaster • QA • Programa em par remotamente • Revisa o código• QA • Time • Arquiteto de Software www.agiletour.com25/10/10 • Revisa o código • Integra continuamente • Realiza provas de conceito • Alinhamento conceitual e arquitetural entre os principais projetos da área
  41. 41. Sessão de Levantamento de Features www.agiletour.com25/10/10
  42. 42. Coaching do PO • Como escrever histórias, aplicando o conceito de INVESTconceito de INVEST (Independent, Negotiable, Valuable, Estimable, Sized right and Testable) • Responsabilidades www.agiletour.com25/10/10
  43. 43. Escrever histórias www.agiletour.com25/10/10
  44. 44. www.agiletour.com25/10/10 - Jeff Patton -
  45. 45. Planning Poker www.agiletour.com25/10/10
  46. 46. Business Value www.agiletour.com25/10/10
  47. 47. Pontos www.agiletour.com25/10/10
  48. 48. Contrato Ágil www.agiletour.com05/05/09
  49. 49. www.agiletour.com25/10/10
  50. 50. www.agiletour.com25/10/10
  51. 51. Reuniões • Daily • Planning• Planning • Review • Retrospective www.agiletour.com25/10/10
  52. 52. Reuniões • Daily • Planning Perguntas: • O que foi feito? • O que será feito?• Planning • Review • Retrospective • O que será feito? • Algum impedimento? Regras: • 15’ • PO liga para todos www.agiletour.com25/10/10
  53. 53. Reuniões • Daily • Planning • Meta do Sprint • Apresentação das histórias• Planning • Review • Retrospective histórias • Estimativa (user stories < 13) • Definição do Sprint www.agiletour.com25/10/10
  54. 54. Reuniões • Daily • Planning • Apresentação das histórias DONE para stakeholders • Planning • Review • Retrospective stakeholders • Aceitação ++ Reviews constantes, quase diários www.agiletour.com25/10/10
  55. 55. Reuniões • Daily • Planning • O que foi bom e devemos continuar? • O que precisa ser• Planning • Review • Retrospective • O que precisa ser melhorado? ++ Retrospectiva geral presencial no final do Release www.agiletour.com25/10/10
  56. 56. Acompanhe a Evolução www.agiletour.com25/10/10 Acompanhe a Evolução
  57. 57. www.agiletour.com05/05/09
  58. 58. Boas Práticas de Desenvolvimento de Software • Pair programming (Team Viewer, Pair Eclipse Programming, etc.) • Code review• Code review • Desenvolvimento orientado a testes • Padronização de código • Integração regular do código • Incentivo à refatoração www.agiletour.com25/10/10
  59. 59. www.agiletour.com05/05/09
  60. 60. “Quem não se comunica, se estrumbica” (Velho Guerreiro) www.agiletour.com25/10/10
  61. 61. @phfrebelo www.agiletour.com25/10/10
  62. 62. www.agiletour.com25/10/10

×