Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • V Vou Imigrar Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • 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
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar
  • Vou Imigrar
  • Vou Imigrar Wiki
  • Wiki
  • processo

Last edited by Arthur Kunzler Jun 18, 2022
Page history

processo

Home Escopo Gerência Processo Mockups Configuração Arquitetura DataBase Infra Referências

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

Branches

O padrão utilizado para nomenclatura da branches será em inglês e deve seguir o padrão feat/nome-da-feature, onde os nomes podem ser retirados diretamente do Trello. Caso seja necessário alguma correção, deverá ser modificado o prefixo para "fix", exemplo fix/nome-da-feature.

Primeiramente vá para a branch develop e atualize para a versão atual:

git checkout develop
git pull

Caso a branch da feature ainda não estiver criada utilize:

git checkout -b nome-da-branch

Commits

Após executar este comando você estará na nova branch, faça as alterações necessárias no código e commite as mudanças:

git add .
git commit -m "comentario-do-commit"

O comentário deve descrever o que foi alterado no código e deverá ser em inglês. Não hesite em realizar vários commits, assim podemos o desenvolvimento fica melhor documentado.

Após, se for o primeiro commit dessa branch, para que ela troque de local para remote:

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

Caso contrário realize um:

git push

Lembre de sempre enviar seus commits para o remoto com o uso do git push após realizar seu trabalho, assim os outros desenvolvedores terão sempre as ultimas atualizações do código.

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 se certificar que não terá conflitos, siga os seguintes passos:

git checkout develop
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

Abra o merge request da sua branch para a develop, no título coloque o nome da feature que foi desenvolvida, e descreva brevemente o que foi realizado no campo de descrição.

Matriz de Responsabilidade

As responsabilidades foram atribuidas com base nos níveis de AGES.
Foi criada uma matriz específica para a sprint 0, pois ela possui atividades diferentes das demais.

Significado das letras:

Letra Papel
R Responsável
A Autoridade
C Consultado
I Informado

Sprint 0

Atividade AGES I AGES II AGES III AGES IV
Definir organização do time I I I R/A
Realizar estudos dirigidos R R R R
Alimentar a wiki R R R R/A
Definir tecnologias (front/back) C C R/A R
Definir ferramenta de mockups R R R R
Desenvolver mockups R R/A I I
Documentação de requisitos R R I R
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 R/A C
Documentar arquitetura inicial do projeto I R R/A I
Apresentação Sprint 0 C C C R

Sprints 1, 2, 3 e 4

Atividade AGES I AGES II AGES III AGES IV
Alimentar a wiki R R R R
Definir squads C C C R
Quebra de tasks R R R R
Desenvolvimento R R R/A C/I
Code review R R R R
Deploy da aplicação I I R/A I
Apresentação das Sprints C C C 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 o Cliente do projeto, 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 (início dos encontros síncronos) Máximo 20 minutos
Sprint Review Momento de apresentar para o Cliente o resultado do que foi desenvolvido durante a Sprint coletando validações e inputs dos Stakeholders para cada atividade do Sprint Backlog. 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
Sprint Retrospective Momento onde o time reflete sobre a sprint anterior, levantando os pontos bons, ruin e melhorias (Action Items). Também é feita a votação do membro destaque da sprint. AGES IV AGES I, II, III, IV No final de cada sprint 1 hora

Plano de Riscos

Risco Probabilidade Impacto Severidade Estratégia Ações
Alterações no escopo do projeto 7 5 35 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 4 7 28 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 User Stories do sprint backlog 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 no sprint delivery 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.
Impossibilidade de homologação na AWS 3 2 6 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. Encontrar e corrigir o problema antes da próxima entrega.
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.
Atingir o limite de uso gratuito da API de mapas 2 6 12 Transferir Alterar a implementação para utilizar alguma outra opção gratuita de API de mapas.
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
  • Infraestrutura
  • Instalação
  • Mockups
  • Utilizando a wiki
    • adicionando imagens
    • escrevendo em markdown
    • wiki no editor de texto
  • arquitetura
  • banco_dados
  • codigo
  • configuracao
  • escopo
  • estudos
  • gerencia
  • Home
  • processo