Desenvolvimento com Scrum

Este post não tem tags.

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.

Sobre o autor(a)

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.

Muitas empresas que passam por transformações ágeis já querem começar utilizando Métodos Ágeis em escala. Para tal, adotam frameworks como SAFe e outros. Entretanto, trabalhar em escala pode ser difícil e complexo, pois todos os problemas que ainda não foram…

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

Todos nós recebemos demandas que têm um prazo exato para ser entregue. Quando isso acontece, uma das ações acaba sendo tomadas. A primeira é parar tudo e começar a fazer a demanda com prazo. Outra, caso o prazo esteja distante,…

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

A Lei de Little vem do professor do MIT John D. C. Little (1928 – 2024). Ele publicou o conceito inicial em 1954 sobre a Teoria das Filas e o comprovou em 1960 no artigo que pode ser lido na…

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

Tratando Riscos em Projetos Ágeis : Riscos de Negócio Há alguns dias estava lendo um artigo do Kanban Plus e esbarrei no tratamento de riscos que o Kanban traz. Senti vontade de dar um passo além e escrever como tratamos…