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:
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:
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:
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.
