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 deberían ser 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. Esta diferencia de tamaño conlleva a que en general las HU se refieren a funcionalidad más específica, a un nivel mayor de detalle funcional.
  3. Las HU se terminan en un determinado momento (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 sí mismos las posibles correcciones de fallos que tengan. 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 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 las HU, así como también puede cambiar su ordenamiento. A diferencia de lo anterior, 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.   

A continuación, mi opinión "arriesgada" :-) al respecto de 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 (lo que equivaldría a HU "Épicas") asociadas a características funcionales. Esto permite hacerse una idea general de los requisitos funcionales 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 (requisito funcional original) estarían fácilmente localizadas en dicho CU. Esto es similar al concepto "Tema" en el ámbito ágil, el cual representa una agrupación de HU, que podría correspondería en este caso a una agrupación funcional.

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. Además, en Worki se ofrece una "Estructura-Temas" para cada producto, la cual se representa como una jerarquía de nodos. Cada UT se asocia a uno o más nodos de esta estructura. 

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 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 son gestionadas de forma detallada en Worki. Así, cada nodo de la "Estructura-Temas" contienen a todas las UT que han realizado cambios en esa funcionalidad y 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

No hay comentarios:

Publicar un comentario