Comunicação Operacional e Desenvolvimento de Equipe

Introdução

Este documento consolida como a equipe operacionaliza a metodologia através de ferramentas, canais, agendamento e desenvolvimento contínuo de skills. Aqui descreve-se como cada ferramenta suporta a metodologia aplicada.

Canais e Ferramentas de Comunicação

Ferramentas

Ferramenta	Finalidade	Tipo de Comunicação	Tempo de Resposta
Discord	Reuniões síncronas, sprints, alinhamentos técnicos com time e PO	Síncrona/Assíncrona	Até 24h
Microsoft Teams	Reuniões formais, validação com PO, gravação de apresentações	Síncrona	Agendado
WhatsApp	Avisos rápidos, decisões operacionais, daily assíncrona	Assíncrona	Até 4h
ZenHub	Gestão do backlog, sprint planning, Kanban integrado ao GitHub	Rastreabilidade	-
GitHub	Versionamento, PRs com revisão de código, CI/CD	Rastreabilidade	-
Visual Studio Code	Ambiente principal de desenvolvimento, edição de código e integração com controle de versão	Desenvolvimento	-
Google Docs	Escrita colaborativa de atas, artefatos em construção	Colaboração tempo-real	-
Google Planilhas	Controle de EVM-Ágil, distribuição de atividades, heatmap	Dados compartilhados	-
Figma	Prototipação de telas, validação de fluxo de navegação	Colaboração visual	-
Canva	Materiais visuais para apresentações e comunicação	Design rápido	-
YouTube	Apoio ao aprendizado técnico por meio de tutoriais e referências	Assíncrona	-

Estrutura de Reuniões: Operacionalizando Scrum Adaptado

Reuniões Internas (Equipe + Líderes)

Segunda-feira, no horário de aula (presencial):

Cerimônia	Duração	Objetivo	Artefatos
Sprint Review	30-45 min	Apresentar que foi entregue; PO valida e aprova	Demo do incremento, feedback documento
Sprint Retrospective	20-30 min	Refletir sobre processo: o que melhorar?	Ata com action items
Sprint Planning	30-45 min	Definir escopo da próxima sprint, estimar, alocar	Sprint backlog no ZenHub, commits

Diariamente (Assíncrono no WhatsApp): - Daily Standup assíncrona (até 12h): Cada dev escreve: O que fiz, o que vou fazer, bloqueios - Líderes da quinzena leem, destrava e escalam bloqueios

Reuniões Externas (Com PO e Stakeholders)

Segunda-feira, 19h30-20h30 (Teams): - Sprint Review com PO: Validação formal da entrega, feedback coletado - Responsáveis: Líderes da quinzena + todos membros do time

Sob demanda (Discord): - Alinhamentos rápidos com cliente se houver dúvida de escopo ou mudança urgente

Agendamento da Equipe

Heatmap de Disponibilidade

A equipe mapeou horários de maior disponibilidade em Google Planilhas.

O arquivo original foi organizado com uma aba individual para cada integrante e uma aba principal consolidando a disponibilidade geral do time.

Planilha 1 - Heatmap de disponibilidade da equipe RetinaScan.

Fonte: André Maia, 2026. Disponível em: heat_map_FCTE-FM-01.

Resultado: Melhores horários para reunião: Segunda, Quarta, Sexta de 20h a 21h.

Como usamos: - Reuniões internas agendadas nestes horários quando possível - Sprints Planning, Review, Retro sempre segunda (horário aula) — obrigatório - Pair programming e mentorias opcionais nos horários de alta disponibilidade

Impacto: Maximiza presença e engajamento em atividades críticas.

Protocolo de Comunicação e Escalonamento

Diretrizes Gerais

Situação	Canal Inicial	Prazo Esperado	Escalonamento
Dúvida funcional sem bloqueio	WhatsApp	Até 24h	Levar para Planning/Review
Bloqueio técnico em tarefa ativa	WhatsApp + Discord	Até 4h em dia útil	Acionar líderes, se necessário revisar escopo
Mudança de prioridade/escopo	Discord + ZenHub	Mesmo dia	Validar com PO antes de replanejar
Impedimento externo	Discord/Teams	Mesmo dia	Registrar em ata e ajustar backlog
Aprovação de PR crítica	GitHub PR comment	Até 24h	Rebase + novo push se mudanças solicitadas

Boas Práticas de Comunicação

Sempre contextualize: "HU#123 está bloqueada porque..." ao invés de "Preciso de ajuda"
Registre decisões: Coloque em issue, PR comment ou ata — não apenas chat
Use o canal no Discord retinascan-po apenas para comunicação com o PO e o professor da disciplina
Atualize ZenHub no mesmo dia da mudança de status
Mensagens no WhatsApp: Evite ping antes das 9h e depois das 22h
Evite: Decisões de escopo apenas por chat. Sempre formal (ata/issue)
Evite: Deixar PR aberta sem revisão > 24h

Desenvolvimento Contínuo de Equipe

Quadro de Conhecimento

A equipe mantém um Quadro de Conhecimentos em Google Planilhas que rastreia proficiência em:

Linguagens: Python, TypeScript, Java, C/C++
Frameworks: Node/Bun, React, Vue
Infraestrutura: Docker, CI/CD, Git, Nginx/Traefik, Deploy
Testing: JUnit, Jest, pytest
Testes: API Rest, VPS

Níveis de Proficiência

Nível	Descrição
Nenhum	Nunca usei na prática; preciso aprender do zero
Básico	Faço tarefas simples, mas dependo de tutoriais ou ajuda
Intermediário	Tenho autonomia para trabalhar sozinho e resolver dia a dia
Avançado	Domino a tecnologia, resolvo problemas complexos e ensino

Planilha 1 - Quadro de Conhecimento da equipe RetinaScan.

Fonte: André Maia, 2026. Disponível em: conhecimentos_FCTE-FM-01.

O arquivo original foi dividido em duas abas: uma com os registros individuais de cada membro e outra com a análise quantitativa por tecnologia, calculada por soma ponderada dos níveis de proficiência.

Como Usamos o Quadro

Alocação de Tarefas: Especialistas (avançado) pegam tarefas complexas; iniciantes (básico) em suporte
Pareamento: Avançado + Básico em issues críticas = transferência de conhecimento
Identificação de Gaps: Tecnologia com "Básico" geral = planejamos capacitação ou contratação
Rodízio de Lideranças: Todos experimentam papéis diferentes, desenvolvem novos skills
Mentoria Registrada: Quando alguém aprende nova skill, documenta no Template MD_xx

Decisão de Alocação por Stack

A equipe formalizou a distribuição inicial por stack com base em preferência e aderência técnica dos membros, para equilibrar velocidade de entrega e aprendizado orientado.

Stack	Integrantes
Frontend	Iderlan Junio, Cecilia Quaresma, Harleny Angélica, Natália Rodrigues e André Maia
Backend	Arthur Ribeiro, Vinícius Roriz, Zenilda Pedrosa, Yan Luca, Elias de Oliveira, Eric Camargo, André Maia e Natália Rodrigues
IA	Gustavo Costa, Cecilia Quaresma, Iderlan Junio
Devops	Yan Luca, Elias de Oliveira

Evidência: Ata de reunião de equipe 2026-04-13.

Quadro de Pareamento

Os pareamentos são feitos no Sprint Planning e na Retrospectiva, podendo mudar conforme bloqueios, prioridades e necessidade de mentoria técnica. As HUs são designadas para os pares conforme a decisão de alocação por stack.

Evolução de Skills

Cada membro registra no Template MD_xx (individual): - Tecnologias que aprendeu na semana - Como aplicou no projeto - Próximas competências a desenvolver

Impacto: Documentação viva de crescimento da equipe, base para avaliações individuais e contratação futura.

Integração: Como Tudo Funciona em Conjunto

Semana Típica de Operação

SEGUNDA (Aula - Presencial)
├─ Sprint Review (30-45 min): Apresenta, PO aprova
├─ Retrospective (20-30 min): Identifica melhorias
├─ Sprint Planning (30-45 min): Define próxima sprint
└─ Noite (19h30 - Teams): Review com PO

TERÇA A SEXTA
├─ Dev contínuo em PRs
├─ Diário assíncrona WhatsApp (daily standup)
├─ Pares opcionais em horários de alta disponibilidade
└─ Ferramentas: GitHub (código), ZenHub (progresso), Discord (suporte)

CONTÍNUO
├─ GitHub Actions: Pipeline CI/CD em cada PR
├─ SonarCloud: Métricas de cobertura e qualidade
├─ ZenHub Kanban: Status visual do fluxo de trabalho
└─ Template MD_xx: Registro individual de aprendizados

SEMANAL
├─ EVM-Ágil: Recalcula VP, VA, CPI, SPI
├─ Matriz de Riscos: Valida eventos críticos
├─ Burndown Chart: Acompanha desvio de sprint
└─ Decisões Baseadas em Dados: Registra achados importantes

Ferramentas Técnicas em Detalhe

GitHub: Versionamento e CI/CD

Como usamos: - Repositório único para cada serviço (backend, frontend, IA) - Proteção da branch main: requer PR + aprovação + pipeline verde - Cada PR gatilha: lint → build → testes → cobertura → SonarCloud - Commits semânticos (feat:, fix:, docs:, etc) para changelog automático - Merge automático após aprovação

Impacto: Rastreabilidade, qualidade garantida, rollback rápido se necessário.

ZenHub: Gestão do Backlog e Sprint

Como usamos: - Backlog Priorizado: Histórias de usuário com critérios de aceitação - Sprint Planning: Issues selecionadas do backlog para semana - Kanban: Visualização To Do → In Progress → In Review → Done - Burndown: Gráfico visual de progresso vs. planejado - Labels: feature, bug, tech-debt, documentação, urgent - Assignees: Cada issue tem responsável claro

Impacto: Transparência total, identificação rápida de gargalos, previsibilidade.

SonarCloud: Qualidade de Código

Como usamos: - Integrado ao GitHub: cada PR mostra cobertura, debt, vulnerabilidades - Requisito: Cobertura ≥85% em código novo - Rejeita PR se vulnerabilidade crítica encontrada - Dashboard disponível: https://sonarcloud.io (público) - Métrica principal para R1: Cobertura ≥85%

Impacto: Garante código limpo, seguro, bem testado.

Google Planilhas: EVM-Ágil e Dados

Como usamos: - EVM-Ágil: Calcula Valor Planejado (VP), Valor Agregado (VA), Custo Real (CR) - CPI (Cost Performance Index) = VA / CR: Se < 1, projeto caro demais - SPI (Schedule Performance Index) = VA / VP: Se < 1, projeto atrasado - Gráfico de Gantt: Marcos do projeto (início, fim), releases (R1, R_MVP, R3) - Matriz de Riscos: Probabilidade × Impacto, plano de resposta

Impacto: Decisões baseadas em dados, projeções realistas, riscos controlados.

Histórico de Versão

Versão	Data	Descrição	Autor
`1.0`	10/04/2026	Criação do documento original heatmap-de-horarios.md e tabela-de-conhecimentos.md	André Maia
`1.0`	13/04/2026	Criação do documento original comunicacao.md e ferramentas.md	Zenilda Vieira
`2.0`	26/04/2026	Consolidação: comunicacao.md + ferramentas.md + heatmap-de-horarios.md + tabela-de-conhecimentos.md	Zenilda Vieira e GitHub Copilot