sábado, 6 de agosto de 2016

¿Las historias de usuario son casos de uso?

Siempre que se mencionan casos de uso e historias de usuario se produce algo de confusión. Hay quien ha logrado incluir casos de uso en su proceso ágil pero eso no quiere decir que las historias de usuario sean equivalentes a los casos de uso.

Un caso de uso es una técnica para capturar la funcionalidad deseada desde la perspectiva de como los usuarios (actores) interactúan con el sistema. Se utiliza en UML (Unified Modeling Language) en los diagramas de casos de uso, un lenguaje de modelado que se utiliza para describir un sistema desde sus perspectivas estática y dinámica. Este resulta en un lenguaje descriptivo pensado inicialmente para sencillez en la comunicación pero que no es cercano a la comunicación humana. En cambio una historia de usuario está escrita en un lenguaje coloquial, que funciona a modo de recordatorio de una conversación con el cliente.

Como comenta Alistair Cockburn en 2001 en su libro Agile Software Development, realmente las historias de usuario están más cerca de la captura de requisitos, la fase que sirve para extraer las necesidades del usuario, que la especificación de requisitos, como son los casos de uso. Describe la diferencia entre historias de usuario y casos de uso de la siguiente manera:

Una historia de usuario es sinónimo de "característica"
como se usaba en la década de los noventa,
un marcador de lo que se debía construir, lo suficientemente detallado
para que se ajuste a una iteración moderna/los periodos del sprint.
Un caso de uso proporciona una visión contextual de lo que se va a construir,
y sirve para unir a la organización, entre otras cosas.

Podríamos decir que una historia de usuario representa el "qué" quiere el cliente o usuario y un caso de uso es el "cómo" lo quiere.
Historias de usuario versus casos de uso
En los criterios de aceptación también hay diferencias de concepto, a diferencia de los casos de uso que requieren matrices de seguimiento de requisitos con porcentajes de terminado, las historias de usuario, que incluyen criterios de aceptación, incluyen el terminado de forma binaria, o vale o no vale.

La propia Agilidad se hace patente en el hecho de que las historias de usuario son vivas. El análisis funcional y técnico se hace poco antes del desarrollo, en la reunión de planificación de sprint en caso de Scrum, por tanto el desglose en tareas lo hace el equipo, con lo que nivel de detalle y previsión supera en mucho al que pueda hacer un único arquitecto o analista funcional en los casos de uso.

Cuando un proyecto comienza a seguir una metodología ágil se deberían de olvidar completamente los casos de uso y el equipo debería de centrarse solo en la realización de historias de usuario.

Para los que estén interesados en complementar historias de usuario con casos de uso les invito a leer el libro de Cockburn, en él describe los problemas que pueden surgir y como les dio solución para sobrellevarlo.

5 comentarios:

  1. Hola Alejandro, mi nombre es Leonardo, quisiera saber si viste alguna forma de transformar Casos de Uso a Historias de Usuario. Gracias!

    ResponderEliminar
    Respuestas
    1. Hola Leonardo,

      Tuve ocasión y lo intenté, pero no tuve éxito. Para trabajar con historias de usuario hay que comprender que estas tratan de finas lonchas funcionales de principio a fin. La perspectiva de las historias de usuario es entender la necesidad del usuario/cliente y focalizarse en construir la mejor solución posible. Eso requiere entender y estar muy conectado con el usuario/cliente, colaborar muy íntimamente a lo largo de los sprints.

      La perspectiva de los casos de usos es de proyecto, elementos que sumados constituyen la solución del proyecto. Los casos de uso "entienden" el proyecto y están conectado a este.

      Lo que aprendí con el caso de no éxito es que la diferencia que está en la "fuente" para ambos tipos de requisitos, en ese equipo que intenté llevar a historias de usuario no hubo éxito porque ellos no tenían la perspectiva del cliente. Síntomas de ello fueron que no eran capaces de entender el valor de negocio de las historias y no sabían del time-to-market de lo que construían.

      Con esa lección creo que para poder trabajar con historias de usuario es necesario crear el entorno para que quién trabaje con historias pueda interactuar y entender directamente las necesidades del usuario/cliente. Por tanto hay que empezar por ahí, por cambiar el modelo de colaboración con el cliente.

      Gracias por preguntar y hacerme recordar experiencias no exitosas y sacar algo positivo de ello :-)

      Alex

      Eliminar
  2. Alex, muchas gracias por tu respuesta. En donde trabajo, tenemos analistas funcionales, pero prácticamente no tienen contacto con los clientes. Ellos comúnmente generan Casos de Uso, pero tenemos ALM Octane (Micro Focus), aún sin uso y queremos implementarla, sin embargo, esta herramienta viene preparada para trabajar con Historias de Usuario. Y por lo que vemos, hay que hacer un doble trabajo. Saludos!

    ResponderEliminar
  3. Excelente artículo. Mi duda es si podemos diseñar Casos de Uso a partir de Historias de Usuario. Evidentemente no son lo mismo, pero sí es cierto que so CU son el sistema desde la perspectiva del cliente, y las HdU son "la voz" del cliente, luego debe de haber cierta interrelación entre ambos. Gracias.

    ResponderEliminar
    Respuestas
    1. Hola,

      Aquí van mis comentarios: primero mencionar que tanto historias de usuario como casos de uso pueden ser elementos en la pila de producto, por eso los elementos de una pila se llaman PBIs (Product Backlog Items).

      La forma más "ágil", que es aplicable en situaciones que permiten una fuerte colaboración equipo/cliente, se hace mediante historias de usuario nada más. Los detalles se tratan en conversación directa.

      Los casos de uso se aplican generalmente cuando la relación entre equipo y cliente es más lejana, como ocurre en compañías más grandes donde la oportunidad de colaborar directamente es escasa. Allí es donde hace falta una forma de requisitos que recoja más detalle, incluido el técnico.

      Y por supuesto podemos aplicar ambas: recuerdo una empresa con la que trabajé donde el Propietario del Producto trataba los requisitos con su cliente en forma de historias de usuario, y luego las transformaba ayudado por un analista en casos de uso para su equipo, equipo remoto con el que no tenía oportunidad de interactuar fácilmente.

      La Agilidad trata de buscar la mejor solución dada nuestra singularidad y situación. Combinar ambos, como el ejemplo, puede ser la mejor solución (por ahora) a nuestra realidad (de ahora).

      Gracias por escribir, saludos,

      Alex

      Eliminar