Durante a formação para minha certificação CAC – Certified Agile Coach da Massimus, tive a oportunidade de participar de 2 módulos com o Peterson Larentis referentes a Agile Software Development e que trouxe a tona diversas situações que eu já defendia e já havia escrito a respeito. E o fato é que não existe um time ágil que não desenvolve software de forma ágil.

Mas como assim, como desenvolvemos software de maneira ágil?

Como será que o Scrum Dev Team vai desenvolver ágil? Será que é programando mais rápido? Trabalhando mais horas? Usando um framework milagroso que otimiza 50% do tempo? (Afinal o time deverá desenvolver o dobro na metade do tempo, principalmente se seu chefe só leu a capa do livro do co-criador do Scrum e do manifesto ágil Dr. Jeff Sutherland “A arte de fazer o dobro do trabalho na metade do tempo”). A resposta para estas perguntas são mais simples do que parecem.

Me formei em Ciências da Computação na Universidade Católica de Pernambuco em 2002 e mesmo antes de entrar nesse mundo acadêmico eu já trabalhava com programação (época de Clipper e Delphi), mas por falta de conhecimento, programava sem nenhuma técnica, simplesmente ia escrevendo o programa, sem se preocupar com usuário, com o aumento do processamento, com limitações de hardware, entre outras variáveis.

Houve muita evolução de lá pra cá… Surgimento de Programação Orientada a Objetos, por exemplo, foi um tapa na cara dos programadores acostumados com desenvolvimento procedural/estruturado.

Muitos programadores tiveram que aprender novamente, literalmente, a como programar com essa estrutura. Entender melhor sobre classes, métodos, linguagens interpretadas, abstração, polimorfismo, design patterns, entre outras técnicas, ferramentas e boas práticas que estavam surgindo a todo vapor.

Confesso que quando deixei de programar em Pascal/Delphi, Visual Basic e comecei a aprender Java, realmente vi que eu não sabia nada de programação.

Nessa mesma época, já começava também a desenvolver alguns web sites em HTML, CSS, Javascript, ASP 3.0, PHP, que eram totalmente diferentes também.

Voltando ao assunto original, o que aprendemos na Universidade sobre os melhores conceitos de Engenharia de Software e como obter os melhores benefícios e resultados sobre as melhores práticas de programação, na maioria das vezes ficavam de fato somente no mundo acadêmico.

Me falavam que na vida real era diferente, que precisava entregar os projetos para os clientes para começarmos sustentação e liberar as equipes para novos projetos.

Muitos programadores da old-school ainda hoje, trazem consigo muito dessa cultura, que para o mundo atual já não faz mais nenhum sentido.

Pegávamos projetos de escopo fechado, passávamos semanas, quiçá meses, escrevendo documentação em UML, especificação de requisitos, modelagem de banco de dados, antes mesmo de iniciar a programação. Quando íamos programar o tempo era mais curto do que o que tinha sido vendido e os programadores para entregar os projetos no prazo, tinham que trabalhar até mais tarde, fins de semana, para não correr o risco da empresa contratante não cobrar multas.

O que acontecia nesses casos, o código que era gerado era em muitas vezes de má qualidade, pois os testes eram deixados de lado, ou só faziam os velhos testes (pelo caminho feliz).

O programa ia para a área de QA (quando tinha) e o que acontecia? Bugs e mais bugs, que geravam uma lista enorme para os programadores corrigirem suas “gambiarras”, o que atrasava ainda mais a entrega dos projetos.

Quando acabavam todos os testes e os bugs eram corrigidos, começava uma nova via-crucis que era fazer deploy no ambiente do cliente. O que acontecia em muitas vezes? No ambiente do cliente não funcionava, pois era diferente do ambiente de desenvolvimento e nessas horas, ouvíamos aquelas frases prontas:

  1. Mas na minha máquina ou no meu ambiente funcionava!
  2. Ah, mas isso é problema de infra-estrutura ou de redes!
  3. A equipe de infra, falava: Ah! O problema é na programação que foi mal feita.

Entre outras frases clássicas que viraram verdadeiros chavões.

O que acontecia? (Será que em alguns lugares ainda acontece? Fica a dúvida)

A TI não entrega no prazo, TI entrega os projetos com problemas, TI não dá suporte e não resolve os problemas em ambiente de produção.

Mas daí então, chegou a bala de prata, “metodologias e frameworks” ágeis, como Scrum, Kanban e XP. Daí começa então o monte de quadros e paredes cheias de Post-Its nas salas, Trello, Jira, TFS, entre outras ferramentas para acompanhamento de Sprints e Releases.

Na maioria dos casos, melhorou muito, pois os erros e problemas eram encontrados mais rápidos, as empresas começaram a ver valor e a disseminação da cultura ágil começou a ser propagada com muita rapidez.

Diversas certificações, cursos, workshops, treinamentos, formação de Scrum Masters, Product Owners e demais outros papéis que foram criados nesse meio tempo.

Só que continuávamos criando produtos sem nos atentar a princípios básicos e importantes de Engenharia de Software.

Uma nova forma de Desenvolvimento de Software

Mas graças a Deus (ou a entidade que você preferir rs..), isso avançou bastante, as empresas, consultorias começaram a enxergar valor nisso e então passaram a investir em mão de obra especializada, arquitetos de sistemas, a investir em testes de software automatizado, através de BDD (Behavior-Driven Development) e TDD (Test-Driven Development), só que pessoas nesse perfil eram poucas, caras e muitos insistiam a não ver valor nisso e sim só custo.

Cresceu com uma ótima fluidez a cultura DevOps, onde a galera sempre injustiçada de infra, começou a desenvolver bastante programação, criação de máquinas virtuais, imagens de servidores em Docker, uso Kubernetes para fazer a orquestração dessas novas imagens de máquinas criadas em Docker.

Cresceu a adoção de softwares como: Sonar Qube, Codacy que realizam inspeção da qualidade do código para revisões automáticas, detecção de bugs e vulnerabilidades de segurança e ferramentas de automação de teste como: Cucumber e Selenium.

Cada vez mais a equipe DevOps está sendo envolvida desde o início dos desenvolvimentos dos produtos, participando de reuniões de planejamento, Lean Inception ou Design Sprint, colaborando com o Dev Team nos deploys cada vez mais automatizados e frequentes.

Concluindo

Não existe Desenvolvimento Ágil de Software sem usar as melhores práticas e técnicas de engenharia de software, sem usar metodologias como XP (independente da linguagem de programação), sem usar um framework ágil (como o Scrum, com o método Kanban), assim como uso de técnicas de desenvolvimento de software BDD, TDD, Continuous Integration (CI), Continuous Delivery (CD), versionamento integrado e acima de tudo um time único, sem “mimimi” por ser de desenvolvimento ou de infra-estrutura, afinal, trabalha-se geralmente numa mesma empresa e o objetivo comum que é entregar o melhor software e ambiente tecnológico para atender o cliente da empresa.

Se alguém se interessou pelo tema, existe um EAD específico no site da Massimus que eu recomendo fortemente e de preço super acessível.

ASD – Agile Software Development – https://ead.massimus.com/asd-agile-software-development

 

Vamos discutir o tema com a comunidade, compartilhe, comente sua experiência, dê like no artigo para ele ganhar relevância, vamos falar sério sobre o tema.

E ai seu time é ágil mesmo ou estão fazendo Go Horse com Post-it?