Integração entre equipe e cliente
5.1 Composição da equipe
| Papel | Descrição | Responsável | Participantes |
|---|---|---|---|
| Product Owner | Responsável pelo produto, gestão do backlog, aceitação de entregáveis e mudanças no escopo. | Samuel | |
| Gerente de Projetos | Responsável por coordenar todo o desenvolvimento do produto, gerenciando cronogramas, recursos e comunicação entre a equipe. | Amanda | Gabriel |
| Scrum Master | Responsável por conduzir cerimônias do Scrum, remover impedimentos, ajudar na coleta de métricas e promover melhorias contínuas. | Davi | Amanda |
| Documentação | Responsável pela documentação do projeto | Gabriel Augusto | Todos integrantes |
| Frontend | Responsável por desenvolver a interface intuitiva para visualização e interação com os dados de compras e estoque. | Beatriz | Gabriel, Amanda |
| Backend | Responsável por implementar algoritmos de análise de dados, integração com sistemas existentes e migração de dados das planilhas existentes e criação de views para diferentes perfis de usuário. | Davi | Samuel, Eduardo, Beatriz, Gabriel |
| Testes | Responsável por verificar o funcionamento do código e remediar eventuais defeitos no funcionamento. | Amanda | Todos os integrantes |
| Analista de Requisitos | Responsável por definir os critérios de análise, métricas importantes e regras de negócio. | Todos os integrantes | Todos os integrantes |
| Infraestrutura e CI | Responsável por configurar o ambiente de desenvolvimento, testes e produção para suportar o sistema de análise de dados. | Gabriel | Davi |
5.2 Comunicação|
A presente seção aborda como se dará a comunicação interna e externa da equipe de maneira a evitar desentendimentos e maximizar o valor agregado do produto ao cliente. Os objetivos a seguir detalham especificamente o que o produto busca alcançar, transformando a gestão de compras e estoque em um processo mais ágil, intuitivo, estratégico e centralizado.
Ferramentas de comunicação
- Discord: ferramenta que armazena links importantes da disciplina e também é usado para comunicação e reuniões informais. Os documentos principais da equipe e do projeto também estão armazenados nele.
- WhatsApp: ferramenta usada para comunicação rápida em situações mais urgentes.
- Microsoft Teams: ferramenta usada para as reuniões com o cliente e gravação dessas reuniões, permitindo que a equipe posteriormente possa rever algumas informações acordadas com o cliente.
- GitHub Projects: será utilizado para gestão de tarefas dentro da equipe. Ele apresenta alta integração com o próprio repositório do projeto e permite a criação de issues, que são cards que podem sinalizar problemas, coisas a serem feitas, pedidos de revisão de código e afins, além de permitir que usuários comentem nessas cards e facilite a colaboração entre membros.
Métodos e frequência de reuniões
- Reuniões semanais entre a equipe: A equipe de desenvolvimento se reunirá toda semana durante 1 hora e meia pelo Discord ou Microsoft Teams para discussão do andamento do projeto, em que cada membro irá relatar os progressos e dificuldades que teve durante a semana. A reunião será documentada por meio de uma ata.
- Reuniões extraordinárias entre a equipe: Em situações excepcionais, a equipe de desenvolvimento poderá se reunir para resolução de um problema ou para fins de alinhamento. A reunião será documentada por meio de uma ata.
5.3 Processo de validação
O processo de validação da solução será estruturado em torno de três pilares fundamentais, garantindo que cada funcionalidade seja bem definida, corretamente implementada e formalmente aprovada pelo cliente.
Critérios de Prontidão (Definition of Ready - DoR): Uma funcionalidade será considerada "Pronta para Desenvolvimento" apenas quando:
- O requisito estiver claramente descrito como uma User Story (ex: "Eu, como analista, quero ver um gráfico de vendas por região para tomar decisões de compra").
- A funcionalidade estiver representada e validada no protótipo interativo (Figma) pelo cliente.
- Os Critérios de Aceite estiverem claramente definidos (ex: "o gráfico deve ser de barras", "deve ser possível filtrar por mês", "os dados devem vir da planilha X").
Critérios de Conclusão (Definition of Done - DoD): Uma funcionalidade só será considerada "Pronta" ao final de um Sprint se atender rigorosamente ao nosso Definition of Done. Nossa definição de "Pronto" inclui:
- O código ter sido desenvolvido, testado (testes unitários e de integração) e integrado à versão principal.
- O código ter passado pela revisão de outro membro da equipe (Code Review).
- A funcionalidade ter sido demonstrada e validada pelo cliente durante a Sprint Review, confirmando que atende visual e funcionalmente ao que foi solicitado.
Teste de Aceitação do Usuário (UAT): Após a conclusão do desenvolvimento de todas as funcionalidades planejadas, ocorrerá o Teste de Aceitação final. Nesta fase:
- O cliente utilizará a ferramenta para executar suas tarefas reais de ponta a ponta (ex: simular uma análise de compras mensal completa).
- A validação será feita com base no conjunto de critérios de aceite de todas as funcionalidades que foram aprovadas ao longo do projeto.
- O sucesso nesta etapa formaliza que a solução, como um todo, atende aos requisitos e está pronta para a implementação final.