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 validació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 validació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.

No hay comentarios:

Publicar un comentario