archivo

Archivos diarios: noviembre 26, 2012

Una historia de usuario no es una descripción de una tarea en un post-it. O tal vez sí. Depende de lo que requiera el proyecto o del contexto actual del mismo.

Sobre esa base, habrá opiniones para todos los gustos. La mía es que las historias de usuario requieren ser descritas con el suficiente nivel de detalle para poder ser estimadas con fiabilidad y para que el programador pueda trabajar con ellas.

Es importante no olvidar que el objetivo no son historias de usuario que lleguen al máximo nivel de detalle, sino la que se necesite. No es fácil alcanzar ese equilibrio pero con la experiencia (desde una visión general) y tras algunas iteraciones (centrándos en el proyecto en el que estamos trabajando) nos iremos aproximando a ello.

Esto desde un punto de vista de la producción, ya que habrá determinados tipos de proyecto que requieran además que el cliente y el proveedor vayan aprobando hitos de trabajo (y su presupuesto correspondiente), en estos casos, el hecho de que las historias de usuario estén por escrito y con el suficiente nivel de detalle es absolutamente necesario.

Puede aparecer que esto contradice en cierto modo el tercer principio el Manifiesto Ágil: “Se valora la colaboración con el cliente por encima de la negociación contractual”, pero hay que tener en cuenta que cuando se contratan nuestros servicios por terceros, el nivel de formalidad vendrá definido por el acuerdo al que se llegue con el cliente y por la experiencia que tengamos en trabajar con ese cliente o con clientes de ese sector. En estos contextos, tener registrado qué se hace y con una aprobación formal por parte del product owner, evitará muchos problemas después.

¿Cómo catalogamos las historias de usuario? Mi recomendación es que las historias de usuario se cataloguen a nivel de sprint, pudiendo estar en un documento independiente o en uno que vaya recopilando los diferentes sprints. Hay que tener en cuenta que no estoy creando un excesivo overhead ya que considero fundamental tener bien especificadas las historias de usuario (cuando digo bien especificada siempre hago referencia a lo que la historia de usuario necesita que en función del estado del proyecto puede requerir más o menos nivel de detalle).

Volviendo a la catalogación de las historias de usuario, se tratarían de documentos que no se modificarían como consecuencia de la evolución del sistema, ya que son fotos de cada sprint. Se pueden hacer trabajos de consolidación para hacer fotos no ya a nivel de sprint sino a nivel de sistema en determinados momentos del tiempo, serán las necesidades del proyecto, del producto y de los participantes las que dicten la necesidad o no de hacer esa actividad.

Con las historias de usuario volvemos al lenguaje natural, lo que no limita la utilización de prototipados de interfaz, subconjuntos del modelo de datos, etc…, sin olvidar que su objetivo y funcionamiento debe ser entendible por el product owner (independientemente de que haya especificaciones concretas para los desarrolladores).

Las historias de usuario deben detallar la tarea y también describir las comprobaciones que debe hacer el product owner para dar por válida la misma (antes las deberá hacer el equipo de desarrollo y testers especializados si existen en el proyecto), es importante señalar que una historia de usuario debería ser válida o no válida y no deberían existir estados intermedios como “casi válida”, recordemos que queremos mantener un ritmo sostenido de desarrollo y eso requiere no estar continuamente dejando flecos abiertos.

Anuncios