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

8

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.

James Daily
fuente
¿Está construyendo el "motor de validación", o simplemente está escribiendo 100 reglas para un motor existente?
Bryan Oakley
@BryanOakley: En mi caso, es una configuración básica de hoja de cálculo de Drools, donde cada historia ágil agregaría / modificaría las definiciones de conjunto de reglas o simplemente agregaría nuevas reglas dentro de un conjunto de reglas existente.
James Daily el
deberías probar Kanban en lugar de scrum aquí ...
user666

Respuestas:

7

¿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.

Bryan Oakley
fuente
Ya veo, por lo que hay una distinción significativa entre "potencialmente liberable" y "suficiente para las necesidades del usuario" (donde el usuario puede ser un usuario de la interfaz de usuario o un cliente de servicio web con la esperanza de llamar a una API, o lo que sea)
James Daily
Me estoy dando cuenta de que mi pregunta no es realmente ágil (el concepto "Listo" responde fácilmente), sino más bien una pregunta de diseño: ¿cómo debería una API detectar y responder con gracia a escenarios no compatibles cuando proporciona versiones incrementales significativas?
James Daily
6

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í.

Thomas Owens
fuente
"pero si alguien se integrara con su motor de reglas, puede crear una sobrecarga para que pueda lidiar con este caso de error" Absolutamente cierto, pero es un mal necesario en escenarios empresariales o nunca sacaríamos nada por la puerta :)
James Daily
@JamesDaily No, no es un mal necesario. Puede mitigarlo al no lanzar una excepción que el sistema terminado no arrojaría o al devolver valores. Cualquier cosa que signifique que el otro sistema no necesita agregar código de manejo de errores solo para manejar el hecho de que su sistema aún no está terminado para poder demostrar una funcionalidad mínima.
Thomas Owens
Quizás lanzar una excepción es demasiado duro. Las advertencias suaves o incluso un indicador de validación completo vs. parcial son más sensibles y más fáciles de reaccionar para un cliente. En otro comentario, noté que mi pensamiento se está moviendo hacia: ¿cómo debería una API detectar y responder con gracia a escenarios no admitidos al proporcionar versiones incrementales significativas?
James Daily
3

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.

Ewan
fuente
Sí, podría imaginar un enfoque iterativo con advertencias informativas temporales que se devuelven cuando se sabe que la validación es incompleta para una entrada determinada. Por ejemplo, me pidió que valide su dirección de residencia local y su dirección bancaria extranjera, pero el motor tuvo que omitir la dirección extranjera ya que aún no es compatible. El PO puede decidir que no está lo suficientemente completo como para que se active, pero al menos la API está siendo honesta sobre lo que ha validado o no.
James Daily el