Da descoberta do Ágil ao Manifesto Luca Bastos Agile Brazil 2013
22 gostaram4,626 visualizações
O documento discute a evolução do desenvolvimento de software, especialmente a transição do modelo tradicional de waterfall para metodologias ágeis. Luca Bastos propõe um novo manifesto que enfatiza a importância de entender o problema antes de codificar, adicionar valor continuamente, e envolver os usuários no processo de desenvolvimento. O texto também reflete sobre a complexidade crescente no desenvolvimento de software e a necessidade de colaboração entre equipes multifuncionais.
Mais conteúdo relacionado
Semelhante a Da descoberta do Ágil ao Manifesto Luca Bastos Agile Brazil 2013 (20)
![01 - Arquitetura de Computadores 1 TEC [Salvo automaticamente].ppt](https://cdn.slidesharecdn.com/ss_thumbnails/01-arquiteturadecomputadores1tecsalvoautomaticamente-250825173800-d03ce433-thumbnail.jpg?width=560&fit=bounds)
Da descoberta do Ágil ao Manifesto Luca Bastos Agile Brazil 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. A coisa está complexa, hein
- 24. Bem, não vim falar disto
- 25. Ou melhor, vim sim!
- 26. Os tempos são de complexidade
- 27. 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."
- 28. Hoje em dia está tudo junto e misturado Comunicadora popular Regina Casé
- 29. Talvez já fosse assim antes mas certamente menos
- 30. Como era antes?
- 31. O negócio era resolver o problema
- 32. Tempos de cowboys Mas não Inha Movimento Passe Livre nas diligências
- 33. Software era para ser usado por especialistas
- 34. Usuário tinha que fazer curso
- 35. Usuário tinha que fazer curso e ler um monte de manuais
- 37. Surgiram metodologias para melhorar a clareza do código
- 39. • Programação estruturada • Programação modular
- 40. • Programação estruturada • Programação modular • Encapsulamento
- 41. • Programação estruturada • Programação modular • Encapsulamento • Programação OO
- 42. Nos tempos antigos" a grande e única preocupação " era com o código"
- 43. Mais ou menos como ainda " pensam alguns..."
- 45. Porém desenvolver um sistema, " por mais importante que o código seja, " não é só escrever código"
- 47. Naquela altura da vida achei que tinha uma ideia para solucionar um problema que sabia que existia
- 48. 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
- 49. 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
- 51. Fui um founder (termo que só descobri muito tempo depois)
- 52. Quando meu produto já tinha vendido para quem podia comprar
- 53. Quando meu produto já tinha vendido para quem podia comprar, eu parti para vender serviços.
- 54. Tinha que apontar o dedo para o vento e dar orçamentos com 10 a 12 meses de previsão
- 55. Tinha que apontar o dedo para o vento e dar orçamentos com 10 a 12 meses de previsão chute
- 56. Vivíamos nos tempos do Waterfall
- 57. Fim da minha historinha
- 58. Voltando ao modo como a gente desenvolvia
- 61. O problema não era só no código
- 62. Era preciso pensar no modo de desenvolver
- 63. E como prever e controlar o desenvolvimento
- 64. Na década de 80 surgiu o CMM
- 65. Na década de 80 surgiu o CMM E também começou o uso de pontos de função
- 66. Não muito tempo depois o povo começou a perceber que havia BUROCRACIA demais (*) (*) Ainda existe até hoje em alguns ambientes
- 67. Surgiram diversos estudos e recomendações,
- 68. Surgiram diversos estudos e recomendações, Todas elas contrapondo o desenvolvimento iterativo ao modo tradicional em cascata adotado pelo SEI
- 69. Desenvolvimento iterativo versus Waterfall
- 70. 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,
- 71. 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
- 72. Pelo artigo o Royce ficou conhecido como o inventor do Waterfall
- 73. Pelo artigo o Royce ficou conhecido como o inventor do Waterfall Nada mais injusto.
- 74. 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.”
- 75. 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)
- 76. Metologias pregando desenvolvimento iterativo:
- 77. Metologias pregando desenvolvimento iterativo: • Crystal Clear (1992 ou 2004).
- 78. Metologias pregando desenvolvimento iterativo: • Crystal Clear (1992 ou 2004). • Dynamic Systems Development Method DSDM (surgiu em 1990, 1a versão em 1995),
- 79. 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),
- 80. 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),
- 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), • Scrum (1995), • Extreme Programming XP (1996).
- 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), • Extreme Programming XP (1996). • Rational Unified Process RUP (1996),
- 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). • Rational Unified Process RUP (1996), • Feature Driven Development (surgiu entre 97 e 99 a partir de métodos +antigos de Peter Coad)
- 84. 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
- 85. 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
- 86. Extreme Programming História: • Kent Beck e Ward Cunningham pareavam na Tektronix -‐ Meados de 80,
- 87. 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.
- 88. 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
- 89. É 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.
- 90. 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.
- 91. 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/
- 92. Se é assim, vamos ver o tal do Manifesto Ágil
- 93. Manifesto Ágil Hotel The Lodge Snowbird ski resort, montanhas Wasatch de Utah
- 94. Manifesto Ágil
- 95. Manifesto Ágil
- 98. 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
- 99. O manifesto ágil não foi o único
- 100. Software Craftsmanship Manifesto Robert Martin fez um keynote intitulado “Software Craftsmanship over Crap” no Agile 2008.
- 101. 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
- 104. Vou propor as minhas
- 105. Ao invés do manifesto do uncle Bob
- 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.
- 117. Justificativa – 2/4 Fazer inception ou liftoff O time e o cliente se conhecem, ganham confiança (*) e entendem melhor o projeto (*) Não percam 5ª feira às 15 horas Claudia Melo falando 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
- 139. Orgulho
- 140. Orgulho
- 141. Orgulho de fazer
- 144. Orgulho de fazer com vocês AgileBrazil 2013 este enorme