Merge branch 'mainDoc' of https://github.com/mdsreq-fga-unb/2024.2-T0…

…3-CafeDoSitio into docs/ataCiclo5

.gitignore

@@ -1,4 +1,8 @@
 .venv
 
 /node_modules
-/site
+/site
+
+.turbo/
+apps/
+packages/

docs/sections/2-docPage/4-engenhariaRequisitos.md

@@ -74,7 +74,7 @@ Antes da validação com o cliente, a equipe realiza reuniões internas para rev
 
 ## 4.2 Engenharia de Requisitos e o Scrum/XP
 
-Baseando-se na estratégia de desenvolvimento de software selecionado, mencionado no tópico 3 e consultando os códigos das User Stories da seção [Visão do Backlog](../4-sprints/VisaoGeralBacklog.md), o cronograma preliminar do projeto pode ser visualizada logo abaixo:
+Baseando-se na estratégia de desenvolvimento de software selecionado, mencionado no tópico 3 e consultando os códigos das User Stories da seção [Backlog do Produto](./9-backlogDeProduto.md), o cronograma preliminar do projeto pode ser visualizada logo abaixo:
 
 Fases do Processo           | Atividades ER             | Prática                    | Técnica                                                        | Resultado Esperado
 --------------------------- | ------------------------- | -------------------------- | -------------------------------------------------------------- | ----------------------------

docs/sections/2-docPage/5-cronogramaEntregas.md

@@ -1,7 +1,7 @@
 # 5. Cronograma e Entregas
 
 
-Baseando-se na estratégia de desenvolvimento de software selecionado, mencionado no tópico 3 e consultando os códigos das User Stories da seção [Visão do Backlog](../4-sprints/VisaoGeralBacklog.md), o cronograma preliminar do projeto pode ser visualizada logo abaixo:
+Baseando-se na estratégia de desenvolvimento de software selecionado, mencionado no tópico 3 e consultando os códigos das User Stories da seção [Backlog de Produto](./9-backlogDeProduto.md), o cronograma preliminar do projeto pode ser visualizada logo abaixo:
 
 Sprint | Início | Fim | Objetivo do Ciclo | Entregas Previstas | Validação com os Stakeholders
 ----- | ------ | --- | ----------------- | ------------------ | -----------------------------

docs/sections/2-docPage/7-Requisitos.md

@@ -62,7 +62,6 @@ Os requisitos não funcionais foram organizados com base no modelo URPS+, que cl
 
 ### Confiabilidade
 
-
 **RNF11 -** O sistema deve estar disponível pelo menos 99,5% do tempo por mês (uptime). <br>
 **RNF12 -** Em caso de falhas no servidor, o sistema deve se recuperar dentro de 10 minutos.
 

docs/sections/2-docPage/8-DoR&DoD.md

@@ -0,0 +1,27 @@
+# 8. DoR e DoD
+
+## 8.1 Definiton of Ready (DoR)
+A Definition of Ready (DoR) é um conjunto de critérios que um item ou uma User Story do Backlog deve atender para ser considerando pronto para iniciar o trabalho desse item. Assim que um item do Backlog atende a esses critérios, ele é puxado para ser trabalhado durante a Sprint. Para que um item possa ser considerado 'Ready', ele precisa atender aos seguintes critérios:
+
+- **A História de Usuário foi construída no formato "Eu como [Ator], devo ser capaz de [o que fazer], para que [objetivo]"?**
+- **O requisito não possui ambiguidade?** Ou seja, se a história de usuário e o seu título não possui outras interpretações para o lado dos desenvolvedores e stakeholders.
+- **As stakeholders passaram os Critérios de Aceitação?** Ou seja, as ações e comportamentos que eles testarão e esperam que deverá ocorrer no software.
+- **As stakeholders passaram o protótipo esperado de como deve ser a interface?** As stakeholders, dentro da empresa, já possuem uma acessoria de imagem e uma designer que já fizeram reuniões e projetaram como deveriam ser as páginas. Além de que novas páginas precisam passar pela aprovação dessa mesma acessoria
+- **A Issue foi validada pela Coordenadora Ana Carol e, portanto, segue padrões de qualidade plausíveis e claros na documentação completa do requisito?**
+
+## 8.2 Definition of Done (DoD)
+Se a DoR é um conjunto de critérios para que um item seja considerado adequado para começar a se trabalhar nele, então a Definition of Done (DoD) é o conjunto de critérios que um item precisa ter para ser considerado como terminado. Sendo esse conjunto de critérios descritos abaixo:
+
+- **A interface está de acordo com o protótipo passado pelas stakeholders?** A interface deve estar de acordo com o que foi passado pela designer stakeholder
+- **Os critérios de aceitação com os stakeholders foram supridos?** O requisito deve conter todas as ações e comportamentos esperados pelas stakeholders, assim como foi definido anteriormente.
+- **O backend foi integrado ao frontend (Caso necessário)?** Backend e frontend devem ser integrados corretamete.
+- **Todo o código passou por revisão de pares para garantir qualidade e aderência aos padrões do projeto, isto é, 2 revisores aprovaram o código?** Pelo processo de desenvolvimento de software aderido, ScrumXP, a revisão é feita também em pares.
+- **O backend foi validado pelo coordenador Daniel Rodrigues e, portanto, segue níveis seguros na manipulação dos dados (Caso esta US exija backend)?**
+- **O código foi validado pelo Analista de Quality Assurance Joao Pedro e, portanto, possui cobertura de testes de no mínimo 80%?**
+- **A funcionalidade foi integrada ao branch principal sem conflitos?** A funcionalidade não pode conter conflitos ou interferir de alguma forma no funcionamento de outra funcionalidade ou do projeto como um todo.
+- **Está disponível em um ambiente de homologação ou produção, pronta para uso?** A cada entrega, o ambiente que contém as funcionalidades desenvolvidas deve estar disponível para que as stakeholdes possam ter acesso.
+
+## Histórico de Versão:
+| Data | Versão | Descrição | Autor | Revisores |
+|---- | ------ | --------- | ----- | --------- |
+| 12/12/24 | 1.0 | Criação do Documento | Arthur Suares | Daniel Rodrigues

docs/sections/2-docPage/9-backlogDeProduto.md

@@ -6,7 +6,29 @@ O backlog de produto é uma lista dinâmica e priorizada que contém todos os re
 
 Essa configuração da logística de escrita das histórias de usuários se justifica pelo fato do processo de engenharia selecionada pela equipe: ScrumXP, conforme descrito na seção de [Estratégias de Engenharia de Software](./3-estrategiasEngSoftware.md). Em resumo, os Requisitos Funcionais são detalhados com mais profundidade durante a fase de Sprint Planning, momento em que as histórias de usuário são escritas no formato _"Eu como (agente), gostaria de (ação), para que (agregação de valor)"_.
 
-### 9.1.1 - Relacionado aos Requisitos Funcionais:
+Dentro do backlog, um dos principais elementos são as User Stories (US), ou histórias de usuário. As histórias de usuário descrevem, em uma linguagem simples e direta, as necessidades do usuário final de forma que todos da equipe possam compreender o valor de cada funcionalidade. Elas são compostas por três elementos principais: quem é o usuário, o que ele deseja fazer e qual o benefício dessa ação. Esse formato ajuda a manter o foco nas necessidades dos usuários, incentivando a equipe a desenvolver soluções que realmente agreguem valor ao produto.
+
+As User Stories mais complexas ou que englobam várias funcionalidades estão agrupadas em Épicos. Um épico é uma descrição ampla de uma necessidade maior, que será posteriormente dividida em histórias menores e mais detalhadas. Esse processo de desmembramento ajuda a equipe a compreender o escopo do projeto e a definir prioridades para desenvolver partes do produto em blocos mais manejáveis. Épicos podem ser definidos com base nas principais funcionalidades ou objetivos do produto, e cada um pode se desdobrar em várias histórias de usuário que detalham as tarefas específicas.
+
+Por sua vez, os Temas funcionam como agrupamentos de histórias e épicos que compartilham um propósito ou um objetivo comum dentro do produto. Eles são úteis para organizar o backlog em seções que representem áreas ou funcionalidades do sistema, facilitando a priorização de desenvolvimento de acordo com as metas do projeto. Diferente dos épicos, que normalmente possuem um escopo mais restrito, os temas são mais amplos e podem abranger múltiplos épicos e histórias de usuário, fornecendo uma visão geral das grandes áreas do produto.
+
+### 9.1.1 - Temas:
+
+Código | Título                                     | Descrição
+------ | ------------------------------------------ | ----------
+TM01   | Experiência do Usuário com a Empresa       | Funcionalidades que permitem ao usuário interagir com a empresa. 
+TM02   | Gestão do Software                         | Funcionalidades voltadas para a administração do site institucional.
+
+### 9.1.2 - Épicos:
+
+Código | Tema Associado | Título                             | User Story
+------ | -------------- | ---------------------------------- | ---------------------------
+EP01   | T01            | Consultar Posts de Blog            | Eu como usuário, devo ser capaz de visualizar os blogs da Família do Sítio para me informar acerca de seus conteúdos.
+EP02   | T01            | Marcar Visitas Técnicas            | Eu como usuário, devo ser capaz de agendar uma visita técnica presencial para conhecer seus processos.
+EP03   | T02            | Administrar informações da Empresa | Eu como funcionário da Família do Sítio, devo ser capaz de gerenciar as informações do site institucional para que sempre se mantenha atualizado.
+EP04   | T02            | Atendimento | Eu como usuário, devo ser capaz de receber atendimento da Família do Sítio para stender à minha necessidade.
+
+### 9.1.3 - Relacionado aos Requisitos Funcionais:
 Código | User Story
 ------ | ----------------------------------------------------
 US01   | Eu como usuário devo ser capaz desenvolver um conteúdo, com permissão à formatação de texto avançados e inserição imagens para que seja publicado como blog no site da Família do Sítio.
@@ -29,7 +51,7 @@ US17   | **INCREMENTO (User Story não será escrito)**
 US18   | Eu como Funcionário da Família do Sítio, devo ser capaz de fazer login com meu email empresarial e senha, para que eu possa acessar as funções da Central de Administração.
 US19   | Eu como Funcionário da Família do Sítio, devo ser capaz de criar ou apagar o acesso de novas contas no sistema, para que eu possa controlar o acesso à central administrativa.
 
-### 9.1.1 - Relacionado aos Requisitos Não Funcionais (Somente de Usabibilidade):
+### 9.1.4 - Relacionado aos Requisitos Não Funcionais (Somente de Usabibilidade):
 Código | Título do Requisito de Usabilidade (Relacionada à implementação de uma interface)
 ------ | ----------------------------------------------------
 RQNF01 | O sistema deve permitir que os usuários localizem facilmente a seção que apresenta a história da empresa, com navegação intuitiva e conteúdo disposto de forma clara e acessível.
@@ -146,11 +168,18 @@ Com esta técnica, foi possível elencar as funcionalidades de maior valor agreg
 
 > RUBIN, Kenneth S. Scrum Essencial: Um Guia Prático para o Processo Ágil Mais Popular. São Paulo: Alta Books, 2014.
 
+> SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum: O Guia Definitivo para o Scrum, as Regras do Jogo. Scrum.org, 2020.
+
+> CAROLI, Paulo. Lean Inception: Como Alinhar Pessoas e Construir o Produto Certo. São Paulo: Caroli.org, 2018.
+
+> RIES, Eric. A Startup Enxuta: Como os Empreendedores Atuais Utilizam a Inovação Contínua para Criar Empresas Extremamente Bem-Sucedidas. Rio de Janeiro: Alta Books, 2012.
+
 ## Histórico de Versão:
 | Data | Versão | Descrição | Autor | Revisores |
 |---- | ------ | --------- | ----- | --------- |
-| 03/12/24 | 1.0 | Criação do documento | Daniel Rodrigues | Arthur Suares
-| 06/12/24 | 1.1 | Desenvolvimento de novos tópicos | Daniel Rodrigues | Arthur Suares
-| 09/12/24 | 1.2 | Corrigindo tópicos e adicinando novos itens do backlog | Daniel Rodrigues | Arthur Suares
-| 09/12/24 | 1.3 | Incluindo o calculo de priorização | Manuella, Arthur, João | Daniel Rodrigues
+| 03/12/24 | 1.0 | Criação do documento | Daniel Rodrigues | Arthur Sousa
+| 06/12/24 | 1.1 | Desenvolvimento de novos tópicos | Daniel Rodrigues | Arthur Sousa
+| 09/12/24 | 1.2 | Corrigindo tópicos e adicinando novos itens do backlog | Daniel Rodrigues | Arthur Sousa
+| 09/12/24 | 1.3 | Incluindo o calculo de priorização | Manuella, Arthur, João | Daniel
 | 12/12/24 | 2.0 | Novos requisitos e reestruturação do backlog | Daniel Rodrigues | Arthur Suares
+| 12/12/24 | 2.1 | Adição dos Temas e Épicos | Daniel Rodrigues | João Pedro