¿Cómo impactan las historias de usuario en la toma de requisitos?

El "Druazo"

Recientemente descubrí un nuevo término que me ha arrancado más de una sonrisa y evidencia la problemática propia de las metodologías que no absorben el cambio de forma natural. Se trata del "Druazo", término que deriva del DRU "Documento de Requisitos de Usuario", documento también conocido en otros ámbitos como DDR "Documento de Definición de Requisitos".

El Druazo se produce cuando el usuario o interesado de negocio ve el producto construido y da feedback en forma de ajustes y cambios necesarios, y entonces el analista o jefe de proyecto esgrime el DRU argumentando que "en la página 67 en el segundo párrafo el usuario escribió hace 6 meses que lo que quería era..." y de forma figurada recibe un carpetazo en toda la frente.

Recordemos que un proyecto es para construir algo nuevo, algo que ampliará la herramienta con la que la compañía gestiona su core-business, mejorando algún aspecto o para incorporar una nueva linea de negocio. Por tanto un proyecto siempre es algo sobre lo que negocio no tiene experiencia y cuyas necesidades se dibujan y maduran a medida que aprende a lo largo de la construcción del producto. Nuestros usuarios no pueden saber a priori lo que necesitan, aún no tienen experiencia ni de la gestión ni de como el producto funcionará en el mercado, sólo tienen una imagen de lo que saben y la visión de lo que quieren.

Una de las dinámicas que hago en mis cursos sirve para traer a la luz los problemas corrientes en los proyectos de TI. Pido a todos los asistentes que escriban cada uno tantos post-its como problemas usuales hayan vivido, para luego consolidarlos en un tablero. El problema por excelencia, como podemos observar en la imagen de arriba a la derecha, se refiere a la presunta falta de definición en los requisitos iniciales, se pueden ver post-its como:

• Indefiniciones de usuarios, DRU con cambios constantes
• DRU escaso y poco definido
• Cambio de requisitos durante el desarrollo
• Especificaciones imprecisas de usuarios
• Falta de definición
• Poco esfuerzo para definir el alcance inicial
• Especificaciones de usuario incompletas o no claras

Viñetas del columpio, un clásico en TI

Intentar definir al detalle todos los requisitos de usuario a principio de proyecto lleva invariablemente a la situación que nos muestran las famosas viñetas TI sobre la construcción de un columpio.

Lo que hay en el trasfondo de este problema es la falta de comunicación, que como sabemos Scrum resuelve con la comunicación cara a cara, la comunicación a lo largo de todo el proyecto y mediante tableros o pizarras, que no son otra cosa que una herramienta de pura comunicación y conexión de las personas que participan en el proyecto.

Para resolver una toma de requisitos progresiva, centrada en lo que da valor en cada momento y de forma que aproveche el conocimiento tácito y la empatía que todos tenemos, la Agilidad utiliza las historias de usuario, una promesa de un conversación cara a cara posterior basada en la fórmula de las 3 C's.

En uno de los cursos sobre historias de usuario hicimos un ejercicio final con la composición de un collage para mostrar lo que cada uno de los asistentes se lleva consigo. Uno de los alumnos compuso el collage que sigue, que describe tan bien como la toma de requisitos a través de las historias de usuario da solución al problema principal de la comunicación negocio-informática. Para mi el mensaje más importante del Manifiesto Ágil es "personas sobre procesos", y este collage lo muestra con toda su profundidad en relación a la toma de requisitos:

Collage que muestra como a través de las historias de usuario la agilidad da solución a un problema tan común
Gracias José Félix :-D