Your SlideShare is downloading. ×
  • Like
Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013

  • 685 views
Published

Keynote Agile Vale 2013 - Da descoberta do Ágil ao Manifesto Luca Bastos …

Keynote Agile Vale 2013 - Da descoberta do Ágil ao Manifesto Luca Bastos
Um emenda so Software Craftmanship Manifesto que por sua vez emenda o Agile Manifesto.
O meu considera coisas atuais tais como Inception, Design Thinking mais algumas coisas de Lean Startup como Customer Validation, MVP e Lean UX

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
685
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
3
Comments
0
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Da descoberta do ágil ao manifesto Luca Bastos @LucaBastos
  • 2. Brasil 1968
  • 3. Brasil 1968 Caminhando e cantando E seguindo a canção
  • 4. Brasil 1968 Caminhando e cantando E seguindo a canção Somos todos iguais Braços dados ou não
  • 5. Brasil 1968 Caminhando e cantando E seguindo a canção Somos todos iguais Braços dados ou não Nas escolas, nas ruas Campos, construções
  • 6. Brasil 1968 Caminhando e cantando E seguindo a canção Somos todos iguais Braços dados ou não Nas escolas, nas ruas Campos, construções Caminhando e cantando E seguindo a canção
  • 7. Brasil 1968 Caminhando e cantando E seguindo a canção Somos todos iguais Braços dados ou não Nas escolas, nas ruas Campos, construções Caminhando e cantando E seguindo a canção Vem, vamos embora Que esperar não é saber
  • 8. Brasil 1968 Caminhando e cantando E seguindo a canção Somos todos iguais Braços dados ou não Nas escolas, nas ruas Campos, construções Caminhando e cantando E seguindo a canção Vem, vamos embora Que esperar não é saber Quem sabe faz a hora Não espera acontecer
  • 9. Brasil 1968
  • 10. Brasil 1968
  • 11. Brasil 1968
  • 12. Brasil 1968
  • 13. Brasil 2013
  • 14. Brasil 2013
  • 15. Brasil 2013
  • 16. Brasil 2013
  • 17. Brasil 2013
  • 18. Brasil 2013
  • 19. 1968, ano que comecei 196
  • 20. 1968, ano que comecei 1968, povo na rua por mudanças
  • 21. 1968, ano que comecei 1968, povo na rua por mudanças 2013, povo na rua por mudanças
  • 22. Sou Luca Bastos
  • 23. Sou Luca Bastos Comecei em 1968
  • 24. Sou Luca Bastos Comecei em 1968 Com 68 anos, sou eterno aprendiz
  • 25. Sou Luca Bastos Comecei em 1968 Com 68 anos, sou eterno aprendiz Compartilho meus sonhos na ThoughtWorks
  • 26. Como disse antes, a coisa está complexa, hein
  • 27. Bem, não vim falar disto
  • 28. Ou melhor, vim sim!
  • 29. Os tempos são de complexidade
  • 30. Os tempos são de complexidade Não percam Jurgen Appelo no Agile Trends, dia 5 de outubro em SP
  • 31. Stephen Hawking disse que este seria o século da complexidade On  January  23,  2000  he  said  in  San  Jose  Mercury  News:     "I  think  the  next  century  will  be  the  century  of  complexity."  
  • 32. Hoje em dia está tudo junto e misturado Comunicadora  popular  Regina  Casé  
  • 33. Talvez já fosse assim antes mas certamente menos
  • 34. Como era antes?
  • 35. O negócio era resolver o problema
  • 36. Tempos de cowboys Mas  não  Inha  Movimento  Passe  Livre  nas  diligências  
  • 37. Software era para ser usado por especialistas
  • 38. Usuário tinha que fazer curso
  • 39. Usuário tinha que fazer curso e ler um monte de manuais
  • 40. Os códigos eram obscuros
  • 41. Surgiram metodologias para melhorar a clareza do código
  • 42. •   Programação estruturada
  • 43. •   Programação estruturada •  Programação modular
  • 44. •   Programação estruturada •  Programação modular •  Encapsulamento
  • 45. •   Programação estruturada •  Programação modular •  Encapsulamento •  Programação OO
  • 46. Nos tempos antigos" a grande e única preocupação " era com o código"
  • 47. Mais ou menos como ainda " pensam alguns..."
  • 48. Porém desenvolver um sistema, " por mais importante que o código seja, " não é só escrever código"
  • 49. Uma  historinha  minha  
  • 50. Naquela altura da vida achei que tinha uma ideia para solucionar um problema que sabia que existia
  • 51. Naquela altura da vida achei que tinha uma ideia para solucionar um problema que sabia que existia Me juntei a 2 sócios que ajudaram a implementar a ideia. Então escrevi o código e sai vendendo o produto final
  • 52. Naquela altura da vida achei que tinha uma ideia para solucionar um problema que sabia que existia Me juntei a 2 sócios que ajudaram a implementar a ideia. Então escrevi o código e sai vendendo o produto final Não eram tempos de startups. Era da busca do ouro e também queria um quinhão
  • 53. Fui um founder (termo que só descobri muito tempo depois)
  • 54. Quando meu produto já tinha vendido para quem podia comprar
  • 55. Quando meu produto já tinha vendido para quem podia comprar, eu parti para vender serviços.
  • 56. Tinha que apontar o dedo para o vento e dar orçamentos com 10 a 12 meses de previsão
  • 57. Tinha que apontar o dedo para o vento e dar orçamentos com 10 a 12 meses de previsão chute
  • 58. Vivíamos nos tempos do Waterfall
  • 59. Fim  da  minha  historinha  
  • 60. Voltando ao modo como a gente desenvolvia
  • 61. Por incrível que pareça
  • 62. Projetos também falhavam naquela época
  • 63. O problema não era só no código
  • 64. Era preciso pensar no modo de desenvolver
  • 65. E como prever e controlar o desenvolvimento
  • 66. Na década de 80 surgiu o CMM
  • 67. Na década de 80 surgiu o CMM E também começou o uso de pontos de função
  • 68. Não muito tempo depois o povo começou a perceber que havia BUROCRACIA demais (*) (*)  Ainda  existe  até  hoje  em  alguns  ambientes  
  • 69. Surgiram diversos estudos e recomendações,
  • 70. Surgiram diversos estudos e recomendações, Todas elas contrapondo o desenvolvimento iterativo ao modo tradicional em cascata adotado pelo SEI
  • 71. Desenvolvimento iterativo versus Waterfall
  • 72. Desenvolvimento iterativo versus Waterfall As vantagens do desenvolvimento iterativo foram citadas no artigo de autoria de Winston Royce publicado nos Proceedings do IEEE sob o nome Managing the development of large software systems,
  • 73. Desenvolvimento iterativo versus Waterfall As vantagens do desenvolvimento iterativo foram citadas no artigo de autoria de Winston Royce publicado nos Proceedings do IEEE sob o nome “Managing the development of large software systems” um clássico que recomendo a todos. http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf
  • 74. Pelo artigo o Royce ficou conhecido como o inventor do Waterfall
  • 75. Pelo artigo o Royce ficou conhecido como o inventor do Waterfall Nada mais injusto.
  • 76. Pelo artigo o Royce ficou conhecido como o inventor do Waterfall Nada mais injusto. Ele encerra o artigo com a seguinte conclusão: “In my experience, however, the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-‐step process listed.”
  • 77. Vejam mais sobre o artigo do Royce em http://blog.budzier.com/2009/04/23/managing-‐the-‐development-‐of-‐large-‐software-‐systems-‐royce-‐1970/ de onde tirei esta figura (o autor copiou do Royce)
  • 78. Metologias pregando desenvolvimento iterativo:
  • 79. Metologias pregando desenvolvimento iterativo: •  Crystal Clear (1992 ou 2004).
  • 80. Metologias pregando desenvolvimento iterativo: •  Crystal Clear (1992 ou 2004). •  Dynamic Systems Development Method DSDM (surgiu em 1990, 1a versão em 1995),
  • 81. Metologias pregando desenvolvimento iterativo: •  Crystal Clear (1992 ou 2004). •  Dynamic Systems Development Method DSDM (surgiu em 1990, 1a versão em 1995), •  Adaptive Software Development ASD (1995),
  • 82. Metologias pregando desenvolvimento iterativo: •  Crystal Clear (1992 ou 2004). •  Dynamic Systems Development Method DSDM (surgiu em 1990, 1a versão em 1995), •  Adaptive Software Development ASD (1995), •  Scrum (1995),
  • 83. Metologias pregando desenvolvimento iterativo: •  Crystal Clear (1992 ou 2004). •  Dynamic Systems Development Method DSDM (surgiu em 1990, 1a versão em 1995), •  Adaptive Software Development ASD (1995), •  Scrum (1995), •  Extreme Programming XP (1996).
  • 84. Metologias pregando desenvolvimento iterativo: •  Crystal Clear (1992 ou 2004). •  Dynamic Systems Development Method DSDM (surgiu em 1990, 1a versão em 1995), •  Adaptive Software Development ASD (1995), •  Scrum (1995), •  Extreme Programming XP (1996). •  Rational Unified Process RUP (1996),
  • 85. Metologias pregando desenvolvimento iterativo: •  Crystal Clear (1992 ou 2004). •  Dynamic Systems Development Method DSDM (surgiu em 1990, 1a versão em 1995), •  Adaptive Software Development ASD (1995), •  Scrum (1995), •  Extreme Programming XP (1996). •  Rational Unified Process RUP (1996), •  Feature Driven Development (surgiu entre 97 e 99 a partir de métodos +antigos de Peter Coad)
  • 86. Scrum História: •  Jeff Sutherland e Ken Schwaber apresentaram um artigo descrevendo a metodologia Scrum na conferência Object-‐ Oriented Programming, Systems, Languages & Applications 1995 (OOPSLA '95) em Austin, Texas
  • 87. Scrum História: •  Jeff Sutherland e Ken Schwaber apresentaram um artigo descrevendo a metodologia Scrum na conferência Object-‐ Oriented Programming, Systems, Languages & Applications 1995 (OOPSLA '95) em Austin, Texas •  2001 Agile Software Development with Scrum, 1o livro
  • 88. Extreme Programming História: •  Kent Beck e Ward Cunningham pareavam na Tektronix -‐ Meados de 80,
  • 89. Extreme Programming História: •  Kent Beck e Ward Cunningham pareavam na Tektronix -‐ Meados de 80, •  1996 Kent Beck era lider do projeto C3 da Chrysler e contratou o Ron Jeffries como coach. Neste projeto surgiu o XP.
  • 90. Extreme Programming História: •  Kent Beck e Ward Cunningham pareavam na Tektronix -‐ Meados de 80, •  1996 Kent Beck era lider do projeto C3 da Chrysler e contratou o Ron Jeffries como coach. Neste projeto surgiu o XP. •  1999 Extreme Programming Explained, 1o livro
  • 91. É importante ressaltar que Extreme Programming já tinha como premissa que o cliente deveria estar sempre presente conduzindo o desenvolvimento a partir do feedback que recebia do sistema.
  • 92. Desenvolvimento Ágil Desenvolvimento iterativo e incremental onde as hipóteses (ou requisitos) são testadas e implementadas por colaboração entre pequenos times auto- organizados multifuncionais. Esta é apenas uma definição e nem sei se é a melhor.
  • 93. Outra definição de desenvolvimento Ágil Desenvolvimento ágil é qualquer processo de desenvolvimento criado com base nos conceitos do Manifesto Ágil. hUp://blog.myscrumhalf.com/2011/05/faq-­‐scrum-­‐o-­‐que-­‐e-­‐desenvolvimento-­‐agil/  
  • 94. Se é assim, vamos ver o tal do Manifesto Ágil
  • 95. Manifesto Ágil Hotel The Lodge Snowbird ski resort, montanhas Wasatch de Utah
  • 96. Manifesto Ágil
  • 97. Manifesto Ágil
  • 98. hUp://agilemanifesto.org/  
  • 99. Influências que levaram ao Manifesto Ágil Scrum (Jeff Sutherland e Ken Schwaber – também Mike Beedle) DSDM (DSDM Consortium representado por Arie van Bennekum) ASD (Jim Highsmith) XP (Kent Beck, Ward Cunningham e Ron Jeffries – Martin Fowler) http://setandbma.wordpress.com/2012/03/23/agile-‐history
  • 100. O manifesto ágil não foi o único
  • 101. Software Craftsmanship Manifesto Robert Martin fez um keynote intitulado “Software Craftsmanship over Crap” no Agile 2008.
  • 102. Software Craftsmanship Manifesto Robert Martin fez um keynote intitulado “Software Craftsmanship over Crap” no Agile 2008. Baseado nele um grupo se reuniu em 13/12/2008 em Chicago e propôs uma emenda ao Manifesto Ágil. hUp://manifesto.so[warecra[smanship.org/   hUp://blog.8thlight.com/paul-­‐pagel/2009/03/11/history-­‐of-­‐the-­‐so[ware-­‐cra[smanship-­‐ manifesto.html  
  • 103. Vivemos tempos de mudanças
  • 104. Vou propor as minhas
  • 105. Ao invés do manifesto do uncle Bob
  • 106. Manifesto do uncle Luca?
  • 107. Manifesto Luca Bastos Baseado no Software Craftmanship Manifesto,
  • 108. Manifesto Luca Bastos Baseado no Software Craftmanship Manifesto, não me reuni com ninguém em nenhuma estação de ski e
  • 109. Manifesto Luca Bastos Baseado no Software Craftmanship Manifesto, não me reuni com ninguém em nenhuma estação de ski e proponho uma emenda ao Software Craftmanship Manifesto
  • 110. Manifesto Luca Bastos Baseado no Software Craftmanship Manifesto, não me reuni com ninguém em nenhuma estação de ski e proponho uma emenda ao Software Craftmanship Manifesto, que por sua vez é uma emenda ao Manifesto Ágil.
  • 111. Manifesto Luca Bastos Uma emenda ao Software Craftmanship Manifesto,  
  • 112. Manifesto Luca Bastos Uma emenda ao Software Craftmanship Manifesto,   incorporando conceitos de Inception, Lean Startup, Lean UX e Design Thinking
  • 113. Disclaimer Nada aqui mencionado representa o que a ThoughtWorks faz ou recomenda. É apenas a opinião exclusiva do autor.
  • 114. Manifesto Luca Bastos - I Não fazer somente software bem feito, mas feito a partir de CLARO entendimento
  • 115. Justificativa – 1/4 Só escrever código depois de entender ou depois de fazer as perguntas certas
  • 116. Justificativa – 1/4 Só escrever código depois de entender(*) ou depois de fazer as perguntas certas Jonathan Rasmunsson (Agile Samurai): alguns times destinam o projeto ao fracasso por: • Não fazer as perguntas certas, • Não fazer as perguntas mais difíceis. (*) http://www.slideshare.net/caetano_tc/agile-‐br-‐oneweekinception por Paulo Caroli e Tainã Caetano  
  • 117. Justificativa – 2/4 Fazer inception ou liftoff O time e o cliente se conhecem, ganham confiança (*) e entendem melhor o projeto (*) http://portal.sliderocket.com/CSQQG/Confianca Claudia Melo diz que o Segredo é a Confiança  
  • 118. Justificativa – 3/4 Escrever antes: Frase missão do projeto
  • 119. Justificativa – 3/4 Escrever antes: Frase missão do projeto Release note ou press release (sucinto e capturando essência do produto).
  • 120. Justificativa – 3/4 Escrever antes: Frase missão do projeto Release note ou press release (sucinto e capturando essência do produto). FAQ
  • 121. Justificativa – 4/4 Validar antes mesmo de iniciar a codar:
  • 122. Justificativa – 4/4 Validar antes mesmo de iniciar a codar: Assistir alguém usando software concorrente
  • 123. Justificativa – 4/4 Validar antes mesmo de iniciar a codar: Assistir alguém usando software concorrente Assistir alguém usando tela com features fake http://www.infoq.com/br/presentations/produtos-‐enxutos-‐pensamento-‐lean
  • 124. Manifesto Luca Bastos - II Não somente adicionar valor continuamente, mas SÓ fazer o que adiciona valor
  • 125. Justificativa – 1/2 Evitar ao máximo processos que não adicionam valor ao produto.
  • 126. Justificativa – 1/2 Evitar ao máximo processos que não adicionam valor ao produto. Tentar o release de cada iteração como algo que funcione e seja visto pelo cliente
  • 127. Justificativa – 2/2 Conceito Minimum Viable Product MVP = versão mínima viável que permite ao time medir e obter o máximo de aprendizado e validações dos clientes, com o mínimo esforço (build-‐measure-‐learn).
  • 128. Manifesto Luca Bastos - III Não ser somente uma comunidade de profissionais de TI, é preciso ver sob o ponto de vista de todos
  • 129. Justificativa – 1/3 É preciso pensar como usuário, se possível conhecer o ambiente e contexto dele. Reconhecer suas dificuldades.
  • 130. Justificativa – 1/3 É preciso pensar como usuário, se possível conhecer o ambiente e contexto dele. Reconhecer suas dificuldades. É preciso pensar como stakeholder, tentar entender as prioridades.
  • 131. Justificativa – 1/3 É preciso pensar como usuário, se possível conhecer o ambiente e contexto dele. Reconhecer suas dificuldades. É preciso pensar como stakeholder, tentar entender as prioridades. É preciso tentar entender do negócio.
  • 132. Justificativa – 2/3 Abrir cabeças, recursos de Design Thinking DT = Inovação centrada em pessoas. Enfatiza análise do negócio, observação, colaboração, aprendizado, visualização de ideias e rápida prototização.
  • 133. Justificativa – 3/3 -‐ percepção do todo Robert Hoekman, Jr (autor de Designing the Obvious, Designing the Moment e Web Anatomy. Founder of Miskeeto) “A experiência do usuário é a soma líquida de cada interação que uma pessoa tem com a empresa, seja via material de marketing, chamada de serviço ou o produto ou serviço em si. É afetada pela visão da empresa, suas crenças e práticas, bem como o propósito do serviço ou produto e o valor que ele tem na vida de uma pessoa.” http://uxdesign.smashingmagazine.com/2013/06/21/13-‐tenets-‐user-‐experience/
  • 134. Manifesto Luca Bastos - IV Não somente uma parceria produtiva com o cliente, é preciso ter o cliente sempre disposto a validar tudo
  • 135. Justificativa Conceito Customer Development e Customer Validation Validar cada feature e cada release com o cliente/usuário
  • 136. Manifesto Luca Bastos -‐ resumo Escrever código só após ENTENDER bem Fazer SÓ o que adiciona valor Ver sempre sob o ponto de vista de TODOS O cliente precisa sempre VALIDAR tudo
  • 137. Da descoberta do ágil ao manifesto Luca Bastos @LucaBastos ThoughtWorks
  • 138. Vou falar sobre inovação e agilidade no http://www.agiletrendsbr.com/