Gerenciamento de Projeto

Aqui se encontram documentos que tratam sobre o gerenciamento de projetos e padronização de tarefas, Scrum e processos.

Glossário

Existem termos que serão utilizados aqui, porém que existem outras definições ou utilizações fora do contexto do Laboratório.
Aqui estão relatados as definições de acordo com o contexto em que utilizamos.

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
   
   
   
   
   
   
   
   
   
   
   
 

Definição de Scrum

O que é Scrum


Características


Manifesto Ágil

Componentes


Papéis

Product Owner - PO
Scrum Master - SM
Time Dev

Cerimônias (Eventos)

Planejamento da sprint 

Ex:
História: Eu como Viajante, quero ver fotos dos hotéis
Tarefas:

Daily Scrum
Sprint Review
Sprint Retrospective

Uma das técnicas de review é o: 

Começar / Parar / Continuar


Artefatos

Backlog do produto (Product Backlog)
Objetivo da Sprint (Sprint Goal)
Sprint Backlog
Gráfico de Sprint Burndown
Gráfico de Tarefas Cumpridas

Escalabilidade

Definição do Board

Fluxo

O fluxo do board segue de cima para baixo, da esquerda para direita.

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.
    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.
      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.
      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 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

Branches Esporádicas

Padrões e Tipos de Commits

Aqui utilizamos uma padronização das mensagens de commits baseado no padrão do Conventional Commits.

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:

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 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 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)