Fluxo de Vida de uma História (B)

O que é

Ponto de vista: ESP — Especificação · documento de processo (complementa todas as histórias H*).

Define os estados e transições obrigatórias das histórias ESP desde o rascunho até implementação ou cancelamento.

Como usar

Consulte antes de alterar status no YAML de qualquer história.
Garanta evidências em 04-evidencias/ nas transições que o framework exige.
Alinhe com DOD para implementado.
Quando a implementação antecipar ou divergir da especificação aprovada, siga Desvio controlado da especificação (nota provisória, classificação de impacto e vínculos PR/commit).

Exemplo

Diagrama de estados

stateDiagram-v2
    [*] --> rascunho: criação
    rascunho --> refinado: refinamento com time
    refinado --> aprovado: aprovação pelo PO ou GTI
    aprovado --> implementado: IMP conclui + DOD atendido
    aprovado --> cancelado: descartado
    implementado --> [*]
    cancelado --> [*]

Onde se aplica

Destino	Link
Framework ESP	/framework/esp/
Índice ESP	/artefatos/esp/
IMP	/framework/imp/
Regras de validação	/artefatos/nomenclatura/regras/

Descrição de cada estado

Estado	Quem cria/move	O que deve existir
rascunho	Qualquer membro do time	Cabeçalho YAML preenchido + descrição inicial
refinado	Time + PO após sessão de refinamento	Critérios de aceite mensuráveis + dependências mapeadas
aprovado	PO ou GTI (formalmente)	Evidência de aprovação em `04-evidencias/`
implementado	IMP após entrega	DOD atendido + evidência de teste + vinculação ao commit
cancelado	PO ou GTI	Justificativa registrada no próprio artefato

Regras de transição

rascunho → refinado

Sessão de refinamento realizada (registrada em ata ou log)
Critérios de aceite revisados e aprovados pelo time
Dependências com outros artefatos identificadas

refinado → aprovado

Aprovação formal do PO ou GTI (Pull Request aprovado ou assinatura rastreável)
Evidência gerada em ESP/04-evidencias/ESP-EVD-NNNN--aprovacao-<sigla>.md
Histórias com dado pessoal: avaliação PDP realizada antes da aprovação

aprovado → implementado

DOD (Definition of Done) atendido conforme IMP/01-visao-geral/IMP-DOD-0001
Evidência de testes em IMP/04-evidencias/
Commit vinculado ao ID da história (ex.: feat: ESP-HNU-0001 — registro de solicitação)
Se existirem pendências documentais (implementação à frente da documentação oficial), o DOD só se considera atendido quando a política de pendências e a tabela de classificação de impacto em Desvio controlado da especificação forem cumpridas (resolução, reversão ou dispensa explícita pelo GTI).

Implementação com pendência documental

Quando o IMP identificar lacuna ou mudança ainda não refletida na história aprovada, o desvio deve ser controlado e rastreável, não incorporado silenciosamente como se fosse especificação oficial.

Política recomendada: manter os estados do diagrama acima e usar, no frontmatter YAML da história (opcional), um campo pendencias-documentais — lista de identificadores de notas em IMP/04-evidencias/ (ex.: IMP-EVD-0042--desvio-ESP-HNU-0001) e/ou RFC em curso. A documentação em IMP/04-evidencias/ com esse prefixo é provisória até a história ou o ADR oficial ser atualizado e a pendência removida.

Quem move o estado para implementado: o mesmo fluxo (aprovado → implementado), desde que o DOD inclua o tratamento das pendências conforme a tabela de classificação de impacto em Desvio controlado da especificação.

Norma completa: Desvio controlado da especificação.

implementado → refinado ou aprovado (retrabalho)

Ocorre quando o comportamento entregue não cumpre critérios de aceite já aprovados ou quando a política do órgão determina correção pós-aceite vinculada à mesma história — ver DOD — retrabalho e História ESP: reabertura ou nova história.
Exige registro de não-conformidade ou relatório de teste nas pastas de evidências e atualização do campo status do artefato.

aprovado → cancelado

Justificativa registrada no campo motivo-cancelamento do artefato
Artefato mantido no repositório para registro histórico (não excluir)

Checklist mínimo da unidade de entrega

Uma história ESP que percorre o fluxo até implementado deve cobrir, de forma rastreável, as mesmas dimensões de uma entrega completa: levantamento, especificação, implementação, testes, documentação e preparação para produção. O quadro abixo liga cada dimensão aos pontos de vista e artefatos já previstos no SinergIA (proporcionalidade ao modo de atuação do SIS).

Dimensão	Onde se materializa	Artefatos / referências típicos
Levantamento	SIS + contexto da demanda	LKP, BRM, ASR quando o modo exigir
Especificação	ESP	História `H*` com critérios de aceite; visão BRD/PRD em `ESP/01-visao-geral/` quando aplicável
Implementação	IMP	Código, TDD, API quando couber; vínculo commit ↔ ID da história (abaixo)
Testes	IMP	DOD, TDD (inclui estratégia e modelos em `IMP/06-modelos/`), evidências em `IMP/04-evidencias/`
Documentação	IMP + SIS	CHG, atualização de artefatos SIS afetados conforme fluxos por tipo de demanda
Preparação para produção	INF + IMP	Requisitos de pipeline na INF — CI/CD; execução e gates na IMP — CI/CD

A classificação da demanda (tipos de demanda) orienta qual fluxo SIS dispara primeiro; a história ESP permanece a unidade rastreável de aceite no ESP.

Rastreabilidade no commit

Toda implementação de história deve conter o ID no commit:

git commit -m "feat: ESP-HNU-0001 — implementa registro de solicitação de serviço"

Isso permite rastrear automaticamente qual commit implementou qual história — base para o dossiê automatizado gerado pelo Artefato Orquestrador.

← HI · IMP →