Da descoberta do
ágil ao manifesto
Luca Bastos
@LucaBastos
Brasil 1968
Brasil 1968
Caminhando e cantando
E seguindo a canção
Brasil 1968
Caminhando e cantando
E seguindo a canção
Somos todos iguais
Braços dados ou não
Brasil 1968
Caminhando e cantando
E seguindo a canção
Somos todos iguais
Braços dados ou não
Nas escolas, nas ruas
Campos,...
Brasil 1968
Caminhando e cantando
E seguindo a canção
Somos todos iguais
Braços dados ou não
Nas escolas, nas ruas
Campos,...
Brasil 1968
Caminhando e cantando
E seguindo a canção
Somos todos iguais
Braços dados ou não
Nas escolas, nas ruas
Campos,...
Brasil 1968
Caminhando e cantando
E seguindo a canção
Somos todos iguais
Braços dados ou não
Nas escolas, nas ruas
Campos,...
Brasil 1968
Brasil 1968
Brasil 1968
Brasil 1968
Brasil 2013
Brasil 2013
Brasil 2013
Brasil 2013
Brasil 2013
Brasil 2013
1968, ano que comecei
196
1968, ano que comecei
1968, povo na rua por
mudanças
1968, ano que comecei
1968, povo na rua por
mudanças
2013, povo na rua por
mudanças
Sou Luca Bastos
Sou Luca Bastos
Comecei em 1968
Sou Luca Bastos
Comecei em 1968
Com 68 anos, sou eterno aprendiz
Sou Luca Bastos
Comecei em 1968
Com 68 anos, sou eterno aprendiz
Compartilho meus sonhos na
ThoughtWorks
Como disse antes, a
coisa está complexa,
hein
Bem,
não vim falar disto
Ou melhor, vim sim!
Os tempos são de
complexidade
Os tempos são de
complexidade
Não percam Jurgen Appelo no Agile Trends,
dia 5 de outubro em SP
Stephen Hawking disse
que este seria o século
da complexidade
On	
  January	
  23,	
  2000	
  he	
  said	
  in	
  San	
  J...
Hoje em dia está tudo
junto e misturado
Comunicadora	
  popular	
  Regina	
  Casé	
  
Talvez já fosse assim
antes mas certamente
menos
Como era antes?
O negócio era resolver
o problema
Tempos de cowboys
Mas	
  não	
  Inha	
  Movimento	
  Passe	
  Livre	
  nas	
  diligências	
  
Software era para ser
usado por
especialistas
Usuário tinha que
fazer curso
Usuário tinha que
fazer curso e ler um
monte de manuais
Os códigos eram
obscuros
Surgiram metodologias
para melhorar a
clareza do código
• 	
  Programação estruturada
• 	
  Programação estruturada
•  Programação modular
• 	
  Programação estruturada
•  Programação modular
•  Encapsulamento
• 	
  Programação estruturada
•  Programação modular
•  Encapsulamento
•  Programação OO
Nos tempos antigos"
a grande e única preocupação "
era com o código"
Mais ou menos como ainda "
pensam alguns..."
Porém desenvolver um sistema, "
por mais importante que o
código seja, "
não é só escrever código"
Uma	
  historinha	
  minha	
  
Naquela altura da vida achei que tinha uma
ideia para solucionar um problema que sabia que
existia
Naquela altura da vida achei que tinha uma
ideia para solucionar um problema que sabia que
existia
Me juntei a 2 sócios qu...
Naquela altura da vida achei que tinha uma
ideia para solucionar um problema que sabia que
existia
Me juntei a 2 sócios qu...
Fui um founder (termo que só
descobri muito tempo depois)
Quando meu produto já tinha
vendido para quem podia comprar
Quando meu produto já tinha
vendido para quem podia comprar,
eu parti para vender serviços.
Tinha que apontar o dedo para o
vento e dar orçamentos com 10 a
12 meses de previsão
Tinha que apontar o dedo para o
vento e dar orçamentos com 10 a
12 meses de previsão chute
Vivíamos nos tempos do
Waterfall
Fim	
  da	
  minha	
  historinha	
  
Voltando ao modo como
a gente desenvolvia
Por incrível que
pareça
Projetos também
falhavam naquela
época
O problema não era
só no código
Era preciso pensar no
modo de desenvolver
E como prever e
controlar o
desenvolvimento
Na década de 80 surgiu o CMM
Na década de 80 surgiu o CMM
E também começou o uso de
pontos de função
Não muito tempo depois o
povo começou a perceber que
havia BUROCRACIA demais (*)
(*)	
  Ainda	
  existe	
  até	
  hoje	
  ...
Surgiram diversos estudos e
recomendações,
Surgiram diversos estudos e
recomendações,
Todas elas contrapondo o
desenvolvimento iterativo ao
modo tradicional em casca...
Desenvolvimento iterativo versus Waterfall
Desenvolvimento iterativo versus Waterfall
As vantagens do desenvolvimento iterativo foram
citadas no artigo de autoria de...
Desenvolvimento iterativo versus Waterfall
As vantagens do desenvolvimento iterativo foram
citadas no artigo de autoria de...
Pelo artigo o Royce ficou conhecido como o inventor
do Waterfall
Pelo artigo o Royce ficou conhecido como o inventor
do Waterfall
Nada mais injusto.
Pelo artigo o Royce ficou conhecido como o inventor
do Waterfall
Nada mais injusto.
Ele encerra o artigo com a seguinte co...
Vejam mais sobre o artigo do Royce em
http://blog.budzier.com/2009/04/23/managing-‐the-‐development-‐of-‐large-‐software-‐...
Metologias pregando desenvolvimento iterativo:
Metologias pregando desenvolvimento iterativo:
•  Crystal Clear (1992 ou 2004).
Metologias pregando desenvolvimento iterativo:
•  Crystal Clear (1992 ou 2004).
•  Dynamic Systems Development Method DSDM...
Metologias pregando desenvolvimento iterativo:
•  Crystal Clear (1992 ou 2004).
•  Dynamic Systems Development Method DSDM...
Metologias pregando desenvolvimento iterativo:
•  Crystal Clear (1992 ou 2004).
•  Dynamic Systems Development Method DSDM...
Metologias pregando desenvolvimento iterativo:
•  Crystal Clear (1992 ou 2004).
•  Dynamic Systems Development Method DSDM...
Metologias pregando desenvolvimento iterativo:
•  Crystal Clear (1992 ou 2004).
•  Dynamic Systems Development Method DSDM...
Metologias pregando desenvolvimento iterativo:
•  Crystal Clear (1992 ou 2004).
•  Dynamic Systems Development Method DSDM...
Scrum
História:
•  Jeff Sutherland e Ken Schwaber
apresentaram um artigo descrevendo a
metodologia Scrum na conferência Ob...
Scrum
História:
•  Jeff Sutherland e Ken Schwaber
apresentaram um artigo descrevendo a
metodologia Scrum na conferência Ob...
Extreme Programming
História:
•  Kent Beck e Ward Cunningham pareavam na
Tektronix -‐ Meados de 80,
Extreme Programming
História:
•  Kent Beck e Ward Cunningham pareavam na
Tektronix -‐ Meados de 80,
•  1996 Kent Beck era ...
Extreme Programming
História:
•  Kent Beck e Ward Cunningham pareavam na
Tektronix -‐ Meados de 80,
•  1996 Kent Beck era ...
É importante ressaltar que Extreme Programming
já tinha como premissa que o cliente deveria estar
sempre presente conduzin...
Desenvolvimento Ágil
Desenvolvimento iterativo e
incremental onde as hipóteses
(ou requisitos) são testadas e
implementada...
Outra definição de
desenvolvimento Ágil
Desenvolvimento ágil é qualquer
processo de desenvolvimento
criado com base nos co...
Se é assim, vamos ver o tal do
Manifesto Ágil
Manifesto Ágil
Hotel The Lodge Snowbird ski
resort, montanhas Wasatch de Utah
Manifesto Ágil
Manifesto Ágil
hUp://agilemanifesto.org/	
  
Influências que levaram ao Manifesto Ágil
Scrum (Jeff Sutherland e Ken Schwaber –
também Mike Beedle)
DSDM (DSDM Consortiu...
O manifesto ágil não foi o único
Software Craftsmanship Manifesto
Robert Martin fez um keynote
intitulado “Software Craftsmanship
over Crap” no Agile 2008.
Software Craftsmanship Manifesto
Robert Martin fez um keynote
intitulado “Software Craftsmanship
over Crap” no Agile 2008....
Vivemos tempos de
mudanças
Vou propor as minhas
Ao invés do manifesto
do uncle Bob
Manifesto
do uncle Luca?
Manifesto Luca Bastos
Baseado no Software Craftmanship
Manifesto,
Manifesto Luca Bastos
Baseado no Software Craftmanship
Manifesto,
não me reuni com ninguém em
nenhuma estação de ski e
Manifesto Luca Bastos
Baseado no Software Craftmanship
Manifesto,
não me reuni com ninguém em
nenhuma estação de ski e
pro...
Manifesto Luca Bastos
Baseado no Software Craftmanship
Manifesto,
não me reuni com ninguém em
nenhuma estação de ski e
pro...
Manifesto Luca Bastos
Uma emenda ao Software
Craftmanship Manifesto, 	
  
Manifesto Luca Bastos
Uma emenda ao Software
Craftmanship Manifesto, 	
  
incorporando conceitos de
Inception, Lean Startu...
Disclaimer
Nada aqui mencionado representa o que a
ThoughtWorks faz ou recomenda.
É apenas a opinião exclusiva do autor.
Manifesto Luca Bastos - I
Não fazer somente
software bem feito,
mas feito a partir de
CLARO entendimento
Justificativa – 1/4
Só escrever código depois de entender ou
depois de fazer as perguntas certas
Justificativa – 1/4
Só escrever código depois de entender(*)
ou depois de fazer as perguntas certas
Jonathan Rasmunsson (A...
Justificativa – 2/4
Fazer inception ou liftoff
O time e o cliente se conhecem, ganham
confiança (*) e entendem melhor o pr...
Justificativa – 3/4
Escrever antes:
Frase missão do projeto
Justificativa – 3/4
Escrever antes:
Frase missão do projeto
Release note ou press release (sucinto e
capturando essência d...
Justificativa – 3/4
Escrever antes:
Frase missão do projeto
Release note ou press release (sucinto e
capturando essência d...
Justificativa – 4/4
Validar antes mesmo de iniciar a codar:
Justificativa – 4/4
Validar antes mesmo de iniciar a codar:
Assistir alguém usando software
concorrente
Justificativa – 4/4
Validar antes mesmo de iniciar a codar:
Assistir alguém usando software
concorrente
Assistir alguém us...
Manifesto Luca Bastos - II
Não somente adicionar
valor continuamente,
mas SÓ fazer o que
adiciona valor
Justificativa – 1/2
Evitar ao máximo processos que não
adicionam valor ao produto.
Justificativa – 1/2
Evitar ao máximo processos que não
adicionam valor ao produto.
Tentar o release de cada iteração como
...
Justificativa – 2/2
Conceito Minimum Viable Product
MVP = versão mínima viável que permite ao
time medir e obter o máximo ...
Manifesto Luca Bastos - III
Não ser somente uma
comunidade de
profissionais de TI,
é preciso ver sob o
ponto de vista de t...
Justificativa – 1/3
É preciso pensar como usuário, se possível
conhecer o ambiente e contexto dele.
Reconhecer suas dificu...
Justificativa – 1/3
É preciso pensar como usuário, se possível
conhecer o ambiente e contexto dele.
Reconhecer suas dificu...
Justificativa – 1/3
É preciso pensar como usuário, se possível
conhecer o ambiente e contexto dele.
Reconhecer suas dificu...
Justificativa – 2/3
Abrir cabeças, recursos de Design Thinking
DT = Inovação centrada em pessoas.
Enfatiza análise do negó...
Justificativa – 3/3 -‐ percepção do todo
Robert Hoekman, Jr (autor de Designing
the Obvious, Designing the Moment e Web
An...
Manifesto Luca Bastos - IV
Não somente uma
parceria produtiva com o
cliente,
é preciso ter o cliente
sempre disposto a
val...
Justificativa
Conceito Customer Development e
Customer Validation
Validar cada feature e cada release com
o cliente/usuário
Manifesto Luca Bastos -‐ resumo
Escrever código só após ENTENDER bem
Fazer SÓ o que adiciona valor
Ver sempre sob o ponto ...
Da descoberta do
ágil ao manifesto
Luca Bastos
@LucaBastos
ThoughtWorks
Vou falar sobre
inovação e agilidade no
http://www.agiletrendsbr.com/
Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013
Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013
Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013
Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013
Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013
Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013
Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013
Próximos SlideShares
Carregando em…5
×

Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013

1.303 visualizações

Publicada em

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

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

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

Nenhuma nota no slide

Da Descoberta do Ágil ao Manifesto Luca Bastos AgileVale 2013

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

×