Se fazes parte de uma equipa técnica, já deves ter ouvido a seguinte frase nalgum momento da tua carreira: “A tua equipa não é ágil? Então não devias ter terminado esta tarefa mais rápido?”

[Nota do editor: este artigo foi originalmente publicado em junho de 2023 e revisto de forma a melhorar a compreensão e a pertinência do mesmo].

Talvez revires os olhos ou, pelo menos, penses no assunto. Contudo, quem diz isto não está totalmente errado. Agile, ou Ágil, em Português, é uma abordagem que pretende acelerar a entrega. A Atlassian faz referência a isso no seu website:

A agilidade é uma abordagem iterativa à gestão de projetos e ao desenvolvimento de software que ajuda as equipas a entregar valor aos seus clientes mais rapidamente e com menos dores de cabeça.”

Ainda assim, neste artigo, vou tentar explicar por que razão ser ágil não significa necessariamente que vais terminar o projeto mais depressa; significa que a equipa pode produzir pequenos resultados mais rapidamente, proporcionando uma maior adaptabilidade a mudanças futuras.

Uma nota importante: todas as pessoas envolvidas no projeto devem compreender a mentalidade ágil. Se uma empresa tenta ser ágil mas tem como prioridade terminar todas as tarefas rapidamente, estará a evitar os princípios desta abordagem. Desta forma, o projeto não será suficientemente flexível quando for necessário fazer mudanças e demorará mais tempo a ser concluído.

Por isso, neste artigo, vou tentar esclarecer o impacto de usar (ou evitar) os princípios da agilidade. Se é a primeira vez que ouves falar desta abordagem, então lê este artigo, para poderes compreender primeiro os conceitos básicos.

O Significado de “Ágil”

De acordo com o dicionário Priberam, ágil significa:

“Que se move com presteza e facilidade.”

Repara que a palavra rapidez ou rápido nem sequer é referida na lista de sinónimos.

Para as empresas, a Agilidade significa ser capaz de mudar os planos do projeto com rapidez e facilidade.

Mas como é que uma empresa se torna ágil?

A Agilidade tem várias frameworks que podem ajudar nessa transformação, para este artigo, vou usar o Scrum como exemplo.

Portanto, vamos começar por falar sobre como o Scrum funciona e como pode ajudar a empresa a ter uma mentalidade ágil.

A maioria dos projetos de IT não segue uma linha reta, falhas acontecem e os planos mudam ao longo da fase de desenvolvimento, mas com o Scrum, o projeto pode ser mais adaptável quando se trata de resolver esses problemas.

Uma vez que o Scrum tenta separar o projeto em pequenas partes que podem ser planeadas e entregues em curtos períodos (2, 3 ou 4 semanas). Esta abordagem oferece maior flexibilidade, permitindo que a equipa se adapte rapidamente e ajuste o rumo conforme necessário. Ao entregar de forma incremental, a equipa pode incorporar feedback desde cedo e fazer as alterações necessárias antes do próximo sprint, garantindo progresso contínuo e capacidade de resposta às necessidades em evolução.

Funções da Equipa Scrum

Uma equipa Scrum é composta por:

• Product Owner
• Programadores
• Scrum Master

Todos os projetos têm uma lista de tarefas – também conhecido por product backlog – a realizar. O product backlog consiste num conjunto de pequenas tarefas que serão desenvolvidas num curto período de tempo.

O product owner cria e gere o product backlog. As suas responsabilidades incluem a compreensão dos requisitos do cliente e do negócio, transformando-os em tarefas, adicionando-os ao product backlog e definindo o valor e o objetivo de cada sprint.

Os membros da equipa de desenvolvimento dedicam-se a concluir as suas tarefas no sprinte a fazer avançar o projeto.

O scrum master forma outros profissionais relativamente à metodologia Scrum e podem ajudar o product owner a definir o valor do sprint e orientar os programadores para o cumprirem.

Ciclo de Etapas

O Scrum possui um ciclo de etapas (chamadas rituais) que devem ser seguidas:

• Planeamento;
• Sprint;
• Retro.

Planeamento: Nesta fase, o Product Owner apresenta o backlog do sprint à equipa de desenvolvimento, delineando as tarefas e os objetivos do sprint. O Scrum Master e os desenvolvedores podem identificar lacunas ou possíveis problemas que possam afetar a conclusão das tarefas antes de finalizar o plano do sprint.

Sprint: A fase de desenvolvimento começa após o planeamento. Durante o sprint, os programadores trabalham nas tarefas atribuídas. Todos os dias, a equipa reúne-se para o Daily Standup (ou Daily Scrum), uma reunião rápida onde cada membro partilha atualizações sobre as suas tarefas. Esta reunião ajuda a equipa a manter-se ágil, permitindo ajustar planos e prioridades para alcançar os objetivos do sprint.

Durante estas reuniões diárias, a equipa pode avaliar se alguma tarefa vai demorar mais tempo do que o previsto, decidir se devem incluir mais pessoas numa determinada tarefa ou retirar prioridade a tarefas menos importantes de forma a garantir o sucesso do sprint.

Retro: Após o fim do sprint, a equipa realiza uma Retrospectiva para analisar os resultados. Eles refletem sobre o que correu bem, o que não correu tão bem e o que pode ser melhorado no próximo sprint. Esta reunião prepara o terreno para o novo ciclo, incorporando as lições aprendidas no trabalho futuro.

Estas etapas do ciclo dão aos membros da equipa a flexibilidade necessária para mudar de ideias e de direção ao longo do desenvolvimento. Depois de cada sprint, as partes interessadas e os clientes têm acesso a uma pequena parte do projeto e conseguem dar o seu feedback. 

Quaisquer alterações necessárias são inseridas no product backlog pelo product ownere a equipa de desenvolvimento começa a trabalhar nele no sprint seguinte.

Para manter tanto a velocidade quanto a agilidade, é essencial uma comunicação forte entre os membros da equipe. A empresa deve respeitar o processo do sprint e evitar interrupções desnecessárias. Interferir no foco do sprint pode prejudicar a comunicação e resultar num processo de desenvolvimento apressado, em vez de ágil. Isto pode dar origem a obstáculos ou problemas que terão impacto nos sprints seguintes, tornando todo o desenvolvimento do projeto mais lento.

Demonstrar os Impactos do Sprint

A palavra Scrum provém do desporto, do rugby. No rugby, o Scrum forma-se depois de ser cometida uma infração às regras, a equipa reúne-se e o jogo recomeça.

Tal como o Scrum, a NFL (Liga Nacional de Futebol Americano) também se baseia no rugby. E o objetivo de ambos os desportos é avançar para o território da outra equipa e marcar, seja levando a bola para end zone ou chutando a bola na direção do field goal. A principal diferença é que, em vez de esperar por alguma infração, na NFL, depois de todas as jogadas, as equipas voltam a reunir-se.

Todas as jogadas na NFL começam com o treinador a planear e a informar o quarterback sobre a jogada que a equipa tem de executar. Depois, o quarterback informa todos os jogadores em campo sobre a jogada, a formação e as direções. Os jogadores colocam-se nas suas posições e a jogada começa.

Uma das jogadas escolhidas pelos treinadores pode ser a jogada de corrida, em que o quarterback dá a bola ao running back e tem de esperar que os bloqueios criem espaço para começar a correr em direção à baliza.

Para que a jogada seja bem-sucedida, a comunicação tem de ser clara e todos têm de compreender a jogada; caso contrário, será fácil para os defesas impedirem a jogada.

Jogada que não foi bem-sucedida

Por vezes, o papel dos membros da equipa não está claro ou alinhado entre si, o que resulta numa jogada em que, a equipa que defende aproveita as brechas e corre diretamente para o running back, bloqueando o seu caminho.

As razões para isso acontecer podem ser:

• O treinador não planeou bem a jogada;
• Há uma falta de comunicação entre o treinador e os jogadores;
• A equipa atacante não estava à espera de um jogador da defesa.

Seja qual for o motivo, o corredor foi parado muito cedo, resultando num sprint com pouco sucesso, o que significa que a equipa começa a jogada seguinte em desvantagem.

Para ver um exemplo claro de como a má comunicação leva a uma jogada de corrida falhada, assiste a este vídeo.

Jogada bem-sucedida

Por outro lado, quando todos os jogadores compreendem os seus papéis e responsabilidades, o running back pode ter um bom arranque depois de ultrapassar os bloqueios iniciais dos defensores. Isto permite-lhe destacar-se naquilo que faz melhor: usar a agilidade para mudar de direção e evitar defensores adicionais, mantendo a velocidade em direção à end zone. Isto resulta frequentemente num sprint bem-sucedido, como demonstrado neste vídeo de exemplo.

Então, Ágil é Sinónimo de Rápido? Considerações Finais

No campo da NFL, o running back é o jogador mais rápido em campo, mas ser mais rápido não significa ser o melhor jogador. O running back precisa de agilidade para mudar de direção.

O mesmo acontece dentro de uma empresa: pode ter a equipa de desenvolvimento mais rápida, mas tal como um running back a correr para a end zone, os projetos de IT não são uma linha reta. A equipa precisa de ter um bom plano e comunicação para evitar bloqueios no início de um sprint. Só então o programador pode começar a construir um projeto ágil, estando preparado para mudanças de direção posteriores enquanto avança num sprint rápido em direção ao objetivo.

Então, para responder à pergunta:

A tua equipa não é ágil? Então não devias ter terminado esta tarefa mais rápido?”

Não, o objetivo é construir um projeto flexível para que os planos do projeto possam mudar, enquanto a equipa de desenvolvimento continua a trabalhar o mais rapidamente possível.