Malas interpretaciones del concepto de historia de usuario I
¿Las historias de usuario equivalen a requisitos funcionales?
Popularmente se asocia el concepto de historia de usuario con el de la especificación de un requisito funcional. De hecho, muchas veces se habla de que a la hora de especificar una necesidad del cliente o del usuario, las metodologías ágiles usan la historia de usuario y las tradicionales, el requisito funcional. Sin embargo, detrás del concepto de historia de usuario hay muchos aspectos que lo diferencian de lo que es una especificación de un requisito, diferencias que muchas veces son poco conocidas y que llevan a muchos equipos a dudas y confusiones.
Una historia de usuario describe funcionalidad que será útil para el usuario y/o cliente de un sistema software. Y aunque normalmente las historias de usuario asociadas a las metodologías ágiles, suelen escribirse en pósit o tarjetas, son mucho más que eso. Como se ha comentado anteriormente, una historia no es sólo una descripción de una funcionalidad, sino también es de vital importancia la conversación que conllevan.
Las historias de usuario, frente a mostrar el “cómo”, sólo dicen el “qué”. Es decir, muestran funcionalidad que será desarrollada, pero no cómo se desarrollará. De ahí que aspectos como que “el software se escribirá en Java” no deben estar contenidos en una historia de usuario.
De esta manera, equiparar las historias de usuario con las especificaciones de requisitos no es demasiado correcto ya que por definición, las historias de usuario no deben tener el nivel de detalle que suele tener la especificación de un requisito
Una historia de usuario debería ser pequeña, memorizable, y que pudiera ser desarrollada por un par de programadores en una semana. Debido a su brevedad, es imposible que una historia de usuario contenga toda la información necesaria para desarrollarla, en tan reducido espacio no se pueden describir aspectos del diseño, de las pruebas, normativas, convenciones de codificación a seguir, etc.
Para resolver el anterior problema hay que entender que el objetivo de las historias de usuario es, entre otros, lograr la interacción entre el equipo y el cliente o el usuario por encima de documentar (manifiesto ágil, ver lección 1) por lo que no se deben sobrecargar de información. Sin embargo, la realidad de los proyectos y de los negocios es otra y hace que la teoría se deba ajustar a la práctica, por lo que se pueden dar varias soluciones para reflejar toda esa información que en un primer momento parece que no cuadra en las historias de usuario:
· Relajar la agilidad usando los tradicionales requisitos en ciclos de vida ágil.
· Usar casos de uso en vez de historias de usuario.
· Utilizar técnicas de trazabilidad para relacionar las historias de usuario con otros documentos: de diseño, normativas, etc.
[1]Cockburn, A. (2002). Agile software development. Boston, MA, USA. Addison-Wesley Longman Publishing Co., Inc.
Francisco Javier Cervigon Ruckauer
No hay comentarios:
Publicar un comentario