PDCA e método ágil são a mesma coisa?

Não são a mesma coisa, mas se encaixam bem. O ágil organiza o ritmo de entrega; o PDCA garante que cada ciclo tenha hipótese declarada e verificação de resultado. Sprint sem Check é entrega repetida, não melhoria.

Qual a diferença entre Check e teste de software?

Teste verifica se o sistema funciona como especificado. O Check verifica se o resultado esperado no negócio aconteceu. Um recurso pode passar em todos os testes e falhar no Check, porque ninguém o usou.

Quanto tempo deve durar um ciclo?

O suficiente para produzir dado observável, normalmente de duas a quatro semanas em software de operação. Ciclo curto demais não dá tempo de o efeito aparecer; longo demais atrasa o aprendizado.

PDCA aplicado a projeto de software

Aplicar PDCA a projeto de software significa tratar cada incremento como uma hipótese testável, não como um item de lista a ser entregue. Você planeja declarando o resultado esperado, constrói o menor pedaço capaz de produzir esse resultado, verifica com dado real e padroniza o que funcionou.

O ciclo, Plan, Do, Check, Act, é simples de descrever e difícil de sustentar, porque a terceira fase não produz nada visível e é sempre a primeira a ser sacrificada quando o prazo aperta.

Plan: escrever a hipótese antes de estimar

A fase de planejamento em software costuma virar "quebrar em tarefas e estimar horas". Falta o essencial: o resultado esperado, escrito em número.

Um item de planejamento completo tem quatro linhas:

Problema: o faturamento leva 3,8 dias em mediana entre o pedido aprovado e a nota emitida. Causa provável: 2,9 desses dias são espera pela conferência manual de cadastro. Hipótese: validar o cadastro na entrada do pedido reduz a espera de conferência para menos de meio dia. Como verificaremos: lead time mediano medido nos 30 primeiros pedidos após a implantação.

Repare que a solução não abre o item, ela aparece só depois do problema e da causa. Quando a conversa começa pela funcionalidade ("precisamos de uma tela de validação"), o Check fica sem referência e nenhuma decisão pode ser tomada ao final do ciclo.

É aqui que ferramentas de análise de causa se encaixam: 5 porquês e Ishikawa entram no Plan, para que a hipótese não seja um palpite disfarçado de requisito.

Do: construir pequeno e registrar o que mudou

Duas disciplinas fazem o Do funcionar:

Entregue a menor versão capaz de gerar dado. Se a hipótese é sobre validação de cadastro, valide os três campos que causam 80% das devoluções, não os 40 campos da tela. Escopo grande demais impede saber qual parte gerou o efeito.

Registre as mudanças com data. Não só o código: mudanças de processo, treinamentos, alterações de responsável. Sem esse registro, o Check vira adivinhação, porque três coisas mudaram na mesma semana e ninguém sabe qual explicou o resultado.

Uma armadilha comum é mudar o processo e o sistema ao mesmo tempo, e depois não conseguir atribuir o ganho. Quando não der para separar, tudo bem, mas registre que não deu, para não tirar a conclusão errada.

Check: a fase que todo mundo pula

Check é comparar o resultado observado com o resultado esperado declarado no Plan. Três regras tornam a fase honesta:

Use o mesmo método de medição do baseline. Mudar a definição do indicador entre antes e depois produz ganho fictício.
Espere a acomodação. As primeiras semanas registram curva de aprendizado, não o processo novo. Duas a quatro semanas de uso estável antes de medir.
Aceite o resultado negativo. Hipótese refutada é aprendizado barato. O desperdício é insistir em uma solução que não moveu o número porque já foi paga.

Um formato de fechamento que cabe em cinco linhas:

Item	Esperado	Observado	Conclusão
Lead time mediano	< 2,0 dias	2,4 dias	Parcial
Espera na conferência	< 0,5 dia	0,3 dia	Confirmado
Retrabalho de cadastro	−50%	−12%	Refutado

Nesse exemplo, a hipótese principal funcionou e a secundária não. O retrabalho não caiu porque a validação pegava formato, não conteúdo, o que gera o item do ciclo seguinte, com causa mais precisa.

Act: padronizar ou descartar, com decisão explícita

Act tem exatamente três saídas possíveis, e escolher uma é obrigatório:

Padronizar. Funcionou: vira o novo jeito oficial. Atualiza-se documento, treinamento e o desenho do processo. Sem esse passo, a melhoria depende da memória de quem participou e regride em meses.
Ajustar e repetir. Funcionou em parte: novo ciclo com hipótese corrigida.
Descartar. Não funcionou: remove-se o que foi construído ou aceita-se o custo de mantê-lo, conscientemente.

A opção mais cara é a que não está na lista: deixar como está sem decidir. É assim que sistemas acumulam funcionalidades que ninguém usa e ninguém tem coragem de remover.

O que muda quando o ciclo roda de verdade

Três efeitos aparecem depois de três ou quatro ciclos:

A conversa de escopo muda de "o que vocês querem" para "qual número queremos mover". Isso encurta reunião e elimina pedido sem justificativa.
Funcionalidade sem hipótese fica difícil de aprovar. O que é saudável: obriga quem pede a explicar o efeito esperado.
O acúmulo de aprendizados vira ativo. O registro de hipóteses testadas, inclusive as refutadas, evita que a mesma ideia volte a cada troca de gestor.

Nos projetos da Retti Tech, esse registro de ciclos fechados costuma ser mais útil que a lista de funcionalidades entregues, porque explica por que o sistema está do jeito que está.

Os três erros que esvaziam o PDCA

Ciclo sem número. Se a verificação é "a equipe achou melhor", não há Check. Percepção entra como complemento, não como prova.

Ciclo longo demais. Seis meses entre Plan e Check é tempo suficiente para o contexto mudar e a conclusão perder validade.

Ciclo sem Act. Times que medem, comentam o resultado na retrospectiva e não padronizam nada estão fazendo relatório, não melhoria.

Se você for adotar uma coisa só, adote a linha de hipótese com número no Plan e a comparação no Check. Duas frases por ciclo. O resto do método acompanha naturalmente, porque fica evidente o que fazer com o resultado.