# Ciclo de Vida das Tarefas

Cada tarefa possui um processo da sua criação à conclusão que comumente chamamos de “Ciclo de Vida”.

Esse Ciclo de Vida dita as ações que serão realizadas sobre as tarefas ao longo do seu processo de conclusão.

## Definição

O Ciclo, normalmente, se dá assim:

1. Cria-se a tarefa no Backlog 
    1. Descreve em poucas palavras o intuito da tarefa em seu título assim como seu escopo, seguindo o padrão em [Definição de Tarefas](https://bookstack.ljit.com.br/books/padronizacao-e-gerenciamento-de-projetos/page/definicao-de-tarefas "Definição de Tarefas").
    2. Descreve em alto nível, sem muito detalhamento, de acordo com o tipo e o template da tarefa, as informações necessárias ao template, como “**Descrição Geral**”, “**Descrição Técnica**” ou “**Critérios de Aceite**”.
2. A tarefa é discutida e possivelmente selecionada para ser realizada em uma Sprint
3. A tarefa entra no Board na coluna "**To-do**"
4. O integrante do time lê e escolhe a tarefa e a vincula a si
5. O mesmo integrante, ao começar a realizar a tarefa, move-a para a coluna "**Fazendo**" 
    1. Caso seja uma tarefa de código, o desenvolvedor deve: 
        1. Criar uma branch seguindo o padrão de branchs descrito em [Padrão e Tipos de Branch](https://bookstack.ljit.com.br/books/padronizacao-e-gerenciamento-de-projetos/page/padroes-e-tipos-de-branch "Padrões e Tipos de Branch").
        2. Vincular a branch à tarefa na plataforma de gerenciamento de tarefas.
        3. Realiza a tarefa.
6. Ao finalizar a tarefa, move-a para a coluna “**Revisando**” 
    1. Caso seja uma tarefa de código, o desenvolvedor deve: 
        1. Criar uma **Pull Request** descrevendo as alterações e utilizando o [Padrão de Pull Requests](https://bookstack.ljit.com.br/books/padronizacao-e-gerenciamento-de-projetos/page/padrao-de-pull-requests "Padrão de Pull Requests").
        2. Pedir para um outro desenvolvedor fazer o Code Review (Revisão de Código) das alterações.
        3. O outro desenvolvedor deve então testar a tarefa em sua máquina e verificar se a mesma possui e cumpre os **Critérios de Aceite** descritos na tarefa.
        4. Só então o outro desenvolvedor poderá aprovar a **Pull Request**.
        5. Após a aprovação da Pull Request, o desenvolvedor deve realizar o merge da Pull Request na branch **develop**.
7. Após a revisão de pares, a tarefa poderá ser movida para a coluna “**Staging**”
8. Ao final da Sprint, é criado um pacote com as tarefas realizadas, onde será listadas todas as tarefas realizadas e quais funcionalidades foram adicionadas. 
    1. Sobre a criação de versões, ler Criação de Versões.
9. Após o lançamento do pacote de tarefas, a tarefa poderá ser movida para a coluna “**Finalizada**”