processo

Home	Escopo e Cronograma	Gerenciamento do Projeto	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 Branching Model
Plano de Comunicação
Plano de Riscos

Git Branching Model

O modelo de gestão das branches do Git é baseado no Git Flow "tradicional" com adaptações. Não é previsto o uso de branches hotfix/*, uma vez que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente.

O desenvolvimento nos repositórios devem seguir o fluxo de Git aqui definido:

uma branch master com o código atualmente em produção;
uma branch develop com o código em desenvolvimento, com funcionalidades finalizadas mas ainda em fase de testes para validação;
feature branches para tasks relacionadas às user stories a serem desenvolvidas. Uma branch de task deve ser nomeada com o número único da task, seguida da breve descrição da task (por exemplo, feature/t06-login ou feature/t24-reports-ui);
quando uma feature é finalizada, um PR da branch feature/ relacionada é aberto com destino à branch develop.

O código da develop é integrado com a master ao final da sprint, após validação dos stakeholders do que foi desenvolvido.

Dessa forma, o fluxo usual de trabalho é o seguinte:

antes de iniciar o desenvolvimento de uma task, fazer checkout para a branch develop e pegar as últimas atualizações (pull);
criar uma branch para a task com o ID da task (feature/tXX-YYYYY);
"enviar" a branch para o remoto (git push -u origin feature/tXX-YYYYY);
desenvolver, commitar mudanças e atualizar o remoto (push);
voltar para o item 4 até finalizar a task;
abrir um PR com destino à branch develop;
mover o card da task no Trello para a lista Code Review e avisar no Discord (canal #pull-requests) que a task está pronta para review;
fim! 😃

Plano de Comunicação

Evento	Descrição	Responsável	Envolvidos	Frequência	Duração
Kick Off (Exemplo)	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. (Exemplo)	Cliente(s) (Exemplo)	AGES I, II, III, IV e Cliente(s) (Exemplo)	Uma vez (início do projeto) (Exemplo)	1 hora - 1 hora e 30 minutos (Exemplo)
TBD...	TBD...	TBD...	TBD...	TBD...	TBD...

Plano de Riscos

Risco	Prevenção	Contingência	Estratégia
Atingir o limite de uso gratuito do Firebase	Atenção ao limite de armazenamento para não utilizar a sua totalidade	Liberar espaço para armazenamento caso esteja próximo de sua carga máxima (monitoramento)	Manutenção
Tecnologia escolhida não suporta os requisitos para o projeto.	Atenção aos requisitos durante as reuniões e decisões da equipe de como desenvolve-los	Avaliar troca da tecnologia escolhida ou buscar uma via alternativa junto com o cliente para o caso de um requisito especifico	Comunicação
Pouco conhecimento do time nas tecnologias selecionadas	Buscar em que pontos o time precisa de mais conhecimento para realizar as tarefas	Realizar estudos dirigidos, dojos e misturar membros da equipe mais experientes com os menos experientes	Estudo/Comunicação
Agenda de reuniões com os stakeholders	Evitar atrasos nas reuniões de entrega com os stakeholders	Reunir a equipe meia hora antes da reunião para combinar como ela será conduzida e dar tempo de todos chegarem.	Organização/Comunicação