Los criterios de aceptación para redactar los criterios de aceptación

Los criterios de aceptación para redactar los criterios de aceptación

Muchos equipos de desarrollo están demasiado familiarizados con las frustraciones de los criterios de aceptación insatisfactorios o incluso con la falta de criterios en sí. No definir requisitos es como prepararse para la batalla sin un plan de acción: el equipo ha dado más pasos hacia el fracaso que hacia el éxito. Ofrezco sugerencias específicas en la elaboración de criterios de aceptación que pueden mejorar cualquier proceso ágil.

Primero, definamos rápidamente los criterios de aceptación.

Los criterios de aceptación son las "condiciones que un producto de software debe cumplir para ser aceptado por un usuario, cliente u otras partes interesadas". (Microsoft Press)

Bastante fácil, ¿verdad? No exactamente. En este punto, me preguntaría si aquí es donde termina mi definición de criterios de aceptación. Además de la definición anterior, cualquier propietario de producto debe tener respuestas listas para las siguientes preguntas:

¿Cómo se ven estas condiciones? ¿Quién crea estas condiciones? ¿Cuántas condiciones debería haber? ¿Cómo se miden los resultados?

Generalmente, los criterios de aceptación los inicia el propietario del producto o la parte interesada. Están escritos antes de cualquier desarrollo de la función. Su función es proporcionar pautas para una perspectiva empresarial o centrada en el usuario.

Sin embargo, redactar los criterios no es responsabilidad exclusiva del propietario del producto. Los criterios de aceptación deben desarrollarse como un esfuerzo conjunto entre el equipo de desarrollo y el propietario del producto.

La elaboración conjunta de estos criterios ayuda al equipo de desarrollo a comprender el deseo presentado. También ayuda al propietario del producto a detectar los detalles que faltan. Además, el propietario obtiene una mejor comprensión de la viabilidad, la complejidad y el alcance.

Formato de los criterios de aceptación

Los criterios se pueden escribir en una variedad de formatos. La mayoría de los equipos se inclinan hacia dos tipos específicos: orientados a reglas u orientados a escenarios .

Los requisitos orientados a las reglas son sencillos. Enumeran los resultados observables. "Mostrar el saldo del extracto tras la autenticación correcta".

Por otro lado, los criterios orientados a escenarios tienden a seguir la plantilla "Dado ... Cuando ... Entonces ...". Esto se derivó del desarrollo impulsado por el comportamiento (BDD). Este requisito describe el resultado observable esperado. Esto ocurre cuando se ejecuta una acción en particular dado algún contexto.

3 características de los criterios de aceptación efectivos

1. Comprobable con resultados de aprobado / reprobado claramente definidos

Tener criterios comprobables. Esto permite a los evaluadores confirmar correctamente que se han cumplido todas las condiciones deseadas. Si los criterios no fueran probables, no habría forma de verificación. Estos criterios deben cumplirse o no cumplirse. Un desarrollador debe conocer el punto en el que se ha logrado el criterio. Cualquier ambigüedad puede prolongar el esfuerzo en la historia.

Por ejemplo, un criterio de aceptación establece "aumentar el número de entradas disponibles en un menú desplegable". El desarrollador no tendría idea de cuántas entradas nuevas agregar y puede tomarse la libertad de asumir un número basado en su experiencia con el producto. Asimismo, un probador manual puede tomarse la misma libertad y asumir una definición diferente de aumento. Esto da como resultado una confusión que volverá al propietario del producto.

2. Sin ambigüedades y concisas

Aquí es donde los criterios de aceptación de la escritura se convierten en un arte. Los ensayos académicos enfatizan la importancia de la claridad y la concisión. Del mismo modo, la redacción de los criterios de aceptación exige el mismo nivel de organización y atención.

Al igual que cuando se escribe una pieza literaria, se debe tener en cuenta a la audiencia. Quienes lean los criterios de aceptación deben comprender lo que está escrito. De lo contrario, esas palabras son completamente inútiles. Si son prolijos y están llenos de jerga, es posible que los puntos principales de las condiciones descritas no se expresen. Muchas personas pueden pasar por alto detalles esenciales en un mar de palabras cuando tienen poco tiempo. Incluso cuando no está presionado por el tiempo, muchas personas pueden fácilmente pasar por alto los borrones largos.

En lugar de echarle la culpa a la falta de lectura cuidadosa de los demás, uno puede presentar de manera proactiva criterios de aceptación que sean fáciles de leer, directos al grano y desprovistos de detalles superfluos.

3. Establecer un entendimiento compartido

Esta es probablemente la característica más importante y la que más se da por sentada. Si todos los miembros del equipo no están en la misma página, el proceso y la productividad se verán comprometidos. Hacer que el equipo de desarrollo revise los criterios de aceptación antes de seguir adelante con la historia minimiza la confusión. Deben hacerse aclaraciones sobre los criterios y los criterios deben actualizarse en consecuencia.

He tenido experiencias en las que todos los miembros del equipo han sido parte de la redacción de los criterios de aceptación. Permitió que todos entendieran todas las partes de la historia. También brindó oportunidades para que los miembros del equipo participaran con preguntas e ideas. Sin embargo, este proceso puede no ser siempre ideal, especialmente para equipos más grandes.

Sin embargo, es importante que cada miembro pueda leer los criterios de aceptación. A partir de ahí, cada miembro debe comprender cómo completar la historia. Independientemente de si está en desarrollo o en pruebas.

Cuando demasiado es un problema

Ya hemos explorado el peligro de los criterios de aceptación poco claros. Esto da como resultado el riesgo de introducir características extrañas en una historia. Sin embargo, también puede existir el caso contrario sorprendente: los criterios de aceptación pueden llegar a ser demasiado detallados.

"Los criterios de aceptación deben indicar la intención, no una solución" ( Segue Technologies )

Proporcione un plano de "qué" (intención) en lugar de "cómo" (implementación). De lo contrario, es posible que el equipo de desarrollo no tenga la oportunidad de explorar diferentes formas de resolver el problema. En ese sentido, se pueden pensar mejores implementaciones después de las ideas iniciales sobre una solución.

Una vez que haya escrito sus criterios de aceptación, puede preguntarse: "¿Cuántos son demasiados?"

He visto historias que van desde criterios de aceptación cero hasta más de quince (o al menos así se sentía).

Como regla general, personalmente me gusta ver de tres a ocho criterios de aceptación por historia. Sin embargo, hacia el extremo superior de ese límite, alrededor de cinco o más criterios de aceptación, verificaría la manejabilidad. Verificaría cuidadosamente para ver que la historia no se pudiera dividir en historias más pequeñas y manejables.

Otros estarían en desacuerdo y argumentarían que ocho ya serían demasiados. Sin embargo, me gusta inclinarme hacia proporcionar tantos detalles de "qué" como pueda sin sacrificar la concisión.

¿Ahora que?

Ok, mentí. No proporcioné una lista exhaustiva de los criterios de aceptación para escribir los criterios de aceptación. Las características deseadas como la concisión, la claridad y la comprensión son subjetivas. Tenía la intención de que lo fueran.

Creo que no existe un formato "correcto" para escribir los criterios de aceptación. Su corrección se mide por la efectividad en el equipo de uno.

Recomiendo encarecidamente utilizar inicialmente una plantilla. Han proporcionado a muchos equipos una estructura sólida y segura que promueve una buena redacción de criterios de aceptación. Sin embargo, no permita que esa estructura le impida avanzar hacia ideas que puedan promover la eficiencia y la eficacia.

Si usted es propietario de un producto o cliente que escribe criterios de aceptación, lo desafío a que solicite a su equipo de desarrollo comentarios sobre los criterios de aceptación actuales. Con un poco de cuidado, práctica y organización, la elaboración de criterios de aceptación eficaces se convierte en una herramienta poderosa para mejorar el flujo de trabajo de cualquier equipo.

Más para leer

  • //rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important - por Maryna Z. y Dmiriy G.
  • //www.leadingagile.com/2014/09/acceptance-criteria/ por Steve Povilaitis
  • //www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ por Segue Technologies
  • //agileforgrowth.com/blog/acceptance-criteria-checklist/ - por Kamlesh Ravlani