1.4.3 - Padrão de Escrita de Itens no Backlog¶

1. Identificação do Item¶

Abaixo estão descritas as regras para a identificação de um item.

1.1. Descrever entre "[]" o tipo do item que será executado;

Exemplo: [Requisito], [História].

1.2. Caso o item já tenha sido executado anteriormente, deve acrescentar a palavra “Mudança” dentro do colchete do tipo:

Exemplo: [História-Mudança]

1.3. Para itens do tipo [Requisito], logo após o colchete do item, colocar a descrição da necessidade do Dono do Produto;

Exemplo: [Requisito] Filtrar a lista de usuários por data/período de cadastro.

1.4. Para Itens de [Requisito – Mudança], deve-se acrescentar o nome da US (User Storie) que será alterada entre "[]";

Exemplo:[Requisito-Mudança] [USXXX - Consultar Dados] Filtrar a lista de usuários por data/período de cadastro.

1.5. Quando o item de mudança de requisitos envolver a mesma alteração em mais de uma funcionalidade, deve-se colocar entre colchetes "ver descrição" e incluir na descrição do item a lista de histórias impactadas pela mudança;

Exemplo: [Requisitos - Mudança][ver descrição] Alterar mensagem de sucesso padrão

1.6. Para itens do tipo [História] ou [Item de Trabalho], deve-se criar um item no backlog para cada história que será alterada ou para cada nova história que será implementada;

Exemplo: [História][US001 - Incluir usuário]

1.7. Implementações que impactam/alteram 2 ou mais histórias, devem ser do tipo [Item de Trabalho]. Nesse caso, logo após o colchete do tipo do item, deve-se colocar entre "[]" a(s) história(s) impactadas;

Exemplo: [Item de Trabalho][US001][US002][US003] Acrescentar a situação do usuário no Gerenciar Usuários

1.8. Caso haja 4 ou mais histórias impactadas pelo mesmo item, deve-se colocar entre colchetes "ver descrição", e acrescentar na descrição do item a lista de histórias impactadas;

Exemplo: [Item de Trabalho][ver descrição] Alterar título/nome do campo "Usuário" para "Pessoa"

1.9. Bugs - Itens do tipo “bug”, devem ser criados quando se identifica um erro ou defeito em uma funcionalidade. Para esses casos, poderá ser criado um item contendo uma lista com a descrição dos bugs encontrados.

Os bugs podem ser de dois tipos:

• Bugs de sistema construídos pela fábrica

Quando forem identificados bugs em sistemas ou funcionalidades desenvolvidas, desde o seu início, pela fábrica, deve-se criar o item com o nome no seguinte formato: [Bug][Garantia] descrição resumida.
Na descrição desses itens, deve-se especificar o bug ou lista de bugs, identificando a funcionalidade quando possível:

Exemplo:
Lista de bugs

• O botão salvar não funcionou (US003 – Gravar Status);
• O cálculo de valor está apresentando o resultado como “0”, independente do cenário testado (US124 – Cálculo de nota final);

• Bugs herdados de sistemas (legado) OU fora do tempo de garantia da fábrica

Quando forem identificados bugs em sistemas ou funcionalidades desenvolvidas por outras fábricas de software ou fora do tempo de garantia, deve-se criar o item com o nome no seguinte formato: [Bug][Corretiva] descrição resumida.
Na descrição desses itens, deve-se especificar o bug ou lista de bugs, de maneira detalhada e que possibilite identificar e corrigir o problema:

Exemplo:
Lista de bugs

#Ao se acessar a funcionalidade “Gravar Status” (caminho: Menu > Submenu), preencher todos os campos obrigatórios e selecionar a opção “Gravar”, o sistema não realizou nenhuma ação. Nesse caso, após a seleção do botão “Gravar”, o sistema deve salvar as informações na base de dados e apresentar a mensagem “Dados gravados com sucesso” e limpar os campos do formulário;

#Ao se selecionar a opção “ver resultado final” na tela Resultados (caminho: Menu > Submenu), o sistema não apresenta o valor do resultado conforme a média das notas, mas apresenta o valor “0” em todos os casos testados. Nessa situação, após se selecionar a opção “ver resultado final”, o sistema deve realizar o calculo: ([nota1] + [nota 2])/2; apresentar o resultado dessa fórmula ao usuário;