finalizando sessão

docs/Unidades/Unidade1.md

@@ -0,0 +1,25 @@
+# Lições Aprendidas na Unidade 1  
+
+## Lições aprendidas e dificuldades com ações para superá-las: 
+
+### 1. Encontrar um cliente 
+
+- Desafio: Achar um cliente real que se interessasse pelo projeto e estivesse disposto a colaborar ao longo do desenvolvimento. 
+- Ação de melhoria: Estabelecer uma rede de contatos e manter um contato constante até achar um interessado. 
+
+### 2. Convencer o cliente das Ideias da Equipe 
+
+- Desafio: Demonstrar como algumas ideias da equipe poderiam otimizar o sistema e beneficiar o negócio, especialmente quando ele já tinha uma ideia em mente, como a ideia de fazer um app e não um site 
+- Ação de melhoria: Explicar ponto a ponto para o cliente as vantagens da abordagem pensado pelo grupo, e falar de experiências passadas, para passar confiança 
+
+### 3. Organização dos requisitos 
+
+- Desafio: Estruturar os requisitos de forma clara e priorizá-los conforme a necessidade do cliente 
+- Ação de melhoria: Adotar uma ferramenta de gerenciamento de requisitos 
+
+### 4.Escolha do Processo de Engenharia de Software 
+
+- Desafio: Identificar o processo mais adequado, que equilibrasse flexibilidade e organização, dada a natureza do projeto e a disponibilidade do cliente para reuniões. 
+- Ação de melhoria: Avaliar previamente as necessidades e o perfil do cliente e do grupo para definir, de forma mais rápida e assertiva, o processo ideal para o projeto, usando das experiências anteriores dos membros da equipe.  
+
+

docs/VisãoProduto/Cronograma.md

@@ -0,0 +1,28 @@
+# Cronogramas e Entregas 
+
+| Sprint | Início             | Fim                 | Objetivos e Entregas Esperadas                                             |
+|--------|--------------------|---------------------|---------------------------------------------------------------------------|
+| 0      | 04/11/2024         | 10/11/2024          | Planejamento do projeto, definição do escopo, decisão dos cargos, organização da documentação. |
+| 1      | 11/11/2024         | 17/11/2024          | Entrega da Unidade 1, capacitações, definir o MVP, definir DoR e DoD.     |
+| 2      | 18/11/2024         | 24/11/2024          | Capacitações, protótipo no Figma.                                         |
+| 3      | 25/11/2024         | 01/12/2024          | Desenvolver o banco de dados, criar as funções de cadastro do dono do animal e do pet, testes das funções feitas na semana. |
+| 4      | 02/12/2024         | 08/12/2024          | Estilizar os cadastros, criar a função de agendamento de banho e tosa, testes das funções/estilizações feitas na semana. |
+| 5      | 09/12/2024         | 15/12/2024          | Estilizar o agendamento, criar a função de upload de fotos para o agendamento e o cadastro dos pets, testes das funções/estilizações feitas na semana. |
+| 6      | 16/12/2024         | 22/12/2024          | Entrega da Unidade 2, estilizar o upload de fotos, criar a função de consultar os agendamentos já feitos pelo usuário, testes das funções/estilizações feitas na semana. |
+| 7      | 23/12/2024         | 29/12/2024          | Estilizar a consulta, criar a função de dar feedback sobre o serviço prestado, testes das funções/estilizações feitas na semana. |
+| 8      | 30/12/2024         | 05/01/2025          | Estilizar o feedback, validação da página do usuário com nosso cliente, testes das funções/estilizações feitas na semana. |
+| 9      | 06/01/2025         | 12/01/2025          | Criar a página dos funcionários do petshop com acesso aos agendamentos e informações dos pets, testes das funções/estilizações feitas na semana. |
+| 10     | 13/01/2025         | 19/01/2025          | Fazer a hospedagem, criar a aba do dono do negócio com acesso aos agendamentos e informações sobre os pets, testes das funções/estilizações feitas na semana. |
+| 11     | 20/01/2025         | 26/01/2025          | Entrega da Unidade 3, estilizar o acesso aos feedbacks pelo dono, criar as funções de controle financeiro, testes das funções/estilizações feitas na semana. |
+| 12     | 27/01/2025         | 02/02/2025          | Estilizar o controle financeiro, criar a função de alterar os preços dos serviços oferecidos, criar a função de cancelar os agendamentos por parte do dono, validação com o cliente, testes das funções/estilizações feitas na semana. |
+| 13     | 03/02/2025         | 09/02/2025          | Fazer as mudanças pedidas pelo cliente, estilizar a alteração de preço e o cancelamento do agendamento, testes das funções/estilizações feitas na semana. |
+| 14     | 10/02/2025         | 12/02/2025          | Encerramento do projeto, entrega da Unidade 4.                            |
+
+
+## Considerações Importantes 
+
+- Datas de Início e Fim: Cada sprint tem a duração de uma semana, começando em 04/11/2024 e finalizando em 12/02/2025. 
+
+ - Entrega do produto final para o cliente na última sprint do projeto. 
+
+

docs/VisãoProduto/Estrategias.md

@@ -0,0 +1,35 @@
+# Estratégias de Engenharias de Software
+
+## Estratégia Priorizada 
+
+- Abordagem de Desenvolvimento de Software: Ágil com elementos dirigidos por plano 
+
+- Ciclo de vida: híbrido (iterativo e incremental) 
+
+- Processo de Engenharia de Software: OpenUP 
+
+## Quadro Comparativo 
+
+| Características                           | Unified Process (UP)                                           | Open Unified Process (OpenUP)                                    |
+|-------------------------------------------|---------------------------------------------------------------|------------------------------------------------------------------|
+| **Objetivo**                     | Fornecer uma metodologia robusta e escalável para desenvolvimento de software com etapas bem definidas e forte documentação.     | Oferecer uma versão simplificada e enxuta do UP, com foco em práticas ágeis e leveza no processo.  |
+| **Foco no Processo**                             | Processo estruturado, com foco em documentação e controle, adequado para projetos de médio a grande porte.  | Processo leve, com foco em colaboração e agilidade, adequado para projetos de pequeno a médio porte.     |
+| **Complexidade**                             | Mais complexo e detalhado, com quatro fases principais e várias disciplinas a serem seguidas em cada fase.                      | Menos complexo, com simplificação das disciplinas e fases, tornando o processo mais fácil de adaptar.   |
+| **Fases**                      | Iniciação, Elaboração, Construção, Transição - cada fase possui uma série de atividades, entregas e artefatos bem definidos.  | Também utiliza as fases de Iniciação, Elaboração, Construção, Transição, mas com uma abordagem mais flexível e menos prescritiva.    |
+| **Disciplinas (Áreas de Foco)**                          | Abrange diversas disciplinas, como Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Testes, e Gerenciamento de Projeto.           | Concentra-se nas disciplinas essenciais, como Requisitos, Implementação, Testes e Gerenciamento de Projeto, com menor ênfase em documentação extensa.  |
+| **Documentação**                             | Documentação rigorosa e detalhada em cada fase, com artefatos obrigatórios para cada etapa.                               | Documentação reduzida, com foco em artefatos essenciais e em manter a equipe mais produtiva com menos formalidades.  |
+| **Iteratividade**               | Iterativo e incremental, permitindo revisões contínuas em cada fase para reduzir riscos.   | Também iterativo e incremental, mas com ciclos de desenvolvimento mais curtos e mais simples, permitindo respostas rápidas a mudanças.             |
+| **Gestão de Riscos**                        | Enfatiza a análise e gestão de riscos na fase de Elaboração para mitigar problemas antes da fase de Construção.                    | Inclui gestão de riscos, mas de forma menos formal e integrada às práticas ágeis    |
+| **Adaptação e Flexibilidade**                        | É mais rígido e detalhado, o que pode dificultar a adaptação a mudanças frequentes no escopo.          | Mais flexível e ágil, com menos formalidade, facilitando a adaptação rápida a mudanças.    |
+| **Colaboração e Equipe**                        |Frequentemente exige uma estrutura de equipe mais formal com papéis específicos definidos, como Analista de Requisitos, Arquiteto e Testador.                   | Incentiva uma equipe colaborativa e multifuncional, onde papéis são menos rígidos e os membros podem assumir várias funções.    |
+| **Recomendações de uso**                        |Ideal para projetos de médio a grande porte, onde a previsibilidade e controle são prioritários. Útil em contextos que exigem alta conformidade com processos e documentação.                    | Mais adequado para projetos menores ou ambientes ágeis, onde a simplicidade, velocidade e resposta rápida às mudanças são essenciais.    |
+
+## Justificativa 
+Como o OpenUp é menos burocrático e requer menos documentação do que o UP, tornando o processo mais ágil, ele é mais adequado para equipes pequenas, com os requisitos mais simples, como este do Pet Shop Guará. 
+
+Este processo promove a colaboração constante e rápida adaptação a mudanças, alinhando-se com as necessidades de um projeto que pode sofrer alterações frequentes conforme o cliente aprende mais sobre o sistema e o produto vai ganhando forma. Para o dono do pet shop, que provavelmente pode mudar algumas ideias ao longo do desenvolvimento, OpenUP permite fazer ajustes sem impactar muito o cronograma ou sobrecarregar a equipe com replanejamentos formais. 
+
+Para um projeto menor, como este de um sistema de agendamento e controle de vendas, o OpenUP é mais escalável e não exige a estrutura robusta e formalizada do UP, que seria mais adequado para projetos complexos e de larga escala. O OpenUP permite que a equipe se concentre nas soluções práticas e relevantes ao projeto sem desviar esforços para atividades que não agreguem valor direto ao cliente. 
+
+O OpenUP reduz a carga de documentação e a complexidade do planejamento detalhado, o que também diminui o custo e o tempo de desenvolvimento — ambos essenciais para um projeto com orçamento e cronograma restritos. Com menos etapas obrigatórias e mais flexibilidade, a equipe pode acelerar o processo de desenvolvimento e entrega, atendendo ao cliente mais rapidamente. 
+

docs/VisãoProduto/Interação.md

@@ -0,0 +1,39 @@
+# Interação entre Equipe e Cliente 
+
+## Composição da Equipe 
+
+| Papel              | Descrição                                                  | Responsável         | Participantes          |
+|--------------------|------------------------------------------------------------|---------------------|------------------------|
+| Gerente de Projeto | Coordena o projeto, garante a comunicação entre cliente e equipe, controla prazos e entregas.   | Manoela           | -   |
+| Desenvolvedor FrontEnd     | Responsável pela interface do usuário, design e implementação das funcionalidades no lado do cliente.  | Alexandre     | Manoela     |
+| Desenvolvedor Backend            | Implementa a lógica de negócios, integração com banco de dados e APIs.         | Enrico     |Kaio e Pedro Henrique    |
+| Analista de Requisitos             | Define os requisitos funcionais e não funcionais do sistema e garante que eles sejam atendidos.       | Pedro Henrique          | Gustavo e Alexandre     |
+| Desenvolvedor CI/CD / Tester | Codificar testes unitários, criar integração e entrega contínua. Realizar testes funcionais, garantindo a qualidade do produto.         | Kaio     | Gustavo         |
+
+
+## Comunicação
+
+Ferramentas de Comunicação 
+
+- Whatsapp: será utilizado para a comunicação diária da equipe e, também, para as conversas rápidas com o cliente. 
+- Teams: será utilizado para as reuniões de começo/fim de sprint entre os membros da equipe e para as reuniões de validação com o cliente. 
+- Github kanban: será utilizado o kanban disponível no github project. 
+
+## Métodos e frequência de reuniões 
+
+- Reunião de Revisão de Sprint (a cada semana): toda segunda-feira, a equipe se reunirá e fará uma retrospectiva e uma revisão das funcionalidades trabalhadas na semana anterior, assim podendo ver como está o andamento da equipe e o que pode ser melhorado. 
+- Reunião de Planejamento de Sprint (a cada semana): logo após a discussão sobre a revisão da sprint passada, a equipe planejará a próxima, comparando com o cronograma planejado e redefinindo prioridades, se necessário. 
+- Reunião de Validação com o Cliente: a primeira acontecendo dois meses após o início do projeto, e a segunda após um mês da primeira, as reuniões de validação acontecerão para mostrarmos o progresso do projeto para o cliente e ele poder validar o que foi feito, podendo solicitar alterações, se necessário. 
+
+## Frequência de Interações com o Cliente 
+
+- Validação: dois meses após o início do projeto e um mês após isso acontecerão as validações com o cliente. Como ele não tem muita experiência com tecnologia, além do básico, foi optado por ele só validar o projeto quando um progresso significativo tiver sido feito, para ele enxergar com mais facilidade o caminho que foi feito. 
+- Interações adicionais pelo Whatsapp: quando necessárias interações rápidas e informais ao longo do desenvolvimento, ou quando houver dúvidas que possam ser respondidas facilmente, a comunicação ocorrerá via whatsapp, pela praticidade de ser usado no dia a dia. 
+
+## Processo de Validação 
+
+O processo de validação da solução será realizado em três etapas principais: 
+
+- Para iniciar o desenvolvimento de uma funcionalidade, o Definition of Ready (DoR) será utilizado, verificando se os requisitos estão claramente definidos, se há documentação e se todos os critérios de aceitação estão estabelecidos.  
+- O Definition of Done (DoD) será utilizado, onde a funcionalidade será considerada pronta apenas se passar pelos testes unitários, integração, e houver aprovação visual e funcional pelos membros da equipe. 
+- Após a validação interna da página dos donos de pets e, depois, das páginas dos funcionários e do dono do negócio, o produto será entregue ao cliente para testes de aceitação. Durante essa fase, o cliente irá verificar se o sistema atende aos requisitos estabelecidos. Cada funcionalidade será validada com base nos critérios de aceitação definidos durante o DoR. 

mkdocs.yml

@@ -13,5 +13,9 @@ nav:
     - Segmentação de clientes : CenarioAtual/Segmentação.md
   - Visão do Produto e Projeto: 
     - Solução Proposta : VisãoProduto/Solucao.md
-
+    - Estratégias de Engenharia de Software : VisãoProduto/Estrategias.md
+    - Cronogramas e Entregas : VisãoProduto/Cronograma.md
+    - Interação entre Equipe e Cliente : VisãoProduto/Interação.md
+  - Lições Aprendidas: 
+    - Unidade 1 : Unidades/Unidade1.md