1. QUALI: Lideranças Técnicas
1.1. Formato
1.1.1. Apresentação
1.1.1.1. Fala Rapaziada, tudo jóia? Peguei o contato de vocês com o Rafael Torres. Estou chegando agora na Reserva e estou marcando este bate papo (e é um bate papo mesmo) sobre nosso cenário de Engenharia de Software. Um momento onde eu gostaria de enxergar com os olhos de vocês alguns pontos macro: o que tá legal, o que precisa melhorar, e eventualmente o que está em situação mais crítica. Tragam a xícara de café! Um abraço e até breve!
1.1.2. Maiores dores / Parte crítica
1.1.3. Contexto
1.1.3.1. O que fazem?
1.1.3.2. Quais áreas atendem? Principais Stakeholders?
1.1.3.3. Quais principais canais e/ou aplicações
1.1.4. O que não funciona bem/ o que voce ve que gostaria de mudar??
1.1.5. O que funciona bem?
1.2. Stakeholders
1.2.1. Funcionais
1.2.1.1. Dex
1.2.1.1.1. Marcio Del Bianco
1.2.1.1.2. Devs
1.2.1.1.3. devs terceiras
1.2.1.2. Rafael
1.2.1.3. Clara
1.2.1.4. De Paula
1.2.1.4.1. Peterson
1.2.1.4.2. Vanderley Soares
1.2.1.5. Faillace
1.2.1.5.1. Hugo Ormond
1.2.1.6. Claudio
1.2.1.6.1. Fernando DIas
1.2.2. Tech Leads
1.2.2.1. APP
1.2.2.1.1. Cleiber Reis
1.2.2.1.2. Leonardo Nogueira
1.2.2.1.3. Gabriel Alexander
1.2.2.1.4. Pos + Scrum
1.2.2.1.5. Conversa
1.2.2.2. Site
1.2.2.2.1. Newton Figueiredo
1.2.2.3. Backoffice
1.2.2.3.1. Rocco
1.2.2.3.2. Gabi
1.2.2.3.3. Aghata (Background Tech)
1.2.2.4. CRM e Vendas
1.2.2.4.1. Peterson Andrade
1.2.2.4.2. Vanderlei Soares
1.2.2.4.3. Produto e Agilidade
1.2.2.5. Faillace
1.2.2.5.1. Patricia Nobre
2. QUANTI: Devs
2.1. Escala de Linkert
2.2. Mapa de calor - Maturidade técnica
2.2.1. Onboarding
2.2.1.1. Tive um onboarding técnico MACRO adequado. Entendi por as principais tecnologias e sistemas usados na empresa
2.2.1.2. Tive um onboarding técnico MICRO adequado. Entendi o contexto técnico da minha tribo e especialmente meu time;
2.2.1.3. Consegui fazer meu primeiro deploy com
2.2.1.3.1. menos de 3 dias
2.2.1.3.2. 1 semana ou um pouco mais
2.2.1.3.3. 2 semanas ou um pouco mais
2.2.1.3.4. Depois de 1 mês
2.2.1.4. Documentação
2.2.1.4.1. Tive acesso a uma documentação técnica que impulsionou meu aprendizado INDIVIDUAL e acelerou minha integração com meu time
2.2.2. Ambiente
2.2.2.1. Ambiente (Dev)
2.2.2.1.1. Não tive dificuldades para configurar meu ambiente de Desenvolvimento; Entender a pipeline, configurar os repositórios, base de dados, etc;
2.2.2.2. Ambiente (homol)
2.2.2.2.1. Tenho ambiente mínimo adequado para testar as aplicações antes de subir para Produção;
2.2.2.3. Pipeline
2.2.2.3.1. A Pipeline atende ao time de maneira satisfatória;
2.2.3. Desenvolvimento
2.2.3.1. Code Review
2.2.3.1.1. No meu time o CODE REVIEW é uma realidade; Há engajamento e participação satisfatória; Aprendo com meus colegas no dia a dia;
2.2.3.2. Debitos técnicos
2.2.3.2.1. Meu time consegue resolver dívidas técnicas
2.2.3.3. Testes
2.2.3.3.1. Meu time se preocupa e escreve TESTES UNITÁRIOS;
2.2.3.3.2. Ao menos as funcionalidades/features mais críticas são cobertas por testes automatizados
2.2.3.4. Gitflow
2.2.3.4.1. Nosso time segue as boas práticas do Gitflow para controlar as versões de código;
2.2.3.5. Design patterns
2.2.3.5.1. Meu time trabalha com algum tipo de Padrão de projeto (DESIGN PATTERNS);
2.2.3.5.2. Meu time consegue fazer uso de Bibliotecas de código (Externas ou internas) que aceleram o desenvolvimento;
2.2.3.6. Documentação
2.2.3.6.1. Uma documentação mínima de software, manual ou gerada automaticamente, faz parte da cultura do meu time
2.2.3.7. Logs
2.2.3.7.1. Temos uma estrutura mínima de Logs suficiente pra entender/rastrear um problema
2.2.3.7.2. Usamos tipos de logs bem definidos. Ex: Trace, Debug, Info, Notice, Warn, Error, etc
2.2.4. Mobile
2.2.4.1. Lançar novas versões no aplicativo na loja é...
2.2.4.1.1. Organizado: Temos o conceito de Release train; todos entendem o fluxo de publicação; Aplicativo sobre com release notes para usuários;
2.2.4.1.2. Satisfatório: Subimos código novo sempre que necessário.
2.2.4.1.3. Ruim: Marcamos o gol mas com muita canelada no caminho;
2.2.4.1.4. Péssimo: Confusão e gritaria para lançamento de novas versões
2.2.4.2. Conseguimos um bom nível de modularização no APP e/ou Frontend
2.2.5. Arquitetura
2.2.5.1. Visao atual
2.2.5.1.1. Meu time um desenho de arquitetura de solução atualizado que me ajuda a entender o contexto atual
2.2.5.2. Visão do futuro:
2.2.5.2.1. Meu time tem um desenho de arquitetura de solução que projeta o futuro - Onde queremos chegar no cenário ideal
2.2.5.3. API FIrst
2.2.5.3.1. Meu time usa a abordagem de "API FIRST" para refinamento de novas demandas
2.2.5.4. Event Driven
2.2.5.4.1. Usamos o conceito de Mensageria (Event-Driven) para evitar acomplamento de serviços
2.2.6. Outros
2.2.6.1. Segurança
2.2.6.1.1. Temos ferramentas para auxiliar no DESENVOLVIMENTO SEGURO de software que ajudam a identificar vulnerabilidades no código antes de ir para produção
2.2.6.2. Dados
2.2.6.2.1. Nossas bases de dados atendem aos requisitos de LGPD (Não temos acesso a dados sensíveis dos clientes)
2.2.6.2.2. Considero que as Bases de dados tem uma modelagem satisfatória; Consultar e armazenar dados não é uma dificuldade
2.2.6.3. Observabilidade
2.2.6.3.1. Temos painéis de monitoramento básico das nossas aplicações que (Performance de Serviços, Performance APIs, Error rate, etc)
2.2.6.3.2. Nossos paineis de monitoramento de software estão atralados as regras de negócio (Ex: Quantidade média de pedidos/vendas por dia/hora, Etc)
3. Team Leads
3.1. Dex
3.1.1. Marcio Bianco