Ricardo Borges da Silva| 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
User Stories
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 addgit 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
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 |
Plano de Recursos Humanos
Identificação dos Riscos
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 |