<p>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.</p>
<p>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.</p>
<p><a href="https://dtidigital.com.br/blog/como-desenvolver-a-abordagem-agil/">A agilidade é uma resposta para essa necessidade</a>. Talvez por isso ande tão em voga.</p>
<p>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.</p>
<div id="toc_container" class="toc_white no_bullets"><p class="toc_title">Sum&aacute;rio</p><ul class="toc_list"><li><a href="#Para-entender-como-esse-processo-se-deu-vamos-voltar-51-anos-na-historia-da-humanidade"><span class="toc_number toc_depth_1">1</span> Para entender como esse processo se deu, vamos voltar 51 anos na história da humanidade</a><ul><li><a href="#1968Conways-Law"><span class="toc_number toc_depth_2">1.1</span> 1968 — Conway’s Law</a></li><li><a href="#1970sWideband-Delphi"><span class="toc_number toc_depth_2">1.2</span> 1970s — Wideband Delphi</a></li><li><a href="#1976Testes-unitarios-automatizados"><span class="toc_number toc_depth_2">1.3</span> 1976 — Testes unitários automatizados</a></li><li><a href="#1976Make-tool"><span class="toc_number toc_depth_2">1.4</span> 1976 — Make tool</a></li><li><a href="#1980sVisual-Controls"><span class="toc_number toc_depth_2">1.5</span> 1980s — Visual Controls</a></li><li><a href="#1984Prototipacao-e-Factoring"><span class="toc_number toc_depth_2">1.6</span> 1984 — Prototipação e “Factoring”</a></li><li><a href="#1985Evolutionary-Delivery-Model"><span class="toc_number toc_depth_2">1.7</span> 1985 — Evolutionary Delivery Model</a></li><li><a href="#1986Modelos-iterativos"><span class="toc_number toc_depth_2">1.8</span> 1986 — Modelos iterativos</a></li><li><a href="#1988Timebox"><span class="toc_number toc_depth_2">1.9</span> 1988 — Timebox</a></li><li><a href="#1991Rapid-Application-Development"><span class="toc_number toc_depth_2">1.10</span> 1991 — Rapid Application Development</a></li><li><a href="#1992Dynamic-Duo"><span class="toc_number toc_depth_2">1.11</span> 1992 — Dynamic Duo</a></li><li><a href="#1993StandUpMeeting-pattern"><span class="toc_number toc_depth_2">1.12</span> 1993 — StandUpMeeting pattern</a></li><li><a href="#1993Scrum"><span class="toc_number toc_depth_2">1.13</span> 1993 — Scrum</a></li><li><a href="#1994Continuous-Integration"><span class="toc_number toc_depth_2">1.14</span> 1994 — Continuous Integration</a></li><li><a href="#2000Burndown"><span class="toc_number toc_depth_2">1.15</span> 2000 — Burndown</a></li><li><a href="#2000Continuous-Integration-de-Martin-Fowler"><span class="toc_number toc_depth_2">1.16</span> 2000 — Continuous Integration de Martin Fowler</a></li><li><a href="#Primavera-de-2000Extreme-Programming"><span class="toc_number toc_depth_2">1.17</span> Primavera de 2000 — Extreme Programming</a></li><li><a href="#Fevereiro-de-2001Manifesto-for-Agile-Software-Development"><span class="toc_number toc_depth_2">1.18</span> Fevereiro de 2001 — Manifesto for Agile Software Development</a></li></ul></li><li><a href="#Agilidade-e-adaptacao"><span class="toc_number toc_depth_1">2</span> Agilidade é adaptação</a></li><li><a href="#Nota-1"><span class="toc_number toc_depth_1">3</span> Nota 1</a></li><li><a href="#Nota-2"><span class="toc_number toc_depth_1">4</span> Nota 2</a></li><li><a href="#Nota-3"><span class="toc_number toc_depth_1">5</span> Nota 3</a></li><li><a href="#Nota-4"><span class="toc_number toc_depth_1">6</span> Nota 4</a></li></ul></div>
<h2><span id="Para-entender-como-esse-processo-se-deu-vamos-voltar-51-anos-na-historia-da-humanidade">Para entender como esse processo se deu, vamos voltar 51 anos na história da humanidade</span></h2>
<h3><span id="1968Conways-Law">1968 — Conway’s Law</span></h3>
<p>No artigo <a href="http://www.melconway.com/research/committees.html">How Do Committees Invent?</a> [1], Melvin Conway propõe:</p>
<blockquote><p>“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.”</p></blockquote>
<p>Empresas como <a href="https://www.thoughtworks.com/pt/insights/blog/demystifying-conways-law">Netflix e a Amazon [2]</a>, 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]</p>
<h3><span id="1970sWideband-Delphi">1970s — Wideband Delphi</span></h3>
<p>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].</p>
<figure id="attachment_4042" aria-describedby="caption-attachment-4042" style="width: 337px" class="wp-caption aligncenter"><img fetchpriority="high" decoding="async" class="wp-image-4042 size-full" title="agilidade" src="https://dtidigital.com.br/wp-content/uploads/2019/01/15mt.png" alt="agilidade" width="337" height="237" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/15mt.png 337w, https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/15mt-300x211.png 300w" sizes="(max-width: 337px) 100vw, 337px" /><figcaption id="caption-attachment-4042" class="wp-caption-text">Wideband Delphi Technique</figcaption></figure>
<h3><span id="1976Testes-unitarios-automatizados">1976 — Testes unitários automatizados</span></h3>
<p>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.</p>
<figure id="attachment_4039" aria-describedby="caption-attachment-4039" style="width: 601px" class="wp-caption aligncenter"><img decoding="async" class="wp-image-4039 " title="agilidade" src="https://dtidigital.com.br/wp-content/uploads/2019/01/1_2U7q8Tl_AfsWecRDpxyz8Q.jpeg" alt="agilidade" width="601" height="338" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/1_2U7q8Tl_AfsWecRDpxyz8Q.jpeg 800w, https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/1_2U7q8Tl_AfsWecRDpxyz8Q-300x169.jpeg 300w, https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/1_2U7q8Tl_AfsWecRDpxyz8Q-768x432.jpeg 768w" sizes="(max-width: 601px) 100vw, 601px" /><figcaption id="caption-attachment-4039" class="wp-caption-text">makefile</figcaption></figure>
<h3><span id="1976Make-tool">1976 — Make tool</span></h3>
<p>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.</p>
<h3><span id="1980sVisual-Controls">1980s — Visual Controls</span></h3>
<p>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.</p>
<blockquote><p>“Use visual controls so no problems are hidden.”</p></blockquote>
<figure id="attachment_4041" aria-describedby="caption-attachment-4041" style="width: 460px" class="wp-caption aligncenter"><img decoding="async" class="wp-image-4041 size-full" title="agilidade" src="https://dtidigital.com.br/wp-content/uploads/2019/01/1_kcfrGnOS7d4FMJiSdYzsTg.png" alt="agilidade" width="460" height="346" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/1_kcfrGnOS7d4FMJiSdYzsTg.png 460w, https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/1_kcfrGnOS7d4FMJiSdYzsTg-300x226.png 300w" sizes="(max-width: 460px) 100vw, 460px" /><figcaption id="caption-attachment-4041" class="wp-caption-text">Visual Controls, Toyota</figcaption></figure>
<h3><span id="1984Prototipacao-e-Factoring">1984 — Prototipação e “Factoring”</span></h3>
<p>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]</p>
<p>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].</p>
<h3><span id="1985Evolutionary-Delivery-Model">1985 — Evolutionary Delivery Model</span></h3>
<p>Tom Glib apresenta um modelo incremental evolucionário de desenvolvimento de software — o Evolutionary Delivery Model, ou simplesmente EVO [15].</p>
<h3><span id="1986Modelos-iterativos">1986 — Modelos iterativos</span></h3>
<p>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.</p>
<figure id="attachment_4037" aria-describedby="caption-attachment-4037" style="width: 528px" class="wp-caption aligncenter"><img loading="lazy" decoding="async" class="wp-image-4037 size-full" title="agilidade" src="https://dtidigital.com.br/wp-content/uploads/2019/01/1_wQYW2vf5gCWr-4NV4T7fyw.png" alt="agilidade" width="528" height="480" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/1_wQYW2vf5gCWr-4NV4T7fyw.png 528w, https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/1_wQYW2vf5gCWr-4NV4T7fyw-300x273.png 300w" sizes="(max-width: 528px) 100vw, 528px" /><figcaption id="caption-attachment-4037" class="wp-caption-text">The New New Product Development Game</figcaption></figure>
<h3><span id="1988Timebox">1988 — Timebox</span></h3>
<p>O timebox é descrito como um fundamento do Rapid Iterative Production Prototyping [18], de Scott Schultz.</p>
<h3><span id="1991Rapid-Application-Development">1991 — Rapid Application Development</span></h3>
<p>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].</p>
<figure id="attachment_4036" aria-describedby="caption-attachment-4036" style="width: 199px" class="wp-caption aligncenter"><img loading="lazy" decoding="async" class="wp-image-4036 size-full" title="agilidade" src="https://dtidigital.com.br/wp-content/uploads/2019/01/5mt.jpeg" alt="agilidade" width="199" height="253" /><figcaption id="caption-attachment-4036" class="wp-caption-text">Rapid Application Development</figcaption></figure>
<h3><span id="1992Dynamic-Duo">1992 — Dynamic Duo</span></h3>
<p>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.</p>
<h3><span id="1993StandUpMeeting-pattern">1993 — StandUpMeeting pattern</span></h3>
<p>James Coplien apresenta o pattern StandUpMeeting.</p>
<h3><span id="1993Scrum">1993 — Scrum</span></h3>
<p>Jeff Sutherland cria o Scrum [21] como um processo na Easel Corporation.</p>
<h3><span id="1994Continuous-Integration">1994 — Continuous Integration</span></h3>
<p>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.</p>
<h3><span id="2000Burndown">2000 — Burndown</span></h3>
<p>Ken Schwaber descreve formalmente o burndown [24].</p>
<figure id="attachment_4038" aria-describedby="caption-attachment-4038" style="width: 600px" class="wp-caption aligncenter"><img loading="lazy" decoding="async" class="wp-image-4038" title="agilidade" src="https://dtidigital.com.br/wp-content/uploads/2019/01/6mt.jpeg" alt="agilidade" width="600" height="355" srcset="https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/6mt.jpeg 800w, https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/6mt-300x177.jpeg 300w, https://www.cms.dtidigital.com.br/wp-content/uploads/2019/01/6mt-768x454.jpeg 768w" sizes="(max-width: 600px) 100vw, 600px" /><figcaption id="caption-attachment-4038" class="wp-caption-text">burndown</figcaption></figure>
<h3><span id="2000Continuous-Integration-de-Martin-Fowler">2000 — Continuous Integration de Martin Fowler</span></h3>
<p>Ainda em 2000, Martin Fowler escreve e artigo Continuous Integration [25] e descreve as práticas de integração contínua usadas à época.</p>
<h3><span id="Primavera-de-2000Extreme-Programming">Primavera de 2000 — Extreme Programming</span></h3>
<p>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.</p>
<h3><span id="Fevereiro-de-2001Manifesto-for-Agile-Software-Development">Fevereiro de 2001 — Manifesto for Agile Software Development</span></h3>
<p>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].</p>
<h2><span id="Agilidade-e-adaptacao">Agilidade é adaptação</span></h2>
<p>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.</p>
<p>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.</p>
<p>Veja como transformar a sua empresa com o mindset ágil também em <strong><a href="http://www.cms.dtidigital.com.br/podcast/">nosso podcast “Os Agilistas”</a> </strong>!</p>
<h2><span id="Nota-1">Nota 1</span></h2>
<p>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.</p>
<h2><span id="Nota-2">Nota 2</span></h2>
<p>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.</p>
<h2><span id="Nota-3">Nota 3</span></h2>
<p>A linha do tempo completa e detalhada da Agilidade está disponível no site da Agile Alliance [32].</p>
<h2><span id="Nota-4">Nota 4</span></h2>
<p>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.</p>
<p>Referências</p>
<p>[1] http://www.melconway.com/research/committees.html</p>
<p>[2] https://www.thoughtworks.com/pt/insights/blog/demystifying-conways-law</p>
<p>[3] https://en.wikipedia.org/wiki/Wideband_delphi</p>
<p>[4] https://en.wikipedia.org/wiki/Planning_poker</p>
<p>[5] https://dl.acm.org/citation.cfm?id=807721</p>
<p>[6] https://en.wikipedia.org/wiki/Make_(software)</p>
<p>[7] https://www.agilealliance.org/glossary/automated-build</p>
<p>[8] http://leanblitzconsulting.com/2012/06/toyota-way-principle-7-visual-controls/</p>
<p>[9] https://www.agilealliance.org/glossary/information-radiators</p>
<p>[10] http://ronjeffries.com/xprog/articles/bigvisiblecharts/</p>
<p>[11] https://dl.acm.org/citation.cfm?id=802007</p>
<p>[12] https://en.wikipedia.org/wiki/Design_thinking</p>
<p>[13] http://thinking-forth.sourceforge.net/</p>
<p>[14] https://en.wikipedia.org/wiki/Code_refactoring</p>
<p>[15] https://dl.acm.org/citation.cfm?id=1012490</p>
<p>[16] https://dl.acm.org/citation.cfm?id=12944.12948</p>
<p>[17] http://www.enterprisescrum.com/publications/The%20New%20New%20Product%20Development%20Game%20-%20Nonaka%20and%20Takeuchi.pdf</p>
<p>[18] https://www.agilealliance.org/glossary/timebox</p>
<p>[19] https://en.wikipedia.org/wiki/Rapid_application_development</p>
<p>[20] http://www.amazon.com/dp/0023767758</p>
<p>[21] https://en.wikipedia.org/wiki/Scrum_(software_development)</p>
<p>[22] https://en.wikipedia.org/wiki/Continuous_integration</p>
<p>[23] http://kmvportal.co.in/Course/OOAD/object-oriented-analysis-and-design-with-applications-2nd-edition.pdf</p>
<p>[24] http://web.archive.org/web/20010503112119/www.controlchaos.com/sburndown.htm</p>
<p>[25] https://www.martinfowler.com/articles/originalContinuousIntegration.html</p>
<p>[26] https://en.wikipedia.org/wiki/Lightweight_methodology</p>
<p>[27] https://project-management.com/xp-fdd-dsdm-and-crystal-methods-of-agile-development/</p>
<p>[28] https://agilemanifesto.org/</p>
<p>[29] http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html</p>
<p>[30] http://c2.com/doc/oopsla89/paper.html</p>
<p>[31] https://www.slideshare.net/mersonHernandez/gil-apenas-uma-expresso-do-zeitgeist</p>
<p>[32] https://www.agilealliance.org/agile101/practices-timeline/</p>
<p>[33] https://www.amazon.com/dp/8537814121</p>


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

Desbloqueie o futuro do seu negócio

Confira outros artigos