Foto de Birmingham Museums Trust na Unsplash
Quando comecei a construir software, a engenharia por trás dos processos era fruto de anos de produção fabril. Projeto era gerido no modelo de cascata, um padrão herdado da linha de montagem: levantamento de requisitos, documento de especificação assinado, meses de desenvolvimento e, no fim, a entrega. Quase sempre o cliente olhava e dizia que não era bem aquilo. A culpa ia para o escopo (aquele que tinha sido escrito seis meses antes).
Depois veio o Kanban, com o quadro de post-its na parede e a ideia simples de limitar o trabalho em andamento. Veio o Scrum, com sprint de duas semanas, daily, planning, review e retrospectiva. Veio o DevOps, que juntou quem escrevia o código com quem colocava no ar, e a esteira de CI/CD (continuous integration / continuous delivery), que testa e publica automaticamente cada mudança no código e permite colocar versões novas no ar várias vezes por dia.
Cada uma dessas abordagens tentou reduzir, à sua maneira, o tempo entre a ideia e o software funcionando e a quantidade de gente necessária para percorrer esse caminho. Nenhuma substituiu a anterior por completo. Elas se somaram, e até hoje convivem na mesma empresa. Mas todas partiam da mesma premissa: software era feito por pessoas, e o processo existia para organizar o trabalho delas.
Até que veio a AI e mexeu nessa premissa. Uma parte crescente da execução já pode ser delegada a agentes, enquanto especificação, arquitetura, revisão e decisão de risco continuam com pessoas. O processo agora precisa organizar o trabalho que acontece de forma híbrida entre humanos e máquinas.



.jpg)




