O objetivo do trabalho diário de um sprint é criar um incremento de produto entregável para o produto em um formato que possa ser entregue a um cliente ou usuário.
Dentro do contexto de um único sprint, um incremento de produto ou incremento despachável significa que um produto de trabalho foi desenvolvido, integrado, testado e documentado de acordo com a definição do projeto de concluído e é considerado pronto para liberação.
A equipe de desenvolvimento pode ou não liberar esse produto no final do sprint – o tempo de lançamento depende do plano de lançamento. O projeto pode exigir vários sprints antes que o produto contenha o conjunto de produto mínimo comercializável (MMP) necessário para justificar uma liberação de mercado.
Para criar funcionalidades despacháveis, a equipe de desenvolvimento e o proprietário do produto estão envolvidos em três atividades principais:
Elaborando
Em um projeto ágil, a elaboração é o processo de determinar os detalhes de um recurso do produto. Sempre que a equipe de desenvolvimento aborda uma nova história de usuário, a elaboração garante que quaisquer perguntas não respondidas sobre uma história de usuário sejam respondidas para que o processo de desenvolvimento possa prosseguir.
O proprietário do produto trabalha com a equipe de desenvolvimento para elaborar histórias de usuários, mas a equipe de desenvolvimento deve ter a palavra final nas decisões de design. O proprietário do produto deve estar disponível para consulta se a equipe de desenvolvimento precisar de mais esclarecimentos sobre os requisitos ao longo do dia.
Em desenvolvimento
Durante o desenvolvimento do produto, a maior parte da atividade, naturalmente, cabe à equipe de desenvolvimento. O proprietário do produto continua a trabalhar com a equipe de desenvolvimento conforme necessário para fornecer esclarecimentos e aprovar a funcionalidade desenvolvida. Durante a Sprint, os membros da equipe:
- Emparelhe os membros da equipe de desenvolvimento para concluir as tarefas. Isso aumenta a qualidade do trabalho e incentiva o compartilhamento de habilidades.
- Siga os padrões de design acordados pela equipe de desenvolvimento. Se você não puder segui-los por qualquer motivo, revise esses padrões e melhore-os.
- Inicie o desenvolvimento configurando testes automatizados. Você pode encontrar mais sobre testes automatizados na seção a seguir e no Capítulo 15. Se novos recursos interessantes se tornarem aparentes durante o desenvolvimento, adicione-os ao backlog do produto. Evite codificar novos recursos que estejam fora do objetivo do sprint.
- Integre as alterações que foram codificadas durante o dia, uma de cada vez. Teste para 100 por cento de acerto. Integrar alterações pelo menos uma vez por dia; algumas equipes se integram muitas vezes ao dia. Realize revisões de código para garantir que o código siga os padrões de desenvolvimento. Identifique as áreas que precisam ser revisadas. Adicione as revisões como tarefas no backlog do sprint.
- Crie documentação técnica enquanto trabalha. Não espere até o final do sprint ou, pior, o final do sprint antes de um lançamento.
Verificando
A verificação do trabalho realizado em um sprint tem três partes: teste automatizado, revisão por pares e revisão do proprietário do produto. A equipe pode realizar:
Teste automatizado
Teste automatizado significa usar um programa de computador para fazer a maioria dos testes de código para você. Com testes automatizados, a equipe de desenvolvimento pode desenvolver e testar códigos rapidamente, o que é um grande benefício para projetos ágeis. Muitas vezes, as equipes de projeto ágeis codificam durante o dia e deixam os testes serem executados durante a noite. De manhã, a equipe do projeto pode revisar o relatório de defeitos gerado pelo programa de teste, relatar quaisquer problemas durante o scrum diário e corrigir esses problemas imediatamente durante o dia.
- O teste automatizado pode incluir o seguinte: Teste de unidade: Testar o código-fonte em suas partes menores — o nível do componente
- Teste do sistema: testando o código com o resto do sistema
- Teste estático: verificar se o código do produto atende aos padrões com base em regras e práticas recomendadas que a equipe de desenvolvimento concordou
Revisão por pares
Revisão por pares significa simplesmente que os membros da equipe de desenvolvimento revisam o código uns dos outros.
Revisão do proprietário do produto
Quando uma história de usuário é desenvolvida e testada, a equipe de desenvolvimento move as histórias para a coluna Aceitar no quadro de tarefas. O proprietário do produto então revisa a funcionalidade e verifica se ela atende aos objetivos da história do usuário, de acordo com os critérios de aceitação da história do usuário. O proprietário do produto verifica as histórias do usuário ao longo de cada dia.
Resumo
A equipe de desenvolvimento relata o progresso da tarefa atualizando o sprint backlog com quais tarefas foram concluídas e quanto trabalho, em horas, resta a ser feito nas novas tarefas iniciadas. Dependendo do software que a equipe scrum usa, os dados do sprint backlog também podem atualizar automaticamente o gráfico de burndown do sprint.
Outros artigos do Scrum
-
- O que é o modelo de função-recurso-motivo?
- Incremento de Sprint x Produto Comercial em Potencial x MVP x MMP
- Escreva metas SMART e INVEST para histórias de usuários
- O Manifesto Ágil e os Doze Princípios
- 10 regras básicas mais frequentemente mencionadas no Scrum
- O que são os eventos do Scrum?
- O que são as Cerimônias Scrum?
- O que é a preparação do backlog do produto?
- O que é um Sprint no Scrum?
- Heartbeat of Scrum – The Daily Standup
This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Ру́сский, Việt Nam, 简体中文 and 繁體中文.