scrum em 20 minutos

Por David Anderson Lino

O Product Owner cria uma lista de prioridades, o Product Backlog

Durante o Planejamento de Sprint oTeamextrai uma parcela do começo desta lista, gerando o Scrum Backlog, e decide como implementar estes pedaços.

O Team tem um certo intervalo de tempo, uma Sprint, para concluir as implementações.

2Scrum em 20 minutos - David Anderson Lino

O Team se reúne diariamente para avaliar o progresso da Sprint(Daily Scrum)

Enquanto isto, o Scrum Master mantém o Team focado no objetivo

No fim da Sprint o resultado será um produto potencialmente utilizável, pronto para ser entregue ao cliente ou colocado nas prateleiras.


A Sprint é encerrada com uma Sprint review e uma Sprint retrospective.

Ao início da próxima Sprint, o Team escolhe uma nova parcela do Product Backlog e começa a trabalhar novamente.


ScrumMaster Product Owner Team


Product Owner é o “Porco” do ProductBacklog

ScrumMaster é o “Porco” do processo Scrum Team são os “Porcos” do desenvolvimento Todos os outros são “Galinhas” “Galinhas” jamais dizem aos “Porcos” o que

eles devem fazer


Responsável por que todos os envolvidos adiram aos valores, práticas e regras do Scrum

Ajuda ao Team e a organização a adotarem o Scrum

Lidera o Team para alcançar maior produtividade e gerar produtos de maior qualidade

Ajuda o Team a entender e usar a auto-organização e a trabalhar em conjunto

Quando ele faz estas e outras mudanças, isto é chamado de “removing impediments”

É o líder-servidor!


Único Responsável por gerenciar o Product Backlog e atribuir/assegurar valor ao trabalho que o Team realiza.

Esta pessoa mantém o backloge assegura que todos possam vê-lo.

Responsável por atribuir as prioridades aos items, assim todos saberão no que trabalhar

É uma pessoa, não um comitê, um comitê pode existir para influenciar esta pessoa, aqueles que desejam alterar o backlog devem convencer o PO

Todos devem respeitar suas decisões


Transformam partes do Product Backlog em funcionalidespotencialmente utilizáveis a cada Sprint

Os membros devem ter habilidades necessárias para incrementar o produto

Os membros podem ter especialidades, mas devem estar abertos a trabalhar longe delas (Ex: Não querer programar por ser um analista)


São auto-organizáveis, ninguém, nem mesmo o SM deve dizer ao Teamcomo trabalhar

Não existem ‘títulos’ num Team, e não existe exceção a esta regra

Teams não possuem Sub-teams dedicados a domínios particulares, como ‘equipe de teste’, ‘equipe de análise de negócio’, etc.


Stand Up Meeting Sprint Planning Meeting Sprint Review Meeting Sprint Retrospective


Cada dia durante o sprint, uma reunião de status do projeto ocorre.

Esta reunião tem diretrizes específicas: A reunião começa precisamente

no horário

Todos são bem-vindos, mas apenas “porcos” podem falar

A reunião é limitada a 15 minutos

A reunião deve acontecer no mesmo local e hora todos os dias


Durante a reunião, cada membro da equipe responde a três perguntas: O que você tem feito desde ontem?

O que você está planejando fazer hoje?

Você tem algum problema impedindo de realizar seu objetivo? (É o papel do Scrum Master facilitar a resolução desses impedimentos. Normalmente, isso deve ocorrer fora do contexto do “Daily Scrum”, visto que a reunião dura 15 minutos)


Ocorre no início das Sprints Serve para: Selecionar qual trabalho será feito. Preparar o Sprint Backlog que

detalha o tempo que vai levar para fazer esse trabalho, com toda a equipe

Identificar e comunicar o quanto do trabalho deverá ser feito durante o sprint atual

Tempo limite de oito horas (Primeiras quatros horas) Product

Owner + Equipe: Diálogo para priorizar o Product Backlog

(Últimas quatro horas) Equipe: Criação de um plano para o Sprint, resultando no Sprint Backlog


Rever o trabalho que foi concluído e não concluído

Apresentar o trabalho realizado aos stakeholders

Um trabalho incompleto não pode ser demonstrado

Limite de tempo de quatro horas


Todos os membros da equipe refletem sobre a sprint passada

O que correu bem durante o sprint?

O que poderia ser melhorado na próxima sprint?

Fazem melhorias contínuas de processos


Product Backlog

Sprint Backlog

BurnDown


Contém os requisitos do produto a ser desenvolvido pelo Team

Cada requisito deve ter uma prioridade

É dinâmico, está sempre se moldando para identificar o que o produto precisa para ser apropriado, competitivo e útil

Enquanto um produto existir, um backlogexistirá.


Contém as tarefas que o Team realiza para tranformar os itens do Product Backlog em um incremento “pronto”

Cada item deve ser possível completar em um dia ou menos

O Team modifica o Spring Backlog ao longo da Spring

Cada tarefa deve ser decomposta o máximo possível


Deve estar bem definido, e todos devem entender bem seu siginificado

Ex: Requisito está pronto quando foi:

Testado

Refatorado

Built


É um gráfico apresentado publicamente para mostrar o trabalho restante nos backlogs

Atualizado todos os dias Dá uma visão simples sobre a evolução do

produto. Ele é um gráfico de execução dos trabalhos

pendentes É útil para prever quando todos os trabalhos

serão concluídos.


scrum em 20 minutos

Documents