Ágil é Sinónimo de Rápido? Scrum, NFL e Outros Conceitos Ágeis

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

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

A metodologia Ágil é 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 da metodologia. 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 metodologia Ágil. Se é a primeira vez que ouves falar desta metodologia, 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 metodologia Ágil significa ser capaz de mudar os planos do projeto com rapidez e facilidade.

Mas como é que uma empresa se torna ágil?

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


Scrum: uma Framework da Metodologia Ágil


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

A maioria dos projetos de IT não segue uma linha reta, acontecem falhas 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 caraterística torna o projeto mais flexível à mudança durante o desenvolvimento.

A imagem abaixo ilustra a estrutura de uma equipa Scrum e as etapas do processo:

img-2


Funções da Equipa Scrum


Uma equipa Scrum é composta por:

  • Product Owner
  • Desenvolvimento
  • 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 ownercria 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.

Os scrum masters formam 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.


O planeamento é a fase em que o product owner apresenta o registo do sprint à equipa de programadores, descrevendo as tarefas e objetivos do sprint. Nesta fase, os programadores e o scrum master têm a oportunidade de apresentar quaisquer informações em falta e situações que possam resultar na inexecução de uma determinada tarefa, antes de chegarem a um acordo sobre o sprint.

Em seguida, o sprint começa e os desenvolvedores começam a trabalhar nas suas tarefas de desenvolvimento. A equipa reúne-se todos os dias para uma Daily, uma reunião rápida onde os membros da equipa atualizam os restantes elementos sobre as suas tarefas. Estas reuniões ajudam a equipa a tornar-se mais ágil, dando-lhe flexibilidade para alterar os seus planos no sentido de atingir os seus objetivos para o sprintatual.

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.

A equipa reúne-se novamente no final do sprint para apresentar os seus resultados. Nesta altura, tomam em consideração quaisquer erros, discutem o que correu bem e o que falhou e fazem ajustes para o sprint seguinte. O retro marca o início de um novo ciclo que repete os mesmos rituais.

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.

Com uma equipa bem coordenada, a empresa pode ter um sprint simultaneamente rápido e ágil. Para fazer isso, é fundamental existir uma boa comunicação entre os membros (dá uma vista de olhos neste artigo sobre como melhorar as tuas capacidades de comunicação). A empresa também precisa de compreender o processo e não interferir com os objetivos do sprint enquanto a equipa ainda o está a executar.

Quaisquer interferências podem perturbar a comunicação entre os membros da equipa, podendo gerar um sprint de desenvolvimento rápido 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.

Para explicar o que quero dizer com o impacto de interferir com os membros da equipa enquanto se executa um sprint, vou exemplificar com uma jogada da NFL, chamada de jogada de corrida.


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.

Eis uma jogada de corrida malsucedida:

img-4


Nesta jogada, um jogador de defesa da equipa vermelha estava livre para bloquear o running back, o que aconteceu provavelmente porque: 

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


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

Eis um exemplo de uma jogada bem-sucedida:

img-6


Nesta jogada, todos compreenderam as suas responsabilidades, o que resultou num bom bloqueio inicial e num grande caminho para o corredor iniciar a sua corrida (o sprint).

Depois de o running back passar os bloqueios iniciais, ainda restam alguns defesas, mas agora cabe-lhe a si ser ágil e mudar de direção para evitar os jogadores de defesa, continuando a correr rapidamente em direção ao seu objetivo, a end zone, celebrando depois um grande sprint com os seus colegas de equipa.


Então, Ágil é Sinónimo de Rápido? Reflexõ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.