Tutorial do Scrum
Neste tutorial, você tem acesso a instruções passo a passo para fazer um projeto Scrum, priorizar e organizar o backlog em sprints, executar as cerimônias Scrum e muito mais — tudo no Jira.
Tempo:
10 minutos de leitura. Complete em duas semanas
Público-alvo:
Você é novo no Scrum, no desenvolvimento de software ágil ou no Jira
Pré-requisito:
Você criou uma conta do Jira
O Scrum é uma das estruturas mais populares para implementar a metodologia ágil. No Scrum, o produto é criado em uma série de iterações de extensão fixa chamadas sprints, o que dá às equipes ágeis a estrutura para enviar software em ritmo regular.
Etapa 1: criar um projeto scrum
Depois de criar e entrar em uma conta no Jira, você pode selecionar um template da biblioteca. Selecione Scrum (você pode pré-visualizar o template de Scrum grátis aqui ou aprender a criar um projeto Kanban aqui).
Em seguida, você deve escolher um tipo de projeto. Se a equipe trabalha com independência e quiser controlar os próprios processos e práticas de trabalho em um espaço autocontido, experimente o template de Scrum gerenciado pela equipe. Consulte Introdução a projetos gerenciados pela equipe na Comunidade da Atlassian para saber mais.
Depois de criar seu projeto, você chega ao backlog vazio. O backlog também é conhecido como backlog do produto e contém uma lista contínua dos possíveis itens de trabalho da sua equipe no projeto.
Etapa 2: criar tarefas ou histórias de usuário na lista de pendências
No Jira, a gente chama os itens de trabalho, como histórias de usuários, tarefas e bugs de "itens". Crie algumas histórias de usuário com a opção de criação rápida no backlog. Se você não tiver histórias de usuários em mente, basta criar amostras de histórias para começar e ver como o processo funciona.
As histórias de usuário são usadas para descrever itens de trabalho em uma linguagem não técnica e da perspectiva de um usuário. Como {tipo de usuário}, eu quero {meta} para que eu {receba benefício}.
Vamos usar um site como um exemplo simples para criar uma história de usuário.
Como cliente, eu quero conseguir criar uma conta para que eu possa ver minhas compras anteriores.
As histórias de usuários geralmente são esboçadas e priorizadas pelo proprietário do produto e, então, a equipe de desenvolvimento determina tarefas detalhadas necessárias para completar a história em um sprint próximo. A equipe de desenvolvimento também é responsável por estimar o esforço relativo necessário para completar o trabalho da história.
Depois de criar algumas histórias de usuário, você pode começar a estabelecer prioridades para elas no backlog. No Jira, você classifica ou prioriza as histórias arrastando e soltando cada uma delas na ordem em que devem ser trabalhadas.
Estas são apenas as histórias iniciais do seu projeto. Você vai continuar criando histórias durante a vida útil do projeto, uma vez que a metodologia ágil envolve aprendizado e adaptação contínuos.
Etapa 3: criar um sprint
Crie e comece a planejar seu primeiro sprint no backlog.
No Scrum, as equipes preveem concluir um conjunto de histórias de usuário ou outros itens de trabalho durante um tempo fixo, chamado de sprint. De modo geral, os sprints duram uma, duas ou quatro semanas. A equipe deve determinar a duração de um sprint — uma boa ideia é começar com duas semanas. O tempo é suficiente para fazer alguma coisa, mas não tão longo que impeça a equipe de receber feedback regular. Depois de determinar o ritmo dos sprints, a equipe trabalha sempre nesse ritmo. Os sprints com duração fixa reforçam as habilidades de estimativa e fazem a previsão da velocidade futura da equipe enquanto ela trabalha no backlog.
Etapa 4: reunião de planejamento do sprint
No início de um sprint, você deve realizar a reunião de planejamento de sprint com o resto da equipe. Essa reunião é uma cerimônia que motiva toda a equipe para o sucesso durante o sprint. Nesta reunião, a equipe discute a meta do sprint e as histórias no backlog priorizado do produto. A equipe de desenvolvimento cria tarefas detalhadas e estimativas para as histórias de alta prioridade e, então, se compromete a concluir um certo número de histórias no sprint. Essas histórias e o plano para sua conclusão compõem o backlog do sprint.
Adicione estimativas de pontos da história às suas histórias adicionando um número no campo Estimativa de pontos da história. Você também pode inserir mais detalhes nas histórias ou clicar no ícone Criar subtarefa para detalhar ainda mais o trabalho da história.
Quando estiver pronto, arraste as histórias combinadas na reunião de planejamento do sprint até o sprint que você acabou de criar. Este é o seu backlog do sprint.
Participantes: Obrigatório: equipe de desenvolvimento, mestre de Scrum, proprietário do produto
Quando: no início de um sprint.
Duração: Em geral, duas horas por semana de iteração. Por exemplo: um sprint de duas semanas começa com uma reunião de planejamento de quatro horas. A reunião termina quando o seu objetivo tiver sido alcançado.
Objetivo: Planejar o trabalho do sprint. A equipe chega a um acordo sobre a meta do sprint e o backlog do sprint.
Ao criar um sprint, o proprietário do produto geralmente identifica um objetivo de sprint. Isso define um tema para o trabalho a ser concluído no sprint. Um objetivo de sprint também oferece alguma flexibilidade no número de histórias que são concluídas em um sprint. Você sabe que um sprint deu certo quando seu objetivo é alcançado.
As equipes de software tradicionais dão estimativas em tempo: dias, semanas, meses.
Muitas equipes ágeis, no entanto, fizeram a transição para pontos de história, que avaliam o esforço relativo do trabalho, muitas vezes em um formato Fibonacci: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Estimativas também ajudam a avaliar quanto trabalho deve ser adicionado ao sprint seguinte, com base no número de membros da equipe. Após alguns sprints, será mais fácil para sua equipe descobrir o quanto consegue fazer em cada sprint, o que ajudará a evitar comprometimento em excesso.
Etapa 5: iniciar o sprint no Jira
Nomeie o sprint. Algumas equipes nomeiam o sprint com base na meta. Se há um traço comum entre os itens no sprint, nomeie o sprint em torno desse tema. Caso contrário, é possível nomear o sprint como quiser.
Adicione a duração e as datas de início e fim do sprint. As datas de início e fim devem estar alinhadas com a programação da sua equipe. Por exemplo: algumas equipes começam sprints na segunda-feira e terminam na manhã de sexta-feira da próxima semana. Outras equipes decidem começar e terminar seus sprints no meio da semana. Cabe a vocês! Se não tiverem certeza sobre quanto tempo seus sprints devem durar, é uma boa ideia começar com duas semanas.
Adicione a meta do sprint conforme combinado na reunião de planejamento do sprint.
Assim que iniciar seu sprint, você será direcionado para a aba de sprints ativos no projeto.
Essa aba é onde sua equipe trabalhará para pegar itens da coluna de afazeres e movê-los para a coluna "em andamento" e, eventualmente, "concluído"!
Se você estiver usando o template de scrum gerenciado pela equipe, ele vai ser chamado de Quadro.
Etapa 6: fazer as reuniões rápidas diárias
After your sprint has started, have your team meet daily, typically in the morning, to review what everyone is working on. The purpose of this is to see if anyone on your team is experiencing any roadblocks towards the completion of sprint tasks.
Participantes (principais): equipe de desenvolvimento
Quando: uma vez por dia, normalmente pela manhã
Duration: No more than 15 minutes. Don't book a conference room and conduct the standup sitting down. Standing up helps keep the meeting short!
Finalidade: a reunião rápida diária é projetada para informar rápido e a todos o que está acontecendo em toda a equipe e planejar o trabalho do dia. Não é uma reunião completa de status. O tom deve ser leve e descontraído, mas informativo. Peça que cada membro da equipe responda às seguintes perguntas:
- O que fiz ontem?
- No que trabalharei hoje?
- Meu trabalho está com algum obstáculo?
Há uma responsabilidade implícita ao relatar o trabalho concluído ontem na frente de seus colegas de trabalho. Ninguém quer ser o membro da equipe que está constantemente fazendo a mesma coisa e não progride.
ProTip: Some teams use timers to keep everyone on track. Others toss a ball across the team to make sure everyone's paying attention. Many distributed teams use video-conferencing or group chat to close the distance gap. Your team is unique — your standup should be, too!
Você pode usar os sprints ativos do quadro do Scrum durante a reunião rápida diária, para que cada membro possa ver as tarefas nas quais está trabalhando.
Etapa 7: visualizar o Gráfico de burndown
É uma boa ideia verificar o gráfico de burndown durante um sprint. No Jira, o gráfico de burndown mostra as quantidades real e estimada de trabalho a ser feito em um sprint. A atualização do gráfico de burndown no Jira é automática quando você conclui itens de trabalho. Para visualizar esse gráfico, clique em Relatórios na barra lateral e selecione Gráfico de burndown na lista suspensa de relatórios.
O gráfico de burndown mostra a quantidade real e a estimada do trabalho a ser feito em um sprint. O eixo x horizontal em um gráfico de burndown indica o tempo, enquanto o eixo y vertical indica os pontos da história.
Use the Burndown Chart to track the total work remaining for a sprint, and to project the likelihood of achieving the sprint goal. By tracking the remaining work throughout the iteration, a team can manage its progress and respond accordingly.
- A equipe finaliza, antecipadamente, sprint após sprint porque ela está se comprometendo a fazer muito trabalho.
- A equipe perde seu sprint de previsão após o sprint porque eles estão se comprometendo a fazer muito trabalho.
- A linha de burndown mostra quedas bruscas em vez de um burndown mais gradual porque o trabalho não foi dividido em partes menores.
- O proprietário do produto adiciona ou altera o sprint intermediário do escopo.
Etapa 8: visualizar o relatório do sprint
Em qualquer momento, durante ou após o sprint, você pode visualizar o relatório do sprint para monitorar o sprint.
O Relatório do Sprint inclui o gráfico de burndown e lista o trabalho concluído, o trabalho não concluído e qualquer trabalho adicionado após o início do sprint.
Etapa 9: reunião de revisão do sprint
The sprint review, or sprint demo, is a sharing meeting where the team shows what they've shipped in that sprint. Each sprint usually produces a working part of the product called an increment.
Esta é uma reunião com muitos comentários sobre o projeto e inclui uma sessão de brainstorming para ajudar a decidir o que fazer a seguir.
Participantes (principais): equipe de desenvolvimento, mestre de Scrum, proprietário do produto
Opcional: partes interessadas
Quando: geralmente no último dia do sprint
Duração: normalmente, duas horas para um sprint de duas semanas
Objetivo: inspecionar o incremento e fazer a atualização colaborativa do backlog do produto
Perguntas a fazer:
- A equipe atendeu a previsão de sprint?
- Houve trabalho adicionado ou removido durante o sprint?
- Algum trabalho não foi concluído no sprint?
- Em caso afirmativo, por quê?
Etapa 10: fazer uma reunião de retrospectiva do sprint
Depois de concluir o sprint, peça que a equipe faça uma retrospectiva. Documente a retrospectiva em algum lugar. Que tal o Confluence?
Participantes: equipe de desenvolvimento, mestre de Scrum, proprietário do produto
Quando: no final da iteração.
Duração: normalmente, 90 minutos para um sprint de duas semanas
Objetivo: a equipe se inspeciona, incluindo seus processos, ferramentas e interação com a equipe Muitas vezes, itens de melhoria são adicionados ao backlog do sprint seguinte.
As retrospectivas não são apenas um momento para reclamações sem ação. Use retrospectivas para descobrir o que está funcionando para que a equipe possa continuar a focar nessas áreas. Além disso, descubra o que não está funcionando e use esse momento para encontrar soluções criativas e desenvolver um plano de ação. Melhoria contínua é o que sustenta e impulsiona desenvolvimento dentro de uma equipe ágil e as retrospectivas são uma parte fundamental disso.
Perguntas a fazer:
- O que fizemos certo durante o sprint?
- O que poderíamos ter feito melhor?
- O que vamos fazer melhor da próxima vez?
ProTip: Even if things are going well across the team, don't stop doing retrospectives. Retrospectives provide ongoing guidance for the team to keep things going well.
Etapa 11: concluir o sprint no Jira
No final do sprint, você deve concluí-lo.
Se o sprint tiver itens incompletos, você pode:
- mover os itens para o backlog
- mover os itens para um sprint futuro
- mover os itens para um sprint novo, que o Jira vai criar para você
Etapa 12: repetição da etapa 2
At this point, you've got the basics on building your backlog with user stories, organizing your user stories into sprints, starting your sprint, and holding Scrum ceremonies. You can decide if this is working for your team, or if you'd like to move forward into some more advanced topics.
Depois que você e sua equipe tiverem concluído as etapas acima, vá para o artigo: Como fazer práticas avançadas de Scrum com o Jira.
