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
This is an old version of this page. You can view the most recent version or browse the history.

processo

Home Escopo Gerência Processo Mockups Configuração Arquitetura DataBase 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