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