| Termo | Significado |
|---|---|
| Board | Quadro de tarefas |
| Task | Tarefa única, com requisitos, critérios de aceitação e responsável |
| Backlog | Repositório de tarefas a serem refinadas, descritas, atuadas e concluídas |
| Sprint | Período de 2 a 4 semanas, que possui um objetivo a ser atingido e uma quantidade de tarefas a serem realizadas |
| Daily | Reunião diária de manutenção do time, realizada para relatar o que foi realizado no dia anterior, o que será realizado no dia e se há algum problema na realização para cada um dos integrantes. No nosso contexto, é um momento diário, onde os relatos ocorrerão via mensagem na plataforma oficial de comunicação (Discord) |
| Branch | Ramo criado a partir de um ponto no repositório de código de um projeto |
| Deploy | Lançamento de uma versão do projeto, normalmente vinculado à um lançamento de versão de código e uma branch somente para isso |
| Pacote | Coleção de tarefas vinculadas à uma versão ou sprint |
| Pull Request | São propostas de merge, vinculadas de uma branch à outra, com o intuito de facilitar a revisão das mudanças realizadas |
| Merge | Integração de código em uma branch diferente |
| Commit | Uma instância de versionamento do código no repositório |
| Ambiente | Local onde está sendo executado um projeto específico, são isolados e possuem uma finalidade |
**Importante** Assim que uma tarefa sai de uma coluna da esquerda pra direita, ela nunca pode voltar para a coluna anterior ou para colunas à esquerda *(vide casos especiais)*, mesmo que hajam correções a ser feitas. O intuito é sempre manter o fluxo das tarefas seguindo sem bloqueios.
## Colunas O nosso board consiste de 5 colunas: **To-do**, **Fazendo**, **Revisando**, **Staging**, **Finalizadas**. ### To-do Aqui ficam as tarefas da **Sprint** que ainda serão escolhidas por um dos integrantes para realizá-la. ### Fazendo Aqui ficam as tarefas da **Sprint** que estão sendo trabalhadas por algum dos integrantes. Integrantes devem mover as tarefas de “To-do” para esta coluna somente quando começarem a atuar sobre a tarefa. Todas as tarefas presentes nessa coluna deverão ter uma **branch** vinculada à elas. Tarefas só poderão sair da coluna “**Fazendo**” após a finalização das ações descritas na tarefa. ### Revisando Aqui ficam as tarefas da **Sprint** que foram finalizadas por um dos integrantes e estão sendo revisadas por algum outro integrante que não realizou a tarefa. Essa coluna ajuda a ver quais tarefas necessitam da ação de outro integrante do time. A revisão é extremamente importante e reforça a qualidade das tarefas que realizamos. Todas as tarefas presentes nessa coluna deverão ter uma **Pull Request** vinculada à elas. Tarefas só poderão sair da coluna “**Revisando**” após passarem por uma revisão de outro integrante, testando e validando os **Critérios de Aceite** desta tarefa. ### Staging Aqui ficam as tarefas da Sprint que já foram finalizadas, testadas e revisadas, e estão somente esperando o “deploy”. Todas as tarefas presentes nessa coluna deverão estar “**mergeadas**” na **branch** de desenvolvimento. Tarefas só poderão sair da coluna “**Staging**” após criada um **pacote** com todas as tarefas de “Staging” para a criação de uma nova versão. ### Finalizada Aqui ficam as tarefas da Sprint que foram lançadas e não possuem nenhuma ação a ser realizadas por nenhum integrante. --- ## Bloqueios Bloqueios são sinalizações de que uma tarefa há um bloqueio ou impedimento na conclusão da mesma. Bloqueios podem ocorrer em qualquer momento do “Ciclo de Vida” de uma tarefa. Bloqueios devem ser sinalizados apropriadamente, tanto na ferramenta de Board quanto nas reuniões de Daily via mensagem no canal de comunicação oficial. # Definição de Tarefas As tarefas são a parte mais atômica do processo, elas podem ser categorizadas em 4 tipos: ## Tipos 1. **Épicos** Descrevem um objetivo final massivo, como a finalização de uma funcionalidade complexa, um módulo, ou uma etapa do desenvolvimento como a **Prototipagem** ou **Levantamento de Requisitos**. Possui **Histórias** vinculadas. 2. **Histórias** Descrevem uma História de Usuário, têm como objetivo descrever uma funcionalidade atômica, um fluxo de usuário ou uma interação do mesmo com o sistema a ser desenvolvido. Possui **Tarefas** vinculadas. 3. **Tarefas** Descrevem o que deve ser feito pelo integrante do time. Geralmente são tarefas que compõe o desenvolvimento de uma funcionalidade (História) como a criação de uma tela, a criação de certas rotas de API, ou a criação de uma classe específica. Devem ser bem descritas utilizando o padrão descrito na Seção **Padrões**. 4. **Bug** Descrevem um bug, erro ou inconsistência no sistema. Têm maior prioridade e possuem um ciclo de vida diferente do que a das tarefas comuns. ## Padrões 1. **Épicos** 1. Intenção - Deve descrever o motivo do porque esse Épico existe, a finalidade e o impacto que esse Épico provê. 2. Descrição Geral - Deve descrever de forma geral o objetivo das tarefas e histórias vinculadas à esse Épico. 3. Critérios de Aceite - Critérios gerais que definem se esse Épico está pronto para ser finalizado ou não 4. Recursos - Links, textos ou ferramentas de apoio para a realização deste Épico 2. **História** 1. Descrição Geral - Deve seguir o modelo de descrição de História de Usuário Como usuário quero fazer x, visualizar y para chegar em z. 2. Descrição Técnica - Deve descrever o que é necessário desenvolver para que o usuário realize a ação descrita na **Descrição Geral** 3. Critérios de Aceite - Critérios gerais que definem se essa História está pronta para ser finalizada ou não, devem cobrir o que foi descrito na **Descrição Geral** 4. Recursos (Opcional) - Links, textos ou ferramentas de apoio para a realização desta História 3. **Tarefas** 1. Descrição Geral - Descreve de forma geral o que será realizado nesta Tarefa 2. Descrição Técnica - Descreve o que deve ser feito a nível técnico, quais padrões devem ser utilizados, onde deverá ser criado, nome de módulo, ou quaisquer tecnicidades específicas da tarefa 3. Possíveis Impactos - Lista possíveis locais e funcionalidades que irão ser impactadas com a realização dessa tarefa 4. Critérios de Aceite - Critérios específicos que definem o que será revisado e testado nesta Tarefa 5. Recursos (Opcional) - Links, textos ou ferramentas de apoio para a realização desta Tarefa 4. **Bugs** 1. Severidade - Descreve a severidade do bug, têm 4 severidades, da maior para a menor: Urgente, Alta, Média e Baixa. 2. Descrição do Comportamento - Descreve como reproduzir o bug, como foi encontrado esse comportamento, (possívelmente com um vídeo demonstrando a reprodução) 3. Descrição Técnica - Descreve quais partes são possivelmente afetadas e o que deve ser feito para a resolução desse bug 4. Critérios de Aceite - Critérios que definem se o bug realmente foi resolvido e se será reproduzível novamente # 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**” # Padrões e Tipos de Branch No momento utilizamos o padrão de pacotes de branch, ou seja, temos um padrão de nomenclatura de branches apropriado que ajuda na organização, empacotamento, versionamento e entrega das tarefas e do desenvolvimento. Utilizamos o padrão de [**Conventional Commits**](https://www.conventionalcommits.org/en/v1.0.0/) para a nomenclatura do **intuito** das tarefas de acordo com o tipo de alteração realizada no sistema. ## Branches comuns As branchs têm de ser criadas com o seguinte padrão: <intuito-da-tarefa>/<codigo-do-projeto>-<numero-da-tarefa> Exemplo: feat/SOL-132 fix/NEB-532**Importante** O padrão é **obrigatório**, visto que a aplicação do board só vincula as tarefas às branches que possuem a **nomenclatura** **correta**.
## Branches especiais Existem algumas branches especiais que têm propósitos específicos. São essas: ### Branches de Ambiente - develop - Branch integradora de códigos para o ambiente de desenvolvimento. - staging - Branch integradora de códigos para o ambiente de homologação. - prod - Branch integradora de códigos para o ambiente de produção. ### Branches Esporádicas - release - Branch utilizada para intergrar códigos antes do lançamento de uma versão em algum dos ambientes - hotfix - Branch utilizada para criar correções rápidas e precisas, saem diretamente da master/main sem precisar de trazer código não finalizado dos outros ambientes # Padrões e Tipos de Commits Aqui utilizamos uma padronização das mensagens de commits baseado no padrão do [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). ## Padrão As mensagens seguem o seguinte padrão: <tipo>(escopo-opcional): <descrição-do-commit> Exemplo: feat(Carrossel): Criação da estrutura inicial do Carrossel fix(Carrossel): Bug do Carrossel não passando imagens ## Tipos Os principais tipos usados são: - **feat** - descreve a adição de uma nova funcionalidade à base de código - **fix** - descreve a correção de um problema ou bug existente na base de código - **chore** - descreve tarefas “obrigatórias”, que não possuem um intuito de funcionalidade novas - **refactor** - descreve a refatoração, limpeza de código ou renomeação de funções e variáveis - **docs** - descreve a alteração ou criação de novas documentações na base de código ou em documentos como README - **test** - descreve alterações em testes automatizados ou em testes de integração - **merge** - descreve alterações de integração de código (deve ser usado com pouca frequência) ## Escopo Descreve o contexto em que a mudança está sendo realizada, por exemplo, qual funcionalidade ou qual a página. ## Descrição A descrição deve ser sucinta, **não passando mais de 15 palavras** e explicando a alto nível o que foi alterado. # Padrão de Pull Requests Pull Requests são uma parte importante do desenvolvimento de software, devem ser feitos com muita intencionalidade e esporádicamente. As Pull Requests devem seguir um padrão de descrição vinculado ao tipo de tarefa que é vinculado. ## Padrões > ### Tarefa > > #### Descrição Geral > > Descrição das alterações de forma geral > > #### Funcionalidades Alteradas > > Lista das funcionalidades alteradas > > #### Recursos > > Links, textos ou contexto para a Pull Request > > #### Link para a Tarefa > > Link para a tarefa na plataforma de gerenciamento de tarefas > > #### Critérios de Aceite > > Critérios de aceite da tarefa (Devem ser copiados da tarefa na plataforma de gerenciamento de tarefas) > ### Bug > > #### Severidade do Bug > > Severidade do Bug (Urgente, Alta, Média ou Baixa) > > #### Descrição Geral > > Descrição das alterações de forma geral > > #### Funcionalidades Alteradas > > Lista das funcionalidades alteradas > > #### Recursos > > Links, textos ou contexto para a Pull Request > > #### Link para a Tarefa > > Link para a tarefa na plataforma de gerenciamento de tarefas > > #### Critérios de Aceite > > Critérios de aceite da tarefa (Devem ser copiados da tarefa na plataforma de gerenciamento de tarefas)