Longe vão os tempos em que trabalhávamos de forma a executar um projeto com início, meio e fim, numa metodologia considerada organizada e estruturada – chamada metodologia Waterfall. No mundo agitado em que vivemos, os prazos apertaram, as entregas querem-se céleres e as expetativas para com o resultado final são cada vez mais elevadas. Hoje em dia, é recorrente a adaptação da metodologia Scrum nos diversos projetos de forma a corresponder às necessidades do negócio e do mercado, tornando tudo muito mais ágil. Claro está que o Scrum não acelera o final de um projeto, pois lá diz o ditado “Depressa e bem, não há quem”. O Scrum apenas proporciona entregas faseadas que irão satisfazer o cliente porque permite disponibilizar parte do software antes de ver o resultado final na sua totalidade. Como a satisfação do cliente é o objetivo final de um projeto de consultoria, esta metodologia veio proporcionar um retorno positivo para ambas as partes.
Existem diferentes roles quando falamos da metodologia Scrum, desde o Scrum Master (elemento que orienta e facilita os constrangimentos de trabalho do resto da equipa), o Product Owner (elemento que cria o backlog - carteira de tarefas - a executar no decorrer de um sprint – etapa - e é responsável pela comunicação com a área de negócio para levantamento de requisitos), o Analyst (traduz o fecho dos requisitos em stories - análises funcionais - passíveis de interpretação do utilizador e programadores da equipa), e o Developer (responsável pelo desenvolvimento técnico das stories).
O objetivo de cada role é executar sprints (desenvolvimento técnico de um conjunto de análises - storypoints).
O dia de trabalho inicia-se com uma daily meeting de cerca de 10 minutos onde todos os intervenientes estão de pé para, cada um, na sua vez, efetuar uma retrospetiva do dia anterior e delinear o dia de trabalho atual. Não existe debate, apenas é relatada de forma sucinta o dia anterior e o atual, de forma a evidenciar os progressos ou os constrangimentos, que o Scrum Master possa resolver após a reunião. De seguida, cada um dos intervenientes executa as suas tarefas diárias que irão de encontro às suas responsabilidades. Não existem hierarquias, existem roles, e todos têm a função de desempenhar as tarefas delineadas para o seu role para que o sprint decorra com a fluidez desejável.
Findo o prazo do sprint, é realizada uma reunião de retrospetiva, que visa debater em equipa o que foi realizado e se existiram eventuais incumprimentos ou problemas que impossibilitaram o fecho da tarefa no sprint, passando ou não para o sprint seguinte. Esta reunião reúne todos os elementos para uma conversa franca e objetiva. A capacidade de se debater todos os pontos torna a ligação de equipa mais forte e sustentável. Por cada sprint terminado, é possível efetuar uma demo (prova de conceito) ao utilizador e entregar um pequeno bloco de software ao utilizador final.
Normalmente, no dia seguinte à reunião de retrospetiva, é realizada a reunião do início do próximo sprint. O backlog de stories é anunciado e a equipa reúne-se na votação da complexidade de cada story. O voto é pessoal e se não reunir consenso numa primeira votação são argumentados os pontos de discórdia até se chegar a uma votação final e consensual. Após a votação da complexidade é votada a morosidade de cada story. Criam-se assim as estimativas para cada tarefa, o que torna tudo mais “democrático”.
O Scrum é isto e muito mais, porque dentro das regras pré-definidas falta descrever as inúmeras potencialidades práticas desta metodologia. A mais conhecida expressa-se pela agilidade na execução e no resultado final. Em todos os projetos podem existir mudanças de planos, e em vez de se recomeçar do zero, o Scrum permite começar de uma escala diferente.
Definiria o Scrum como uma corrida onde se passa a cada etapa o testemunho. Cada corrida cumpre várias ‘metas’, o objetivo é chegar ao final, juntos, e saborear a vitória em equipa.
Autora : Emiléne Gomes (Consultora da área de Legacy Systems da Mind Source)
