Gestão de projectos em SCRUM

Como é que funciona?

Na prática, isto significa que todo o processo é constantemente optimizado e adaptado às necessidades do equipa e o produto durante todo o período de trabalho do projeto. Responsabilidade pela gestão desenvolvimento de produtos é repartida entre o proprietário do produto (PO) e a equipa de conceção. O PO é a pessoa responsável pela tomada de decisões relacionadas com a direção do desenvolvimento do produto e tem uma "visão" holística daquilo em que o produto se vai tornar. A gestão de tarefas baseia-se no quadro Kanban (em conjunto com o correr funcionalidade designada por quadro SCRUM). Cada participante no processo pode adicionar tarefas à lista de pendências, mas o PO é responsável pela definição de prioridades. A equipa de projeto é responsável por "transformar" as ideias do PO em tarefas específicas e planear a sua implementação.

Percurso do ciclo

O processo é dividido em iterações (sprints). No âmbito de um sprint com a duração aproximada de 2 semanas, a equipa de projeto implementa e testa a parte da funcionalidade previamente planeada.

O Sprint começa com o "planeamento", onde a equipa discute e prepara as tarefas que foram previamente preparadas e colocadas pelo PO no topo do backlog. De seguida, a dificuldade destas tarefas é estimada e são-lhes atribuídos pontos de acordo com a sua dificuldade. Com a composição da equipa e as condições de trabalho relativamente constantes, o número de pontos realizados em cada sprint é repetível e permite o planeamento do trabalho futuro. No final da reunião de planeamento, são selecionadas as tarefas com um número total de pontos a completar num sprint e inicia-se um novo sprint.

A meio do sprint, ocorre o grooming. Trata-se de uma reunião em que o PO apresenta à equipa novas expectativas e ideias, enquanto a equipa de projeto as analisa, divide-as em tarefas mais pequenas e apresenta possíveis sugestões ao PO. Ao planear tarefas futuras, o PO consulta analistas, utilizadores, UX e designers gráficos. Análises adicionais (mercado investigação e ciência dos dados) são frequentemente necessários nesta fase. Só depois de analisar e formular a chamada história do utilizador é que o PO publica essas histórias numa lista de pendências. A User Story deve conter informações sobre o que o PO espera de uma determinada tarefa ou grupo de tarefas e quais os critérios que devem ser utilizados para reconhecer se a tarefa está concluída.

Durante o sprint, realizam-se diariamente as chamadas "reuniões diárias de standup". Nestas reuniões, cada programador conta ao resto da equipa o que fez no último dia e, possivelmente, informa sobre quaisquer problemas ou bloqueios que impeçam a continuação do seu trabalho. Graças a esta troca de informações sobre o estado atual, é possível detetar mais rapidamente potenciais conflitos entre várias tarefas e evitar a situação em que o programador fica bloqueado num problema e não consegue progredir. O pressuposto do standup diário é ser o mais curto possível, mas cumprindo o seu papel ao mesmo tempo. A fórmula permanente da reunião incentiva a equipa a mantê-la curta.

Durante o sprint, as tarefas são movidas no quadro SCRUM de acordo com o seu estado atual. A escolha das colunas corresponde normalmente ao sistema de trabalho das empresas ou da equipa e está associada ao sistema de controlo de versões e à frequência dos lançamentos. Para nós é o seguinte:

• A fazer - tarefas à espera de serem concluídas
• Em curso - tarefas em curso
• Código revisão - tarefas à espera de serem verificadas por outro programador
• Preparado - tarefas verificadas e aceites pelos programadores
• Em preparação - tarefas localizadas numa instância de preparação e à espera da aprovação da OP
• Aceite - tarefas aceites pelo OP
• Concluído - tarefas prontas localizadas na instância de produção

Após o sprint, tem lugar uma retrospetiva. Trata-se de uma reunião dedicada à otimização do trabalho. Toda a equipa discute o que correu bem no último sprint e o que precisa de ser melhorado. Também nos referimos frequentemente à retrospetiva anterior e verificamos se conseguimos implementar todas as ideias para melhorar o trabalho. Os problemas discutidos na retrospetiva podem ser qualquer coisa, desde ferramentas de desenvolvimento, passando por pressão, dificuldade de tarefas, até problemas de comunicação (tanto entre os programadores e a equipa como o PO).

Responsabilidades do mestre SCRUM

A pessoa responsável pela correta condução do processo SCRUM é o SCRUM master. Este é frequentemente o papel mais incompreensível da equipa. O SCRUM master não tem poder de decisão. As decisões são tomadas em conjunto pela equipa e pelo PO, enquanto o papel do SCRUM master é remover os obstáculos ao bom desenrolar do processo.

As funções do SCRUM master incluem o seguinte

• Realização de reuniões SCRUM, incluindo planeamento, preparação, reunião diária de standup e retrospetiva
• Assegurar que as tarefas no quadro SCRUM são regularmente preparadas pela equipa e classificadas por ordem de prioridade pelo PO
• Funciona como elo de ligação entre a equipa e o PO; assim, é muitas vezes o SCRUM master que tem o difícil papel de traduzir a linguagem dos programadores para a linguagem empresarial e vice-versa. Isto deve-se ao facto de, na nossa empresa, o SCRUM master ser um programador, ou seja, uma pessoa técnica. O quadro geral do trabalho do SCRUM master não exige isso.
• Impedir a equipa de se desviar do tema e proteger a ordem de trabalhos nas reuniões
• Cuidar do ambiente na equipa - principalmente nas reuniões.
• Resolver os conflitos que possam surgir.

Leia também:

• As boas práticas da Codest para a construção de software. A nossa abordagem ao percurso do cliente
• As boas práticas da Codest para a criação de software: GitFlow
• As boas práticas da Codest para a construção de software. Como implementar a análise de requisitos?