A linha do tempo da agilidade: Como chegamos até aqui?

A agilidade — nascida no submundo do desenvolvimento de software — chegou ao mundo dos negócios. E, chegou pra ficar, não há dúvidas sobre isso.

No mundo contemporâneo as mudanças acontecem numa frequência infinitamente maior do que já aconteceram em qualquer época de nossa história .  Não há nenhum indício de que esse ritmo irá diminuir. Para sobreviver, é fundamental adaptar-se rapidamente às mudanças.

A agilidade é uma resposta para essa necessidade. Talvez por isso ande tão em voga.

Para ser mais do que um hype, deve haver uma fundamentação sólida por trás dela. Ninguém escolhe ser ágil à noite e acorda ágil no dia seguinte. Por esse mesmo motivo não é possível que a agilidade tenha surgido da noite pro dia. Houve um processo evolutivo que permitiu o surgimento do que hoje chamamos de agilidade.

Para entender como esse processo se deu, vamos voltar 51 anos na história da humanidade

1968 — Conway’s Law

No artigo How Do Committees Invent? [1], Melvin Conway propõe:

“Qualquer empresa que projeta um sistema (definição mais ampla aqui do que apenas sistemas de informação), inevitavelmente produz um projeto cuja estrutura é uma cópia da estrutura de comunicação da organização.”

Empresas como Netflix e a Amazon [2], por exemplo, estão estruturadas em pequenos times com independência e autonomia. Isso não é uma versão organizacional de micro-serviços? [2]

1970s — Wideband Delphi

Nos anos 1970, Barry Boehm propõe o método Wideband Delphi [3]. Este método é uma forma de se conseguir estimativas através do consenso de especialistas, assim como fazemos no Planning Poker [4].

1976 — Testes unitários automatizados

O artigo Test procedures: A new approach to software verification [5] de David Panzl propõe um método e uma nova linguagem para a verificação de software. Esse método é essencialmente o mesmo que usamos hoje para automatizar os testes de nossas aplicações.

1976 — Make tool

Em abril de 1976, Stuart Feldman criou o Make [6]. É uma ferramenta que compila automaticamente um código fonte a partir de um arquivo com instruções. De uma forma ou de outra, isso é o que fazemos com os Builds Automáticos [7] hoje em dia.

1980s — Visual Controls

Nos anos 1980, no Sistema Toyota de Produção, surge a noção de Controle Visual [8], que é uma precursora dos Information Radiators [9], ou dos Big Visible Charts [10] do XP.

“Use visual controls so no problems are hidden.”

1984 — Prototipação e “Factoring”

Um estudo empírico [11] de Barry Boehm compara implementações de um mesmo problema usando abordagens de Especificação e Prototipação. O resultado mostrou que com a prototipação, há menor esforço e menor quantidade de linhas; os produtos são levemente menos robustos, mas são mais fáceis de usar. Design thinking? [12]

Em 1984 também, Leo Brodie lança o Thinking Forth [13], um livro sobre resolução de problemas e um guia de estilo de programação. Os princípios apresentados neste livro são a base para o que hoje chamamos de Refactoring[14].

1985 — Evolutionary Delivery Model

Tom Glib apresenta um modelo incremental evolucionário de desenvolvimento de software — o Evolutionary Delivery Model, ou simplesmente EVO [15].

1986 — Modelos iterativos

Barry Boehm publica A spiral model of software development and enhancement [16]. Enquanto Takeuchi e Nonaka escrevem o The New New Product Development Game [17], propondo uma abordagem baseada no rúgbi para o desenvolvimento de software; essa abordagem se baseia na interação constante de uma equipe multidisciplinar trabalhando junto do início ao fim. Esse artigo inspirou o Scrum.

1988 — Timebox

O timebox é descrito como um fundamento do Rapid Iterative Production Prototyping [18], de Scott Schultz.

1991 — Rapid Application Development

James Martin combina os conceitos de timebox e iterações incrementais e apresenta o RAD, Rapid application development [19] no livro homônimo de 1991 [20].

1992 — Dynamic Duo

Em 1992, Larry Constantine visita a Whitesmiths Inc. e observa que em cada terminal havia dois programadores, e cunha o termo Dynamic Duo. Um dos precursores do Pair Programming.

1993 — StandUpMeeting pattern

James Coplien apresenta o pattern StandUpMeeting.

1993 — Scrum

Jeff Sutherland cria o Scrum [21] como um processo na Easel Corporation.

1994 — Continuous Integration

Em 1994, Grady Booch usa o termo Continuous Integration [22] no livro Object-Oriented Analysis and Design with applications [23], a expressão já vinha sendo usada.

2000 — Burndown

Ken Schwaber descreve formalmente o burndown [24].

2000 — Continuous Integration de Martin Fowler

Ainda em 2000, Martin Fowler escreve e artigo Continuous Integration [25] e descreve as práticas de integração contínua usadas à época.

Primavera de 2000 — Extreme Programming

Líderes do Extreme Programming se reúnem para discutir o XP e sua relação com os então Lightweight Methods [26] — Scrum, DSDM, ASD, Crystal, FDD, PP [27]. Dessa discussão, Uncle Bob teve a ideia de criar um encontro para os interessados nos Lightweight Methods.

Fevereiro de 2001 — Manifesto for Agile Software Development

Diversas pessoas proeminentes no universo do Desenvolvimento de Software foram contactadas e 17 delas se reuniram em um resort de ski nas montanhas de Utah e escreveram os quatro valores e doze princípios do que foi batizado como Manifesto Ágil do Desenvolvimento de Software [28].

Agilidade é adaptação

Após essa pequena viagem no tempo, fica fácil perceber que a agilidade é o resultado cumulativo de diversas práticas testadas e comprovadas no solução de novos e velhos problemas. São várias pequenas adaptações sendo aprimoradas ao longo do tempo. Entender que foram esses pequenos incrementos que construíram a agilidade é uma parte importante do processo de entender os próprios métodos ágeis, a metafísica da agilidade.

Entendendo isso, entende-se também por que a agilidade é uma resposta sólida para o cenário atual de constantes mudanças. A própria agilidade passou (e está passando) por um processo ágil de amadurecimento.

Veja como transformar a sua empresa com o mindset ágil também em nosso podcast “Os Agilistas” !

Nota 1

Não se engane pensando que foram apenas flores, houve também ideias contrárias às apresentadas aqui e muitas pessoas notórias teceram duras críticas a essas ideias. Como o artigo On the cruelty of really teaching computing science [29], de 1988, onde Edsger Dijkstra — uma das mais brilhantes mentes do século XX — defende que a “metáfora antropomórfica” deveria ser banida do ensino de Ciência da Computação. Um ano mais tarde, Ward Cunningham e Kent Beck descreveram a técnica CRC [30], uma abordagem no ensino de orientação a objetos.

Nota 2

A ideia de escrever esse texto surgiu depois de assistir à excelente apresentação Ágil é apenas uma expressão do Zeitgeist? [31] do Émerson Hernandez no Agile Brazil 2018 Campinas.

Nota 3

A linha do tempo completa e detalhada da Agilidade está disponível no site da Agile Alliance [32].

Nota 4

O título é uma (tentativa de) brincadeira com o livro Como chegamos até aqui: A história das inovações que fizeram a vida moderna possível, de Steven Johnson.

Referências

[1] http://www.melconway.com/research/committees.html

[2] https://www.thoughtworks.com/pt/insights/blog/demystifying-conways-law

[3] https://en.wikipedia.org/wiki/Wideband_delphi

[4] https://en.wikipedia.org/wiki/Planning_poker

[5] https://dl.acm.org/citation.cfm?id=807721

[6] https://en.wikipedia.org/wiki/Make_(software)

[7] https://www.agilealliance.org/glossary/automated-build

[8] http://leanblitzconsulting.com/2012/06/toyota-way-principle-7-visual-controls/

[9] https://www.agilealliance.org/glossary/information-radiators

[10] http://ronjeffries.com/xprog/articles/bigvisiblecharts/

[11] https://dl.acm.org/citation.cfm?id=802007

[12] https://en.wikipedia.org/wiki/Design_thinking

[13] http://thinking-forth.sourceforge.net/

[14] https://en.wikipedia.org/wiki/Code_refactoring

[15] https://dl.acm.org/citation.cfm?id=1012490

[16] https://dl.acm.org/citation.cfm?id=12944.12948

[17] http://www.enterprisescrum.com/publications/The%20New%20New%20Product%20Development%20Game%20-%20Nonaka%20and%20Takeuchi.pdf

[18] https://www.agilealliance.org/glossary/timebox

[19] https://en.wikipedia.org/wiki/Rapid_application_development

[20] http://www.amazon.com/dp/0023767758

[21] https://en.wikipedia.org/wiki/Scrum_(software_development)

[22] https://en.wikipedia.org/wiki/Continuous_integration

[23] http://kmvportal.co.in/Course/OOAD/object-oriented-analysis-and-design-with-applications-2nd-edition.pdf

[24] http://web.archive.org/web/20010503112119/www.controlchaos.com/sburndown.htm

[25] https://www.martinfowler.com/articles/originalContinuousIntegration.html

[26] https://en.wikipedia.org/wiki/Lightweight_methodology

[27] https://project-management.com/xp-fdd-dsdm-and-crystal-methods-of-agile-development/

[28] https://agilemanifesto.org/

[29] http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html

[30] http://c2.com/doc/oopsla89/paper.html

[31] https://www.slideshare.net/mersonHernandez/gil-apenas-uma-expresso-do-zeitgeist

[32] https://www.agilealliance.org/agile101/practices-timeline/

[33] https://www.amazon.com/dp/8537814121