Refinamento do backlog – automatizado

Refinamento do backlog

O refinamento do backlog é a atividade de preparar itens de trabalho para sua equipe de software trabalhar. Seu acúmulo de histórias de usuários, tarefas de desenvolvedor e ideias épicas é o fila de possíveis itens de trabalho para trabalhar nas próximas semanas (sprints). Para manter um fluxo constante de trabalho para a equipe, uma lista de itens refinados do backlog deve estar pronta para a equipe começar a trabalhar a qualquer momento. Deveria haver um pouco mais pronto e priorizado do que a equipe precisa para os próximos sprints.

O que significa refinamento do backlog?

Refinamento do backlog (também conhecido como preparação do backlog) significa trabalhar na validade e nos detalhes dos requisitos/ideias/tarefas para que as principais questões sejam respondidas corretamente, de modo que o desenvolvedor/testador faça a coisa certa na primeira vez. As histórias de usuários devem ser refinadas e prontas antes do início do trabalho de codificação e teste.

Para encurtar as reuniões do backlog, você deseja que sua contribuição seja da mais alta qualidade possível. Isso significa fazer com que seu analista de negócios ou proprietário do produto refine as histórias de usuários tanto quanto possível antes da reunião. A análise automatizada pode realmente ajudar nisso, pois ajudará você a deixar suas histórias em boa forma antes da reunião de refinamento.

O que “pronto” realmente significa?

Pronto, ou definição de pronto, significa que verificação, questionamento, reformulação, revisão e análise suficientes foram concluídas ANTES da codificação, para que o trabalho de codificação possa ser feito corretamente na primeira vez. Isso significa que os objetivos do usuário são totalmente compreendidos, claros, idealmente mensuráveis e certamente inequívocos antes que uma linha de código seja escrita. (A prototipagem Nb costuma ser um meio útil de verificação de requisitos, mas a prototipagem não é necessariamente codificação).

Uma história de usuário refinada deve ser:

Simplificado

Suas histórias de usuário devem ser declarações funcionais curtas e concisas que descrevam completamente as etapas funcionais de todos os requisitos do usuário. Tal que o sistema esteja em estado estacionário antes e depois das etapas terem ocorrido.

Esclarecido

Suas histórias de usuários devem ser claras, sucintas e inequívocas. O ideal é que vários membros descrevam sua interpretação de cada história de usuário. Cada interpretação é a mesma. Agora, isso é difícil com o idioma inglês, às vezes mesmo que todas as partes estivessem presentes durante a conversa que descreveu a história do usuário. O objetivo é alcançar essa interpretação consistente por todos os membros da equipe, ou seja. a entendimento compartilhado.

Orientado ao usuário

Vemos muitas histórias de usuários começando com “como desenvolvedor…”. Isso não descreve o requisito da perspectiva do usuário, é, em vez disso, um tarefa.  Antes de criar tarefas de desenvolvedor, você deve primeiro ter uma história de usuário que descreva o que o usuário precisa alcançar e por quê. Então, e somente então, você poderá dividir isso em tarefas de desenvolvedor, se necessário.

Consistência verificada

É vital que você use termos consistentes em todas as suas histórias de usuário para cada persona de usuário. Também é vital que você use palavras idênticas para cada tipo de objeto. Esse problema é muito comum quando duas ou mais pessoas estão criando as histórias de usuário, mas pode até acontecer se apenas uma pessoa estiver fazendo o trabalho. O uso inconsistente de nomes de objetos ou personas de usuários levará a interpretações inconsistentes e erros.

Completude verificada

A sua história de usuário está completa e descreve todas as funcionalidades necessárias para oferecer a experiência do usuário ou as funcionalidades necessárias? Você “enterrou” a funcionalidade real em seus critérios de aceitação (este é um erro muito comum).

Se você estiver mantendo dados dentro de um sistema, é prática comum realizar uma análise CRUD, crie uma matriz CRUD. Isso o ajudará a garantir que todos os dados sejam criados, lidos, atualizados e excluídos por pelo menos um processo. A análise CRUD é um meio eficiente e eficaz de garantir que suas histórias de usuários sejam competitivas entre si. Eventualmente, todos os dados precisam ser totalmente mantidos por um sistema. A realização antecipada da análise CRUD proporcionará uma melhor avaliação do escopo final do seu projeto.

Dimensionado

É importante dimensionar cada história de usuário, épico ou tarefa em seu backlog. Por que? Para que você possa planejar e priorizar o trabalho. Embora muitas equipes utilizem a ideia de tamanhos de camisetas ou pontos de história, eles são de uso limitado, pois são inconsistentes e não têm significado absoluto. Nós recomendamos:

• Tarefas são dimensionados em horas de pessoal ou dias de pessoal.
• Histórias de usuários, histórias de usuários especificamente funcionais são dimensionadas em pontos de função COSMIC (CFPs).
• Épicos geralmente pode ser estimado em CFPs.

N.º. Os CFPs de uma equipe geralmente são facilmente conversíveis em horas estimadas. Para mais informações sobre Pontos de Função COSMIC.

Priorizado

Os itens do backlog devem ser priorizados. A prioridade (e os itens sequenciais de prioridade semelhante) devem ser determinados com pelo menos as seguintes considerações:

• Valor da funcionalidade para o negócio, incluindo uso provável
• Tamanho (determina o esforço provável de entrega).
• Impacto sobre o negócio de atrasar isso. Custo do atraso.
• Relacionamento técnico desta funcionalidade com outras, ou seja, dependências técnicas
• Risco de incógnitas que podem levar a uma mudança significativa em outro trabalho realizado.

Uma técnica comum para mapear algumas dessas considerações para um valor numérico é chamada Weighted Shortest Job First (WSJF).

Colin Hammond, 2022

Refinamento do backlog automatizado

Outros artigos sobre este tópico discutirão a divisão e a elaboração de histórias. Consideramos esses termos um pouco vagos. Fomos mais específicos porque é importante que assim seja. Uma palavra errada em um requisito pode levá-lo a ser mal interpretado e potencialmente a horas e horas de desperdício, se o código precisar ser reescrito.

Leitura adicional de sites externos

Lutei para encontrar muitos artigos que pudesse defender fortemente. Eu recomendo este livro Requisitos de Software, de Karl Wiegers e Joy Beatty

Artigo Digite sobre refinamento do backlog