Desenvolvimento com Scrum

Compartilhe:

Vamos falar sobre desenvolvimento com Scrum? 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.

Carlos Felippe Cardoso
Sobre o autor

Carlos Felippe Cardoso

Cofundador e Trainer na K21

Carlos Felippe Cardoso é cofundador da K21 e tem experiência em métodos ágeis desde 2004. Palestrante nos maiores eventos de agilidade do Brasil e da Europa, é instrutor do treinamento de CSD (Certified Scrum Developer), pela Scrum Alliance, e também instrutor oficial de Kanban (AKT – Accredited Kanban Trainer), pela Kanban University. Como Executivo, possui vasta experiência em Transformação Digital e Liderança, atuando especialmente no C-Level de empresas.

No headers found for the table of contents.

Artigos relacionados

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

No texto “O caos invisível”, falei um pouco sobre a cultura do herói/heroína. Também já escrevi outros textos sobre o tema. Um deles com o meu colega Raphael Montenegro: “Paradoxo do Gestor Capitão Planeta”, que publicamos no final de 2020….

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Clique aqui para baixar PDF do Test Card 2.0 formato retrato PDF do Test Card 2.0 formato paisagem Imagem do Test Card 2.0 no formato retrato Imagem do Test Card 2.0 no formato paisagem Você trabalha com desenvolvimento de produtos….

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

O Usage-Driven Development (UDD) não é uma metodologia cheia de cerimônias e artefatos. É o nosso jeito, aqui na Nower/K21, de pensar produto na era da Inteligência Artificial (IA). E, como todo jeito de pensar, ele se sustenta em princípios:…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Existem organizações que parecem funcionar. Tudo acontece dentro da “normalidade”. Projetos são entregues, reuniões acontecem, relatórios circulam e indicadores são apresentados. Mesmo assim, há um cansaço estrutural no ar. As pessoas já estão tão cansadas de matar um leão por…