Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013
7 gostaram1,757 visualizações
O documento aborda a evolução do desenvolvimento ágil, destacando a importância de entender o problema antes de codificar e a necessidade de validar as soluções com os clientes. Luca Bastos propõe uma emenda ao manifesto ágil, incorporando conceitos como design thinking e lean startup, e enfatiza a colaboração e a adição de valor contínua nos projetos. Ao longo do texto, refletem sobre as lições aprendidas desde a década de 1960 até as metodologias contemporâneas, evidenciando a crescente complexidade dos projetos de software.
Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013
- 1. Da descoberta do ágil ao manifesto Luca Bastos @LucaBastos
- 3. Brasil 1968
- 4. Brasil 1968 Caminhando e cantando E seguindo a canção
- 5. Brasil 1968 Caminhando e cantando E seguindo a canção Somos todos iguais Braços dados ou não
- 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
- 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
- 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
- 9. 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
- 10. Brasil 1968
- 11. Brasil 1968
- 12. Brasil 1968
- 13. Brasil 1968
- 14. Brasil 2013
- 15. Brasil 2013
- 16. Brasil 2013
- 17. Brasil 2013
- 18. Brasil 2013
- 19. Brasil 2013
- 20. 1968, ano que comecei 196
- 21. 1968, ano que comecei 1968, povo na rua por mudanças
- 22. 1968, ano que comecei 1968, povo na rua por mudanças 2013, povo na rua por mudanças
- 23. Sou Luca Bastos
- 24. Sou Luca Bastos Comecei em 1968
- 25. Sou Luca Bastos Comecei em 1968 Com 68 anos, sou eterno aprendiz
- 26. Sou Luca Bastos Comecei em 1968 Com 68 anos, sou eterno aprendiz Compartilho meus sonhos na ThoughtWorks
- 27. Como disse antes, a coisa está complexa, hein
- 28. Bem, não vim falar disto
- 29. Ou melhor, vim sim!
- 30. Os tempos são de complexidade
- 31. Os tempos são de complexidade Não percam Jurgen Appelo no Agile Trends, dia 5 de outubro em SP
- 32. 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."
- 33. Hoje em dia está tudo junto e misturado Comunicadora popular Regina Casé
- 34. Talvez já fosse assim antes mas certamente menos
- 35. Como era antes?
- 36. O negócio era resolver o problema
- 37. Tempos de cowboys Mas não Inha Movimento Passe Livre nas diligências
- 38. Software era para ser usado por especialistas
- 39. Usuário tinha que fazer curso
- 40. Usuário tinha que fazer curso e ler um monte de manuais
- 42. Surgiram metodologias para melhorar a clareza do código
- 44. • Programação estruturada • Programação modular
- 45. • Programação estruturada • Programação modular • Encapsulamento
- 46. • Programação estruturada • Programação modular • Encapsulamento • Programação OO
- 47. Nos tempos antigos" a grande e única preocupação " era com o código"
- 48. Mais ou menos como ainda " pensam alguns..."
- 50. Porém desenvolver um sistema, " por mais importante que o código seja, " não é só escrever código"
- 52. Naquela altura da vida achei que tinha uma ideia para solucionar um problema que sabia que existia
- 53. 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
- 54. 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
- 56. Fui um founder (termo que só descobri muito tempo depois)
- 57. Quando meu produto já tinha vendido para quem podia comprar
- 58. Quando meu produto já tinha vendido para quem podia comprar, eu parti para vender serviços.
- 59. Tinha que apontar o dedo para o vento e dar orçamentos com 10 a 12 meses de previsão
- 60. Tinha que apontar o dedo para o vento e dar orçamentos com 10 a 12 meses de previsão chute
- 61. Vivíamos nos tempos do Waterfall
- 62. Fim da minha historinha
- 63. Voltando ao modo como a gente desenvolvia
- 66. O problema não era só no código
- 67. Era preciso pensar no modo de desenvolver
- 68. E como prever e controlar o desenvolvimento
- 69. Na década de 80 surgiu o CMM
- 70. Na década de 80 surgiu o CMM E também começou o uso de pontos de função
- 71. Não muito tempo depois o povo começou a perceber que havia BUROCRACIA demais (*) (*) Ainda existe até hoje em alguns ambientes
- 72. Surgiram diversos estudos e recomendações,
- 73. Surgiram diversos estudos e recomendações, Todas elas contrapondo o desenvolvimento iterativo ao modo tradicional em cascata adotado pelo SEI
- 74. Desenvolvimento iterativo versus Waterfall
- 75. 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,
- 76. 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
- 77. Pelo artigo o Royce ficou conhecido como o inventor do Waterfall
- 78. Pelo artigo o Royce ficou conhecido como o inventor do Waterfall Nada mais injusto.
- 79. 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.”
- 80. 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)
- 81. Metologias pregando desenvolvimento iterativo:
- 82. Metologias pregando desenvolvimento iterativo: • Crystal Clear (1992 ou 2004).
- 83. Metologias pregando desenvolvimento iterativo: • Crystal Clear (1992 ou 2004). • Dynamic Systems Development Method DSDM (surgiu em 1990, 1a versão em 1995),
- 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),
- 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),
- 86. 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).
- 87. 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),
- 88. 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)
- 89. 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
- 90. 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
- 91. Extreme Programming História: • Kent Beck e Ward Cunningham pareavam na Tektronix -‐ Meados de 80,
- 92. 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.
- 93. 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
- 94. É 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.
- 95. 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.
- 96. 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/
- 97. Se é assim, vamos ver o tal do Manifesto Ágil
- 98. Manifesto Ágil Hotel The Lodge Snowbird ski resort, montanhas Wasatch de Utah
- 99. Manifesto Ágil
- 100. Manifesto Ágil
- 103. 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
- 104. O manifesto ágil não foi o único
- 105. Software Craftsmanship Manifesto Robert Martin fez um keynote intitulado “Software Craftsmanship over Crap” no Agile 2008.
- 106. 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
- 109. Vou propor as minhas
- 110. Ao invés do manifesto do uncle Bob
- 112. Manifesto Luca Bastos Baseado no Software Craftmanship Manifesto,
- 113. Manifesto Luca Bastos Baseado no Software Craftmanship Manifesto, não me reuni com ninguém em nenhuma estação de ski e
- 114. 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
- 115. 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.
- 116. Manifesto Luca Bastos Uma emenda ao Software Craftmanship Manifesto,
- 117. Manifesto Luca Bastos Uma emenda ao Software Craftmanship Manifesto, incorporando conceitos de Inception, Lean Startup, Lean UX e Design Thinking
- 118. Disclaimer Nada aqui mencionado representa o que a ThoughtWorks faz ou recomenda. É apenas a opinião exclusiva do autor.
- 119. Manifesto Luca Bastos - I Não fazer somente software bem feito, mas feito a partir de CLARO entendimento
- 120. Justificativa – 1/4 Só escrever código depois de entender ou depois de fazer as perguntas certas
- 121. 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
- 122. 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
- 123. Justificativa – 3/4 Escrever antes: Frase missão do projeto
- 124. Justificativa – 3/4 Escrever antes: Frase missão do projeto Release note ou press release (sucinto e capturando essência do produto).
- 125. Justificativa – 3/4 Escrever antes: Frase missão do projeto Release note ou press release (sucinto e capturando essência do produto). FAQ
- 126. Justificativa – 4/4 Validar antes mesmo de iniciar a codar:
- 127. Justificativa – 4/4 Validar antes mesmo de iniciar a codar: Assistir alguém usando software concorrente
- 128. 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
- 129. Manifesto Luca Bastos - II Não somente adicionar valor continuamente, mas SÓ fazer o que adiciona valor
- 130. Justificativa – 1/2 Evitar ao máximo processos que não adicionam valor ao produto.
- 131. 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
- 132. 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).
- 133. Manifesto Luca Bastos - III Não ser somente uma comunidade de profissionais de TI, é preciso ver sob o ponto de vista de todos
- 134. Justificativa – 1/3 É preciso pensar como usuário, se possível conhecer o ambiente e contexto dele. Reconhecer suas dificuldades.
- 135. 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.
- 136. 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.
- 137. 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.
- 138. 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/
- 139. Manifesto Luca Bastos - IV Não somente uma parceria produtiva com o cliente, é preciso ter o cliente sempre disposto a validar tudo
- 140. Justificativa Conceito Customer Development e Customer Validation Validar cada feature e cada release com o cliente/usuário
- 141. 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
- 142. Da descoberta do ágil ao manifesto Luca Bastos @LucaBastos ThoughtWorks
- 143. Vou falar sobre inovação e agilidade no http://www.agiletrendsbr.com/