No Scrum / Agile, como fornecer um mecanismo de validação / regras de forma incremental?

Digamos que você tenha um mecanismo de validação que precise cobrir 100 regras para ser útil.

Vamos supor também que a equipe possa entregar apenas cerca de 10 regras por iteração.

Como você faria um "incremento de produto potencialmente liberável" até o final da primeira iteração, quando o mecanismo de regras ainda estaria faltando 90 das regras principais?

Você poderia, por exemplo, adicionar uma falha / aviso temporário que sempre é acionado com base no fato de que nem todas as regras foram implementadas?

Editar para o contexto: estou desenvolvendo middleware para um processo de negócios complexo com muitos casos de uso herdados, destinados a replicar e substituir um grande monólito. É um desafio entrar no ar sem uma cobertura de 100%, pois temos capacidade limitada para decidir ou restringir quais casos de uso complicados aparecerão na produção solicitando manutenção.

Como você faria um "incremento de produto potencialmente liberável" até o final da primeira iteração, quando o mecanismo de regras ainda estaria faltando 90 das regras principais?

Você libera os dez primeiros no primeiro sprint. Só porque é "potencialmente liberável" não significa que deve ser utilizável pelo cliente. Significa apenas que funcionalidade existe, foi testada e se comporta conforme projetado, e não causa nenhuma regressão no produto.

Pense em "potencialmente liberável" como "não temos mais trabalho a fazer para esse recurso. O código está pronto e foi devidamente testado e documentado".

Você poderia, por exemplo, adicionar uma falha / aviso temporário que sempre é acionado com base no fato de que nem todas as regras foram implementadas?

Definitivamente, isso é algo que você deve considerar se quiser que o cliente realmente teste o recurso.

No Guia Scrum, a definição de um Incremento diz :

No final de um Sprint, o novo incremento deve ser "Concluído", o que significa que deve estar em condições de uso e atender à definição de "Concluído" da equipe Scrum. Ele deve estar em condições úteis, independentemente de o Dono do produto decidir realmente liberá-lo.

Se você não tiver regras suficientes concluídas, é provável que o Dono do produto opte por não realmente liberá-lo. No entanto, o incremento deve ser "Concluído". Qualquer regra que você já tenha implementado deve ter sido concluída de acordo com a Definição de Concluído da sua equipe.

As decisões que você toma dependem do que será feito com o incremento. Na sua pergunta, você menciona a possibilidade de lançar exceções para regras não implementadas. Isso pode funcionar, mas se alguém estiver se integrando ao seu mecanismo de regras, isso poderá gerar uma sobrecarga para que ele lide com esse caso de erro, especialmente se ele não existir em um produto acabado. Ou talvez seja o que facilitaria a vida deles. Considere qual é a intenção do incremento, quem pode estar usando e vá a partir daí.

Você definiu uma situação sem escapatória.

Tenho certeza de que existem situações da vida real em que você tem um bloco de funcionalidades complicadas que não podem ser divididas. Mas o caso usual é que você pode dividir um requisito em sub-requisitos, os quais têm algum benefício em si.

Digamos, por exemplo, que minha exigência é validar endereços de cobrança de cartão de crédito no Reino Unido. Isso é bastante complicado, queremos garantir, da melhor maneira possível, que o endereço seja o endereço residencial da pessoa nomeada no cartão, para que, se o pagamento for padrão, possamos persegui-lo.

Há potencialmente centenas de validações e verificações que podemos fazer para melhorar a confiabilidade da verificação, mas cada uma individualmente é testável e oferece uma redução real no risco de fraude.

• o endereço tem um número da casa e um código postal
• código postal é formato válido
• pesquisa de código postal com API externa é bem-sucedida
• código postal é um código postal geográfico
• endereço é validado com fornecedor de cartão de crédito etc etc

Se a pressão surgisse, o cliente seria capaz de ganhar dinheiro com apenas um subconjunto das regras implementadas. O risco extra pode ser aceito ou soluções alternativas manuais podem ser adicionadas ao fluxo de trabalho para atenuar a situação.

Metodologias Scrum e ágeis são projetadas com isso em mente. Eles tentam evitar a falha de todo o projeto, garantindo que alguns requisitos ausentes não façam com que toda a solução seja inútil.

Mas eles não podem mudar a realidade, se você tiver um foguete espacial que definitivamente precisa de X, Y e Z para voar. Então você precisa dos três!

O truque é reconhecer que, geralmente, na linha de aplicativos de negócios, esse não é o caso, apesar do que o cliente possa dizer.