Agile

870 visualizações

Publicada em

Slides apresentados na disciplina in0953.2012 do Professor Silvio Meira

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

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

Nenhuma nota no slide

Agile

  1. 1. Agile Eric Cavalcanti ecavalcanti@gmail.com @ericoc
  2. 2. O Problema Chaos Report 18% 2004 53% 29% 19% 2006 46% Fracassados 35% Comprometidos Bem sucedidos 24% 2009 44% 32% !"#$%&(")&*%+,-."/0$12""
  3. 3. Principais fatores de insucesso requisitos incompletos falta de envolvimento de usuários mudanças de requisitos e especificações falta de apoio de negócios falta de recursos
  4. 4. Como resolver?
  5. 5. Abordagem Tradicional
  6. 6. BDUF Big Design Up Front
  7. 7. Analista de Requisitos, Analista de Negócios,Engenheiro de Requisitos, Engenheiro de Qualidade, Gerente de Configuração, Líder de Projeto... Programadores
  8. 8. Processo!!
  9. 9. Ainda assim...
  10. 10. Ainda mais...Código Complexo.Manutenção difícil.Baixa produtividade.Cronograma sempre atrasado.Insatisfação de todos.Design degradado.Documentação defasada, excessiva e ilegível.Fracasso em grande parte dos projetos.
  11. 11. Por quê?
  12. 12. Previsibilidade
  13. 13. O desenvolvimento de software dependemuito mais das pessoas e da comunicação
  14. 14. “Ao contrário do cenário numa linha deprodução em massa, o software não é algoprevisível ou imune a mudanças” Larman
  15. 15. “Desenvolver software é como desenvolver novos produtos” Larman
  16. 16. “Desenvolver é como criar uma receita,enquanto produzir é seguir a receita”Poppendieck
  17. 17. “O desenvolvimento é um processo deaprendizado, que envolve tentativa e erros” Larman
  18. 18. “Como a manufatura previsível, não pode ser comparada aosoftware, dificilmente as práticas e valores enraizados nesseparadigma trazem algum benefício” Larman
  19. 19. 64% das funcionalidadesdesenvolvidas nos softwaresnão são utilizadasStandish Group
  20. 20. Muitas vezes, pelo fato do clientesó poder pedir uma vez, eleacaba pedindo coisas que não tem certeza que precisa
  21. 21. Essas funcionalidadesfazem parte dos64% que ele nemrepara que estão lá,quando o software éentregue
  22. 22. 70% dos usuários utilizam asfuncionalidades básicas de um software.20% utilizam as funcionalidadesintermediárias.10% utilizam as funcionalidades avançadas.Microsoft
  23. 23. Cone da Incerteza Construx
  24. 24. É natural que osusuários tenham novas idéias e suas opiniões mudem quando vêem as primeiras versões do software
  25. 25. Os softwares mais famosose utilizados no mundo sãoos mais simples
  26. 26. “Menos é Mais” A cabeça de Steve Jobs (Inside Steve’s Brain) - Agir 2008
  27. 27. DANIEL COOK
  28. 28. Abordagem Ágil
  29. 29. Final da década de 90 eXtreme Programming Feature Driven Development Scrum Adaptive Development Crystal Clear Dynamic Systems Development Method
  30. 30. 2001Kent Beck Ron JeffriesMike Beedle Jon KernArie van Brian MarickBennekum Robert C. MartinAlistair Cockburn Steve MellorWard Cunningham Ken SchwaberMartin Fowler Jeff SutherlandJames Grenning Manifesto Ágil Dave ThomasJim HighsmithAndrew Hunt
  31. 31. Indivíduos e interação entre eles mais que processos e ferramentas
  32. 32. Software em funcionamentomais que documentação abrangente
  33. 33. Colaboração com o clientemais que negociação de contratos
  34. 34. Responder a mudanças maisque seguir um plano
  35. 35. Princípios por trás do manifesto ágil
  36. 36. Nossa maior prioridade ésatisfazer o cliente, atravésda entrega adiantada econtínua de software devalor
  37. 37. Aceitar mudanças de requisitos,mesmo no fim do desenvolvimento
  38. 38. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas
  39. 39. Entregar software funcionando com frequencia, na escala desemanas até meses, com preferência aos períodos mais curtos
  40. 40. Pessoas relacionadas à negócios e desenvolvedoresdevem trabalhar em conjunto e diariamente,durante todo o curso do projeto
  41. 41. Construir projetos ao redor de indivíduos motivados. Dando a eles oambiente e suporte necessário, e confiar que farão seu trabalho.
  42. 42. O método mais eficiente e eficaz detransmitir informações é através de umaconversa cara a cara.
  43. 43. Softwarefuncional é amedida primáriade progresso.
  44. 44. Processos ágeis promovem um ambientesustentável. Os patrocinadores, desenvolvedorese usuários, devem ser capazes de manterindefinidamente, passos constantes.
  45. 45. Contínua atenção à excelênciatécnica e bom design, aumentaa agilidade.
  46. 46. Simplicidade: a arte demaximizar a quantidade detrabalho que não precisouser feito
  47. 47. As melhores arquiteturas,requisitos e designs emergem de times auto-organizáveis
  48. 48. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo
  49. 49. Por que adotarabordagens ágeis?
  50. 50. STATE OFAGILE SURVEY2011 6.042 participantes VersionOne
  51. 51. STATE OFAGILE SURVEY2011 >80% 90% trabalham em são pelo menos"esclarecido" organizações que usam sobre técnicas de práticas de desenvolvimento ágil de desenvolvimento ágil software em um certo grau VersionOne
  52. 52. STATE OFAGILE SURVEY2011 45% utilizam abordagem ágil a mais de 2 anos VersionOne
  53. 53. STATE OFAGILE SURVEY2011 Scrum e variantes de Scrum são de longe os mais utilizados VersionOne
  54. 54. STATE OFAGILE SURVEY2011 As razões mais comuns para a adoção ágil gira em torno de tempo de aceleração para o mercado, gereciamento de mudanças de prioridade e aumento produtividade VersionOne
  55. 55. STATE OFAGILE SURVEY2011Princípios fundamentais ágeis atualmente em uso são Daily Standup, Iteration Planning e Unit Testing. O mais notável é o uso crescente de Kanban (24%). VersionOne
  56. 56. O Scrum
  57. 57. A origem 1995 Jeff Sutherland Ken Schwaber 1986
  58. 58. Se destaca dos demais métodos ágeis pelaênfase dada ao gerenciamento do projeto
  59. 59. Práticas de Engenharia de d c lu t in No
  60. 60. Papéisdo Scrum
  61. 61. ProductProduct Owner Determina a visão do produtoOwner Define as funcionalidades Escolhe as datas de release Dá o feedback Gerencia os stakeholders Aceita ou rejeita os resultados Prioriza de acordo com o ROI
  62. 62. Pequenos (5 a 9 pessoas) Desenvolve as funcionalidades Auto-organizável Auto-gerenciável Multifuncional Estima o esforço Defina as tarefasO Time Responsável pela qualidade
  63. 63. Scrum MasterLíder ServidorProtege o timeRemove impedimentosGuia do Scrum
  64. 64. Como funciona?
  65. 65. Então ao invés de um grande grupo gastandoum monte de tempo construindo uma grandecoisa, temos uma equipe pequena gastando um tempo curto construindo uma pequena coisa.Mas integrando regularmente para ver o todo. Henrik Kniberg
  66. 66. Product Backlog Uma lista de coisas que queremos que sejam entregues
  67. 67. As funcionalidades sãogeralmente escritas em estórias de usuários.
  68. 68. Como um <perfil>,quero <funcionalidade>,para <valor de negócio> Como um agente de viagens, quero reservar lugar, para facilitar o atendimento dos clientes corporativos
  69. 69. O time estima o trabalhoassociado a cada estória.
  70. 70. As estórias são rankeadas em ordemde importância pelo product owner.
  71. 71. O product owner é o dono do backlog do produto.
  72. 72. Team Velocity
  73. 73. Sprint Backlog
  74. 74. Executando a Sprint Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Análise Código Testa Análise Código Testa Análise Código Testa Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Análise Análise Análise Código Código Código Testa Testa Testa
  75. 75. Daily Scrum Meeting• O que você fez ontem?• O que você fará de hojepara amanhã?• Há algum impedimentoem seu caminho? 15 minutos
  76. 76. Taskboard
  77. 77. Acompanhamento
  78. 78. Sprint Burndown
  79. 79. Sprint Review
  80. 80. Scrum Retrospective
  81. 81. Revisando...
  82. 82. Scrum of Scrums
  83. 83. Mude alguma coisa => Saiba como foi => Aprenda com isso => Mude alguma coisa novamente. Falando de um modo geral, você quer o ciclo de feedback o mais rápido possível,Scrum + XP e ciclos feedbackfeedback para que seja possa adaptar o processo rapidamente. Em Scrum, a iteração básica de um de é o sprint. Há mais, porém, especialmente se você combinar com o XP (eXtreme Programm ing): Quando feito corretamente, Scrum + XP lhe oferece vários ciclos de feedback extremamente valiosos.
  84. 84. Kanban
  85. 85. O Kanban é baseado numa idéia muito simples. As atividades em andamento devem ser limitadas. Algo novo só deve ser iniciado quando uma peça detrabalho existente é liberada ou quando uma função automática inicia isso.
  86. 86. O princípio do Kanban é que você inicia com o que estiver fazendo agora.
  87. 87. Como Funciona?
  88. 88. Visualize o fluxo de trabalho Divida o trabalho em partes, escreva cada item em um cartão e coloque na parede Use colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho
  89. 89. Limite o trabalho em progresso (WIP- work in progress)Associe limites explícitos para quantos itens podemestar em progresso em cada estado do fluxo detrabalho
  90. 90. Acompanhe o tempo de execução datarefaTempo médio para completar um item, algumas vezeschamado de “Lead Time”Otimize o processo para tornar o tempo de execução omenor e mais previsível possível.
  91. 91. ReferênciasLean Software Development: An Agile Toolkit, Mary Poppendieck e Tom Poppendieck, 2003, Addison-Wesley ProfessionalAgile Project Management with Scrum, Ken Schwaber, 2004, Microsoft ProfessionalThe Enterprise and Scrum, Ken Schwaber, 2007, Microsoft PressKanban e Scrum - obtendo o melhor de ambos, Henrik Kniberg e Mattias Skarin, 2009, C3 Media Inc.Kanban: Mudança Evolucionária de Sucesso para seu Negócio de Tecnologia, David Anderson,2011, Blue Hole PressAgile Estimating and Planning, Mike Cohn, 2005, Prentice HallUser Stories Applied: For Agile Software Development, Mike Cohn, 2004, Addison-WesleyProfessionalExtreme Programming Explained: Embrace Change (2nd Edition), Kent Beck, 2004, Addison-WesleyProfessionalTest Driven Development, Kent Beck, 2002, Addison-Wesley ProfessionalRefactoring: Improving the Design of Existing Code, Martin Fowler, Kent Beck, 1999, Addison-WesleyProfessional
  92. 92. Obrigado! Eric Cavalcanti ecavalcanti@gmail.com @ericoc

×