Historias de Usuario

Recordemos siempre que cuando en este blog se habla acerca de ingeniería de software nos enfocamos en la metodología ligera extreme programming (XP).

En el post pasado comenté acerca de los roles en un equipo de desarrollo y esta vez nos toca echar a andar el proyecto. En las metodologías clásicas de desarrollo había 4 etapas principales (las que me enseñaron en la prepa):

Generalmente la etapa de análisis comprende mucho papeleo, cosas que a veces no se les ve importancia. Digo esto desde el punto de vista de un estudiante, como yo, o un desarrollador no tan formal cuyo mayor interés es sacar versiones de su aplicación, como yo.

Sin embargo la etapa de análisis es impresindible para el desarrollo de un sistema, en esta etapa es donde se obtienen los requisitos que necesita realmente el cliente o usuario final. eXtreme Programming propone una manera menos formal y más rápida de recabar esta información directamente del cliente y de una forma más natural para él.

La técnica es recolectar “historias de usuario”, pero qué son las historias de usuario.

Las historias de usuario son pequeñas sentencias, lo recomendado son 3 renglones, en un lenguaje común que describe una funcionalidad que el cliente desea para el sistema. Obviamente las historias de usuario deben escribirse por éstos mismos, los usuarios no están limitados a pensar en cómo será la interfaz, o cómo quiere que se haga, el usuario sólo escribe lo que él quiere que el programa haga y listo.

Son parecidos a los casos de uso de UML, pero no son exactamente lo mismo. Además de expresar funcionalidades las historias de usuario son apreciadas por dar al desarrollo un método de prueba. En XP la calidad es fácil de expresar: funciona o no funciona. Basándonos en la historia de usuario original y comprobando el sistema podemos ver si fue cubierta o no.

Las historias de usuario también nos dan una idea de qué tan largo será el proceso antes de hacer un release, antes de esto las historias de usuario deben analizarse varias veces antes de aceptar su implementación.

Hay que remarcar para que quede claro que las historias de usuario se basan en lo que el cliente o usuario desea, sin dar detalles técnicos ni de tecnología.

Al tener las historias de usuario recolectadas procederemos a trabajar con ellas en equipo, es recomendable que las historias de usuario SEAN ESCRITAS POR USUARIOS y yo recomiendo que en tarjetas que sean manejables, como para barajearlas sobre una mesa.