Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Comunicacao HSL Wiki Comunicacao HSL Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Comunicacao HSL
  • Comunicacao HSL WikiComunicacao HSL Wiki
  • Wiki
  • processo

Last edited by Leonardo Vargas Soares Oct 20, 2021
Page history

processo

Home Escopo e Cronograma Processo Design/Mockups Configuração Arquitetura Código BD Qualidade Utilização Instruções AWS

Processo de Desenvolvimento

Descrição

Esta seção é dedicada a apresentar o processo de desenvolvimento do time, junto dela serão apresentados documentos referentes a maneira como o time se organizou na realização das tarefas e na forma de trabalho.

Sumário

  • Git Workflow
  • Matriz de Responsabilidade
  • Plano de Comunicação
  • Plano de Riscos

Git Workflow

Branches

Nomes

Como padrão para nomes de branches, foi decidido o seguinte:

<tipoDeItem>-<nomeDoItem>

Exemplo de Componentes:

component-navBar
component-slider

Exemplo de Páginas:

page-recipes
page-creations

Criação

Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch dev antes de criar uma branch nova:

git pull origin dev

Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:

git checkout -b <nomeDaBranch>

Assim que criar a branch, é necessário fazer um pushpara garantir que a mesma estará remota:

git push --set-upstream origin <nomeDaBranch>

Pronto! Agora você já pode começar a programar na sua Branch.

Commits

Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de commit e push

Salvando Localmente

Para garantir que apenas o código necessário para funcionamento da tarefa lembre-se de realizar o comando add apenas nos arquivos essenciais para a tarefa:

git add <nomeDoArquivo>

Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:

git commit -m 'descrição da tarefa em português'

Não hesite em realizar vários commits, assim podemos ter docuemntado e salvo vários estados do desenvolvimento

Salvando Remotamente

Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando push:

git push

Merge Requests

Depois de uma task ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:

Criando o Merge Request

A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request siga os seguintes passos:

  1. Selecionar a branch de origem (sua branch de desenvolvimento);
  2. Selecionar a branch de destino (branch develop);
  3. Selecione Compare branches and continue
  4. Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
  5. Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
  6. Na seção Assignee, selecione Assign to me para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
  7. Em Milestone selecione a Sprint em que a tarefa foi realizada;
  8. Em Labelsselecione qual é o tipo de tarefa que foi realiada;
  9. Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em Submit Merge Request.

Padrão para abertura de Merge Request

Os merge requests também devem seguir um padrão de criação:

O Title deve ser escrito UserStory - Título do Card no Trello e na Description deve ser informado o link para o card, além de uma descrição da tarefa e se possível uma imagem/gif para visualização do que foi desenvolvido. Exemplo:

Title: US04 - Criar componente de botão para navegar para a tela de comparação
Description: https://trello.com/c/d67o9cLk/26-us09-criar-menu

Revisando o Merge Request

A revisão de merge request pode ser realizada por qualquer desenvolvedor, mas é preciso da aprovação de pelo menos um AGES III ou AGES IV para que a mesma seja incorporada na dev.

Na hora de revisar o Merge Request, entre na branch em sua máquina e teste a funcionalidade/bug/componente/tela de acordo com os critérios de aceitação apresentados no Airtable.

Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração.

Matriz de Responsabilidade

Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.

Atividades AGES I AGES II AGES III AGES IV
Alimentar a wiki R R R R
Definir squads C C C R
Definir marcos da sprint I I C R
Quebra de tasks C C C R/A
Desenvolvimento R R R/A C/R/A
Code review C C R/A C/R/A
Executar testes funcionais A A R R
Deploy da aplicação I I R R/A
Apresentação da review C C C R

I: Deve ser informado C: Deve ser consultado R: Responsável A: Aprova

Plano de Comunicação

Evento Descrição Responsável Envolvidos Frequência Duração
1ª Reunião com o Cliente Primeiro encontro entre o time e os stakeholders do projeto. Nesse encontro são apresentados os principais itens do projeto e a ideia geral. Também são realizados questionamentos sobre o que foi apresentado, com a finalidade de ajudar nas definições dos requisitos do projeto em conjunto com o cliente. Cliente(s) AGES I, II, III, IV e Cliente(s) Uma vez (início do projeto) 1 hora - 1 hora e 30 minutos
Daily Cada membro da equipe atualiza os outros sobre o que produziu desde o último encontro síncrono (ou assíncrono via Discord), o que visa fazer em seguida, e se tem obstáculos, com finalidade de que possam ser discutidos e resolvidos. AGES IV AGES I, II, III e IV Duas vezes na semana, uma síncrona (Segundas) e outra assíncrona (Sextas) Síncrona: 15 minutos; Assíncrona: 1 dia
Sprint Review Momento em que é apresentado o que foi desenvolvido e revisa-se o trabalho realizado. Esse envento é uma preparação para a Sprint Planning, pois podemos ver o que deu certo e o que precisamos melhorar em conjunto com o cliente. AGES IV AGES I, II, III, IV e Cliente(s) Sempre no final das Sprints. Aproximadamente a cada 3 semanas. 30 minutos - 1 hora
Sprint Planning É realizado o planejamento do que irá ser feito durante a Sprint que se inicia. Realizada a priorização das User Stories que estão no Product Backlog para o Sprint Backlog atual do projeto. AGES IV AGES I, II, III e IV No início das Sprints. Aproximadamente a cada 3 semanas. 15 minutos - 30 minutos
Sprint Retrospective Momento em que a equipe revisa como foi o processo e o trabalho do time na Sprint. Os membros são incentivados para expor o que gostaram, o que não gostaram, com quem gostaram de trabalhar e qualquer comentário construtivo sobre a Sprint que se encerra. Como output desse encontro, temos itens de ação para aprimorar e melhorar processos que não foram produtivos na Sprint seguinte. AGES IV AGES I, II, III e IV No final das Sprints. Aproximadamente a cada 3 semanas. 45 minutos - 1 hora
Tasks/Squads Planning Evento realizado pela gerência, com o intuíto de dividir o time em Squads focando produtividade. A divisão é pensada para maximizar desempenho na sprint atual. Após a divisão dos squads, é realizada a quebra das User Stories priorizadas para a Sprint atual em tarefas. Essas tarefas são divididas entre os squads e, consequentemente, entre seus integrantes. As tarefas possuem o menor escopo possível e critérios de aceitação mensusáveis para cada integrante. AGES IV AGES IV No início das Sprints. Aproximadamente a cada 3 semanas. 1 hora - 1 hora e 30 minutos
Code Review and Deploy Meeting Reunião para definição dos responsáveis pela revisão de código e para revisão da apresentação final da Sprint. AGES IV AGES IV No final das Sprints, um final de semana antes da entrega. Aproximadamente a cada 3 1 hora - 1 hora e 30 minutos

Plano de Riscos

Risco Prevenção Contingência Estratégia
Falha na comunicação com steakholds Manter canal de comunição aberto com steakholders e incentivar comuniação Revisar documentação e entrar em concenso com o time sobre estratégia a ser adotada Mitigar
Atraso na entrega Revisar constantemente as tarefas e o andamento dos épicos a cada sprint Focar esforço no trabalho atrasado Mitigar
Falta de conhecimento nas tecnologias utilizadas Incentivar estudos dirigidos Fornecer materias de estudo e realizar pair-programming para balacear conhecimento nas duplas Mitigar
Falta de motivação na equipe devido ao distanciamento Lideranças devem acompanhar tarefas no trello e verificar constantemente a moral da equipe Online Party no Discord Aceitar
Alterações de escopo Fechar o escopo do projeto com os Stakeholders antes do início do desenvolvimento Negociar com Stakeholders a troca de itens para não alterar o tamanho do escopo Mitigar
Clone repository
  • Utilizando a wiki
    • adicionando imagens
    • escrevendo em markdown
    • wiki no editor de texto
  • arquitetura
  • banco_dados
  • codigo
  • configuracao
  • design_mockups
  • escopo
  • Home
  • instrucoes
  • instrucoesAws
  • processo
  • qualidade
  • utilizacao