HISTORIAS DE USUARIO: UN MONSTRUO QUE ENTIENDEN MUCHOS
Hace unos meses, participé en un proyecto de integración universitaria en mi ciudad natal, convocaron más de 20 desarrolladores para tal tarea; nosotros emocionados por empezar con fuerza y convicción el día 0 de nuestro trabajo, nos comunican que el jefe del proyecto aún está en negociaciones con el cliente de los detalles del cliente de los primeros sistemas que atacar y que durante ese tiempo estaríamos en capacitación.
Al paso de un mes, todo el equipo se quedó sudando del miedo al recibir un libro, en el cual encontramos más de 100 páginas con diagramas de casos de uso, diagramas de clase e información de los sistemas actuales en la universidad; además un requerimiento del cliente deseando resultados continuos en el paso de un tiempo determinado.
¿En que fallaron los dirigentes del proyecto? ¿Tenían idea del tiempo que tomaría descifrar esta información y desglosarla en una forma más sencilla?
¿POR QUE NO EMPEZAR SIMPLE?
CONTEXTO DE PROBLEMA
El proceso de desarrollo de software debe empezar siempre con la exploración y la recopilación de las necesidades del mismo; esto no significa que hemos terminado, aún tenemos que validar los resultados con ejemplos o pruebas de aceptación, solo cuando tenemos historias de usuario concretas podemos arrancar con los sprints o iteraciones correspondientes.
El primer principio ágil es la satisfacción del cliente, preferiblemente con entregas frecuentes. Mientras más pequeño sea este tiempo, más rápido recibiremos retroalimentaciones y oportunidades de mejora.
El no dar un tiempo adecuado a la realización de historias de usuario podría causar penalidades en las futuras fases del proyecto, como un planeamiento improductivo de sprints, no haber terminado cuando la iteración dice que sí y otras consecuencias adicionales.
HISTORIAS DE USUARIO ¿QUE SON? ¿POR QUE USARLAS?
Las historias de usuario son pequeñas descripciones de una funcionalidad dicha desde la perspectiva del cliente o la persona que desea esa nueva funcionalidad siguiendo una estructura típica como esta: Como (rol de usuario), Quiero (Alguna necesidad), Para (¿Por qué?)
Las historias de usuario pueden ser utilizadas para representar nuevas características, una mejora de una característica existente, requerimientos no funcionales (tareas técnicas) o un defecto a considerar durante las pruebas; una vez que las historias han sido identificadas y priorizadas en colaboración con el cliente, el equipo lo estima y pasa a formar parte del product backlog para su posterior implementación. Una vez desarrolladas, se ejecutan pruebas de aceptación para asegurar que las historias funcionan de la forma que el cliente lo deseaba.
Estas descripciones además tienen componentes básicos en la mayoría de los casos los cuales son: Tarjeta que es la descripción de la historia, Conversación que serían los diálogos con el usuario y la Confirmación, también conocida como criterios de aceptación que se utiliza para confirmar si la historia esta lista o no.
¿QUE DEBERÍAS TENER EN CUENTA AL REALIZAR UNA HISTORIA DE USUARIO?
Autor: Rodrigo Alarcon Garcia
REFERENCIAS
- Bea Düring & Håkan Kleijn(2015) Agile Requirements in 60 minutes
- Jake Bartlett(2016) https://blog.testlodge.com/user-story-vs-requirements/
- Roman Pichler(2016) http://www.romanpichler.com/blog/10-tips-writing-good-user-stories/?doing_wp_cron=1512339875.4913840293884277343750
