Da descoberta do Ágil ao Manifesto Luca Bastos Agile Brazil 2013
-
Upload
luca-bastos -
Category
Technology
-
view
31 -
download
14
description
Transcript of Da descoberta do Ágil ao Manifesto Luca Bastos Agile Brazil 2013
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, construções
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
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
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
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
A coisa está complexa, hein
Bem, não vim falar disto
Ou melhor, vim sim!
Os tempos são de complexidade
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."
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 que ajudaram a implementar a ideia. Então escrevi o código e sai vendendo o produto final
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
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 em alguns ambientes
Surgiram diversos estudos e recomendações,
Surgiram diversos estudos e recomendações,
Todas elas contrapondo o desenvolvimento iterativo ao modo tradicional em cascata adotado pelo SEI
Desenvolvimento iterativo versus Waterfall
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,
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
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 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.”
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)
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
(surgiu em 1990, 1a versão em 1995),
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),
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),
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).
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),
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)
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
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
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 lider do projeto C3 da Chrysler e contratou o Ron Jeffries como coach. Neste projeto surgiu o XP.
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
É 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.
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.
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/
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 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
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.
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
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
proponho uma emenda ao 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
proponho uma emenda ao Software Craftmanship Manifesto, que por sua vez é uma emenda ao Manifesto Ágil.
Manifesto Luca Bastos
Uma emenda ao Software Craftmanship Manifesto,
Manifesto Luca Bastos
Uma emenda ao Software Craftmanship Manifesto,
incorporando conceitos de Inception, Lean Startup, Lean UX e Design Thinking
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 (Agile Samurai): alguns times destinam o projeto ao fracasso por:
• Não fazer as perguntas certas,
• Não fazer as perguntas mais difíceis.
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
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 do produto).
Justificativa – 3/4
Escrever antes:
Frase missão do projeto
Release note ou press release (sucinto e capturando essência do produto).
FAQ
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 usando tela com features fake
http://www.infoq.com/br/presentations/produtos-‐enxutos-‐pensamento-‐lean
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 algo que funcione e seja visto pelo cliente
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).
Manifesto Luca Bastos - III
Não ser somente uma comunidade de profissionais de TI,
é preciso ver sob o ponto de vista de todos
Justificativa – 1/3
É preciso pensar como usuário, se possível conhecer o ambiente e contexto dele. Reconhecer suas dificuldades.
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.
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.
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.
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/
Manifesto Luca Bastos - IV
Não somente uma parceria produtiva com o cliente,
é preciso ter o cliente sempre disposto a validar tudo
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 de vista de TODOS
O cliente precisa sempre VALIDAR tudo
Da descoberta do ágil ao manifesto
Luca Bastos
@LucaBastos ThoughtWorks
Orgulho
Orgulho
Orgulho
de fazer
Orgulho
de fazer
com vocês
Orgulho
de fazer
com vocês
este enorme
Orgulho
de fazer
com vocês
AgileBrazil 2013
este enorme
Perguntas?
http://join.thoughtworks.com
Visite nosso Stand