Processo Scrum: Dos itens do Backlog do Produto ao Incremento do Produto Entregável

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