Da descoberta do ágil ao manifesto ágil

Da descoberta do
ágil ao manifesto
Luca Bastos
@LucaBastos

Brasil 1968
Caminhando e cantando
E seguindo a canção

Brasil 1968
Somos todos iguais
Braços dados ou não

Brasil 1968
Somos todos iguais
Nas escolas, nas ruas
Campos, construções

Brasil 1968
Somos todos iguais

Brasil 1968
Somos todos iguais
Vem, vamos embora
Que esperar não é saber

Brasil 1968
Somos todos iguais
Vem, vamos embora
Que esperar não é saber
Quem sabe faz a hora
Não espera acontecer

1968, ano que comecei
1968, povo na rua por
mudanças

1968, ano que comecei
mudanças
mudanças

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

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

Surgiram metodologias
para melhorar a
clareza do código

• 
Programação estruturada

• 
•  Programação modular

• 
•  Encapsulamento

• 
•  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"

Naquela altura da vida achei que tinha uma
ideia para solucionar um problema que sabia que
existia

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

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

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
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

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,

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

do Waterfall
Nada mais injusto.

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:

•  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),

•  Scrum (1995),
•  Extreme Programming XP (1996).

•  Scrum (1995),
•  Rational Unified Process RUP (1996),

•  Scrum (1995),
•  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:
•  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:
•  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

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

Ao invés do manifesto
do uncle Bob

Manifesto Luca Bastos
Baseado no Software Craftmanship
Manifesto,

Manifesto,
não me reuni com ninguém em
nenhuma estação de ski e

Manifesto,
proponho uma emenda ao
Software Craftmanship Manifesto

Manifesto,
proponho uma emenda ao
Software Craftmanship Manifesto,
que por sua vez é uma emenda
ao Manifesto Ágil.

Uma emenda ao Software
Craftmanship Manifesto,

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

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.

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

Escrever antes:
Frase missão do projeto

Escrever antes:
Release note ou press release (sucinto e
capturando essência do produto).

Escrever antes:
Release note ou press release (sucinto e
capturando essência do produto).
FAQ

Validar antes mesmo de iniciar a codar:

Assistir alguém usando software
concorrente

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

Evitar ao máximo processos que não
adicionam valor ao produto.

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

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

É 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 pensar como stakeholder, tentar
entender as prioridades.
É preciso tentar entender do negócio.

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
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

Da descoberta do ágil ao manifesto ágil

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (9)

Similaire à Da descoberta do ágil ao manifesto ágil

Similaire à Da descoberta do ágil ao manifesto ágil (20)

Plus de Luca Bastos

Plus de Luca Bastos (9)

Da descoberta do ágil ao manifesto ágil