Desenvolvimento com Scrum

Este post não tem tags.

Compartilhe:

Após a reunião de Sprint Planning, inicia-se o trabalho de desenvolvimento propriamente dito dos itens do Sprint Backlog. Os membros do Time de Desenvolvimento definiram, durante a reunião de Sprint Planning, como o trabalho será realizado. Agora, são os responsáveis por se auto-organizar para realizar esse trabalho e por monitorar seu progresso em direção à Meta do Sprint.

O desenvolvimento inicia-se a partir do primeiro item do Sprint Backlog, que é o item mais importante para se atingir a Meta do Sprint. Os diferentes membros do Time de Desenvolvimento realizam as diferentes tarefas necessárias, comunicando-se e colaborando sempre que necessário. Ao completar o primeiro item, seguem juntos para o item seguinte, e assim por diante.

Em cada dia do trabalho de desenvolvimento, os membros do Time de Desenvolvimento se encontram por no máximo quinze minutos, preferencialmente no mesmo horário e no mesmo local, para a reunião de Daily Scrum. O objetivo da reunião é garantir a visibilidade de seu trabalho entre eles e planejar, informalmente, o próximo dia de trabalho. O ScrumMaster pode, se necessário, facilitar essa reunião, mas sua presença não é obrigatória.

A reunião de Daily Scrum é um ótimo momento para se atualizar o Gráfico de Sprint Burndown, uma ferramenta que o Time de Desenvolvimento pode utilizar para monitorar seu progresso no Sprint. Esse gráfico possui no eixo x os dias de trabalho no Sprint e no eixo y a quantidade de trabalho restante, que pode ser medida pela quantidade de tarefas restantes ou por algum tipo de estimativa realizada sobre as tarefas, por exemplo. O Time de Desenvolvimento marca no gráfico a quantidade de trabalho restante no dia corrente.

Exemplo de Gráfico de Burndown

Em seu dia a dia de trabalho, é comum os membros do Time de Desenvolvimento se depararem com desafios. Sempre que encontram algo que os impede de realizar seu trabalho, eles avisam ao ScrumMaster, que inicia imediatamente o trabalho de remoção desse impedimento.

Um Product Owner acessível ao longo do Sprint permite que o Time de Desenvolvimento tire dúvidas de negócios sobre os itens em desenvolvimento que naturalmente surgem. Ao mesmo tempo, o Product Owner mantém contato constante com os clientes do projeto e demais partes interessadas para entender suas necessidades ou objetivos de negócios mais urgentes, colher feedback e, assim, atualizar o Product Backlog de acordo, em um trabalho contínuo de Refinamento do Product Backlog.

O Product Owner também busca interagir com o Time de Desenvolvimento para preparar itens para o Sprint seguinte. Para realizar esse Refinamento do Product Backlog, eles podem se encontrar em sessões agendadas, ou esse pode ser um trabalho contínuo ao longo do Sprint. Em qualquer caso, pode-se utilizar uma Definição de Preparado como critério sobre o que significa um item estar preparado.

Sobre o autor(a)

Função não encontrada

No headers found for the table of contents.

Artigos relacionados

Um pouco do que foi o evento Product to Rescue em 9 de Julho 2024   Foco no problema Manter o foco no problema pode ser Old School mas ainda está em alta. Ficamos muito presos em problemas inexistentes ou…

Após terminar de ler o livro Ruído de Daniel Kahneman, decidi reler alguns clássicos que não olhava há algum tempo. Dentre eles, Rápido e Devagar do mesmo autor e Pensando em Sistemas de Daniela Meadows. Não pude deixar de perceber…

O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar…

Marcos Garrido, Sócio-fundador e Trainer na K21

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…