Políticas de Issues · Git Breakdown

Data	Autor	Descrição	Versão
31/08/2019	Diego Resende	Abertura do Documento	0.1

As issues vão ser utilizadas dentro do desenvolvimento do projeto como forma de facilitar o acompanhamento das contribuições no projeto de forma a mitigar o risco de trabalho duplicado e facilitar a organização das tarefas assim como a sua distribuição para a equipe

1. Criando uma issue

Antes de criar uma issue deve-se averiguar se alguns pontos estão satisfeitos. Segue os pontos a serem analisados abaixo:

Você conhece a política de issues?
Existe um problema, solução, modificação, reparo a ser realizado no projeto?
Já existe uma issue relacionada?

Se todas as perguntas forem satisfeitas pode seguir.

1.1. Título da issue

Descreva o problema de forma sucinta, sendo sucinto da descrição do título. Um padrão a ser seguido é o uso do [Verbo] + [substantivo].

Ex.: Criar documento de visão

Em caso de User Story é recomendado que siga o padrão: [USX] + [Verbo] + [Substantivo]

Ex.: US12 - Manter usuário

1.2. Corpo da issue

Todas as Issues devem possuir uma descrição detalhada de o que deve ser feito e como deve ser feito.

Em caso de User Story, a issue deve seguir um padrão onde deve responder as seguintes perguntas:

Eu como [Papel], quero [Meta] para que eu possa [Motivo].

Ex.: “Eu, como desenvolvedor, desejo realizar os testes funcionais das classificações, para garantir o devido funcionamento da aplicação”

Após a descrição detalhada, o corpo da issue deve haver um checklist de todas as operações que deve ser realizada.

2. Classificando com Labels

2.1 Qual tipo de incremento?

a) Funcionalidade
b) Dúvida Técnica
c) Documentação

2.2 Quem realiza?

a) Scrum Master
b) DevOps
c) PO
d) MDS

2.3 Pontos (em caso de US)

Pontos de acordo com a sequência de Fibonacci previamente definida