Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • M Meu Mundo Azul 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
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Meu Mundo Azul
  • Meu Mundo Azul Wiki
  • Wiki
  • processo

Last edited by Camila Borba Rocha Aug 24, 2022
Page history

processo

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

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 que o time se organizou e trabalha.

Sumário

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

Git Workflow

O Gitflow é um modelo alternativo de ramificação do Git que consiste no uso de ramificações de recursos (features) e várias ramificações primárias (Master e DEV).

Fluxo_GIT

Branches

Cada branch relacionada à features será criada a partir da branch dev. Nos tópicos abaixo será explicado as nomenclatura que serão utilizadas para o desenvolvimento.

Nomes

O nome da branch será em inglês e deve seguir o padrão feature/nome-da-feature, onde os nomes das features podem ser encontrados no Trello. Quando for necessário fazer alguma correção, o prefixo utilizado deverá ser fix/nome-da-feature.

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 criar a Branch, para isso, execute o seguinte comando:

git checkout -b <nomeDaBranch>

Commits

Após criar a sua branch de desenvolvimento, faça as alterações necessárias no código e commite as mudanças:

Para adicionar as mudanças é possível utilizar dois comandos:

O comando git add . , faz com que todas as alterações que foram feitas localmente sejam commitadas no repositório remoto.

git add .

O comando git add <nomeDoArquivo> , faz com que apenas as alterações do arquivo informado seja commitado no repositório remoto.

git add <nomeDoArquivo>

Após adicionar as alterações é necessário commitar elas usando o comando git commit-m"comentario-do-commit"

git commit-m"comentario-do-commit"

O comentário deve descrever o que foi alterado no código e deverá ser em inglês.

Após, se for o primeiro commit dessa branch:

git push --set-upstream origin nome-da-branch

Caso contrário utilize:

git push 

Importante: Sempre envie seus commits para o repositório remoto após realizar o seu trabalho, assim os outros desenvolvedores terão sempre as ultimas atualizações do código.

Merge Requests

Depois da sua issue 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 dev.

Antes de abrir a MR certifique-se que, não irá ocorrer conflitos da sua branch com a DEV, para isso, siga os seguintes passos:

git checkout dev
git pull
git checkout nome-da-branch
git merge develop

Resolva os conflitos caso ocorra, após resolvê-los, envie as alterações para o Gitlab:

git push

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 dev);
  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. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
  7. Na seção Assignee, marcar os AGES 3 ( Camila Borba Rocha, Leonardo Argenton Pasqualotto e Marco Antônio G. Goedert ).

Matriz de Responsabilidade

Tendo em vista que na primeira sprint do projeto temos atividades diferentes que nas demais, foi feita uma matriz de responsabilidade exclusiva para esta. Segue abaixo o significado de cada uma das letras utilizadas nos quadros:

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

Sprint 0

Atividades AGES I AGES II AGES III AGES IV
Alimentar a wiki R R R R
Definir organização do time I I I R/A
Realizar estudos dirigidos R R R R
Definir tecnologias (front/back) C C R/A C
Desenvolver mockups R R/A I I
Criar User Stories I I I R/A
Criar projeto inicial (front/back) I I R/A I
Modelar o BD (conceitual/lógico) I R/A C C
Documentar arquitetura inicial do projeto I R R/A I

Sprint 1,2,3 E 4

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

Plano de Comunicação

Evento Descrição Responsável Envolvidos Frequência Duração
Kickoff A reunião de Kickoff é a primeira reunião entre o time e os Stakeholders. Nela é apresentada a ideia geral do projeto e são respondidas dúvidas e questionamentos sobre o mesmo, possibilitando um levantamento inicial dos requisitos do projeto por parte da equipe, com o auxílio do cliente, que detém o conhecimento sobre o produto a ser desenvolvido. AGES IV e Cliente AGES I, II, III, IV e Cliente Uma vez no início do semestre 1 hora e 30 minutos
Daily Cada integrante do time atualiza os demais sobre o que fez desde o último encontro síncrono, o que pretende fazer em seguida e se tem impedimentos para que possam ser solucionados. As dailies são registradas pelos AGES IV AGES IV AGES I, II, III, IV Terças-feiras via Discord e Sextas-feiras às 19:15 Máximo 20 minutos
Sprint Review Momento de apresentar para o Cliente o que foi desenvolvido durante a Sprint coletando validações e feedback dos Stakeholders para cada atividade acordada. AGES IV AGES I, II, III, IV e Cliente No final de cada sprint 1 hora
Sprint Planning Decisão, junto ao cliente, das tarefas que serão realizadas durante a sprint seguinte. AGES IV AGES I, II, III, IV e Cliente No final de cada sprint 30 minutos
Retrospectiva da Sprint Momento onde o time reflete sobre a sprint anterior, levantando os pontos bons, ruin e melhorias a serem feitas. AGES IV AGES I, II, III, IV Após a Sprint Planning 30 minutos
Planning Poker Momento em que o time atribui um nível de complexidade para cada tarefa da Sprint e comenta como pode ser feita. AGES IV AGES I, II, III, IV Após retrospectiva 30 minutos

Plano de Riscos

Risco Probabilidade Impacto Severidade Estratégia Ações
Alterações no escopo do projeto 6 5 30 Mitigar Evitar grandes mudanças no escopo asó a definição inicial, aceitando somente mudanças que não necessitem de muito retrabalho.
Falta de engajamento dos membros do time 7 8 56 Mitigar Acompanhar o desenvolvimento das tarefas no Trello. Fazer reuniões periodicas (dailies) para saber sobre o progresso do desenvolvimento. Caso haja impacto no time, conversar com os membros do time e replanejar as tarefas caso necessário.
Não entregar as tarefas da Sprint 5 6 30 Mitigar Acompanhar o desenvolvimento das atividades no Trello e realizar reuniões periódicas com o time para saber sobre o progresso do desenvolvimento, ressaltando o tempo limite da sprint.
Problemas inesperados na entrega 3 8 24 Eliminar Testar a aplicação na homologação para todas funcionalidades antes da entrega. Homologar o projeto com pelo menos 1 dia de antecedência da entrega da sprint.
Ausência do cliente no sprint delivery 1 8 8 Transferir Relembrar o cliente da entrega da sprint.
Falta de créditos da AGES para homologação na AWS 2 4 16 Transferir Realizar a homologação em uma plataforma alterativa, como MS Azure. Caso não seja possível, fazer a apresentação da entrega de sprint executando a aplicação localmente.
Falta de conhecimento nas tecnologias utilizadas 6 6 36 Mitigar Recomendar documentações e tutoriais sobre as tecnologias utilizadas para os membros do time. Desenvolver utilizando pair programming para compartilhamento de conhecimento.
Clone repository
  • Gerência
  • Instalação
  • Retro
  • Utilizando a wiki
    • adicionando imagens
    • escrevendo em markdown
    • wiki no editor de texto
  • arquitetura
  • banco_dados
  • configuracao
  • design_mockups
  • escopo
  • estudos
  • gerencia
  • Home
  • instrucoes
View All Pages