En Scrum / Agile, ¿cómo entregar un motor de validación / reglas incrementalmente?

Digamos que tiene un motor de validación que necesita cubrir 100 reglas para ser útil.

Supongamos también que el equipo solo puede entregar unas 10 reglas por iteración.

¿Cómo harías para hacer un "incremento de producto potencialmente liberable" al final de la primera iteración, cuando el motor de reglas todavía faltaría 90 de las reglas centrales?

¿Agregaría, por ejemplo, una falla / advertencia temporal que siempre se dispara debido al hecho de que no se han implementado todas las reglas?

Editar para el contexto: estoy desarrollando middleware para un proceso empresarial complejo con muchos casos de uso heredados, destinados a replicar y reemplazar un gran monolito. Es desafiante comenzar a funcionar sin una cobertura del 100%, ya que tenemos una capacidad limitada para decidir o restringir qué casos de uso difíciles aparecerán en la producción que soliciten ser atendidos.

¿Cómo harías para hacer un "incremento de producto potencialmente liberable" al final de la primera iteración, cuando el motor de reglas todavía faltaría 90 de las reglas centrales?

Lanzas los primeros diez en el primer sprint. El hecho de que sea "potencialmente liberable" no significa que deba ser utilizado por el cliente. Simplemente significa que la funcionalidad que existe ha sido probada y se comporta según lo diseñado, y no causa ninguna regresión en el producto.

Piense en "potencialmente liberable" como "no tenemos más trabajo que hacer para esta función. El código está hecho y se ha probado y documentado correctamente".

¿Agregaría, por ejemplo, una falla / advertencia temporal que siempre se dispara debido al hecho de que no se han implementado todas las reglas?

Definitivamente es algo que quizás desee considerar, si desea que el cliente realmente pruebe la función.

De la Guía Scrum, la definición de un Incremento dice :

Al final de un Sprint, el nuevo Incremento debe estar "Listo", lo que significa que debe estar en condiciones de uso y cumplir con la definición del Equipo Scrum de "Listo". Debe estar en condiciones de uso, independientemente de si el propietario del producto decide liberarlo.

Si no tiene suficientes reglas completadas, es probable que el propietario del producto elija no publicarlo. Sin embargo, el Incremento debe estar "Hecho". Cualquier regla que ya haya implementado debería haberse completado según la Definición de hecho de su equipo.

Las decisiones que tome dependerán de lo que se haga con el Incremento. En su pregunta, menciona excepciones de lanzamiento para reglas no implementadas. Esto podría funcionar, pero si alguien se integrara con su motor de reglas, puede crear una sobrecarga para que pueda lidiar con este caso de error, especialmente si no existe en un producto terminado. O tal vez es lo que les facilitaría la vida. Considere cuál es la intención del Incremento, quién puede estar usándolo, y vaya desde allí.

Has definido una situación sin escapatoria.

Estoy seguro de que hay situaciones de la vida real en las que tienes un bloque de funcionalidad complicada que no se puede dividir. Pero el caso habitual es que puede dividir un requisito en requisitos secundarios que sí tienen algún beneficio.

Digamos, por ejemplo, que mi requisito es validar las direcciones de facturación de tarjetas de crédito del Reino Unido. Esto es bastante complicado, queremos asegurarnos lo mejor posible de que la dirección sea la dirección residencial de la persona nombrada en la tarjeta para que, si no cumplen con el pago, podamos perseguirla.

Hay potencialmente cientos de validaciones y verificaciones que podemos hacer para mejorar la confiabilidad de la verificación, pero cada una de ellas individualmente es comprobable y ofrece una disminución real en el riesgo de fraude.

• la dirección tiene un número de casa y un código postal
• el código postal es un formato válido
• La búsqueda de código postal con API externa tiene éxito
• código postal es un código postal geográfico
• la dirección se valida con el proveedor de la tarjeta de crédito, etc.

Si llegara el momento, el cliente podría ganar dinero con solo un subconjunto de las reglas implementadas. Se podría aceptar el riesgo adicional o se podrían agregar soluciones manuales al flujo de trabajo para mitigar la situación.

Las metodologías Scrum y ágil están diseñadas teniendo esto en cuenta. Intentan evitar el fracaso de todo el proyecto asegurándose de que algunos requisitos faltantes no causen que toda la solución sea inútil.

Pero no pueden cambiar la realidad, si tienes un cohete espacial que definitivamente necesita X, Y y Z para volar. ¡Entonces necesitas los tres!

El truco es reconocer que, en general, en línea de aplicaciones comerciales, este no es el caso, a pesar de lo que el cliente pueda decir.