6. Interação Equipe-Cliente
6.1 Composição da Equipe
Os papéis seguem o modelo FDD + Kanban. Cada integrante pode acumular papéis; as responsabilidades permanecem individuais e rastreáveis. Passe o mouse (ou toque) em cada membro para ver papel, responsabilidades e disponibilidade.
- PM/DM: gerenciar roadmap, prazos e interface com cliente/professor; conduzir Replenishment.
- Chief Architect: liderar a modelagem de domínio e decisões estruturais da arquitetura.
- DM backup: desbloquear issues críticas.
- DM: coordenar o progresso técnico diário (Kanban), WIP limits e a consolidação final do Build.
- Class Owner: desenvolver e testar classes/features específicas.
- Chief Programmer: conduzir o Technical Design Review (Backend/Infra/K8s); aprovar PRs estruturais.
- Class Owner: desenvolver o código das responsabilidades assumidas no design.
- Chief Programmer: decisões técnicas e revisões de PR focadas em Frontend e QA; design detalhado.
- Class Owner: implementar de ponta a ponta as partes da interface sob sua responsabilidade.
- Implementação primária de código, garantindo regras de negócio e critérios de aceite codificados e testados.
- Atualização do board em tempo real e code review entre pares.
- Requirements/Docs: gestão dos artefatos (feature cards, rastreabilidade, critérios) e do Documento de Visão.
- Class Owner: desenvolver e testar features alocadas.
Papéis rotativos por iteração
| Papel | Responsabilidade |
|---|---|
| Facilitador Metodológico | Conduz cerimônias semanais; garante adesão ao processo; sinaliza desvios na retrospectiva |
| Responsável por Validação | Coordena Partial e Formal Client Validation com Otávio; prepara checklists e materiais de demo; documenta aprovações nas issues |
6.2 Estrutura de Comunicação
Cada ferramenta tem escopo exclusivo — o que vai para o Miro não vai para o Discord. Isso evita decisões tomadas no canal errado e mantém rastreabilidade.
Roadmap, backlog macro, Feature Cards, Iteration Goal, modelo de domínio, atas e lições aprendidas. Não para acompanhamento de issues.
Issues fluindo de Backlog → Done com WIP limit visível. Não para cerimônias ou alinhamento estratégico.
Código-fonte, Pull Requests, code review, CI/CD e evidências de execução.
Documento de Visão, rastreabilidade OE → CP → Feature e artefatos formais. Não para operação diária.
Comunicação da semana, reuniões da equipe, dúvidas técnicas e Midweek Sync ("Ontem fiz / Hoje farei / Bloqueios").
Canal direto com Otávio para validações parciais e alinhamentos urgentes.
Reuniões formais com o cliente.
Links das Ferramentas
| Ferramenta | Link |
|---|---|
| Miro (board principal) | Acessar board |
| GitHub Projects (Kanban) | Acessar board |
A cadência de cerimônias (única e iterativa) e o detalhamento semanal estão em Cadência de Cerimônias.
Histórico de Revisão
| Versão | Data | Descrição | Autor(es) |
|---|---|---|---|
| 1.0 | 11/04/2026 | Criação das seções 6.1 a 6.6 | Lucas A. Zanetti |
| 1.4 | 06/06/2026 | Separação de cerimônias únicas e iterativas | Lucas A. Zanetti |
| 1.5 | 15/06/2026 | Correção de sintaxe nas tabelas | Heitor Macedo Ricardo |
| 2.0 | 26/06/2026 | Migração Docusaurus: membros em cards com popover; ferramentas com logos; cadência movida para página própria | Equipe Crianex |