Que o Manifesto Ágil foi escrito há 15 anos, nós já sabemos. Mas qual será a história por de trás desse documento?
Vamos voltar o relógio alguns anos atrás, mais precisamente para o final do século XVIII.
Em 1785 em Paris, Honoré Blanc, um fabricante de armas da França, convocou militares e diplomatas a seu ateliê a fim de demonstrar um novo método de fabricação em escala. Esse processo era feito através de partes intercambiáveis.
Um dos diplomatas presentes era Thomas Jefferson, que viria, anos mais tarde, a se tornar presidente dos EUA. Que acabava de conseguir sua independência e também precisavam de armamento para seu projeto expansionista. O México que o diga. Jefferson percebeu que, através do processo de Blanc, uma grande quantidade de armas poderia ser facilmente produzida por trabalhadores levemente desqualificados.
O engenheiro Eli Witney foi encarregado de adaptar esse método para o contexto americano. O que mais tarde ficou conhecido como sistema americano de produção. O que fez com que os EUA se tornassem a potência que conhecemos hoje. Mas a história não acaba aí…
Em 1914, em Detroit, EUA, Henry Ford aplica as ideias do especialista Frederick Taylor e dá inicio a um processo de linha de montagem que mudaria a história para sempre. Ele reduziu em 85% o trabalho de produzir um carro e aumentou o salário dos trabalhadores para que os mesmos se transformassem em potenciais consumidores. Ajudando a criar uma nova classe média.
Esse processo ficou conhecido como Modelo T e foi bastante eficiente por um certo tempo. Neste modelo, os trabalhadores é que eram intercambiáveis, pois era relativamente barato trocar um trabalhador caso ele viesse a ficar incapaz por uma lesão de esforço repetitivo, por exemplo. Nem é necessário explicar que o modelo T se tornou impraticável pois as condições de trabalho ficaram insustentáveis. O que causou uma agitação trabalhista na década de 30.
Trabalhar na linha de montagem era uma tarefa, desgastante, repetitiva, monótona e altamente controlada. No entanto, o modelo T iria influenciar uma indústria, a qual as pessoas nem faziam ideia que viria a surgir alguns anos mais tarde.
Na década de 60, a indústria do software já era consolidada. Tanto que já estava em crise.
Em 1968, foi reconhecido oficialmente a existência da chamada Crise do Software. Foi observado que cerca de 80% de projetos de software não eram entregues. Dos 90% que foram concluídos, terminaram 150 a 400% acima do orçamento e do prazo estipulado. Além de que eram entregues repletos de falhas e funcionalidades desnecessárias.
Naquele mesmo ano, ocorre, em Garmisch, na Alemanha, uma conferência na OTAN sobre Engenharia de Software chamada Conferência da OTAN sobre Engenharia de Software. O objetivo era discutir e mostrar possíveis soluções para a Crise. A conferência foi um marco na indústria, pois é conhecida como o nascimento da disciplina de Engenharia de Software.
Em 1986, Alfred Spector, então presidente da Transarc Corporation, foi coautor de um artigo comparando a construção de pontes ao desenvolvimento de software. Ele apontou que as pontes eram construídas no tempo planejado, no orçamento planejado, e nunca caiam. Enquanto que softwares nunca ficavam prontos dentro do prazo, do orçamento, e, quase sempre apresentavam problemas.
Mas os problemas reais começaram lá em 68. Lá naquela conferência em Garmisch. A Engenharia de Software surgiu com o objetivo de atender as necessidades dos projetos da OTAN, que eram projetos de grandes sistemas de defesa. Bem diferentes de sistemas comerciais. No entanto, a indústria adotou a Engenharia de Software com o objetivo de atender o mesmo nível de previsibilidade de outros ramos da engenharia.
A Engenharia de software deu início a uma gama de processos de desenvolvimento. Dentre eles estava o famoso Modelo Cascata. E que, por sua vez, deu origem ao falido modelo de fábricas de software. O processo cascata organiza os projetos em etapas realizadas sequencialmente.
Esse modelo faz com que o processo de desenvolvimento se assemelhe a uma linha de produção do Modelo T. Como resultado é gerado uma série de artefatos, representados através de pilhas de documentações. Gerando desperdício através de formalismos e burocracia, além de gerar conflitos de interesses entre equipe de desenvolvimento e clientes e potencializar conflitos dentro do próprio time. Tal processo é incapaz de levar o fator humano em consideração.
Assim, a Engenharia de software, contribuiu para o agravamento da Crise do Software.
A organização The Standish Group publica em 1995, um relatório chamado Chaos Report. E revela, dentre outros dados bizarros, que empresas públicas e privadas gastaram 81 bilhões em projetos cancelados nos EUA e mais de 59 bilhões em projetos entregues com prazo estourado.
No mesmo ano, Jeff Sutherland e Ken Schwaber, mostram ao mundo um framework que eles haviam desenvolvido e já aplicado em algumas empresas, o Scrum. A primeira implementação completa do pensamento Lean na indústria de software.
Ainda em 95 Jim Coplien e Larry Constantine simultaneamente, mas independentemente fazem publicações sobre programação em par.
Em 1999, James A. Highsmith publica seu livro Adaptive Software Development. No mesmo ano, Andrew Hunt e Dave Thomas publicam O Programador Pragmático. Kent Beck publica sobre uma metodologia que ele havia desenvolvido com a colaboração de Ward Cunningham e Ron Jeffries, o Extreme Programming.
Em 2000, Bob Martin tem a iniciativa de organizar uma reunião em um resort de ski em Utah. Uma reunião que viria a mudar a indústria para sempre, só que dessa vez para melhor. Profissionais experientes e que estavam trazendo inovação para a indústria se reuniram no resort para discutir alternativas aos processos falidos que estavam sendo utilizados em projetos de software mundo afora.
Eles decidiram usar o termo desenvolvimento ágil e criaram um manifesto que estabelece um conjunto de princípios e valores que devem ser adotados em projetos de software.
A proposta é fazer o mínimo necessário com o máximo de resultados. Uma clara influencia do pensamento Lean. Começar projetos de forma simples, avaliar os resultados e atribuir melhorias quando necessário.
Hoje, métodos ágeis vem sendo largamente adotados em inúmeros projetos. Vamos aguardar os futuros Chaos Report, mas parece que as previsões são otimistas.
Agradecimentos a Fábio Lima por ter revisado o post.
Deixe um comentário