O que é o Quadro de Tarefas do Sprint

---

O que é um Quadro de Tarefas do Sprint?

Uma caixa de tarefas do sprint é um período com tempo definido. Cada sprint tem uma data de início e término durante os quais um conjunto de histórias de usuário selecionadas deve ser concluído e confirmado. A imagem a seguir mostra os elementos principais de um sprint, que incluem um conjunto de histórias de usuário, os membros do Scrum envolvidos, a atribuição de tarefas, a duração e a data de término (canto superior direito).

No início de um sprint, o proprietário do produto, os interessados e a equipe de desenvolvimento se reúnem para priorizar e, em seguida, selecionar as histórias de usuário a serem concluídas no sprint. Como diferentes partes têm preferências, considerações e preocupações distintas em relação ao projeto e ao cronograma do projeto, o objetivo da reunião é proporcionar às diferentes partes a oportunidade de ouvir e compreender as visões dos outros, e chegar a um conjunto de histórias de usuário que seja aceito por todas as partes.

Duração do sprint

A entrega rápida de trabalho de qualidade é uma das razões pelas quais equipes de software desejam adotar metodologias de software ágil. Assim, embora não exista uma escolha única que se aplique a todos os casos para a duração do sprint, é amplamente aceito que a duração deveria ser o mais curta possível. Mas quão curta deveria ser?

Embora uma duração longa de sprint não seja preferida, uma duração excessivamente curta pode enfraquecer a motivação da equipe de desenvolvimento para concluir trabalhos significativos, ou até mesmo levar a uma qualidade pobre dos entregáveis.

Portanto, a seleção da duração do sprint é o resultado de uma discussão entre toda a equipe – proprietário do produto, mestre do Scrum e membros do Scrum, como designers de banco de dados, programadores, designers de UX, testadores, analistas, etc. Mas, no final, alguém precisa tomar uma decisão. Nesse momento, o mestre do Scrum geralmente é quem dará a resposta.

Tradicionalmente, um sprint dura de três semanas a um mês, mas atualmente mais e mais equipes têm tido sucesso com sprints de duas semanas. Afinal, ainda não existe uma escolha fixa para a duração do sprint. Um bom mestre do Scrum possui habilidades colaborativas e facilitadoras para definir o tamanho do sprint, garantindo que as tarefas sejam concluídas conforme esperado. Aqui estão alguns fatores que um mestre do Scrum pode considerar:

1. Cronograma do projeto acordado
2. Disponibilidade de clientes/interessados/proprietário do produto (quem pode esclarecer dúvidas potenciais)
3. Cultura de trabalho dos clientes
4. Capacidade da equipe Scrum
5. Experiência com Scrum

Uma vez que a equipe tenha alcançado um consenso, todos os sprints futuros seguirão a mesma duração do sprint, sem mudanças frequentes de sprint para sprint. No entanto, é uma boa prática para a equipe Scrum continuar revisando a eficácia do sprint e encontrar uma duração ideal que funcione melhor para todos.

Confirmação de Trabalhos (Histórias de Usuário) no Sprint

As atividades de desenvolvimento são organizadas em torno das histórias de usuário após o início do sprint, e cada vez mais histórias de usuário são implementadas conforme o sprint avança. No entanto, a implementação completa de uma história de usuário não é o fim da história. Ainda há uma etapa importante a ser percorrida – a confirmação.

Confirmar uma história de usuário é testar a funcionalidade implementada e decidir se ela foi implementada conforme esperado. A avaliação deve ser feita exclusivamente com base nos critérios estabelecidos ao detalhar as histórias de usuário, escritos na forma de itens de confirmação. Durante a confirmação, o proprietário do produto recebe um ambiente de teste ou dispositivo para testar o trabalho implementado. O proprietário do produto percorrerá os itens de confirmação escritos na história de usuário um por um. Se todos os itens forem confirmados como concluídos, a história de usuário é considerada confirmada. Se qualquer item for encontrado incompleto ou não funcionar conforme esperado, o proprietário do produto solicitará à equipe de desenvolvimento uma correção. Os processos de correção e confirmação serão repetidos até que a história de usuário seja totalmente confirmada.

Quando confirmar?

Sprint, e de fato o ágil, é um processo contínuo de entrega. Em vez de confirmar as histórias de usuário ao final de um sprint, a confirmação deve ser feita logo após a conclusão de qualquer história de usuário. No entanto, se o proprietário do produto não puder participar da confirmação contínua, você pode organizar reuniões semanais que durem de 1 a 2 horas cada. Durante a reunião, o proprietário do produto trabalhará com a equipe para confirmar as histórias de usuário concluídas. A reunião também inclui uma sessão de discussão que esclarece as dúvidas encontradas ao implementar as outras histórias incluídas no sprint.

A confirmação não é equivalente ao teste

Como dito, o propósito da confirmação é garantir que a história de usuário tenha sido implementada corretamente. A avaliação é baseada nos itens estabelecidos como itens de confirmação durante o detalhamento da história de usuário, nem mais, nem menos. A escala de verificação é muito insuficiente para garantir que a funcionalidade esteja pronta para uso em produção. Então, quando realizar um ‘teste real’?

Diferentes equipes têm práticas diferentes em relação ao teste de software. Algumas equipes preferem um teste por sprint, que envolve a realização de testes como teste de integração e teste de regressão ao final de um sprint. Algumas equipes preferem montar um sprint de estabilização, como seu nome diz, para testes e correção de bugs. Nenhum novo trabalho de desenvolvimento será feito nesse sprint.

Independentemente da abordagem que você escolher, lembre-se de que a escolha não é de ninguém em particular, mas de todos.

Visual Paradigm fornece todas as ferramentas de que você precisa em desenvolvimento de software ágil, que inclui ferramenta de diagrama de casos de uso UML, (ágil) história do usuário, sprint, quadro de histórias e wireframes para design de UX, ferramenta de gerenciamento de tarefas, etc.