Gerência.md

@@ -5,4 +5,149 @@
 
 Esta seção é dedicada a apresentar as responsabilidades de cada AGES, junto dela serão apresentados documentos referentes a maneira que o time se organizou e trabalha.
 
-## Cronograma
\ No newline at end of file
+## Cronograma
+
+| **Sprint** | **Data Início** | **Data Fim** |
+| ------ | ------ | ------ |
+| Sprint 0 (warm up) | 07/08/2024 | 26/08/2024 |
+| Sprint 1 | 28/08/2024 | 11/09/2024 |
+| Sprint 2 | 16/09/2024 | 30/09/2024 |
+| Sprint 3 | 02/10/2024 | 30/10/2024 |
+| Sprint 4 | 04/11/2024 | 18/11/2024 |
+
+# EAP
+
+
+
+# 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. 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. | Cliente | AGES I, II, III, IV e Cliente | Uma vez | 1 hora e 30 minutos |
+| Daily (aula meeting) | 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 removidos. | AGES IV | AGES I, II, III, IV | Segundas e Quartas, 17:30 | 20 minutos |
+| Sprint Review | Demonstra-se, revisa-se e discute-se aquilo que foi trabalhado durante a Sprint, fornecendo inputs importantes para a Sprint Planning. | AGES IV | AGES I, II, III, IV e Cliente | Ao final de cada sprint (A cada 2 ou 3 semanas) | 45 minutos |
+| Sprint Planning | Planeja-se o trabalho que será realizado durante a Sprint, priorizando-se itens do Product Backlog e movendo-os para o Sprint Backlog. | AGES IV | AGES I, II, III, IV e Cliente |Ao final de cada sprint (A cada 2 ou 3 semanas) | 45 minutos |
+| Retrospectiva da Sprint | A Retrospectiva da Sprint é uma oportunidade para o time se inspecionar e criar um plano de melhorias a serem implementadas durante a próxima Sprint. Durante o evento, a equipe discute o que correu bem na Sprint e o que pode ser melhorado na próxima Sprint. Embora melhorias possam ser implementadas a qualquer momento, a Retrospectiva da Sprint oferece uma oportunidade formal para focar na inspeção e adaptação. | AGES IV | AGES I, II, III, IV | Ao final de cada sprint (A cada 2 ou 3 semanas) | 1 hora e 40 minutos |
+| Divisão de tarefas | Momento em que é realizada a divisão das User stories entre as squads. | AGES IV | AGES I, II, III, IV | Aproximadamente a cada 2 ou 3 semanas (início da Sprint) | 20 minutos |
+| Squads Breakdown | Momento em que os Gerentes de Projeto se reunem para organizar o time dividindo-o em squads, considerando nessa divisão critérios que visem maximizar a produtividade e efetividade dos desenvolvedores para que assim atinjam o objetivo da entrega estipulada na Sprint. | AGES IV | AGES IV | Ao fim da sprint, podendo manter as squads atuais | 30 minutos |
+
+## Plano de Recursos Humanos
+
+**Função por níveis**
+
+| **Ages** |**Responsáveis** | **Objetivo** | **Função** | **Artefatos** |
+|---------------|---------------|---------------|---------------|---------------|
+| I | - Adrielle Dewes <br/> - Leonardo Simom <br/> - Lucca Muniz <br/> - Rafael Melo | - Programação<br/>- Testes<br/>- Depuração | - Desenvolver<br/>- código Auxiliar no desenvolvimento dos Mockups<br/>- Auxiliar na documentação da Wiki<br/>- Executar testes funcionais | - Codigo desenvolvido e salvo no GIT<br/>- Relatorio das Sprints<br/>- Relatorio de Andamento<br/>- Relatorio Final |
+| II | - Eduardo Tavares <br/> - Fernanda Farias <br/> - Gabriel Severo <br/> - Giselle Chaves <br/> - Mariah Freire <br/> - Murilo Machado <br/> - Ruan Necker <br/> - Vitor Jacom | - Analise de Requisitos<br/>- Projeto de Banco de Dados<br/>- Programação | - Apoio a AGES I<br/>- Desenvolver código<br/>- Refatorar código | - Fazer o levantamento dos Requisitos<br/>- Desenvolver e documentar o banco de dados (exemplo ER)<br/>- Toda a documentação técnica deve estar na Wiki | - Mockups dos frontend<br/>- Banco de dados (Colletions e ScriptSQL)<br/>Página na wiki de Documentação<br/>Relatorio das Sprints<br/>Relatório de andamento<br/>Relatório Final |
+| III | - Andressa Farkas <br/> - Bruno Brandão <br/> - Lucas Barros | - Testes e verificação<br/>- Projeto de software<br/>- Arquitetura de software |- Apoio a AGES I e II<br/> - Desenvolver o setup para o projeto<br/>- Toda a documentação técnica deve estar na wiki | - Segurança<br/>- Rotas de Backend (Arquitetura funcional)<br/>- Backend API<br/>- Arquitetura Não Funcional<br/>- Diagrama de Pacotes/Componentes (Arquitetura de Software)<br/>- Diagrama de Deploy<br/>- Documentação sobre aplicação de Design do Projeto<br/>- Analise dos principios SOLID<br/>- Code Review<br/>- Pagina na Wiki de Documentação<br/>- Relatorio das Sprints Andamento e Final |
+| IV | - Dylan Silveira <br/> - Leandro da Nóbrega <br/> - Nicolas Marques | - Gerenciamento de Projetos<br/>- Aprofundamento de outras competências desenvolvidas no curso<br/>- Portfolio de conclusão de curso<br/> | - Apoio a AGES I, II e III<br/>- Planejamento das Sprints<br/>- Criação das User Stories junto aos Stakeholders<br/>- Controle das tarefas do time (exemplo via trello)<br/>- Motivação do time<br/>- Controle do Processo da AGES<br/>- Desenvolvimento do Plano de Gestão do Projeto<br/>- Toda a documentação da gestão do projeto deve estar na Wiki | - Termo de abertura (Atualização)<br/>- Identificação dos Stakeholders<br/>- EAP<br/>- User Stories<br/>- Cronograma<br/>- Plano de Comunicação<br/>- Plano de Recursos Humanos<br/>- Identificação dos Riscos<br/>- Plano de Respostas a Riscos<br/>- Pagina da Wiki de Documentação<br/>- Relatórios das Sprints, andamento e Final |
+
+## Identificação dos Riscos
+
+| Probabilidade | Impacto |
+| ------ | ------ |
+| 0 até 10 da probabilidade de ocorrer algum risco | 0 até 10 onde mais próximo a 0 é menos prejudicial|
+
+| Risco | Tipo | Probabilidade | Impacto | Exposição |
+|-----------|--------|---------|----------|---------|
+| Falha na comunicação com as Stakeholders | Externo | 3 | 4 | 12 |
+| Falha na comunicação interna do time | Gerenciamento de Projeto | 4 | 5 | 20 |
+| Má divisão das tarefas | Gerenciamento de Projeto | 3 | 4 | 12 |
+| Problemas com as tecnologias/arquitetura | Técnico | 3 | 5 | 15 |
+| Problemas com a infraestrutura | Técnico | 3 | 5 | 15 |
+| Centralização de conhecimento | Gerenciamento de Projeto | 4 | 4 | 16 |
+| Redução do interesse do cliente | Gerenciamento de Projeto | 3 | 5 | 15 |
+| Desistência de integrantes do time | Gerenciamento de Projeto | 3 | 5 | 15 |
+
+
+## Plano de Respostas a Riscos
+
+
+| Risco | Estratégia | Ação | Responsáveis |
+|-----------|--------|---------|----------|
+| Comunicação com as Stakeholders (clientes) | Mitigar | Sugerir uma possível outra forma de contato que a cliente utilize com maior frequência, sempre enfatizando a importância da participação dela nas decisões e entregas do time. | Professor e Ages IV (Whats). |
+| Comunicação interna do time | Mitigar | Manter os canais de comunicação, tanto em aula quanto fora, em funcionamento. | Ages IV |
+| Divisão de tarefas do time | Mitigar | Plannings organizadas/objetivas e histórias de usuário bem descritas e inseridas na ferramenta Trello, também garantir que todos os membros do time tenham tarefas a serem realizadas. | Ages IV |
+| Tecnologias escolhidas | Mitigar |Garantir que as tecnologias escolhidas sejam suficientes para o desenvolvimento do projeto e que o time inteiro as utilize seguindo boas práticas de desenvolvimento. | Ages III |
+| Modelagem de BD escolhida | Mitigar | Garantir que a modelagem do Banco de Dados esteja sendo seguida no desenvolvimento | Ages II |
+| Infraestrutura escolhida | Mitigar | Avaliar caminhos possiveis a seguir | Ages III |
+| Centralização de conhecimento | Mitigar | Incentivar a troca de informações entre o time. | Ages IV |
+| Padrões de Projeto | Mitigar | Alinhamento e definição para melhor modelo a seguir | Ages III |
+
+
+## Matriz de Responsabilidade
+
+Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.
+
+<table>
+<tr>
+<th>Resumo das Siglas</th>
+</tr>
+<tr>
+<td>
+
+<div>
+
+<span dir="">P: Participa da atividade</span>
+
+</div></td>
+</tr>
+<tr>
+<td>
+
+<div>
+
+<span dir="">R: Responsável pela atividade</span>
+
+</div></td>
+</tr>
+<tr>
+<td>
+
+<div>
+
+<span dir="">C: Deve ser consultado</span>
+
+</div></td>
+</tr>
+<tr>
+<td>
+
+<div>
+
+<span dir="">I: Deve ser informado</span>
+
+</div></td>
+</tr>
+<tr>
+<td>
+
+<div>
+
+<span dir="">A: Aprova</span>
+
+</div></td>
+</tr>
+</table>
+
+| 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 |
+| Desenvolvimento back/front | R | R | R | R |
+| Realização de Testes unitários | R | R | I | I |
+| Apresentação do Projeto | C | C | C | R |
+