docs: adiciona o topico de interação e a nav

docs/interação/composição.md

@@ -0,0 +1,42 @@
+# Interação entre Equipe e Cliente
+
+## Composição da Equipe
+
+| Papel                  | Descrição                                                                                                                             | Responsável     | Participantes   |
+| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | --------------- | --------------- |
+| Gerente do Projeto     | Assegura a comunicação eficaz entre o cliente e a equipe, monitora prazos e gerencia as entregas para manter o projeto no cronograma. | Edilson Ribeiro |                 |
+| Desenvolvedor Frontend | Cuida do design e da implementação das funcionalidades no front-end, garantindo uma experiência de usuário intuitiva e atraente.      | Matheus Brant   | Igor Silva      |
+| Desenvolvedor Backend  | Realiza a integração com o banco de dados e APIs, garantindo que os processos internos e fluxos de dados funcionem corretamente.      | Caio Felipe     |                 |
+| Analista QA            | Conduz testes de funcionalidade, desempenho e usabilidade para assegurar que o produto atenda aos padrões exigidos.                   | Igor Silva      |                 |
+| Analista de Requisitos | Estabelece os requisitos funcionais e não funcionais e assegura sua implementação conforme planejado.                                 | Felipe Matheus  | Edilson Ribeiro |
+
+## Comunicação
+
+- **Telegram**: Utilizado para a comunicação diária entre os membros da equipe, permitindo o envio rápido de mensagens, compartilhamento de arquivos e criação de grupos específicos para discussões sobre funcionalidades, bugs ou tarefas. Também será uma ferramenta eficaz para interações rápidas com o cliente, garantindo uma comunicação fluida e contínua.
+- **Microsoft Teams**: As reuniões semanais de revisão e planejamento de sprints com o cliente serão realizadas por videoconferência no Microsoft Teams. Essas reuniões permitirão validar as entregas, coletar feedback e discutir as atividades planejadas para o próximo sprint, mantendo a equipe e o cliente alinhados quanto ao progresso e necessidades do projeto.
+
+- **Trello**: Ferramenta para gerenciamento do backlog, controle de tarefas e acompanhamento do progresso de cada sprint. Ele permitirá que tanto a equipe quanto o cliente visualizem o andamento do projeto em quadros organizados e participem ativamente do processo de priorização das funcionalidades, mantendo o fluxo de trabalho organizado e transparente.
+
+## Métodos e Frequência de Reuniões
+
+- **Reuniões Diárias (Daily Scrum)**: A equipe de desenvolvimento realizará reuniões diárias de 15 minutos (via Telegram) para discutir o progresso de cada membro, os obstáculos e as prioridades do dia. Essas reuniões garantirão que todos estejam cientes do andamento do projeto e possam resolver rapidamente problemas que possam surgir.
+
+- **Reunião de Revisão de Sprint (a cada 2 semanas)**: Ao final de cada sprint (a cada 2 semanas), haverá uma reunião de revisão com o cliente. Nessas reuniões, a equipe apresentará as funcionalidades desenvolvidas, permitirá que o cliente as teste e coletará feedback para ajustar o backlog, se necessário.
+
+- **Reunião de Planejamento de Sprint**: Após a reunião de revisão, a equipe e o cliente se reunirão para planejar o próximo sprint, revisando o backlog e definindo as prioridades de acordo com o feedback do cliente.
+
+- **Reunião de Retrospectiva**: Será realizada uma retrospectiva a cada final de sprint, onde a equipe discutirá o que funcionou bem, o que pode ser melhorado e as lições aprendidas no ciclo anterior, garantindo a melhoria contínua no processo.
+
+### Frequência de Interações com o Cliente
+
+- **Revisões de Sprint (a cada 2 semanas)**: O cliente estará diretamente envolvido nas revisões de sprint a cada 2 semanas, onde poderá validar as entregas e fornecer feedback.
+
+## Processo de Validação
+
+O processo de validação da solução será realizado em três etapas principais:
+
+1. **Definition of Ready (DoR)**: Para iniciar o desenvolvimento de uma funcionalidade, o 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.
+
+2. **Definition of Done (DoD)**: 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 e pelo cliente.
+
+3. **Testes de Aceitação pelo Cliente**: Após a validação interna, 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

@@ -4,9 +4,10 @@ repo_url: https://github.com/mdsreq-fga-unb/2024.2-T01-IdeaSpace
 repo_name: IdeiaSpace
 
 nav:
-  - Home: 'index.md'
+  - Home: "index.md"
   - Visão de Produto e Projetos:
-    - Estratégias de Engenharia de Software: produto/estrategias.md
+      - Estratégias de Engenharia de Software: produto/estrategias.md
+      - Interação entre equipe e cliente: interação/composição.md
 
 theme:
   name: material
@@ -15,15 +16,15 @@ theme:
 
   palette:
     - scheme: default
-      primary: 'indigo'
-      accent: 'pink'
+      primary: "indigo"
+      accent: "pink"
       toggle:
         icon: material/lightbulb
         name: Dark mode
-        
+
     - scheme: slate
-      primary: 'indigo'
-      accent: 'pink'
+      primary: "indigo"
+      accent: "pink"
       toggle:
         icon: material/lightbulb-outline
         name: Light mode