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:
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 |
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.
Hola Alejandro, mi nombre es Leonardo, quisiera saber si viste alguna forma de transformar Casos de Uso a Historias de Usuario. Gracias!
ResponderEliminarHola Leonardo,
EliminarTuve 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
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!
ResponderEliminarExcelente 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.
ResponderEliminarHola,
EliminarAquí 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
Hola Alexander, soy Isaías, actuamente estoy estudiando Ingeniería de Software, entiendo que una de las principales diferencias entre los casos de uso y las historias de usuario, es que en las historias la cercanía al cliente es mayor y el equipo de desarrollo debe tener la capacidad de poder entender la problemáctica desde la perspectiva del usuario, pero cuales serían otras diferencias más notorias?
ResponderEliminarHola Isaías,
EliminarEn un entorno clásico estamos acostumbrados a que nos digan y diseñen exactamente lo que quieren que construyamos, tanto la funcionalidad, la arquitectura y herramientas que hemos de utilizar. Eso se describe en gran medida en los casos de uso.
Una historia de usuario trata de dar entendimiento de lo que necesita el cliente a aquellos que van a construir la funcionalidad. La toma de decisiones sobre tecnología, herramientas, el cómo hacerlo recae toda en el equipo. No hay nadie mejor que un equipo multidisciplinar y autogestionado para diseñar y construir la mejor funcionalidad posible. Lo único que necesitan es entender la funcionalidad, para lo demás ellos son los expertos.
Puedes imaginarte que el uso de casos de uso o de historias de usuario dependerá de la autonomia y el método de trabajo del equipo.
Espero haberte ayudado, saludos,
Alex
Excelente, me ayudo mucho.
ResponderEliminar