Página Inicial

Página de Gerênciamento do Projeto

Termo de Abertura (Atualização)

Termo-de-Abertura-do-Projeto-Doe-Vida.pdf

Identificação dos Stakeholders

EAP

Pipeline de Desenvolvimento

GitFlow

Para o Projeto será utilizado 'GitFlow', cada desenvolvedor pega uma US e cria uma branch baseada na branch DEV

git checkout -b feature-branch-name

Após desenvolver a US deve ser commitado e realizado um push para TEST

• git add
• git commit -m "commit message"
• git push

Envie o Merge Request para ser avaliado por um ages 3 ou 4 avaliar, caso aprovado seu código irá para branch de TEST onde será testado funcionalmente por alguém. Caso o revisor deixe algum comentário seu MR não será aprovado e você deverá ajustar seu código ou conversar com o revisor sobre aquele comentário;

Code Review

O code review deve ser realizado por 2 integrantes das AGES 3 e 4, apenas quando duas pessoas aprovarem o código que está sendo enviado o mesmo será mergeado para TEST

Teste Funcional

Para o teste funcional leia a US na coluna de teste funcional, mude para a branch de TEST. Verifique se as US implementadas estão funcionando conforme especificado na US, caso estejam faça o merge de TEST para DEV.

Deploy

O deploy de dev para homolog será realizado nas quintas-feira, todo merge de TEST para DEV deve ser realizado no máximo até quarta a noite para ser apresentado sexta durante a aula.

Cronograma

Cronograma_-_Doe_Vida.pdf

Plano de Comunicação

Evento	Objetivo	Responsável	Envolvidos	Frequência	Duração
Dayly	Acompanhar o desenvolvimento do projeto	Voluntário	Time	de segunda à sexta	10min
Planning	Planejar a próxima sprint	GP	Time	Após retrospectiva	30min
Review	Apresentar o que foi desenvolvido aos stakeholders	GP	Time e stakeholders	Ao final da sprint	30min
Retrospectiva	Avaliar desempenho do time na última sprint, sugerir melhorias e criar planos de ação	GP	Time	Após review	30min
Refinamento	Refinar user stories que serão desenvolvidas na sprint subsequente	GP ou Arquitetetos	GP e arquitetos	Uma vez por sprint	1h

Matriz de responsabilidades

Atividade	Ricardo	Larissa	Lucas Stein	Ramon	Fernando	Luiz	Vitor Demenigh	Eduardo	Gabriel	Giovanni	Igor	Jéssica	John	Leandro	Lucas Bankow	Vitor Delela
Gerenciamento do projeto	R	C	C	C	I	I	I	I	I	I	I	I	I	I	I	I
Elicitação de requisitos	R	R	R	R	R	R	R	I	I	I	I	I	I	I	I	I
Arquitetura	C	R	R	R	I	I	I	I	I	I	I	I	I	I	I	I
Modelagem do banco de dados	C	C	C	C	R	R	R	I	I	I	I	I	I	I	I	I
Desenvolvimento de testes	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R	R

Plano de Respostas a Riscos

Risco	Impacto	Probabilidade	Plano A (prevenção)	Plano B (contingência)	Estratégia
Feriados	3	5	--	Adicionar mais user stories a sprint dado que serão mais longas	Aceitar
Conhecimento do time em relação às tecnologias utilizadas	5	3	Incentivar estudos dirigidos	Formar subequipes balanceadas no quesito conhecimento técnicos	Mitigar
Qualidade do projeto não satisfatória	5	3	Incentivar práticas como testes automatizados e code review	Reduzir quantidade de user stories por sprint para priorizar qualidade acima de quantidade entregue	Mitigar
Demandas fora do escopo	1	3	--	Priorizar demandas de acordo com a duração do projeto	Mitigar
Baixo comprometimento dos stakeholders	3	1	--	Seguir o escopo inicial e o que foi definido na reunião de elicitação de requisitos	Mitigar
Impossibilidade de reuniões presencias	3	1	--	Realizar reuniões onlines e usar canais de comunicação abertos com em uma frequência alta.	Mitigar
Baixo engajamento da equipe	5	3	--	Realizar práticas como pair programing e conding dojo	Mitigar