Processo de Desenvolvimento e Entrega (Kanban)¶
Documento de Referência de Processo¶
Versão: 1.0 Escopo: Define o processo de desenvolvimento, acompanhamento e entrega do trabalho técnico, executado a partir dos artefatos já gerados pelos processos de Engenharia de Requisitos e de Arquitetura de Software, até a composição de um MVP.
1. Objetivo¶
Este documento define o fluxo de trabalho (Kanban) e a estratégia para transformar os artefatos de requisitos já documentados (User Stories e Tasks) em itens de trabalho, permitindo evolução incremental e contínua do software até o alcance do MVP (Minimum Viable Product).
Este processo não substitui nem duplica os artefatos das fases anteriores — ele consome User Stories (US-000) e Tasks (TASK-000) já especificadas em 05-User-Stories.md e 06-Tasks.md e as conduz através de um fluxo visual de trabalho até a entrega.
2. Visão Geral do Pipeline¶
flowchart LR
A[(Backlog)] -.->|priorização| B[A Fazer]
B --> C[Em Desenvolvimento]
C --> D[Em Revisão/Teste]
D --> E[Pronto para Deploy]
E --> F[Concluído]Cada fase consome a saída da fase anterior. As Fases formam um ciclo contínuo, este processo se repete continuamente enquanto houver itens no Backlog.
3. Fluxo Kanban¶
3.1 Repositório de Entrada (Backlog)¶
O Backlog não é uma coluna de fluxo, mas o repositório onde todos os itens identificados residem antes de serem priorizados. Um item entra no Backlog ao ser definido na Fase 1, e sai dele para o Kanban ao ser priorizado (MoSCoW) e ter suas dependências resolvidas.
3.2 Colunas do quadro¶
| Coluna | Objetivo | Critério de entrada | Critério de saída |
|---|---|---|---|
| A Fazer | Fila de trabalho pronta para ser iniciada | Critérios de aceitação claros e sem bloqueios | Puxado por capacidade disponível (respeitando WIP) |
| Em Desenvolvimento | Implementação ativa do item | Item puxado da coluna “A Fazer” | Código implementado e critérios de aceitação atendidos |
| Em Revisão/Teste | Verificação de qualidade (revisão de código e execução de Casos de Teste) | Implementação concluída | Casos de Teste (TC-000) executados e aprovados |
| Pronto para Deploy | Aguardando janela/consolidação de entrega | Aprovado em revisão/teste | Integrado ao ambiente de destino |
| Concluído | Item finalizado e disponível | Deploy realizado | — (fim do fluxo para este item) |
3.2 Limite de Trabalho em Progresso (WIP)¶
Cada coluna intermediária (“A Fazer”, “Em Desenvolvimento”, “Em Revisão/Teste”) deve ter um limite explícito de itens simultâneos, evitando acúmulo e priorizando o fluxo contínuo sobre o início de novas frentes.
3.3 Sistema de puxada (Pull System)¶
Um item só avança de coluna quando há capacidade disponível na coluna seguinte — nunca é empurrado. A priorização segue a classificação MoSCoW já definida no processo de ER: itens Must são puxados antes de itens Should, Could ou Won’t.
4. Composição do MVP¶
4.1 Princípio¶
O MVP é atingido incrementalmente: cada item concluído soma-se ao produto, até que o conjunto de itens classificados como Must (MoSCoW) esteja integrado e funcional de ponta a ponta.
4.2 Regra de composição¶
Itens Should e Could continuam fluindo pelo Kanban após o MVP, compondo incrementos subsequentes do produto.
4.3 Resultado¶
Produto em estado utilizável, correspondente ao subconjunto de funcionalidades essenciais já entregues.
5. Plano de Implementação¶
O Plano de Implementação e uma análise de dependências técnicas aplicada sobre os as User Story e Task, para garantir que nenhuma User Story ou Task entre em desenvolvimento antes que os pré-requisitos dos quais ela depende funcionalmente já estejam concluídos e integrados.
Cada US-000 / TASK-000 referenciada passa a registrar um campo Status, refletindo a coluna atual no quadro Kanban:
6. Definition of Ready (DoR) e Definition of Done (DoD)¶
6.1 Definition of Ready (para entrar em “A Fazer”)¶
- Item decomposto conforme critérios da seção 3.2;
- Critério de aceitação claro e verificável;
- Sem dependências bloqueantes pendentes.
6.2 Definition of Done (para entrar em “Concluído”)¶
- Código implementado e integrado;
- Casos de Teste relacionados executados e aprovados;
- Deploy realizado no ambiente de destino;
- Critério de aceitação do item atendido integralmente.
7. Fluxograma Resumido do Processo Completo¶
1. Selecionar US/Task já documentada (processo de ER)
↓
2. Priorizar no Backlog (MoSCoW: Must primeiro)
↓
3. Puxar para "A Fazer" conforme capacidade (WIP)
↓
4. Desenvolver o item
↓
5. Revisar código e executar Casos de Teste
↓
6. Aprovar para Deploy
↓
7. Realizar Deploy
↓
8. Marcar como Concluído
↓
9. Consolidar itens "Must" concluídos → MVP
↓
10. Continuar fluxo com itens "Should"/"Could" → incrementos pós-MVP