Agência de software · Entrega
Entrega de software e aceite do cliente
Leve cada marco dos requisitos acordados até um aceite do cliente que fica registrado. O cliente confirma os critérios de aceite e dá o aceite por um link público, e nenhuma versão chega a ele antes de o QA e o líder de engenharia aprovarem.
- Duração: 4 a 8 semanas
- Frequência: Para cada marco
- Etapas: 11 etapas
- Agentes de IA: 2 agentes de IA
- Aprovações: 3 aprovações
Plano gratuito, sem cartão de crédito.
O que muda com este modelo
Sem o modelo
O cliente se lembra de uma funcionalidade indispensável na demo do sprint.
Uma versão testada pela metade chega à homologação na véspera da demo.
O aceite é um joinha em uma call que ninguém encontra um mês depois.
O QA escreve cada plano de testes do zero.
Com o modelo
O cliente confirma os critérios de aceite antes do desenvolvimento, e a equipe trabalha com uma única lista.
Os testes do cliente ficam travados até o QA e o líder de engenharia aprovarem a versão.
O cliente dá o aceite na execução, com as verificações marcadas, o nome e o horário.
Um agente de IA escreve o plano com base nos critérios, e o engenheiro de QA revisa.
O modelo, etapa por etapa
Cada etapa diz quem a faz: alguém da sua equipe, um agente de IA ou o cliente por um link público. Uma aprovação mantém todas as etapas seguintes travadas até ser dada.
- Feito pela sua equipe
- Feito por um agente de IA
- Feito pelo cliente, por um link público
Começa quando
Um marco do escopo de trabalho está pronto para começar. O gerente de produto inicia uma execução com o nome do cliente e o marco.
- 1
Escrever o escopo e os critérios de aceite
Semana 1Gerente de produto · Equipe
Transforme o marco do escopo de trabalho em histórias de usuário com critérios de aceite testáveis, anote as perguntas que o cliente ainda precisa responder e mande tudo por e-mail, com os designs, ao product owner do cliente.
Checklist
- Cada história tem critérios de aceite
- O que fica fora do escopo está anotado
- Critérios e designs enviados ao cliente
Campos a preencher
- Marco (obrigatório)
- Critérios de aceite (obrigatório)
- Perguntas para o cliente
- Link para os designs (obrigatório)
- 2
O cliente confirma os requisitos
Semana 1Product owner do cliente · Link público
O product owner do cliente lê os critérios de aceite, os designs e as perguntas que o gerente de produto enviou, e depois responde às perguntas e confirma o escopo pelo link público. A equipe desenvolve e testa com base no que for confirmado aqui.
Checklist
- Critérios de aceite lidos
- Designs revisados
- Perguntas em aberto respondidas
Campos a preencher
- Respostas às perguntas em aberto
- Link para regras de negócio ou exemplos
- Confirmo os critérios de aceite (obrigatório)
- 3
Escrever o plano de testes
Semana 1Redator de planos de teste · Agente de IA
O redator de planos de teste transforma cada critério de aceite confirmado em casos de teste com passos e resultados esperados, e inclui verificações de regressão para as funcionalidades que o marco afeta.
Campos a preencher
- Rascunho do plano de testes (obrigatório)
Revisão humana: O engenheiro de QA revisa e completa o plano de testes na etapa 4.
- 4
Revisar o plano de testes
Oculto no link públicoSemana 2Engenheiro de QA · Equipe
Confira se cada critério de aceite tem um caso de teste, inclua os casos-limite que faltam no rascunho e coloque o link do plano de testes final.
Checklist
- Cada critério tem um caso de teste
- Casos-limite incluídos
- Dados de teste prontos em homologação
Campos a preencher
- Link para o plano de testes final (obrigatório)
- 5
Desenvolver e revisar em sprints
Semanas 2 a 5Líder de engenharia · Equipe
Desenvolva as histórias em sprints e revise cada alteração antes do merge. Se a equipe estiver esperando uma resposta do cliente, marque a execução como bloqueada e anote a pergunta.
Checklist
- Cada alteração revisada antes do merge
- Demos de sprint feitas com o cliente
- Nenhuma pergunta em aberto para o cliente
Campos a preencher
- Data prevista da versão (obrigatório)
- Notas dos sprints (obrigatório)
- Link para o código já mesclado (obrigatório)
- O que a equipe está esperando
- 6
Testar em homologação cada critério
Oculto no link públicoSemana 6Engenheiro de QA · Equipe
Rode o plano de testes em homologação, registre os defeitos na ferramenta de tickets e teste de novo as correções até não restar nenhum bug crítico ou grave em aberto.
Checklist
- Cada critério testado
- Testes de regressão rodados
- Nenhum bug crítico ou grave em aberto
- Problemas menores conhecidos anotados
Campos a preencher
- Link para o relatório de testes (obrigatório)
- Problemas conhecidos
Aprovação: A aprovação da versão fica travada até o engenheiro de QA aprovar os resultados dos testes.
- 7
Escrever as notas da versão
Semana 6Redator de notas da versão · Agente de IA
O redator de notas da versão escreve para o cliente as notas com base nos critérios de aceite, nas notas dos sprints e nos problemas conhecidos: o que é novo, o que mudou e o que ainda está em aberto.
Campos a preencher
- Rascunho das notas da versão (obrigatório)
Revisão humana: O líder de engenharia corrige as notas e aprova a versão na etapa 8.
- 8
Aprovar a versão para os testes do cliente
Semana 6Líder de engenharia · Equipe
Leia o relatório de testes, corrija as notas da versão e confira se a homologação roda a versão testada. Depois aprove e mande por e-mail ao product owner do cliente o link de homologação e as notas da versão.
Checklist
- Relatório de testes lido
- Notas da versão corrigidas
- A homologação roda a versão testada
Campos a preencher
- Link de homologação enviado ao cliente (obrigatório)
Aprovação: Os testes do cliente ficam travados até o líder de engenharia aprovar a versão.
- 9
O cliente testa em homologação e dá o aceite
Semana 7Product owner do cliente · Link público
O product owner do cliente testa a versão em homologação, com o link que a equipe enviou, com base nos critérios de aceite, e depois marca cada verificação e registra a decisão pelo link público. Os problemas vão no campo abaixo, com links para capturas de tela ou gravações.
Checklist
- Cada critério de aceite testado
- Notas da versão lidas
Campos a preencher
- Decisão (obrigatório)
- Problemas encontrados
- Links para capturas de tela ou gravações
- 10
Decidir sobre os achados do cliente
Semana 7Gerente de produto · Equipe
Repasse a decisão e cada achado com o líder de engenharia. Se um achado impedir o aceite, marque a execução como bloqueada com o motivo até a correção ser verificada e o cliente concordar, e depois aprove a publicação em produção.
Checklist
- Cada achado classificado como bloqueante ou não
- Achados bloqueantes corrigidos e verificados
- Demais achados planejados para um marco seguinte
Campos a preencher
- Achados movidos para um marco seguinte
Aprovação: A publicação em produção fica travada até o gerente de produto aprovar.
- 11
Publicar em produção e encerrar o marco
Semana 7Engenheiro de DevOps · Equipe
Publique a versão aceita com o plano de reversão pronto, rode os testes de fumaça e registre a versão publicada.
Checklist
- Plano de reversão pronto
- Testes de fumaça aprovados
- Monitoramento conferido após a publicação
Campos a preencher
- Versão publicada (obrigatório)
- Publicada em (obrigatório)
Termina quando
O cliente deu o aceite no marco com base nos critérios acordados, e a versão está em produção com o relatório de testes, as aprovações e o aceite na execução.
Deixe do seu jeito. Renomeie etapas, troque responsáveis e adicione itens de checklist, campos ou aprovações. O modelo é um ponto de partida para o jeito de trabalhar da sua equipe.
Os agentes de IA deste modelo
Um agente só trabalha nas próprias etapas, e alguém da sua equipe confere o que ele fez. Tudo o que um agente grava em um app conectado aguarda aprovação, a menos que você permita.
Redator de planos de teste
Transforma os critérios de aceite confirmados em um rascunho de plano de testes.
O que ele faz
- Lê os critérios de aceite e as respostas do cliente na execução
- Escreve casos de teste com passos e resultados esperados
- Inclui verificações de regressão para as funcionalidades que o marco afeta
- Conclui a sua etapa para o engenheiro de QA revisar
Revisão humana: O engenheiro de QA revisa e completa o plano de testes na etapa 4.
Redator de notas da versão
Escreve para o cliente as notas da versão que vai para os testes de aceite.
O que ele faz
- Lê os critérios de aceite, as notas dos sprints e os problemas conhecidos
- Escreve o que é novo, o que mudou e o que ainda está em aberto
- Usa uma linguagem clara para o cliente
- Conclui a sua etapa para a aprovação da versão começar
Revisão humana: O líder de engenharia corrige as notas e aprova a versão na etapa 8.
Perguntas que este modelo responde
Peça o aceite com base nos critérios que o cliente confirmou no início, e não em uma demo. Na etapa 9 o product owner do cliente testa em homologação, depois marca cada verificação e registra a decisão pelo link público, com nome e horário na execução.
Combine critérios de aceite testáveis antes de o desenvolvimento começar, e faça o cliente confirmá-los por escrito. Na etapa 2 o product owner do cliente responde às perguntas em aberto e confirma os critérios pelo link público, e a equipe desenvolve e testa com base em uma única lista acordada.
Faça os testes do cliente dependerem de resultados de teste aprovados, e não da data da demo. As etapas 6 e 8 são controles de aprovação: os testes do cliente ficam travados até o engenheiro de QA e o líder de engenharia aprovarem a versão.
Guarde os critérios de aceite, os resultados dos testes e a decisão do cliente em um único registro. A execução mostra os critérios confirmados na etapa 2, os resultados e aprovações das etapas 6 e 8, e o aceite da etapa 9 com nome e horário.
Deixe a IA escrever o plano de testes e as notas da versão a partir do que a equipe já escreveu, e mantenha a revisão com pessoas. Na etapa 3 o redator de planos de teste escreve casos de teste que o engenheiro de QA revisa na etapa 4, e na etapa 7 o redator de notas da versão escreve notas que o líder de engenharia corrige na etapa 8.
Separe os bugs que impedem o aceite dos pontos que podem esperar, e deixe uma pessoa tomar essa decisão. Na etapa 10 o gerente de produto classifica cada achado como bloqueante ou não, mantém a execução bloqueada até as correções bloqueantes serem verificadas e só então aprova a versão.
Execute este fluxo no OKiDO
Configure as etapas, os responsáveis e as aprovações uma vez e depois inicie uma execução para cada caso novo.