From dd93407b3fba5c1bfbce2fe7291363b2bbc372a1 Mon Sep 17 00:00:00 2001 From: AlexandreLJr Date: Mon, 11 Nov 2024 00:23:42 -0300 Subject: [PATCH] =?UTF-8?q?finalizando=20sess=C3=A3o?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/Unidades/Unidade1.md | 25 ++++++++++++ "docs/Vis\303\243oProduto/Cronograma.md" | 28 +++++++++++++ "docs/Vis\303\243oProduto/Estrategias.md" | 35 +++++++++++++++++ .../Intera\303\247\303\243o.md" | 39 +++++++++++++++++++ mkdocs.yml | 6 ++- 5 files changed, 132 insertions(+), 1 deletion(-) create mode 100644 docs/Unidades/Unidade1.md create mode 100644 "docs/Vis\303\243oProduto/Cronograma.md" create mode 100644 "docs/Vis\303\243oProduto/Estrategias.md" create mode 100644 "docs/Vis\303\243oProduto/Intera\303\247\303\243o.md" diff --git a/docs/Unidades/Unidade1.md b/docs/Unidades/Unidade1.md new file mode 100644 index 0000000..076f64a --- /dev/null +++ b/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. + + \ No newline at end of file diff --git "a/docs/Vis\303\243oProduto/Cronograma.md" "b/docs/Vis\303\243oProduto/Cronograma.md" new file mode 100644 index 0000000..2de510d --- /dev/null +++ "b/docs/Vis\303\243oProduto/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. + + diff --git "a/docs/Vis\303\243oProduto/Estrategias.md" "b/docs/Vis\303\243oProduto/Estrategias.md" new file mode 100644 index 0000000..5c90335 --- /dev/null +++ "b/docs/Vis\303\243oProduto/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. + diff --git "a/docs/Vis\303\243oProduto/Intera\303\247\303\243o.md" "b/docs/Vis\303\243oProduto/Intera\303\247\303\243o.md" new file mode 100644 index 0000000..6fd8cba --- /dev/null +++ "b/docs/Vis\303\243oProduto/Intera\303\247\303\243o.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. \ No newline at end of file diff --git a/mkdocs.yml b/mkdocs.yml index f664772..23e873e 100644 --- a/mkdocs.yml +++ b/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