6. Interação entre Equipe e Cliente

6.1 Composição da Equipe

Conforme detalhado na tabela a seguir, são apresentados os papéis e responsabilidades de cada integrante da equipe.

Papel	Descrição	Responsável	Participantes
Desenvolvedor Frontend	Responsável pela interface gráfica do sistema, garantindo a interação eficiente e acessível do usuário com a aplicação.	Weverton Rodrigues	Felipe Henrique
Desenvolvedor Backend	Responsável pela implementação da lógica de negócio, integração com o banco de dados e desenvolvimento de serviços e APIs da aplicação.	Caio Sabino	Caio Melo, Felipe de Aquino
Modelador de Dados	Responsável pela modelagem conceitual, lógica e física do banco de dados utilizado na aplicação.	Caio Melo
Gerente de Projeto	Coordena as atividades do projeto, realiza o acompanhamento de prazos, garante a comunicação com o cliente e facilita a organização interna da equipe.	Vinicius Rufino	Weverton Rodrigues, Caio Sabino
Analista de Requisitos	Responsável pela elicitação, documentação e validação dos requisitos funcionais e não funcionais do sistema junto ao cliente.	Vinicius Rufino	Caio Melo, Caio Sabino, Felipe de Aquino, Felipe Henrique, Weverton Rodrigues

6.2 Comunicação

Nesse tópico iremos apresentar as ferramentas e métodos a serem usados pela nossa equipe durante todo o desenvolvimento do projeto. Além de como será feita a comunicação entre os membros da nossa equipe.

Ferramentas de Comunicação
- Google Meet: Ferramenta responsável pela interação com o cliente, a fim de obter uma comunicação efetiva e didática, com transmissão de tela.
- Discord: Ferramenta de comunicação entre membros, a fim de desenvolver o projeto em conjunto, envio de links e documentos importantes.
- Whatsapp: Comunicação diária entre os membros do grupo, interação com o cliente a fim de marcar/confirmar reuniões.
- Microsoft Teams: Gravação de apresentações de final de unidade.

Métodos e Frequência de Reuniões
- Reuniões com o cliente: Realizadas quinzenalmente, via Google Meet, com o objetivo de apresentar entregas parciais, validar funcionalidades, revisar protótipos e coletar feedback, valorizando a participação ativa do cliente e prevê validações frequentes durante o desenvolvimento.
- Reuniões internas da equipe: Ocorrerão semanalmente, utilizando o Discord, para o planejamento, acompanhamento das tarefas em andamento, discussão de dificuldades e organização das próximas entregas.
- Comunicação Assíncrona Diária: Realizada via Whatsapp, garantirá agilidade na tomada de decisões, reforçando a colaboração e o fluxo contínuo de informações.

6.3 Processo de Validação

Nessa seção foram decididos quais serão os processos de validação do produto antes de sua implementação final. Visando atender às expectativas do cliente com excelência.

Definition of Ready(DoR): Conjunto de critérios que assegura que uma funcionalidade ou requisito identificado possua informações claras, está bem compreendido pela equipe e estimado de forma adequada, estando pronto para ser desenvolvido. Esses critérios reduzem ambiguidades e contribuem para um avanço mais fluido e eficaz do time durante o ciclo de desenvolvimento.

O Requisito está documentado no backlog de forma detalhada e sem ambiguidade? Para que possa ser iniciado, o requisito deve estar registrado de maneira clara, objetiva e completa no backlog, incluindo contexto, cenários de uso e dados de entrada e saída bem definidos.
A História de Usuário está dentro da estrutura padrão? A história de usuário deve seguir o formato padrão: "Como [persona], eu quero [funcionalidade], para que [benefício]".
O requisito foi prototipado? Existe um mockup ou protótipo navegável (ex.: no Figma) referenciado na própria User Story, garantindo clareza visual sobre o comportamento e layout esperado da funcionalidade.
Os Critérios de Aceitação foram definidos e acordados com o cliente ? Cada critério foi validado em reunião de refinamento com o cliente.
A interface está em conformidade com o design aprovado, refletindo cores, tipografia e layout especificados? As telas foram validadas pelo designer e estão de acordo com o guia de estilo definido.
A interface atende às normas e diretrizes de Interação Humano-Computador (IHC), garantindo usabilidade e acessibilidade? Foram seguidas boas práticas de usabilidade.
O requisito cabe em uma única iteração de desenvolvimento? Deve ser pequeno e bem delimitado para ser concluído no período de duas semanas.

Definition of Done(DoD): Trata-se de um conjunto de critérios objetivos que estabelece quando uma funcionalidade implementada ou incremento de produto pode ser considerado completamente finalizado. Esses critérios geralmente envolvem a aprovação nos testes previstos, a devida atualização da documentação associada e a revisão de código. A não conformidade com esses requisitos implica que a entrega não deve ser considerada concluída nem liberada para uso.

O código foi revisado por um desenvolvedor diferente do que fez o código? O código deve ser revisado por outro desenvolvedor, diferente de quem o escreveu, para que um olhar externo possa identificar melhorias e possíveis ajustes.
A funcionalidade passou por todos os Critérios de Avaliação? A funcionalidade só pode ser considerada concluída se for avaliada e aprovada em todos os critérios definidos previamente.
A funcionalidade foi testada e validada com todos os testes unitários e de integração? A funcionalidade deve ser validada com testes unitários e de integração que cubram todos os fluxos críticos do sistema, garantindo seu correto funcionamento.
A entrega representa um incremento ao produto? Cada entrega deve adicionar uma funcionalidade relevante que contribua, de forma prática, para a evolução do produto.

Histórico de Versão

Data	Versão	Descrição	Autor
20/04/2025	1.3	Inserção do Tópico 5	Caio Sabino
21/04/2025	1.4	Refatoração dos Tópicos 5.2 e 5.3	Vinícius Rufino
24/06/2025	1.5	Atualização do DoR e do DoD	Vinícius Rufino