Aula 07 - Planejamento de Release e Conformidade (LGPD)

• Objetivos: Planejar releases e considerar conformidade regulatória (LGPD).
• Curso: CST em Análise e Desenvolvimento de Sistemas
• Série: 4º semestre
• Disciplina: Gerenciamento de Software Ágil

7.1 Planejamento de release

7.1.1 Conceitos-chave

• Release: incremento de produto pronto para uso por clientes ou usuários, com valor claro e riscos controlados.
• Release Candidate (RC): versão estável candidata a release, sujeita às validações finais.
• Roadmap: visão macro de objetivos e marcos, orientando o escopo dos releases.
• Release Train: cadência fixa de entrega, como uma entrega mensal, reduzindo variabilidade e facilitando a coordenação entre equipes.
• Escopo do release: conjunto priorizado de itens do backlog alinhados aos objetivos mensuráveis.
• Release Done: conjunto de requisitos técnicos e de negócio necessários para considerar o release concluído, incluindo qualidade, segurança e conformidade.

Relação entre os principais conceitos

A ideia central é que um release não representa simplesmente uma nova versão do software. Ele representa uma entrega de valor que atende a critérios previamente definidos.

7.1.2 Versionamento e organização das entregas

Uma forma comum de representar versões é o Versionamento Semântico (SemVer):

MAJOR.MINOR.PATCH

Exemplo conceitual:

O versionamento facilita a comunicação entre equipes, usuários e clientes, pois permite identificar de forma objetiva a natureza das mudanças realizadas.

Estratégias de branching

Duas estratégias comuns são:

• Trunk-Based Development: integração frequente em uma linha principal de desenvolvimento, normalmente utilizando feature flags para controlar funcionalidades.
• GitFlow simplificado: utilização de branches de curta duração para releases e correções quando necessário.

Independentemente da estratégia adotada, é importante garantir:

• rastreabilidade das versões;
• identificação clara do conteúdo de cada release;
• histórico das alterações;
• possibilidade de relacionar uma versão aos itens de backlog correspondentes.

Rastreabilidade

7.1.3 Calendário de release e janelas

O calendário de release define:

• datas-alvo;
• períodos de preparação;
• possíveis janelas de congelamento;
• momentos de validação;
• decisões de Go/No-Go;
• comunicação às partes interessadas.

Também é importante considerar janelas de risco, evitando períodos em que uma falha possa causar impacto operacional elevado.

Exemplos:

• feriados críticos;
• períodos de fechamento financeiro;
• grandes campanhas comerciais;
• períodos de alta utilização do sistema;
• indisponibilidade prevista de equipes ou fornecedores.

Fluxo de decisão do release

7.1.4 Elaboração do Release Plan

Um Release Plan conecta objetivos, escopo, riscos, métricas e critérios de sucesso.

Elementos recomendados:

• objetivo do release;
• métricas-alvo;
• escopo priorizado;
• dependências;
• riscos;
• plano de validação;
• estratégia de lançamento;
• estratégia de rollback;
• comunicação;
• suporte;
• evidências de qualidade, segurança e conformidade.

Estrutura conceitual de um Release Plan

Priorização do escopo

O escopo pode ser organizado em níveis de prioridade:

Essa classificação ajuda a evitar que o release seja definido apenas pelo volume de funcionalidades.

O objetivo deve ser responder:

Qual é o menor conjunto de funcionalidades capaz de entregar o resultado esperado?

7.1.5 Feature flags e estratégias de lançamento

Feature flags permitem controlar a disponibilização de uma funcionalidade sem necessariamente alterar a versão implantada.

Principais estratégias:

• Dark Launch: funcionalidade implantada, mas ainda invisível para os usuários.
• Canary: funcionalidade disponibilizada inicialmente para uma pequena parcela dos usuários.
• Blue/Green: dois ambientes equivalentes são mantidos e o tráfego pode ser direcionado de um ambiente para o outro.

Estratégias de rollout

Em cada etapa devem ser observados indicadores como:

• taxa de erro;
• desempenho;
• comportamento dos usuários;
• incidentes;
• métricas de negócio.

Cuidados com feature flags

Uma feature flag não deve permanecer indefinidamente no sistema.

É recomendável definir:

• responsável;
• objetivo;
• data prevista para remoção;
• critérios de ativação;
• critérios de desativação;
• métricas acompanhadas.

7.1.6 Métricas e previsibilidade

As métricas ajudam a compreender a capacidade de entrega da equipe e a identificar problemas no fluxo.

Principais métricas:

• Lead Time for Changes: tempo entre o início da mudança e sua disponibilização.
• Deployment Frequency: frequência de implantação.
• Change Failure Rate: proporção de mudanças que causam falhas ou exigem intervenção.
• MTTR: tempo médio necessário para restaurar o serviço após uma falha.

Relação entre métricas

Previsibilidade

Outras ferramentas ajudam a visualizar a evolução do trabalho:

• Burnup: acompanha o trabalho concluído em relação ao escopo.
• Cumulative Flow Diagram (CFD): mostra a distribuição dos itens nas diferentes etapas do fluxo.
• Throughput: quantidade de itens concluídos em determinado período.

Essas métricas devem apoiar decisões, e não servir apenas para produzir relatórios.

7.1.7 Riscos e plano de rollback

Todo release possui riscos.

Algumas categorias comuns:

• complexidade técnica;
• dependências externas;
• alterações em dados;
• mudanças de infraestrutura;
• problemas de desempenho;
• vulnerabilidades;
• indisponibilidade de fornecedores.

Gestão de riscos

Rollback

Rollback é a estratégia utilizada para retornar o sistema a uma condição anterior quando os critérios definidos indicam que o release não deve continuar.

Um bom plano de rollback deve possuir:

• critérios objetivos para acionamento;
• responsáveis claramente definidos;
• procedimento conhecido pela equipe;
• mecanismos previamente testados;
• comunicação às partes interessadas;
• preservação dos dados;
• avaliação posterior do incidente.

Migrações e reversibilidade

Alterações em dados exigem atenção especial.

Uma estratégia segura é realizar mudanças em etapas:

A remoção definitiva deve ocorrer somente depois de validada a nova estrutura e encerrado o período de risco.

7.1.8 Pipeline de release e quality gates

Um pipeline de release pode utilizar quality gates, ou pontos de controle que precisam ser aprovados antes da próxima etapa.

Exemplos:

• compilação;
• testes;
• análise de qualidade;
• análise de segurança;
• análise de dependências;
• cobertura de testes;
• validação de conformidade;
• aprovação de negócio.

Pipeline conceitual

Quality Gate

A principal ideia é:

Um release só avança quando os critérios definidos para aquela etapa são atendidos.

7.2 Auditoria leve e conformidade com a LGPD

7.2.1 Fundamentos da LGPD

A Lei Geral de Proteção de Dados Pessoais (LGPD) estabelece regras para o tratamento de dados pessoais.

Entre os principais papéis estão:

• Controlador: determina as decisões referentes ao tratamento dos dados.
• Operador: realiza o tratamento dos dados em nome do controlador.
• Encarregado: atua como canal de comunicação relacionado à proteção de dados.

Princípios da LGPD

Entre os princípios estão:

• finalidade;
• adequação;
• necessidade;
• livre acesso;
• qualidade dos dados;
• transparência;
• segurança;
• prevenção;
• não discriminação;
• responsabilização e prestação de contas.

Direitos dos titulares

A LGPD estabelece diversos direitos relacionados aos dados pessoais, incluindo:

• confirmação da existência de tratamento;
• acesso aos dados;
• correção;
• portabilidade, quando aplicável;
• anonimização, bloqueio ou eliminação em determinadas situações;
• informação sobre compartilhamentos;
• revogação do consentimento;
• oposição em determinadas hipóteses;
• revisão de determinadas decisões automatizadas.

Bases legais

O tratamento de dados deve estar fundamentado em uma base legal adequada à finalidade.

Exemplos incluem:

• consentimento;
• cumprimento de obrigação legal ou regulatória;
• execução de contrato;
• legítimo interesse;
• proteção da vida;
• tutela da saúde;
• proteção do crédito.

A escolha da base legal deve estar relacionada à finalidade específica do tratamento.

7.2.2 Privacidade e segurança no desenvolvimento ágil

A privacidade não deve ser analisada somente depois que o sistema estiver pronto.

Ela deve fazer parte do processo desde o início.

Privacy by Design

Privacidade deve ser considerada durante a concepção da funcionalidade.

Privacy by Default

As configurações padrão devem favorecer a proteção dos dados.

Integração com o fluxo ágil

A privacidade deve acompanhar todo o ciclo de vida da funcionalidade.

7.2.3 Critérios de aceite relacionados à privacidade

Os critérios de aceite devem considerar aspectos de privacidade quando houver tratamento de dados pessoais.

Exemplo conceitual:

Funcionalidade: Exportação de dados do usuário

Objetivo: permitir que o titular obtenha seus dados pessoais.

Critérios:

• usuário deve estar autenticado;
• somente dados relacionados ao titular devem ser disponibilizados;
• dados devem estar corretos e atualizados;
• dados desnecessários não devem ser incluídos;
• dados sensíveis devem receber tratamento adequado;
• a solicitação deve ser registrada para fins de rastreabilidade.

Fluxo

7.2.4 Registro de operações de tratamento e mapeamento de dados

Uma organização precisa saber:

• quais dados possui;
• por que os utiliza;
• onde estão armazenados;
• quem pode acessá-los;
• por quanto tempo são mantidos;
• com quem são compartilhados;
• qual é a base legal;
• se existe transferência internacional.

Mapa de dados

Modelo conceitual de inventário

O inventário permite visualizar o ciclo de vida do dado.

7.2.5 Bases legais e consentimento

A escolha da base legal deve ser feita de acordo com a finalidade do tratamento.

Consentimento

Quando o consentimento for a base legal adequada, ele deve ser:

• livre;
• informado;
• inequívoco;
• relacionado a uma finalidade;
• registrável;
• revogável.

Ciclo do consentimento

O registro deve permitir demonstrar quando, para qual finalidade e em qual contexto o consentimento foi obtido.

7.2.6 Segurança, retenção e descarte

A proteção de dados depende de controles técnicos e organizacionais.

Exemplos:

• criptografia;
• controle de acesso;
• autenticação;
• monitoramento;
• segregação de ambientes;
• pseudonimização;
• anonimização, quando aplicável;
• descarte seguro.

Ciclo de vida dos dados

A retenção deve estar relacionada à finalidade e às obrigações aplicáveis.

A ideia central é:

Não manter dados pessoais indefinidamente sem uma justificativa adequada.

7.2.7 Testes, dados e ambientes

Dados reais de usuários devem ser tratados com cuidado, especialmente fora do ambiente de produção.

Preferencialmente devem ser utilizados:

• dados sintéticos;
• dados anonimizados;
• dados mascarados;
• conjuntos de dados especialmente preparados para testes.

Separação dos ambientes

Observabilidade

Logs e métricas devem fornecer informações suficientes para operação e investigação sem registrar dados pessoais desnecessários.

Exemplos de informações que podem exigir tratamento:

• e-mail;
• CPF;
• telefone;
• endereço;
• identificadores pessoais;
• informações sensíveis.

7.2.8 Gestão de incidentes e notificações

Um incidente relacionado a dados pessoais exige uma resposta organizada.

Ciclo de resposta

Durante o processo devem ser avaliados:

• quais dados foram afetados;
• quantos titulares podem ter sido envolvidos;
• quais sistemas foram afetados;
• quais medidas foram tomadas;
• qual foi o impacto;
• quais comunicações são necessárias.

A organização deve avaliar, conforme o caso, as obrigações de comunicação à ANPD e aos titulares.

7.2.9 Auditoria leve: evidências e trilhas

Auditoria não precisa significar uma grande quantidade de documentos.

O objetivo de uma auditoria leve é manter evidências suficientes para demonstrar que os controles existem e são utilizados.

Evidências possíveis

• checklist de LGPD;
• registros relacionados aos direitos dos titulares;
• evidências de consentimento, quando aplicável;
• resultados de testes;
• registros de alterações;
• documentação de segurança;
• inventário de dados;
• documentação de dependências;
• registros de incidentes;
• evidências de aprovação.

Trilha de auditoria

Uma trilha de auditoria deve permitir responder perguntas como:

• Quem realizou a ação?
• Quando ocorreu?
• Qual ação foi realizada?
• Sobre qual recurso?
• Qual era a finalidade?
• Qual foi o resultado?

A retenção dessas trilhas também deve observar o princípio da necessidade.

7.2.10 Riscos e avaliações de impacto — RIPD

O Relatório de Impacto à Proteção de Dados Pessoais (RIPD) documenta uma avaliação relacionada aos riscos de determinado tratamento de dados.

Pode ser especialmente relevante em situações que apresentem riscos elevados aos titulares.

Exemplos de situações que podem demandar atenção especial:

• tratamento de dados sensíveis;
• monitoramento sistemático;
• uso de novas tecnologias;
• grandes volumes de dados;
• decisões automatizadas com impacto relevante.

Estrutura conceitual de um RIPD

Integração com o ágil

O RIPD não precisa ser tratado como uma atividade exclusivamente documental realizada no final do projeto.

Ele pode ser integrado ao discovery e revisado quando houver mudanças relevantes no tratamento.

7.3 Artefatos de release e comunicação

7.3.1 Release Notes e Changelog

Release Notes são utilizadas para comunicar uma nova versão aos usuários e demais partes interessadas.

Podem apresentar:

• novidades;
• correções;
• mudanças incompatíveis;
• alterações de segurança;
• migrações necessárias;
• funcionalidades descontinuadas;
• ações recomendadas.

Estrutura conceitual

O objetivo é permitir que o usuário entenda o que mudou e o que precisa fazer.

7.3.2 Contratos e dependências

Sistemas modernos frequentemente dependem de outros sistemas.

Exemplos:

• APIs;
• serviços de terceiros;
• provedores de infraestrutura;
• serviços de autenticação;
• serviços de comunicação;
• bancos de dados externos.

Gestão das dependências

É importante conhecer:

• responsabilidades;
• níveis de serviço;
• riscos;
• disponibilidade;
• dependências;
• condições de mudança;
• tratamento de dados pessoais.

Quando terceiros tratam dados pessoais, também devem ser considerados os aspectos contratuais e de proteção de dados.

7.4 Exemplos práticos integrados

7.4.1 Rollout seguro

Imagine uma nova funcionalidade que será disponibilizada gradualmente.

Estratégia

Essa estratégia reduz o impacto potencial de problemas encontrados após a implantação.

7.4.2 Política de logging

Uma política de logging deve definir quais informações podem ser registradas e quais devem ser protegidas.

Exemplo conceitual

Princípio

7.4.3 Teste de performance e objetivo do release

Os testes de desempenho devem estar relacionados aos objetivos definidos para o release.

Exemplo:

Objetivo: melhorar o tempo de resposta de uma funcionalidade.

Fluxo

Uma métrica deve possuir uma meta clara para que possa apoiar uma decisão.

7.4.4 Validação das evidências de conformidade

As evidências de conformidade podem fazer parte dos critérios de aprovação do release.

Fluxo

7.5 Integração entre Release e LGPD

Planejamento de release e conformidade não devem ser tratados como processos independentes.

A conformidade deve fazer parte do fluxo de entrega.

Visão integrada

A principal ideia da aula é:

Qualidade, segurança e conformidade devem fazer parte do processo de entrega, e não ser verificadas somente depois que o software estiver pronto.

7.6 Checklist conceitual de Release

Antes de realizar um release, a equipe pode verificar:

Objetivo

• O objetivo do release está definido?
• Existem métricas para verificar o sucesso?

Escopo

• O escopo está priorizado?
• Os itens essenciais estão identificados?
• As dependências estão conhecidas?

Qualidade

• Os testes necessários foram realizados?
• Os critérios de aceite foram atendidos?
• O desempenho está dentro da meta?

Segurança

• As verificações de segurança foram realizadas?
• As vulnerabilidades relevantes foram tratadas?
• Os acessos estão adequadamente protegidos?

Privacidade e LGPD

• A finalidade do tratamento está documentada?
• A base legal está definida?
• A coleta é necessária?
• A retenção está definida?
• Os dados de teste estão protegidos?
• Os logs evitam dados pessoais desnecessários?

Operação

• O plano de implantação está definido?
• O rollback foi planejado?
• O monitoramento está preparado?
• As equipes de suporte foram comunicadas?

Comunicação

• Release Notes estão disponíveis?
• Mudanças relevantes foram comunicadas?
• Clientes e usuários foram informados quando necessário?

Conclusão

Planejar releases de forma ágil e disciplinada aumenta a previsibilidade, reduz riscos e facilita a entrega contínua de valor.

A integração de qualidade, segurança e conformidade aos critérios de aceite e ao pipeline transforma essas preocupações em parte natural do fluxo de desenvolvimento.

O uso de:

• métricas;
• planejamento de release;
• feature flags;
• rollout controlado;
• rollback;
• quality gates;
• inventário de dados;
• controles de privacidade;
• evidências de auditoria;

permite que a equipe tome decisões baseadas em informações e reduza riscos durante a entrega.

Na perspectiva da LGPD, o ponto central é compreender que proteção de dados não é uma etapa isolada do projeto.

Ela deve acompanhar o ciclo de vida da funcionalidade:

O objetivo é construir um fluxo no qual entrega de valor, qualidade, segurança e responsabilidade sobre os dados façam parte da mesma prática ágil.

Próxima aula

Revisões e retrospectivas baseadas em dados

• utilização de métricas para apoiar decisões;
• análise de resultados do processo;
• retrospectivas baseadas em evidências;
• inspeção e adaptação;
• identificação de melhorias;
• síntese do ciclo de desenvolvimento;
• consolidação de planejamento, execução, qualidade e operação em um fluxo de melhoria contínua.