lunes, 30 de noviembre de 2020

5 diferencias entre Historias de Usuario y Casos de Uso

 

Me he decidido a escribir este post después de haber comentado y respondido al respecto de esta duda en repetidas ocasiones. Así pues, es más práctico tener un lugar donde dejar disponible esta información :-).

Los Casos de Uso son parte de la notación UML pero fueron propuestos originalmente por Ivar Jacobson a fines de los 80's. Por otra parte, a Alistair Cockburn se le atribuye la denominación User Story (Historia de Usuario) a fines de los 90's, nombre que se popularizó con el libro de Kent Beck describiendo el método Extreme Programming (XP). 

Antes de entrar en materia hay que remarcar que para el enfoque ágil no hay un estándar, lo cual tiene sus ventajas e inconvenientes :- ). Existen varias propuestas de métodos ágiles (Scrum, Kanban, Lean Development, Extreme Programming, y otros) con información proporcionada por sus autores, y además, mucha literatura adicional con "interpretación" de dichos métodos, del enfoque ágil en general y de la adaptación necesaria al aplicarlos en un contexto específico. Dicho esto, a continuación, paso a comentar "mi interpretación" al respecto :-).

Estas serían algunas de las diferencias destacables entre Casos de Uso (CU) e Historias de Usuario (HU):

  1. Las HU son unidades de trabajo que debe abordar el equipo de trabajo, pueden ser cambios en el producto (nuevos requisitos funcionales o no funcionales, mejoras o correcciones de fallos) u otras tareas como montar servidor, preparar demos, etc. Los CU especifican, por defecto, solo requisitos funcionales del producto. Según esto, las HU y los CU coinciden en ser ambos una forma de representar requisitos funcionales, pero las HU además pueden representar otro tipos de trabajo que debe realizar el equipo, tales como mejoras y correcciones en requisitos ya implementados, e incluso otras tareas que no implican un cambio en el producto.
  2. Las HU deberían ser en general pequeñas, lo suficiente para que se puedan implementar y probar en un par de días o una semana como máximo. Si son más grandes, se consideran HU "Épicas" y lo más recomendable es que sean abordadas incrementalmente mediante varias HU "más pequeñas" y desarrolladas de forma consecutiva. Los CU no tienen a priori ninguna restricción de tamaño, pero dado que los diagramas de CU muestran visualmente el modelo de requisitos, debería tratarse de abstracciones de mayor nivel. Sin embargo, aprovechando de hacer una crítica "constructiva", a veces me sorprende ver diagramas de CU con muchísimos CU. Esto, en general, se debe a que los CU se están especificando muy asociados a cada operación CRUD relacionada con cada entidad del sistema :-(. Por ejemplo, si tenemos la entidad Usuario, se establecen los CU: "Alta de usuario", "Modificación de usuario", "Eliminación de Usuario" y "Lista de usuarios", y aplicando esta estrategia de forma indiscriminada, si el sistema tiene 50 entidades de dominio el modelo de requisitos tendrá al menos 200 CU!!., los cual posiblemente entorpecerá la organización del desarrollo de las funcionalidades. Otra crítica que suelo hacer es considerar como CU funcionalidades que pueden ser prescindibles en el nivel de abstracción del modelo de requisitos, por ejemplo, incluir el CU "Login" y para más remate ponerlo como <<include>> de todos o casi todos los CU, perjudicando la legibilidad del diagrama. A menos que el "Login" no sea el "estándar", esta funcionalidad entraría en el terreno de lo obvio, lo que no es necesario especificar. Si se trata de un sistema multiusuario obviamente debe tener implementado un mecanismo de autenticación, y esto, por tamaño, podría perfectamente ser una HU.
  3. Las HU se terminan en algún momento (en un Sprint, si se trabaja con iteraciones), luego no se vuelve a trabajar en ellas, cualquier "fleco" (mejora o corrección) se establece como una nueva HU. Los CU se mantienen, pueden evolucionar, y no consideran en su especificación las posibles correcciones de fallos que pudiesen tener. Por esto, los CU no son ítems apropiados para ponerlos en una planificación temporal, ya que a menos que no se produzcan mejoras ni correcciones de fallos, un CU nunca se termina. Se podría indicar en una planificación cuándo se comienza el desarrollo de un CU y cuándo se termina una primera versión de él, pero los posteriores cambios ya no serían nuevos CU.
  4. Las HU se estiman en Puntos (tamaño relativo a una HU que sirve de referencia) u Horas Ideales (horas ininterrumpidas de trabajo). Los CU en un contexto tradicional suelen estimarse en horas de contrato, es decir, Horas Hombre (HH).
  5. La gestión de HU se realiza en el Backlog, que es una lista ordenada de todas las HU no terminadas. Este ordenamiento responde a una priorización establecida por el Product Owner (PO) que determina el orden en el cual se abordarán las HU. Se asume que el Backlog puede cambiar, es decir, pueden añadirse, modificarse o eliminarse HU, pueden agruparse o dividirse en nuevas HU, así como también puede cambiar su ordenamiento. En cambio los CU no conllevan en su aplicación una estrategia de implantación a lo largo del tiempo. Los CU suelen establecerse y especificarse detalladamente al comienzo del desarrollo de un producto, antes de comenzar a construirlo, y posteriormente, al menos el diagrama de CU, no suele tener demasiados cambios (no es usual añadir o eliminar CU durante el desarrollo).

A continuación, mi opinión "arriesgada" :-) respecto de una posible convivencia de CU e HU. He comprobado en la práctica que al inicio del desarrollo de un producto, cuando se están descubriendo sus requisitos, es útil elaborar un diagrama de CU que permita visualizar los actores y CU globales, es decir, lo que equivaldría a en el enfoque ágil a "Features", o también estaría cercano al concepto de HU "Épicas". Se trataría de características funcionales más globales que requisitos software específicos. La visualización de estas funcionalidades globales permite hacerse una idea general de los requisitos y de los tipos de usuarios (actores). Además, si fuese conveniente en este diagrama de CU se podría mostrar jerarquías de actores en el caso de requisitos funcionales específicos para ciertos tipos de actores. Esta identificación de actores y CU globales también es útil posteriormente para contextualizar las HU que se van desarrollando. Por ejemplo, todas las HU que se han implementado en el contexto de un CU estarían fácilmente localizadas en dicho CU. 

En Worki, nuestra herramienta de apoyo para la gestión ágil del trabajo, y según "nuestra interpretación" del enfoque ágil :- ), utilizamos concepto de Unidad de Trabajo (UT) para referirnos a los ítems de trabajo que debe abordar el equipo. Usamos este nombre más general que HU para destacar que puede tratarse de cualquier tipo de trabajo del equipo, sean cambios en el producto u otro tipo de tareas, donde hablar de HU resulta extraño :-). Además, en Worki se ofrece una "Estructura-Temas" para cada producto, la cual se representa como una jerarquía de nodos que pueden representar una jerarquía de descomposición de requisitos. Cada UT se asocia a uno o más nodos de esta estructura, aquellos nodos donde la UT hará algún cambio. 

En cuanto a especificación de requisitos, nuestra recomendación es especificar los cambios en el producto usando mockups y Pruebas de Aceptación, y si fuera el caso, una breve descripción de contexto y justificación del cambio. Así pues, las UT se especifican básicamente mediante mockups y Pruebas de Aceptación. En Worki, tanto las UT como sus Pruebas de Aceptación quedan asociadas a nodos de la "Estructura-Temas" y en cada cono son gestionadas de forma detallada (acciones de creación, modificación, eliminación o ejecución que se realizan en una UT). Así, cada nodo de la "Estructura-Temas" tiene asociadas todas las UT que han realizado cambios en esa funcionalidad y además, acumula todas las Pruebas de Aceptación implementadas por esas UT, las cuales establecen el comportamiento de dicha funcionalidad. 

Lecturas adicionales respecto de este tema:
Discusión en Wiki Wiki Web. http://wiki.c2.com/?UserStoryAndUseCaseComparison


Patricio Letelier

1 comentario: