diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/workflows/PULL_REQUEST_TEMPLATE.md
similarity index 100%
rename from .github/PULL_REQUEST_TEMPLATE.md
rename to .github/workflows/PULL_REQUEST_TEMPLATE.md
diff --git a/docs/faccao/faccao.md b/docs/faccao/faccao.md
index 84b1938..4b6791b 100644
--- a/docs/faccao/faccao.md
+++ b/docs/faccao/faccao.md
@@ -2,6 +2,7 @@
# GoHorse Starbone Legion
+
# GoHorse Starbone Legion
@@ -15,12 +16,5 @@
![](../img/historia_img/dom.png)
![](../img/historia_img/alicate.png)
![](../img/historia_img/soldador.png)
-
-
-
-
-
-
-
-
+
\ No newline at end of file
diff --git a/docs/missoes/missao1/licoes-aprendidas.md b/docs/missoes/missao1/licoes-aprendidas.md
new file mode 100644
index 0000000..8504d0f
--- /dev/null
+++ b/docs/missoes/missao1/licoes-aprendidas.md
@@ -0,0 +1 @@
+# tmj
\ No newline at end of file
diff --git a/docs/processo-desenvolvimento.md b/docs/processo-desenvolvimento.md
deleted file mode 100644
index 915fbbe..0000000
--- a/docs/processo-desenvolvimento.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# Visão Geral do Produto
-
-## 1.1 - Problema
-
- Com base na experiência de um Corretor de Seguros, um dos principais problemas enfrentados hoje é a própria gestão da sua empresa. Mesmo com o uso de serviços pagos de gestão, ainda fica aparente a falta de uma plataforma que seja focada no usuário e que tenha alguns serviços que hoje é feito em planilhas, muito propenso a erros humanos, e buscando uma forma de reduzir esses erros e também automatizar tarefas que hoje consome bastante tempo, entendemos que um Software que faça esses serviços é bastante desejado nesse nicho de negócio. Podendo ser cada vez mais abrangente e futuramente ser uma plataforma completa de gestão de Corretoras, Seguradoras, e empresas de todos os nichos e com os mesmos problemas que encontramos agora.
-
-## 1.2 - Declaração de Posição do Produto
-
-|||
-|------|-----------------------------------|
-| Para | Gestores de corretoras de seguros |
-| Quem | Necessita de um sistema centralizado para gerir a corretora |
-| O Nimbus | É uma aplicação web |
-| Que | Auxilia na gestão da corretora e na interação desta com os clientes |
-| Ao contrário | Agendor |
-| Nosso produto | Além de fornecer ferramentas que promovem a relação cliente-corretora, provê funcionalidades que auxiliam na gestão da corretora como um todo, como o controle das comissões e proteção de documentos de clientes |
-
-## 1.3 - Objetivos do Produto
-
-#### Objetivos Principais:
-
-1. Prover uma forma simplificada de calcular a comissão de cada venda para os corretores
-2. Prover uma forma de guardar os dados de documentos sensíveis dos clientes;
-
-#### Objetivos Secundários
-
-1. Fomentar a interação da corretora com seus clientes e angariar dados deles para a tomada de decisões da corretora.
-
-## 1.4 - Abordagem de Desenvolvimento do Software
-
-De base com a abordagem do framework Sommerville, optamos responder as perguntas classificadas em 3 temas.
-
-Questões Técnicas conectadas ao sistema que será desenvolvido.
-Questões humanas conectadas à equipe que cuidará do desenvolvimento
-Questões de organização conectadas às condições do ambiente que será desenvolvido a aplicação.
-
-### Questões técnicas:
-
-**Qual o tamanho do software que será desenvolvido?**
-
- - Um sistema de pequeno porte.
-
-**Qual modelo de software será desenvolvido?**
-
-- Uma aplicação web, de média complexidade e com requisitos pouco conhecidos.
-
-**Qual a vida útil prevista para o software?**
-
-- Por hora, vida útil, médio a longo período
-
-**O sistema está sujeito a controle externo?**
-
-- Sim, sujeito ao controle dos corretores e o acompanhamento dos clientes dos seguros
-
-### Questões Humanas:
-
-**Qual o nível técnico da equipe responsável pelo desenvolvimento?**
-
-- A equipe possui conhecimentos em desenvolvimento web front-end, desenvolvimento de APIs e gerenciamento e modelagem de bancos de dados.
-
-**Como está organizado o time de desenvolvimento?**
-
-- A equipe foi dividida em front-end e back-end.
-
-**Quais são as tecnologias disponíveis para apoiar o desenvolvimento do sistema?**
-
-- Frameworks de desenvolvimento front-end (no caso, React) e back-end (Java, com o framework Spring).
-
-### Questões organizacionais:
-
-**É importante ter uma especificação e um projeto (design) bem detalhados antes de passar para a implementação — talvez por motivos contratuais?**
-
-- Não, algumas partes da aplicação podem ser concluídas sem especificações de design.
-
-**É realista uma estratégia de entrega incremental, na qual o software é entregue aos clientes ou outros stakeholders e um rápido feedback é obtido?**
-
-- Sim. Este método permite resolver problemas locais que podem afetar todo o produto antes da implementação completa do projeto.
-
-**Os representantes do cliente estarão disponíveis e dispostos a participar do time de desenvolvimento?**
-
-- Não, os representantes, estarão apenas disponíveis para dar feedbacks, durante o processo, mas não participando do desenvolvimento em si.
-
-**Existem questões culturais que possam afetar o desenvolvimento do sistema?**
-
-- Não, como o time está iniciando, não está vinculada a uma metodologia específica de desenvolvimento.
diff --git a/docs/visao-geral/processo-desenvolvimento.md b/docs/visao-geral/processo-desenvolvimento.md
new file mode 100644
index 0000000..3454ddf
--- /dev/null
+++ b/docs/visao-geral/processo-desenvolvimento.md
@@ -0,0 +1,89 @@
+## Abordagem de Desenvolvimento: Ágil
+
+Com base na série de questionamentos propostos por Sommerville (2019), a escolha da abordagem ágil é fundamentada nas características iniciais do projeto. Conforme vistas abaixo:
+
+- Requisitos não definidos na sua totalidade.
+- Prazo de entrega já definido.
+- Falta de verba inicial.
+- Entrega incremental de funcionalidades em prazos mais curtos.
+
+## Ciclo de vida: Iterativo e Incremental
+
+Como os requisitos são incertos, provavelmente teremos que voltar em alguns durante o projeto, para assegurar a confiança e segurança para o cliente final. Ademais, não são conhecidas todas as exigências do cliente, portanto é importante a proximidade para consultas e mudanças mais rápidas. A escolha de um ciclo de vida iterativo e incremental proporciona uma maior flexibilidade no desenvolvimento baseado no surgimento ou alteração de requisitos, além do envolvimento com o cliente buscando feedback contínuo.
+
+## Processo: XP
+
+A metodologia ágil XP (Extreme Programming), é uma metodologia de desenvolvimento de software que se concentra na criação de software de alta qualidade, de maneira rápida e eficaz. Valoriza a simplicidade no design e na implementação, priorizando soluções simples e diretas. O XP é uma solução para projetos de software que tem requisitos voláteis, por conta de sua abordagem flexível, que permite a adaptação do desenvolvimento às mudanças. Dentre os valores centrais do Extreme Programming, os principais fatores que guiaram a escolha da metodologia foram:
+
+- Alta adaptabilidade à mudanças nos requisitos.
+- Utilização do Desenvolvimento Orientado a Testes (TDD).
+- Refatoração de código, facilitando a manutenção e melhorando a clareza.
+- Entrega de pequenas versões do sistema ao decorrer das interações.
+
+| Atividade | Método | Ferramenta | Entrega |
+|----------------------------------|-------------------------|----------------|-----------------------------------------------|
+| Planejamento da Release | Padronização do código | Discord | Documento que define o que será entregue em cada Release |
+| Desenvolvimento de software | Em pares | Editor de Texto| Código com a resolução do problema |
+| Testes de Software | TDD | Editor de Texto| Testes unitários e de integração |
+| Elicitação e Descoberta | Entrevistas com o cliente: Brainstorm | Gather Town | Definição de RFs e RNFs iniciais |
+| Análise de Requisitos |R eunião com cliente |Miro |R efinamento dos RFs e RNFs |
+
+
+
+## 1.4 - Abordagem de Desenvolvimento do Software
+
+De base com a abordagem do framework Sommerville, optamos responder as perguntas classificadas em 3 temas.
+
+Questões Técnicas conectadas ao sistema que será desenvolvido.
+Questões humanas conectadas à equipe que cuidará do desenvolvimento
+Questões de organização conectadas às condições do ambiente que será desenvolvido a aplicação.
+
+### Questões técnicas:
+
+**Qual o tamanho do software que será desenvolvido?**
+
+ - Um sistema de pequeno porte.
+
+**Qual modelo de software será desenvolvido?**
+
+- Uma aplicação web, de média complexidade e com requisitos pouco conhecidos.
+
+**Qual a vida útil prevista para o software?**
+
+- Por hora, vida útil, médio a longo período
+
+**O sistema está sujeito a controle externo?**
+
+- Sim, sujeito ao controle dos corretores e o acompanhamento dos clientes dos seguros
+
+### Questões Humanas:
+
+**Qual o nível técnico da equipe responsável pelo desenvolvimento?**
+
+- A equipe possui conhecimentos em desenvolvimento web front-end, desenvolvimento de APIs e gerenciamento e modelagem de bancos de dados.
+
+**Como está organizado o time de desenvolvimento?**
+
+- A equipe foi dividida em front-end e back-end.
+
+**Quais são as tecnologias disponíveis para apoiar o desenvolvimento do sistema?**
+
+- Frameworks de desenvolvimento front-end (no caso, React) e back-end (Java, com o framework Spring).
+
+### Questões organizacionais:
+
+**É importante ter uma especificação e um projeto (design) bem detalhados antes de passar para a implementação — talvez por motivos contratuais?**
+
+- Não, algumas partes da aplicação podem ser concluídas sem especificações de design.
+
+**É realista uma estratégia de entrega incremental, na qual o software é entregue aos clientes ou outros stakeholders e um rápido feedback é obtido?**
+
+- Sim. Este método permite resolver problemas locais que podem afetar todo o produto antes da implementação completa do projeto.
+
+**Os representantes do cliente estarão disponíveis e dispostos a participar do time de desenvolvimento?**
+
+- Não, os representantes, estarão apenas disponíveis para dar feedbacks, durante o processo, mas não participando do desenvolvimento em si.
+
+**Existem questões culturais que possam afetar o desenvolvimento do sistema?**
+
+- Não, como o time está iniciando, não está vinculada a uma metodologia específica de desenvolvimento.
diff --git a/docs/visao-geral/visao-produto.md b/docs/visao-geral/visao-produto.md
new file mode 100644
index 0000000..0ecf3ca
--- /dev/null
+++ b/docs/visao-geral/visao-produto.md
@@ -0,0 +1,28 @@
+# Visão Geral do Produto
+
+## 1.1 - Problema
+
+ Com base na experiência de um corretor de seguros, um dos principais problemas enfrentados hoje é a própria gestão da sua empresa. Mesmo com o uso de serviços pagos de gestão, ainda fica aparente a falta de uma plataforma que seja focada no usuário e que tenha alguns serviços que hoje são feitos em planilhas, muito propensos a erros humanos. Buscando uma forma de reduzir esses erros e também automatizar tarefas que hoje consomem muito tempo, entendemos que um software que faça esses serviços é bastante desejado nesse nicho de negócio, podendo ser cada vez mais abrangente e futuramente ser uma plataforma completa de gestão de corretoras, seguradoras, e empresas de todos os nichos e com os mesmos problemas que encontramos agora.
+
+## 1.2 - Declaração de Posição do Produto
+
+|||
+|------|-----------------------------------|
+| Para | Gestores de corretoras de seguros |
+| Quem | Necessita de um sistema centralizado para gerir a corretora |
+| O Nimbus | É uma aplicação web |
+| Que | Auxilia na gestão da corretora e na interação desta com os clientes |
+| Ao contrário | Agendor |
+| Nosso produto | Além de fornecer ferramentas que promovem a relação cliente-corretora, provê funcionalidades que auxiliam na gestão da corretora como um todo, como o controle das comissões e proteção de documentos de clientes |
+
+## 1.3 - Objetivos do Produto
+
+#### Objetivos Principais:
+
+1. Prover uma forma simplificada de calcular a comissão de cada venda para os corretores
+2. Prover uma forma de guardar os dados de documentos sensíveis dos clientes;
+
+#### Objetivos Secundários
+
+1. Fomentar a interação da corretora com seus clientes e angariar dados deles para a tomada de decisões da corretora.
+
diff --git a/docs/visao-projeto.md b/docs/visao-geral/visao-projeto.md
similarity index 100%
rename from docs/visao-projeto.md
rename to docs/visao-geral/visao-projeto.md
diff --git a/docs/visao-produto.md b/docs/visao-produto.md
deleted file mode 100644
index 915fbbe..0000000
--- a/docs/visao-produto.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# Visão Geral do Produto
-
-## 1.1 - Problema
-
- Com base na experiência de um Corretor de Seguros, um dos principais problemas enfrentados hoje é a própria gestão da sua empresa. Mesmo com o uso de serviços pagos de gestão, ainda fica aparente a falta de uma plataforma que seja focada no usuário e que tenha alguns serviços que hoje é feito em planilhas, muito propenso a erros humanos, e buscando uma forma de reduzir esses erros e também automatizar tarefas que hoje consome bastante tempo, entendemos que um Software que faça esses serviços é bastante desejado nesse nicho de negócio. Podendo ser cada vez mais abrangente e futuramente ser uma plataforma completa de gestão de Corretoras, Seguradoras, e empresas de todos os nichos e com os mesmos problemas que encontramos agora.
-
-## 1.2 - Declaração de Posição do Produto
-
-|||
-|------|-----------------------------------|
-| Para | Gestores de corretoras de seguros |
-| Quem | Necessita de um sistema centralizado para gerir a corretora |
-| O Nimbus | É uma aplicação web |
-| Que | Auxilia na gestão da corretora e na interação desta com os clientes |
-| Ao contrário | Agendor |
-| Nosso produto | Além de fornecer ferramentas que promovem a relação cliente-corretora, provê funcionalidades que auxiliam na gestão da corretora como um todo, como o controle das comissões e proteção de documentos de clientes |
-
-## 1.3 - Objetivos do Produto
-
-#### Objetivos Principais:
-
-1. Prover uma forma simplificada de calcular a comissão de cada venda para os corretores
-2. Prover uma forma de guardar os dados de documentos sensíveis dos clientes;
-
-#### Objetivos Secundários
-
-1. Fomentar a interação da corretora com seus clientes e angariar dados deles para a tomada de decisões da corretora.
-
-## 1.4 - Abordagem de Desenvolvimento do Software
-
-De base com a abordagem do framework Sommerville, optamos responder as perguntas classificadas em 3 temas.
-
-Questões Técnicas conectadas ao sistema que será desenvolvido.
-Questões humanas conectadas à equipe que cuidará do desenvolvimento
-Questões de organização conectadas às condições do ambiente que será desenvolvido a aplicação.
-
-### Questões técnicas:
-
-**Qual o tamanho do software que será desenvolvido?**
-
- - Um sistema de pequeno porte.
-
-**Qual modelo de software será desenvolvido?**
-
-- Uma aplicação web, de média complexidade e com requisitos pouco conhecidos.
-
-**Qual a vida útil prevista para o software?**
-
-- Por hora, vida útil, médio a longo período
-
-**O sistema está sujeito a controle externo?**
-
-- Sim, sujeito ao controle dos corretores e o acompanhamento dos clientes dos seguros
-
-### Questões Humanas:
-
-**Qual o nível técnico da equipe responsável pelo desenvolvimento?**
-
-- A equipe possui conhecimentos em desenvolvimento web front-end, desenvolvimento de APIs e gerenciamento e modelagem de bancos de dados.
-
-**Como está organizado o time de desenvolvimento?**
-
-- A equipe foi dividida em front-end e back-end.
-
-**Quais são as tecnologias disponíveis para apoiar o desenvolvimento do sistema?**
-
-- Frameworks de desenvolvimento front-end (no caso, React) e back-end (Java, com o framework Spring).
-
-### Questões organizacionais:
-
-**É importante ter uma especificação e um projeto (design) bem detalhados antes de passar para a implementação — talvez por motivos contratuais?**
-
-- Não, algumas partes da aplicação podem ser concluídas sem especificações de design.
-
-**É realista uma estratégia de entrega incremental, na qual o software é entregue aos clientes ou outros stakeholders e um rápido feedback é obtido?**
-
-- Sim. Este método permite resolver problemas locais que podem afetar todo o produto antes da implementação completa do projeto.
-
-**Os representantes do cliente estarão disponíveis e dispostos a participar do time de desenvolvimento?**
-
-- Não, os representantes, estarão apenas disponíveis para dar feedbacks, durante o processo, mas não participando do desenvolvimento em si.
-
-**Existem questões culturais que possam afetar o desenvolvimento do sistema?**
-
-- Não, como o time está iniciando, não está vinculada a uma metodologia específica de desenvolvimento.
diff --git a/mkdocs.yml b/mkdocs.yml
index 0dda4d5..1ffeb7a 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -5,19 +5,14 @@ repo_name: 2024.1-Nimbus
nav:
- Home: index.md
- História: faccao/faccao.md
- - Visão Geral do Produto: visao-produto.md
- - Visão Geral do Projeto: visao-projeto.md
- - Processo de Desenvolvimento de Software: processo-desenvolvimento.md
- - Lições aprendidas: licoes-aprendidas.md
+ - Visão Geral do Produto e Projeto:
+ - Visão Geral do Produto: visao-geral/visao-produto.md
+ - Visão Geral do Projeto: visao-geral/visao-projeto.md
+ - Processo de Desenvolvimento: visao-geral/processo-desenvolvimento.md
- Missão 1:
- Questionário: missoes/missao1/questionario.md
- - Missão 2: missao2.md
- - Missão 3: missao3.md
- - Missão 4: missao4.md
- - Backlog do Produto: missao2.md
- - Sprints:
- - Sprint 0: sprints/sprint-0.md
- - Sprint 1: sprints/sprint-1.md
+ - Lições aprendidas: missoes/missao1/licoes-aprendidas.md
+
theme:
name: material
icon:
@@ -31,6 +26,8 @@ theme:
- navigation.tabs.sticky
- navigation.path
- navigation.prune
+ - navigation.top
+ - navigation.footer
- navigations.indexes
- content.code.copy
- toc.integrate