Pages Menu
Categories Menu

Posted by on Feb 24, 2014 in General | 0 comments

Herramientas del product owner: las historias de usuario, solas, no son suficientes

Cuando hablamos del product owner, siempre a casi todo el mundo le vienen a la cabeza únicamente dos conceptos: las historias de usuario y el product backlog.

Pero conviene recordar que si bien las historias de usuario son importantes, pieza clave en un ciclo ágil, pensadas para recoger funcionalidad, etc., no son suficientes para definir plenamente un nuevo producto software, nos van a faltar cosas.

Cosas como, por ejemplo, la “no funcionalidad”, las restricciones que le llaman algunos, aspectos como el tiempo de respuesta, requisitos de seguridad, etc. También nos van a venir bien bocetos sobre el diseño, borradores de las pantallas, etc.

En resumen, vamos a necesitar cuatro dimensiones para especificar plenamente un producto software, o partes complejas del mismo:

– Interacciones o escenarios. Ayudan a ver cómo un usuario interactúa con la aplicación, son ejemplos de interacción. Casos de uso, escenarios y “storyboards” son útiles en esta parte. Aquí trabajamos en cosas como “primero el usuario se dará de alta, luego seleccionará x, posteriormente el sistema le dirá y, etc.”

– Diseños y borradores de las pantallas. Ayudan a la hora de ver cómo van a ser las pantallas de la aplicación. Hablamos de este tema cuando tratamos los mockups como complemento gráfico de requisitos o historias de usuario.

– Los requisitos no-funcionales. Hay quien les llama historias técnicas, hay quien incluso utiliza el formato de la historia de usuario adaptándolo a contar no-funcionalidad, es decir, cosas como seguridad, rendimiento, tiempos, fiabilidad, tolerancia, etc.

– La funcionalidad. Que recaerá en manos de herramientas como, por ejemplo, las historias de usuario.

Tampoco es que la anterior división en 4 dimensiones sea nada nuevo. De hecho, siempre se ha tratado. Hace tiempo, por ejemplo, las diferentes técnicas y diagramas que acompañaban al mundo UML abordaban de alguna manera los anteriores: requisitos (funcionalidad), casos de uso (secuencias tipo), y diagramas de estado o actividad (escenario e interacciones).

En un mundo cada vez más ágil, conviene recordar las anteriores dimensiones, que ya existían desde hace tiempo y que por algo era.

Javier Garzás

Javier Garzás

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.
Javier Garzás

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This