Team Agreements

Acordos e princípios que guiam como trabalhamos juntos.

Valores do Time

🤝 Colaboração sobre Competição

Ajudamos uns aos outros
Compartilhamos conhecimento abertamente
Celebramos sucessos juntos
Ninguém é "dono" de código

📖 Transparência e Documentação

Decisões importantes são documentadas (RFCs)
Código é documentado (docstrings, comments quando necessário)
Processos são claros e acessíveis
Comunicação é assíncrona first (Slack antes de reuniões)

🎯 Qualidade e Pragmatismo

Código com testes é esperado
Perfeito é inimigo do bom (iterar é melhor que procrastinar)
Code review é para aprender e melhorar (não para criticar)
Technical debt consciente é OK se documentado

🚀 Entregas Contínuas

Deploy frequente é melhor que deploy grande
Feedback rápido do usuário é valioso
Features pequenas e incrementais
Production-first mindset

🌱 Crescimento e Aprendizado

Erros são oportunidades de aprendizado
Perguntas "bobas" não existem
Pair programming é encorajado
Experimentação é valorizada

Comunicação

Slack

Quando usar:

✅ Dúvidas rápidas
✅ Discussões técnicas (threads!)
✅ Compartilhar links e artigos
✅ Notificações importantes
✅ Comunicação assíncrona

Etiqueta:

Use threads para manter conversas organizadas
@here apenas para urgências
@channel nunca (a menos que emergência)
Mencione pessoas específicas quando precisar de resposta
Emojis de reação ajudam a indicar "vi" sem precisar responder

Horários de resposta:

Durante horário comercial: resposta em até 2h (não é imediato!)
Fora do horário: sem expectativa de resposta
Urgências: ligar ou enviar SMS

Reuniões

Princípios:

Toda reunião tem agenda compartilhada antes
Reuniões começam e terminam no horário
Câmera ligada quando possível (mas não obrigatório)
Uma pessoa fala por vez
Anotar decisões e action items

Tipos de Reuniões:

Daily Stand-up (15 min) - O que fiz ontem - O que vou fazer hoje - Algum bloqueio?

Sprint Planning (1h) - Revisar backlog - Escolher issues para o sprint - Estimar esforço - Definir sprint goal

RFC Meeting (2h, quinzenal) - Apresentar RFCs - Discutir alternativas - Tomar decisões - Ver processo completo

Retrospectiva (1h, mensal) - O que foi bem? - O que pode melhorar? - Action items para próximo mês

Regra de Ouro: Se pode ser email/Slack, não é reunião.

Email

Quando usar:

Comunicação formal externa
Registros que precisam ser auditados
Comunicação com stakeholders fora do time

Quando NÃO usar:

❌ Discussões técnicas (use Slack)
❌ Decisões do time (use RFC ou Slack)
❌ Assuntos urgentes (use Slack ou ligue)

Horário de Trabalho

Flexibilidade

Core hours: 10h-16h (todos devem estar disponíveis)
Fora disso: flexível, desde que entregue
Reuniões agendadas dentro do core hours quando possível
Trabalho remoto: OK, mas avisar no Slack

Foco Time

Blocos de foco: Marcar no calendário quando precisa de foco ininterrupto
Respeitar status "Do Not Disturb" no Slack
Fones de ouvido = não perturbe (a menos que urgente)

Disponibilidade

Atualizar status no Slack (🏖️ férias, 🤒 doente, 🍽️ almoço, etc.)
Bloquear calendário para compromissos pessoais
Avisar ausências com antecedência quando possível

Code Review

Para Autores (quem abre o PR)

Antes de abrir PR:

Código funciona localmente
Testes passam (incluindo linter)
Commits organizados e mensagens claras
PR description preenchida (use template)
Self-review feito (revisei meu próprio código)
Screenshots adicionados se mudança visual

Durante review:

Responda comentários prontamente (mesmo que seja "vou olhar depois")
Não fique na defensiva - review é para melhorar, não criticar
Faça perguntas se não entender sugestão
Agradeça feedback (mesmo crítico)
Marque quando fizer mudanças solicitadas

Tamanho de PR:

Ideal: até 400 linhas de código
Se maior: considere quebrar em PRs menores
Exception: migrations, código gerado, etc.

Para Revisores

Checklist:

Entendo o que o código faz?
Está alinhado com nossa arquitetura?
Testes cobrem os casos principais?
Código é legível e manutenível?
Documentação necessária foi atualizada?
Não há problemas óbvios de segurança?

Feedback Construtivo:

✅ "Que tal extrair isso em uma função? Ficaria mais legível"
✅ "Encontrei um edge case: e se X for null?"
✅ "Aprendi algo novo com esse código!"
❌ "Isso está errado" (sem explicar por quê)
❌ "Eu faria diferente" (sem justificativa técnica)

Tipos de Comentário:

[nit]: Nitpick, sugestão menor, não bloqueante
[question]: Pergunta para entender melhor
[blocker]: Precisa ser resolvido antes do merge
[suggestion]: Sugestão de melhoria, considerar mas não obrigatório

Timing:

Revisar PRs em até 24h (melhor esforço)
PRs urgentes: avisar no Slack
Se não puder revisar: desfazer-se do PR e mencionar outra pessoa

Git e Código

Git Workflow

Ver documentação completa
Branches: feature/, hotfix/
Sempre rebase (não merge) ao sincronizar
PRs obrigatórios para dev e main
Commits: Conventional Commits (feat:, fix:, etc.)

Padrões de Código

Ver Coding Standards completo
Linter e formatter configurados (Black para Python, Prettier para JS)
pre-commit hooks instalados
Seguir convenções da linguagem (PEP 8, Airbnb Style Guide)

Testes

Novo código = novos testes
Coverage mínimo: 70% backend, 60% frontend
Testes devem ser rápidos e determinísticos
Mockar dependências externas (APIs, banco, AWS)

Decisões Técnicas

Quando Criar RFC

Mudanças arquiteturais
Novas tecnologias/serviços
Padrões de código importantes
Processos do time

Ver RFC Process completo

Quando Não Criar RFC

Bug fixes
Refatorações locais
Melhorias de performance pontuais
Atualização de dependências

Tomada de Decisão

Princípios:

Consenso quando possível: Buscamos acordo
Commit quando decidido: Após decisão, todos seguem (mesmo se discordaram)
Reverter se não funcionar: Decisões não são permanentes
Documentar sempre: RFCs documentam o "porquê"

Hierarquia de Decisão:

Consenso do time (ideal)
Tech Lead (quando há impasse)
Experimentar (quando incerto, testar ambas opções)

Deploys e Incidentes

Deploys

Staging: Automático após merge em dev
Production: Após testes em staging e PR para main
Horário preferencial: 10h-16h (horário comercial)
Evitar sextas-feiras (a menos que necessário)
Quem faz deploy monitora por 30 min após

Incidentes

Se você causou:

Não entre em pânico
Avise no #incidents imediatamente
Rollback se souber como
Peça ajuda se precisar
Ninguém será punido por erro honesto

Se você detectou:

Avise no #incidents
Alerte pessoa on-call (se fora de horário)
Não assuma que alguém já viu

Postmortem:

Todo incidente significativo tem postmortem
Foco em processos, não em pessoas
"What went wrong?" não "Who messed up?"
Action items para prevenir recorrência

Ver Incident Response completo

Bem-Estar

Work-Life Balance

Trabalho é importante, mas não é tudo
Tire férias regularmente
Desconecte fora do horário
Não responda Slack depois do expediente (a menos que queira)
Burnout é real - fale se sentir sobrecarregado

Saúde Mental

Dias ruins acontecem - tudo bem não estar 100%
Peça ajuda quando precisar (técnica ou pessoal)
Pausas são importantes - levante, caminhe, respire
Não há recompensa por trabalhar doente

Feedback e Crescimento

Feedback 1:1 com gestor mensalmente
Feedback entre pares é encorajado
Plano de desenvolvimento individual (PDI)
Budget para cursos e conferências

Revisão destes Acordos

Revisamos estes acordos trimestralmente
Qualquer um pode propor mudanças (via PR neste doc ou RFC)
Acordos são living document - evoluem com o time

Última revisão: 2026-01-20
Próxima revisão agendada: 2026-04-20

Sugestões? Abra um PR ou comente no Slack #tech-docs