|
|
|
<table>
|
|
|
|
<th> [Home](home) </th>
|
|
|
|
<th> [Gerenciamento](gerenciamento) </th>
|
|
|
|
<th> [Escopo e Cronograma](escopo)</th>
|
|
|
|
<th> [Design e Mockups](design) </th>
|
|
|
|
<th> [Arquitetura](arquitetura) </th>
|
|
|
|
<th> [Database](database) </th>
|
|
|
|
<th> [Infraestrutura](infraestrutura) </th>
|
|
|
|
<th> [Desenvolvimento & Qualidade](qualidade) </th>
|
|
|
|
<th> [Instalação e Configuração](instalacao) </th>
|
|
|
|
<th> [Utilização](utilizacao) </th>
|
|
|
|
</table>
|
|
|
|
|
|
|
|
> **Instruções para edição:** A atualização desta seção deve ser realizada preferencialmente pelos membros da equipe **Ages IV**, ou sob sua supervisão direta.
|
|
|
|
|
|
|
|
|
|
|
|
# Gerenciamento do Projeto
|
|
|
|
|
|
|
|
## Sumário
|
|
|
|
- [Gerenciamento do Projeto](#gerenciamento-do-projeto)
|
|
|
|
- [Sumário](#sumário)
|
|
|
|
- [Termo de Abertura](#termo-de-abertura)
|
|
|
|
- [Cronograma](#cronograma)
|
|
|
|
- [EAP/ Release Plan](#eap-release-plan)
|
|
|
|
- [User Stories](#user-stories)
|
|
|
|
- [Squads](#squads)
|
|
|
|
- [Sprint 1](#sprint-1)
|
|
|
|
- [Sprint 2](#sprint-2)
|
|
|
|
- [Sprint 3](#sprint-3)
|
|
|
|
- [Sprint 4](#sprint-4)
|
|
|
|
- [Matriz de responsabilidades](#matriz-de-responsabilidades)
|
|
|
|
- [Plano de Comunicação](#plano-de-comunicação)
|
|
|
|
- [Plano de Riscos](#plano-de-riscos)
|
|
|
|
|
|
|
|
## Termo de Abertura
|
|
|
|
<a href="resources/images/termo_de_abertura_do_projeto-3JK5JK-FluiMap.pdf" target="_blank">📄 Termo de Abertura</a>
|
|
|
|
|
|
|
|
|
|
|
|
## Cronograma
|
|
|
|
O cronograma do projeto pode ser encontrado pelo link: [Cronograma FluiMap](escopo#cronograma)
|
|
|
|
|
|
|
|
|
|
|
|
## EAP/ Release Plan
|
|
|
|
|
|
|
|
|
|
|
|
<img src="resources/images/under_construction.PNG" width="150">
|
|
|
|
|
|
|
|
## User Stories
|
|
|
|
|
|
|
|
<details open>
|
|
|
|
<summary> US01 T1 - Criar botão de ordem de operações na tela inicial </summary>
|
|
|
|
<br>
|
|
|
|
|
|
|
|
**Critérios de aceitação:**
|
|
|
|
|
|
|
|
1. Seguir design estabelecido no Figma
|
|
|
|
|
|
|
|
2. Ser responsivo
|
|
|
|
|
|
|
|
3. Criar rota par garantir que o usuário seja redirecionado para a página correspondente.
|
|
|
|
|
|
|
|
</details>
|
|
|
|
|
|
|
|
<details open>
|
|
|
|
<summary>US01 T2 - Criar botão de cadastro de matéria prima</summary>
|
|
|
|
<br>
|
|
|
|
|
|
|
|
**Critérios de aceitação:**
|
|
|
|
|
|
|
|
1. Seguir design estabelecido no Figma
|
|
|
|
|
|
|
|
2. Ser responsivo
|
|
|
|
|
|
|
|
3. Criar rota par garantir que o usuário seja redirecionado para a página correspondente.
|
|
|
|
|
|
|
|
</details>
|
|
|
|
|
|
|
|
<details open>
|
|
|
|
<summary>US01 T3 - Criar botão de cadastro produto final</summary>
|
|
|
|
<br>
|
|
|
|
|
|
|
|
**Critérios de aceitação:**
|
|
|
|
|
|
|
|
1. Seguir design estabelecido no Figma
|
|
|
|
|
|
|
|
2. Ser responsivo
|
|
|
|
|
|
|
|
3. Criar rota par garantir que o usuário seja redirecionado para a página correspondente.
|
|
|
|
|
|
|
|
</details>
|
|
|
|
|
|
|
|
|
|
|
|
US01 T4 - Card de ordens com estado de em andamento (componente)
|
|
|
|
|
|
|
|
US01 T5 - Card de operações com estado finalizado (componente)
|
|
|
|
|
|
|
|
US01 T6 - Card para acessar estoque de matéria prima (componente)
|
|
|
|
|
|
|
|
US01 T7 - Card para acessar estoque de produtos finais (componente)
|
|
|
|
|
|
|
|
US01 T8 - Header com logo da Hortti (componente)
|
|
|
|
|
|
|
|
US01 T9 - Endpoint para criação de ordem
|
|
|
|
|
|
|
|
|
|
|
|
## Squads
|
|
|
|
|
|
|
|
### Sprint 1
|
|
|
|
|
|
|
|
<table>
|
|
|
|
<tr>
|
|
|
|
<td><img src="resources/images/warriors.png" width="150"></td>
|
|
|
|
<td>
|
|
|
|
<strong>Warriors</strong><br>
|
|
|
|
- Caio Araújo Batista<br>
|
|
|
|
- Isadora Santos da Silva<br>
|
|
|
|
- Gabriel Cristiano Ramos Barcelos<br>
|
|
|
|
- Stefan Augusto Reiznautt Chagas
|
|
|
|
</td>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><img src="resources/images/lakers.png" width="150"></td>
|
|
|
|
<td>
|
|
|
|
<strong>Lakers</strong><br>
|
|
|
|
- Thiago de Souza Cardoso<br>
|
|
|
|
- Victor Hugo Boeira Leitte<br>
|
|
|
|
- Eduardo Rosa Rodrigues<br>
|
|
|
|
- Gustavo Dos Santos Pias
|
|
|
|
</td>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><img src="resources/images/celtics.png" width="150"></td>
|
|
|
|
<td>
|
|
|
|
<strong>Celtics</strong><br>
|
|
|
|
- Emanuel Costa Pereira<br>
|
|
|
|
- Gustavo Caldeira de Mesquita<br>
|
|
|
|
- Arthur Humberto Silva Plentz<br>
|
|
|
|
- Guilherme Dentzien Silva
|
|
|
|
</td>
|
|
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td><img src="resources/images/globe trotters.jpeg" width="150"></td>
|
|
|
|
<td>
|
|
|
|
<strong>GlobeTrotters</strong><br>
|
|
|
|
- Marcus Filipe Carvalho Patricio Quirino<br>
|
|
|
|
- Pedro Petrini Castello
|
|
|
|
</td>
|
|
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Sprint 2
|
|
|
|
|
|
|
|
**Squad A**
|
|
|
|
|
|
|
|
**Squad B**
|
|
|
|
|
|
|
|
### Sprint 3
|
|
|
|
|
|
|
|
**Squad A**
|
|
|
|
|
|
|
|
**Squad B**
|
|
|
|
|
|
|
|
### Sprint 4
|
|
|
|
|
|
|
|
**Squad A**
|
|
|
|
|
|
|
|
**Squad B**
|
|
|
|
|
|
|
|
|
|
|
|
## Matriz de responsabilidades
|
|
|
|
|
|
|
|
**Legenda**<br>
|
|
|
|
P: Participa da atividade<br>
|
|
|
|
R: Responsável pela atividade<br>
|
|
|
|
C: Deve ser consultado<br>
|
|
|
|
I: Deve ser informado<br>
|
|
|
|
A: Aprova<br>
|
|
|
|
|
|
|
|
**Sprint 0**
|
|
|
|
|
|
|
|
| Atividade | AGES I | AGES II | AGES III | AGES IV |
|
|
|
|
| --------- | ------ | ------- | -------- | ------- |
|
|
|
|
| Alimentar a wiki | R | R | R | R |
|
|
|
|
| Definir ferramenta de mockups | C | R | A | A |
|
|
|
|
| Desenvolver mockups | C | R/A | C | A |
|
|
|
|
| Definir arquitetura | I | I | R/A | C/A |
|
|
|
|
| Definir tecnologias (front/back) | C | C | R/A | A |
|
|
|
|
| Criar projeto inicial (front/back) | I | I | R/A | A |
|
|
|
|
| Definir estratégia de Verificação e Validação | I | C | R/A | C/A |
|
|
|
|
| Documentar projeto/arquitetura inicial | I | I | R/A | A |
|
|
|
|
| Criar User Stories | C | C | C | R/A |
|
|
|
|
| Realizar estudos dirigidos | R | R | R | R |
|
|
|
|
| Definir plano de comunicações | I | I | I | R/A |
|
|
|
|
| Definir organização do time | I | I | C | R/A |
|
|
|
|
| Documentação de requisitos | R/A | C | C | A |
|
|
|
|
| Definir o git workflow | C | C | R | A |
|
|
|
|
| Modelar o BD (conceitual/lógico) | I | R/A | R/A | A |
|
|
|
|
| Apresentar | C | C | C | R |
|
|
|
|
|
|
|
|
**Sprint 1,2,3,4**
|
|
|
|
|
|
|
|
| Atividade | AGES I | AGES II | AGES III | AGES IV |
|
|
|
|
| --------- | ------ | ------- | -------- | ------- |
|
|
|
|
| Alimentar a wiki | R | R | R | R |
|
|
|
|
| Definir squads | C | R | A | A |
|
|
|
|
| Definir marcos da sprint | I | I | C | R/A |
|
|
|
|
| Quebra de tasks | C | C | R | R/A |
|
|
|
|
| Documentar projeto/arquitetura inicial | I | I | R/A | A |
|
|
|
|
| Desenvolvimento | R | R | R/A | C/A |
|
|
|
|
| Code review| C | C | R/A | C |
|
|
|
|
| Deploy da aplicação | I | I | R | A |
|
|
|
|
| Definir organização do time | I | I | C | R/A |
|
|
|
|
| Documentação de requisitos | R/A | C | C | A |
|
|
|
|
| Definir o git workflow | C | C | R | A |
|
|
|
|
| Apresentação da review | C | C | C | R |
|
|
|
|
|
|
|
|
**Apresentações ao Stakeholder**
|
|
|
|
|
|
|
|
|Sprint | Pessoa (R)|
|
|
|
|
| --------- | ------ |
|
|
|
|
| 0 | Ages IV |
|
|
|
|
| 1 | Ages IV e Ages III |
|
|
|
|
| 2 | Ages IV e Ages III |
|
|
|
|
| 3 | Ages IV e Ages III |
|
|
|
|
| 4 | Ages IV e Ages III |
|
|
|
|
|
|
|
|
## Plano de Comunicação
|
|
|
|
|
|
|
|
| **Evento** | **Descrição** | **Responsável** | **Envolvidos** | **Frequência** |
|
|
|
|
|:----------:|---------------|:---------------:|:--------------:|:--------------:|
|
|
|
|
| Kickoff | Primeiro encontro do time com o cliente, neste momento é apresentado o conceito do projeto,os objetivos e expectativas. enquanto isso, o time faz anotações sobre os requisitos do projeto | Clientes | Clientes e Ages I, II, III, IV | Uma vez |
|
|
|
|
| Daily | Momento em que todos do time comentam sobre o andamento de suas respectivas tarefas. Seguindo o conceito de: o que fiz, o que vou fazer e se tenho algum impedimento ou não | Ages IV | Ages I,II,III e IV | Duas vezes por semana (terça-feira no canal do Discord e sexta durante a aula |
|
|
|
|
| Sprint Review | Momento onde é demonstrado tudo o que foi feito durante a sprint. Comentando pontos importantes para a preparação da próxima sprint | Ages IV | Ages I,II,III e IV | No final de cada sprint |
|
|
|
|
| Sprint Retrospective | Nesta reunião, o time avalia o desempenho e a entrega durante a sprint. Discutindo sobre o que foi bom, no que podemos melhorar e citar possíveis planos de ação para implementar as melhorias mencionadas | Ages IV | Ages I,II,III e IV | No final da sprint |
|
|
|
|
| Sprint Planning | Esta é a reunião em que o time planeja tudo o que deve ser feito durante a sprint. Movendo as stories que estão no product backlog para sprint backlog e também esta reunião serve para reorganizar as squads | Ages IV | Ages I,II,III e IV | No início de cada sprint |
|
|
|
|
|
|
|
|
|
|
|
|
## Plano de Riscos
|
|
|
|
|
|
|
|
| **Possíveis Imprevistos** | **Risco** | **Impacto** | **Ações Preventivas** | **Contigência** | **Estratégia** |
|
|
|
|
|:---------:|:-----------------:|:-----------:|:--------------:|:--------------:|-----------|
|
|
|
|
| Alterações no escopo no início do projeto | Risco Baixo | Impacto Médio | Não sugerir features além das mencionadas pelo cliente e considerar escopo inicial | Avaliar as mudanças sugeridas e priorizar as pequenas mudanças que não exijam um grande retrabalho do time | Mitigar |
|
|
|
|
| Alterações no escopo no meio do projeto | Risco Baixo | Alto Impacto | Não sugerir features além das mencionadas pelo cliente e considerar escopo inicial | Não haverá alterações devido ao tempo e quantidade de retrabalho exigido | Negar |
|
|
|
|
| Feriados e eventos da faculdade | Risco Alto | Alto Impacto | Mencionar para o time e incluir avisos nos canais de comunicação | Manter reuniões daily normalmente, comunicação ativa com os membros do time e acompanhar o desenvolvimento | Mitigar |
|
|
|
|
| Falta de engajamento do time | Risco Médio | Alto Impacto | Estar em constante comunicação com a equipe e caso necessário realizar reuniões 1:1 com os membros da equipe para ouvi-los e reorganizar tarefas | Reorganizar tarefas/squads se necessário, manter e conversas direcionadas quando isso acontecer. Reforçando a importância dos prazos e responsabilidades | Mitigar |
|
|
|
|
| Falta de disponibilidade para realizar as atividades | Risco Médio | Impacto Médio | Comunicar ao time o mais breve possível | Pedir mais comprometimento em relação às faltas | Mitigar |
|
|
|
|
| Dificuldade com alguma tecnologia específica | Risco Médio | Baixo Impacto | Revisar material disponibilizado no Discord através do canal links-úteis para aprendizado | Realizar treinamento remoto/presencial da tecnologia se necessário para melhor entendimento | Mitigar |
|
|
|
|
| Semana de provas das outras disciplinas | Risco Médio | Alto Impacto | Comunicar com antecedência a necessidade de focar nas atividades de outras disciplinas para que o time possa se organizar de acordo | Não há contingência sobre semana de provas | Aceitar |
|
|
|
|
| Não entrega das user stories planejadas | Risco Alto | Alto Impacto | Acompanhar o desenvolvimento do time e caso um possível atraso seja identificado, auxiliar no que for necessário | Definir tempo de integração de tarefas(Code Freeze); E deixar como débito técnico para próxima sprint | Mitigar |
|
|
|
|
| Entrega das user stories antes do fim da sprint | Risco Médio | Alto Impacto | Analisar cronograma e capacidade para incluir mais USs na sprint | Se for possível a inclusão de mais USs delegar as tarefas de acordo com a disponibilidade de cada squad | Melhorar |
|
|
|
|
| Falta da presença dos stakeholders na apresentação | Risco Baixo | Impacto Médio | Mandar lembrete na semana anterior e com 8hrs ou 6 hrs de antecedência para confirmar ou não a presença do mesmo | Lidar os requisitos fornecidos e continuar a implementar o combinado | Transferir |
|
|
|
|
| Cliente não retorna as dúvidas relacionadas ao sistema | Risco Médio | Alto Impacto | Cobrar resposta do cliente caso não se tenha resposta em até 4 dias úteis | Deixar funcionalidade como débito e implementar as funcionalidades/stories com requisitos claros | Aceitar |
|
|
|
|
| Falta de comunição entre os squads| Risco Médio | Alto Impacto | Monitorar os canais do discord e o que é comentado na daily | Reunir com os ages 3, (líderes dos squads) para incentivar e realçar a importância de o time estar alinhado | Mitigar |
|
|
|
|
|
|
|
|
---
|
|
|
|
[**Topo**](#gerenciamento-do-projeto) |
|
|
\ No newline at end of file |
