Historias de usuario, un taller de José Manuel Beas

IMG_0562

El pasado 18 de enero asistí al Taller de Historias de Usuario que organizó Jose Manuel Beas en Madrid, un taller que recomiendo a cualquiera que desarrolle software, esté o no interesado en metodologías ágiles. Si estás interesado porque te ayudará a mejorar en el que es el primer paso de todo desarrollo: crear las historias que nos deben decir qué quiere el usuario. Si no lo estás porque igual te abre la puerta hacia una forma de plantear los proyectos software radicalmente distinta a la tradicional.

El agilismo lleva ya muchos años cambiando la forma en que se desarrolla el software. Parte de la premisa de que los cambios se van a producir, y por tanto no hay que huir de ellos, sino aceptarlos, integrarlos en el proceso de desarrollo y darles la bienvenida. Son estos cambios y nuestra capacidad para integrarlos en el desarrollo los que harán que nuestro software haga lo que tiene que hacer el día de la entrega, y no lo que suponíamos que tenía que hacer el día del análisis inicial. El agilismo se basa en 4 principios, que forman el Manifiesto por el Desarrollo Ágil de Software, escrito en 2001. Consiste en cambiar las prioridades, valorando…

  • Individuos e interacciones sobre procesos y herramientas
  • Software funcionando sobre documentación extensiva
  • Colaboración con el cliente sobre negociación contractual
  • Respuesta ante el cambio sobre seguir un plan

Aunque valora los elementos de la derecha, valora más los de la izquierda.

Cuando hablamos de agilismo lo más habitual es usar Scrum o alguna variante. El primer artefacto que aparece en Scrum es el Backlog, o la Pila de Producto, que no es más que una lista de Historias de Usuario prorizada y con una estimación sobre su dificultad. De ahí la importancia de contar con unas buenas historias, porque son el punto de partida, y si el primer paso ya lo damos mal la calidad de los siguientes se verá seriamente afectada.

¿Y qué es una historia de usuario? Pues es la descripción de un requisito del software a desarrollar en lenguage natural, coloquial, sin usar UML ni nada parecido, tal cual lo ha pedido el cliente, usando una pequeña fórmula que nos permite saber:

  • Quien lo solicita
  • Qué solicita
  • Para qué lo solicita
  • Como validaremos que está hecho y que funciona.

Un pequeño ejemplo de historia sería: «COMO responsable de fábrica QUIERO poder ver en tiempo real las velocidades de producción PARA actual de inmediato sobre las que tengan problemas».

Esto que contado así parece tan sencillo no lo es cuando te enfrentas a problemas reales, como vimos con algunos ejemplos en el taller, y por eso creo que vale le pena invertir tiempo en aprender a desarrollarlas bien y dar ese primer paso con la máxima calidad.

Aparte de aprender la teoría sobre cómo debe ser una historia de usuario, el enfoque práctico del taller permite que saques tus propias conclusiones, que en mi caso fueron:

  • Tengo tendencia a pensar demasiado pronto en el «cómo» en lugar de en el «qué».
  • Gran parte de lo que en un principio veo como historias son en realidad criterios de aceptación, no historias.
  • Empezar desde el «quien lo pide», poner a la persona en el primer lugar puede ayudar mucho, sobre todo cuando desarrollas para tu empresa y conoces a quien va a acabar usando los programas.
  • La reponsabilidad de las Historias de Usuario recae en un perfil llamado «Dueño de producto» en Scrum, y ese es un perfil que no existe en empresas que no usen metodologías ágiles. No se puede coger a un responsable de proyectos y cambiarle el nombre, hay que inventar el perfil y darle la formación adecuada.
  • El cambio no es fácil, pero vale la pena. A la hora de asumir cambios radicales a veces la experiencia no es un grado. Tantos años haciendo las cosas de otra manera te llevan a seguir haciéndolas igual en cuanto te relajas. Como en todo cambio es necesario un periodo de aprendizaje y de repetición hasta que todo salga de manera natural, pero al principio creo que es importante tener un buen guión y no saltárselo por nada, porque a la mínima ocasión caes en viejos vicios.

Se hace ameno, de hecho queda muy justo de tiempo, sería ideal poderlo hacer en dos jornadas para asentar mejor los conceptos, pero es sin duda un taller que aporta un gran valor y un buen punto de arranque o de mejora en metodologías ágiles.

Y por último y no menos importante me permitió charlar un rato con José Manuel, al que ya había «desvirtualizado» en la conferencia «Corporate Agile» que organizó y donde apenas tuvimos tiempo de hablar. Como demostración de que el mundo no es tan grande, conocí la existencia de José Manuel al leer el prólogo que hizo del libro de Carlos Blé, Diseño Ágil con TDD. Tiempo más tarde alguien hizo un comentario en el artículo «La flor roja con el tallo verde» de este blog y me siguió en Twitter, y bastante tiempo después, tras ver que hablaba mucho de agilismo en Twitter y tras investigar un poco en su web descubrí que era aquel crack del agilismo que había creado agilismo.es y prologado el libro de Carlos que fue mi primer contacto con el desarrollo ágil, del que hasta entonces no conocía ni su existencia. Si os interesa el agilismo o si este artículo os ha despertado el interés, no dudéis en seguirle de cerca.

2 Comentarios

  • Hola Jaume,
    Estuve también en el taller, y efectivamente me parece una experiencia más que recomendable. Además, hemos empezado también a trabajar con historias de usuario y a introducir SCRUM poco a poco en la empresa. Es impresionante cómo la cabra tira al monte! Nos va a tocar lidiar con tratar de no buscar el «como» lo primero durante una temporada… pero efectivamente merece la pena!
    Un buen artículo!
    Un saludo.

    • jaume

      ¡Gracias por tu comentario Antonio!
      Efectivamente la cabra tira al monte, y cuanto más vieja es la cabra más tira, pero no hay nada que no se consiga mediante repetición hasta integrarlo como hábito si aporta ventajas, como es el caso.

¿Quieres dejar un comentario?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *