Esta é a tradução do texto original de Martina Šnajder, publicado no blog da Infinum. O artigo pode ser acessado aqui, e todos os créditos são devidos ao autor, Martina Šnajder.
Se você é um ser humano com uma TV, provavelmente está familiarizado com a Fórmula 1. Os não-fãs podem descrever como um bando de caras dirigindo em círculos por 2 horas até que alguém ganhe, e como uma completa perda de tempo para assistir.
Para os fãs, a F1 é muito mais – trata-se de estratégias, temperaturas dos pneus, pit stops e chuva na pista, para citar alguns elementos.
Agile e desenvolvimento de software: dois esportes coletivos comparados
Se você trabalha com desenvolvimento de software, provavelmente está familiarizado com o Agile ou talvez até esteja trabalhando em um de seus frameworks. Agile é uma mentalidade definida por quatro valores, guiada por 12 princípios, e manifestada por meio de muitas práticas diferentes. E, assim como a F1, você ou ama ou acha que não faz sentido.
Essa não é a única semelhança entre eles, então junte-se a mim enquanto traço paralelos entre esses dois esportes coletivos.
Time, time, time
Você leu corretamente – tanto a F1 quanto o Agile são esportes coletivos. E enquanto no Agile os times são mantidos relativamente pequenos, as equipes de F1 podem ter mais de 1000 pessoas, se o orçamento permitir. Assim, além de dois pilotos, você encontrará um chefe de equipe, mecânicos de corrida, engenheiros de corrida, cientistas de dados e muitos outros especialistas. Todos estão trabalhando juntos como uma equipe em direção ao objetivo comum – vencer o campeonato de pilotos e construtores acumulando pontos em 22 corridas através de cinco continentes ao longo de uma temporada ou nove meses. As equipes são multifuncionais, compostas por profissionais motivados que cada um contribui para o quadro maior.
A Fórmula 1 é um esporte que progrediu muito em seus quase 100 anos de história. Não só os carros são mais rápidos agora, mas eles estão utilizando muitas tecnologias que pessoas dos anos 1920 nem poderiam imaginar.
Para criar algo novo e inovador, as pessoas precisam ser altamente motivadas, mas também precisam ser capazes de falhar sem consequências ou punições. Não é o medo de falhar que impede as pessoas, é o medo das repercussões dessa falha.
Não há espaço para uma cultura de culpa em um ambiente rápido e estressante como uma corrida de F1. As equipes às vezes precisam tomar decisões em frações de segundos, e você quer que elas sejam capazes de fazer isso sem medo do que acontecerá se a decisão estiver errada. Se falharem, falham juntas. Elas aprendem com isso e voltam mais fortes.
Um time prospera em um ambiente saudável, recebendo o apoio e a confiança de que precisa. Quando as pessoas sentem que seu trabalho contribui para algo maior e se sentem ouvidas e valorizadas, isso as motiva a trabalhar ainda mais. Essas são as pessoas que você quer na sua equipe.
O mesmo precisa acontecer no desenvolvimento de software. Se queremos construir produtos de qualidade que façam nossos usuários felizes, precisamos dar espaço para as pessoas falharem e aprenderem com seus erros.
Se olharmos para a equipe de F1 por outro ângulo e colocarmos o piloto de F1 no papel de usuário, você também pode ver como é vital a colaboração diária entre ele e o restante da equipe. Ele é quem está dirigindo o carro e pode fornecer o melhor feedback à equipe sobre como melhorar o desempenho do carro. Nossos usuários finais são aqueles que deveriam guiar o desenvolvimento de nossos produtos. Não faz sentido construir algo que ninguém vai querer ou ser capaz de usar.
“Você não espera estar no topo da montanha no dia em que começa a escalá-la.”
— Ron Dennis, CEO da McLaren
Eu quero ir rápido!
Agile é frequentemente associado à velocidade. Mas isso não significa que os desenvolvedores vão programar mais rápido. Isso significa que estamos focados em entregar funcionalidades de aplicativos pouco a pouco, mas com mais frequência. Agile significa priorizar os recursos essenciais e deixar o resto para versões futuras – é por isso que chamamos a primeira iteração de minimum viable product (MVP). Ciclos de desenvolvimento curtos permitem que as marcas lancem produtos mais cedo, obtenham feedback sobre eles e possam reagir rapidamente às tendências e mudanças de mercado.
Na F1, os carros mudam a cada temporada, e o carro de cada temporada é a evolução do anterior. Eles constroem um protótipo a cada ano, colocam-no na pista, aprendem algo novo em cada corrida, melhoram-no e depois o testam novamente. O mesmo ocorre no desenvolvimento Agile. Normalmente, você começa com algum MVP, o lança para os usuários, coleta seu feedback e, com base nisso, trabalha em melhorias e novos recursos.
As corridas de F1 acontecem quase todo fim de semana, dando às equipes um ciclo de feedback curto, algo valioso no Agile. Em vez de tentar planejar cada situação ou problema possível com antecedência, eles lidam com uma corrida de cada vez. Ao dar esses pequenos passos, acabam a temporada com o melhor carro possível.
A preferência do Agile por curtas iterações no desenvolvimento de software tenta fazer o mesmo. Não só permite construir seus produtos passo a passo, mas também oferece mais oportunidades para uma melhor gestão de riscos. Se você não sabe o que está à frente, não faz sentido perder tempo planejando tudo que pode acontecer. Em vez disso, pense nos seus objetivos de curto prazo e prepare-se para eles – tanto em como você deseja alcançá-los quanto em como mitigar possíveis riscos.
Copy, Lewis, vamos conversar depois
Um dos pilares do Agile é a reflexão constante. Chame de retrospectiva, inspeção e adaptação ou lições aprendidas. O ponto é o mesmo – aprender algo com o que você acabou de passar. Não há progresso sem mudança. Você precisa aprender com suas experiências passadas para se tornar melhor. Como equipe, como desenvolvedor e como pessoa. Em ambientes acelerados como a F1 e o desenvolvimento de software, sempre haverá algo que você poderia ter feito melhor.
As equipes de F1 sabem bem disso. Quer um Grande Prêmio tenha corrido bem ou mal, elas conversam sobre tudo o que aconteceu ao longo do fim de semana para ver o que pode ser aprendido. Elas destacam os pontos positivos, mas também examinam o que deu errado e como evitar isso no futuro. Isso une toda a equipe, tanto as pessoas na pista quanto na fábrica, para dar seu feedback, perspectiva e visão geral da corrida. Como resultado, elas saem disso mais inteligentes e mais focadas para a próxima corrida.
“Se tudo parece estar sob controle, você simplesmente não está indo rápido o suficiente.”
— Mario Andretti, ex-piloto campeão de F1 em 1978
Bandeira quadriculada
Se a abordagem Agile funciona para algo tão complexo quanto construir o carro mais rápido da Fórmula 1, você pode ter certeza de que funcionará para o seu próximo projeto de desenvolvimento de software. Dê à sua equipe a chance de conversar com seus usuários. Confie que eles sabem o que estão fazendo. Dê a eles um ambiente seguro onde possam falhar e ajude-os a aprender com seus erros.
Leve a palavra de Guenther Steiner a sério.
Treinamentos relacionados com essa postagem
