Camada 6 — Artefatos, gates, organização e KPIs (S)

Camada 6 — Desenvolvimento da solução

Executa a construção do sistema com apoio de ferramentas de especificação, prototipação, codificação, teste, qualidade, segurança, entrega e sustentação.

Exemplos de artefatos obrigatórios

BRD — Business Requirements Document

Contexto: problema, stakeholders, drivers de negócio.
Objetivos mensuráveis: KPIs e métricas de sucesso.
Restrições regulatórias, de prazo e orçamento.
Aprovações: PO, sponsor e GTI.

SRS — Software Requirements Specification

Histórias em formato BDD: “Como papel, quero ação para benefício”.
Critérios de aceite em cenários Given/When/Then.
Requisitos não funcionais: desempenho, segurança, acessibilidade.
Rastreabilidade: cada requisito tem ID único (REQ-001, REQ-002, etc.).
Aprovação: Analista + PO (baseline).

ADR — Architecture Decision Record

Decisão: qual foi a escolha (por exemplo, “usar PostgreSQL como banco principal”).
Contexto: por que essa decisão era necessária.
Alternativas consideradas: trade-offs.
Consequências positivas e negativas.
Autor, status (Aceita/Reconsiderada/Supersedida) e data registrados pelo controle de versão do artefato.

Para o artefato canônico, ver ADR — Architecture Decision Record.

OpenAPI / AsyncAPI Spec

Contratos de APIs: endpoints, request/response e códigos de status.
JSON Schema para estruturas de dados.
Exemplos funcionais.
Indicação clara de qual versão da API está em produção.

Matriz de rastreabilidade

REQ-001 → código no commit XYZ → teste TEST-001 → resultado (PASSOU/FALHOU)

Cada requisito deve ter evidência de que foi testado, e cada teste deve ser rastreável a um requisito.

Post-mortem de incidentes

Incidente: o que aconteceu.
Causa raiz: por que aconteceu (rastreável a spec violada ou ausente).
Ações corretivas: o que será feito para evitar.
Atualização de specs: se necessário, qual história entra no backlog.

Checklists de gates

Gate de baseline de requisitos

Cada história tem ID rastreável.
Critérios de aceite em formato Gherkin (Given/When/Then).
Sem ambiguidade identificada.
Assinado pelo PO e validado pelo Analista.
Requisitos de segurança e conformidade vinculados.

Gate de arquitetura

Cada decisão relevante tem ADR assinado.
OpenAPI/AsyncAPI specs versionadas e validadas.
Diagrama C4 (ou equivalente) completo.
Threat modeling realizado e riscos mitigados.
Aderência a padrões da instituição.

Gate de implementação (PR)

CI/CD verde: build, testes e SAST.
Cobertura de testes adequada à criticidade (em projetos com requisitos formais, o usual é meta ≥ 80%).
Rastreabilidade: commit vinculado a ID de requisito.
Tech Lead aprova com justificativa.
Sem código legado não justificado ou marcado como deprecated.

Gate de qualidade

Cenários BDD executados e passando.
DAST e teste de segurança concluídos.
Teste de acessibilidade (WCAG 2.1) aprovado.
Matriz de rastreabilidade preenchida.
QA assina off.

Gate de aceite (UAT)

Cenários BDD validados por usuários-chave.
Ata de aceite assinada pelo PO.
Sem issues críticas pendentes.

Gate de deploy

Contract tests passando.
Plano de rollback validado.
Aprovação de CAB ou board de mudança.
Runbook atualizado e testado.

Organização em fábrica de software

Estrutura recomendada

Squads multidisciplinares: 1 PO + 1 Arquiteto (compartilhado) + 3–4 desenvolvedores + 1 QA + suporte de DevOps.
Cerimônias: Daily (15 min), Sprint Planning (~4 h), Sprint Review (~2 h), Retrospectiva (~1,5 h).
Sprints de duas semanas como padrão para médio porte.
Backlog refinement: cerca de 1 h/semana com PO e Tech Lead.

Práticas críticas

Code review: todo PR deve ter ao menos uma aprovação de Tech Lead antes do merge.
Pair programming: para técnicas complexas e onboarding de devs novos.
TDD: testes escritos antes do código.
Definition of Done (DoD): lista de critérios que cada história precisa satisfazer — ver DOD.
Documentação como código: tudo em Markdown no Git, rastreável.

Escalações e riscos

Tech Lead → Arquiteto: decisões arquiteturais e trade-offs complexos.
Arquiteto → CTO/Comitê: riscos de negócio e conformidade regulatória.
QA → Tech Lead: bugs que escapam e padrões de falha.
PO → Sponsor: scope creep e requisitos conflitantes.

Métricas e KPIs de sucesso

Os valores baseline e target abaixo são referências de mercado e devem ser calibrados ao seu contexto antes de virar meta contratual. Ferramentas são exemplos e podem ser substituídas.

Métrica	Baseline típico	Target sugerido	Ferramenta de exemplo
Cobertura de testes	60–70%	≥ 80%	SonarQube / Codecov
Bugs em produção	Alto sem boas práticas	Tendência decrescente release a release	Jira / observabilidade
Tempo de deploy	2–4 horas	Tendência a < 30 min	Logs do CI/CD
Disponibilidade (SLA)	95–97%	≥ 99,5% (ajustar ao contrato)	Monitoração / health checks
Rastreabilidade	Manual / parcial	Automatizada e auditável	Matriz de rastreabilidade
Taxa de erros	Alta sem observabilidade adequada	Tendência a < 1%	Observabilidade

Anterior: Roteiro, ferramentas e timeline · Voltar para: Visão geral do Modelo 2