Chega mais! Este artigo é uma reflexão sobre o que ainda nos falta após 20 anos de lançamento do Extreme Programming.
Mais de 20 anos atrás, em 1996, o primeiro projeto de eXtreme Programming foi iniciado, mas olhando para os dias atuais, será que amadurecemos o suficiente em relação a suas filosofias e práticas?
Primeiramente, para entendermos onde estamos, há a necessidade de olharmos de onde partimos e então analisarmos onde chegamos.
O Modelo Waterfall
Em 1970, em meio aos primeiros anos da computação de larga escala, o Professor Winston Royce propôs um modelo de desenvolvimento de software (método) batizado de waterfall, modelo o qual, propunha que o trabalho fosse seguido de forma cascateada, fase após fase.
Entretanto, o mesmo artigo que descreveu este modelo cascateado propunha a existência de feedback entre cada etapa, porém não com etapas tão “afastadas” da etapa em que se encontra.
Modelo cascata sem feedback
Modelo cascata com feedback
Ainda que houvesse boa intenção em propor a possibilidade de um modelo com feedback em etapas, pois uma das poucas certezas que possuímos em nosso ofício é o princípio da incerteza, em software tudo muda, desde os requisitos até o humor daqueles que entregam.
Este modelo surgiu como uma primeira “bala de prata” para nossa forma de trabalho e o modelo cascateado sem feedback foi o que brilhou aos olhos do mercado.
O impacto da crença em uma bala de prata na época nos levou ao que ficou conhecido na como a Crise do Software (1970) e seus impactos foram registrados na história no famoso CHAOS REPORT (1995).
Tempos difíceis onde apenas 16.2% dos projetos feitos alcançaram sucesso em tempo e custo, 52.7% possuíam problemas com compromissos de entrega com redução de features ou estouro de orçamento e 31.1% com projetos completamente cancelados.
Os anos se passaram, nossos erros foram reconhecidos e admitidos, e na década de 90 chegamos a um consenso sobre uma nova forma de trabalho, processos leves, foco em iterações curtas, gestão de risco de curto prazo, diminuição da documentação desnecessária (Big Design Up front) e relacionamento entre pessoas (sim, software é feito por pessoas) lideraram o tom da nova forma de trabalho em nosso ofício.
Manifesto Ágil
Como consequência, em 2001, um grupo reunido por algumas das pessoas mais influentes do mercado de software escreveram um dos manifestos mais importantes que iria direcionar o pensamento de toda uma geração futura sobre como desenvolvemos software, o “Manifesto Ágil”.
Apesar de não chegarem em um comum acordo sobre como devemos produzir software, ao menos chegamos em um acordo sobre o que deveria ser a forma como fazemos software e o que deveria ser mais valorizado nessa atividade.
Com o passar dos anos vimos esse movimento crescer, alianças e grupos se desenvolvendo, certificações sendo criadas, alguns métodos atingindo o mainstream e uma corrida de empresas para alcançar a sua tão sonhada “transformação ágil”, pois se você não for ágil estará fadado a ficar para trás, como o próprio mercado definiu.
Mais de 20 anos depois, acompanhando o crescimento deste “movimento”, vimos o amadurecimento de todo um mercado e consequentemente o destaque de alguns dos métodos propostos para essa forma de trabalho se destacando em relação aos demais.
Desde a sua primeira versão, 13 anos trás, o “The State of Agile”, questionário sobre o estado do movimento e uso do ágil aplicado em empresas do mundo todo nos demonstrou um firmamento e preferência por um método em relação aos demais.
Ao olharmos para o último relatório publicado em 2019, o Scrum se mantém e é o método, processo, forma de trabalho (ou seja lá como o chamemos) mais adotado no mundo, assim, se tornando o mais popular no mundo do software.
Prós e contras
A adoção por tal método em específico trouxe, como tudo, prós e contras em termos de mentalidade de mercado.
A corrida por “educação” em Scrum fez com que muitos grupos pudessem oferecer treinamentos e certificações sobre o tema, gerando assim um lucrativo mercado (até os dias atuais) onde muitas empresas e pessoas recorrem como forma de colocar seus times em um caminho onde seu trabalho e entrega estejam em alinhamento com aquilo que foi pregado pelo “Manifesto”. Por outro lado também ajudou positivamente a disseminar as ideias da corrente de pensamento “ágil” ao maior número de profissionais possível.
Entretanto, no lado negativo de tudo isso é que a predileção por apenas uma forma de trabalho pode nos levar a ignorarmos aspectos importantes que são contemplados por outros pontos de vista que diferentes deste foque em algo que vá além do “processo de software”.
Por consequência, diversas empresas (como no movimento Cascata), correram para essa fonte de sabedoria, com a crença de que se seguirem as cerimônias e produzirem os artefatos recomendados estariam, automaticamente, se valendo dos benefícios dessa “nova forma de trabalho” e tudo o que ela tem a oferecer.
Entretanto, o Scrum, por se tratar de um método não prescritivo e que, em sua essência, apenas trata da gestão da carga de trabalho, ou melhor, do fluxo que o trabalho deveria seguir em termos de como as coisas devem ser levadas ao time para que este o desenvolva, deixou uma lacuna muito importante, a da Engenharia.
Quando pensamos em Engenharia, em termos de software, nos referimos as ferramentas e meios que utilizamos para chegarmos em nosso objetivo final. Sejam estes o código, o design de uma arquitetura ou até mesmo uma classe, do nível de qualidade que aceitamos e até onde nos preocupamos com o que testamos (e em qual nível).
Se olharmos para Agilidade, se a definirmos pela fórmula Agilidade = Produto + Processo e Engenharia, como gosto de visualizar o trabalho que fazemos, nos faltaria uma perna deste tripé, a Engenharia, dado que Scrum dá certas diretrizes relacionada ao Produto e apresenta um Processo claro de como podemos conduzir nosso trabalho.
Voltando nossos olhos ao que a Programação Extrema nos oferece, de forma clara, em termos de práticas como: propriedade coletiva, padrões de código, testes (sejam de clientes, unitários, integração e dirigidos ao desenvolvimento ou não), design simples, integração contínua e até mesmo programação em pares, vemos uma explícita preocupação sobre o ofício de produzir software, a escrita do código e como evoluirmos a arquitetura daquilo que produzimos como resultado de nosso trabalho.
Anos se passaram e, algumas dessas coisas, de forma independente, ganharam notoriedade como TDD ou Integração contínua, mas por quê ainda temos problemas relacionados a Engenharia e em certa proporção, não entregamos as coisas com a preocupação que as boas práticas exigem?
Olhando pela popularidade que outras formas de trabalho tomaram e ainda tomam, em relação a Programação eXtrema, fica o sentimento de “foquemos no processo que, a engenharia, podemos tentar endereçá-la em outro momento”.
Essa falsa ilusão de que, se o processo estiver sendo seguido a risca e as pessoas envolvidas, tudo vai dar certo no final, é uma auto-enganação, pois desenvolvedores manifestam preocupações que muitas vezes impactam no resultado final daquilo que entregamos e consequentemente em sua evolução, se pensarmos em termos de produto ou plataforma.
Dívidas técnicas, arquiteturas frágeis ou não escaláveis podem impactar tanto uma entrega quanto uma história mal escrita, e se essas coisas causam grande impacto em nosso dia a dia, é imaginável que o quanto negligenciarmos a qualidade, seja em termos de testes ou de código isso possa se voltar contra nós em um futuro não tão distante.
Olhando para o mercado, vemos novas bandeiras sendo levantadas, como DevOps e entre outras, que aproximam o desenvolvimento da infraestrutura (e até da segurança) da escrita do software (e isso é bom).
Entretanto, essas novas “culturas” nasceram de fontes também oriundas do mesmo “manifesto ágil” e que se propõe a aproximar não somente as pessoas, mas áreas que antes distantes, hoje, podem atuar juntas como uma só unidade, aproveitando ao máximo de nossas capacidades em termos de engenharia buscando uma qualidade cada vez maior em nossa ofício.
Sejamos honestos e, principalmente, responsáveis, atualmente todos os times desejam Integração contínua e Implantação contínua (seja lá o que for isso), mas será que fazemos isso da forma correta desde o dia 0 de nossos times? Ou será que estamos seguindo um caminho apenas bom e que, por desconhecimento, nos traz apenas resultados limitados e que os aceitamos como suficientes?
Temos um fluxo de tratamento de código em repositórios em nuvem (a.k.a GitFlow) que atendam a todas as especificidades de nossas equipes? E será que quando nossos códigos sobem para tais plataformas, sendo eles testados, analisados automaticamente (em termos de padrões e boas práticas), alimentando com informações que possam nos ajudar em termos de uniformidade sobre aquilo que produzimos?
Uma coisa que costumo dizer, “fazer software é fácil, o difícil é que se leva 10 anos para formar um bom engenheiro de software”, parafraseando um antigo professor, e depois de algum tempo, percebendo que aquela lei das 10 mil horas possam estar alinhadas a esse conceito, vejo que devemos olhar para além de Analisar, Desenhar, Implementar, Testar e, com sorte, Entregar.
O racional aqui, que fique claro, não é criticar uma forma A ou B em como se produz software. A intenção é proporcionar uma auto reflexão se estamos realmente olhando para tudo o que é importante em nosso ofício, ou se estamos simplesmente negligenciando outras em detrimento de uma “onda” ou predileção de massa e deixando para trás ideias tão importantes quanto ter nossos usuários/clientes próximos de nós, não que isso não seja muito importante, mas não é somente com isso que que bons softwares são construídos.
Como reflexão, e se baseando em um estudo científico de 2018 [7], “An Analysis of agile practices in Brazilian Startups”, pensemos em nossa forma de trabalho como um grande quadro branco. Este quadro precisa de um começo, como tudo, e que comecemos sempre da forma mais simples, experimentando coisas minimamente importantes para o nosso dia a dia e, com o tempo, incrementando coisas novas que possam trazer amadurecimento para o que fazemos como um todo.
Voltando nossos olhares para métodos importantes como a Programação eXtrema e, ainda que não a sigamos de forma estrita, se dermos atenção a suas práticas e princípios talvez possamos preencher algumas das lacunas que nos estejam faltando. E isso não significa que tudo estará resolvido magicamente ou que simplesmente programação em pares fará com que tenhamos as menores taxas de erros jamais vistas, não sejamos inocentes.
Coisas simples em nosso dia a dia que podemos estar negligenciando, como nossa integração contínua, se dois desenvolvedores trabalhando juntos não é algo viável, nem que de vez em quando, que façamos revisão de código ao submetermos novas funcionalidades a um repositório principal. Além de evitarmos erros antes de promovê-las a ambientes de testes, a revisão fará com que outras pessoas possam entender o que foi pensando como as coisas estão sendo feitas e o resultado pode ser até melhor do que esperamos.
Tenhamos sempre em mente o mantra KISS – “keep it simple, stupid”
Que melhorias sejam testadas em pequena escala, mudanças controladas e gestão de risco “tijolinho a tijolinho”.
Voltemos a criar o discernimento sobre aspectos importantes relacionados à Engenharia, voltemos nossa atenção a princípios e ideias tão simples quanto as pregadas pela Programação eXtrema, há mais de 20 anos atrás.
Sejamos honestos, a busca pela agilidade não pode se tratar apenas de um belo processo e envolvimento motivacional, é preciso seriedade, uma grande gestão de produto e a melhor engenharia e qualidade que possamos proporcionar, tudo isso, melhorando e evoluindo, dia após dia.
Se o refinamento de uma iteração é algo tão importante e realizado, que seja, semanalmente, por que não fazemos cerimônias em semelhante formato que revisem nossa arquitetura e, com isso, possa promover refatorações constantes sobre aquilo que já construímos?
Será que não está na hora de um “back to basics”, 20 anos atrás, e prestarmos atenção nas coisas valiosas que talvez tenhamos deixado para trás?
E você, o que acha? Deixe nos comentários sua opinião sobre Extreme Programming!
Algumas referências usadas
- Managing the development of large software systems, disponível aqui.
- “No Silver Bullet – Essence and Accident in Software Engineering”, Fred Brooks.
- The Standish Group Report, veja por aqui.
- The Agile Manifesto
- Agilidade = Produto + Processo + Engenharia
- An Analysis of agile practices in Brazilian Startups, 2018
Zup Open Talks com Kent Beck
O Zup Open Talks é uma iniciativa que reúne grandes nomes do mercado de tecnologia para incentivar a troca de conteúdo técnico, gerar discussões e novas ideias.
Quer assistir ao Kent Beck, criador do Extreme Programming e um dos signatários do Agile Manifesto em 2001, em um evento online exclusivo? Assista agora ao Zup Open Talks com Kent Beck.
