Como ya sabéis, en Apiumhub utilizamos metodologías ágiles y uno de los principales componentes de este tipo de metodologías son las historias de usuario. Breves inputs que recibimos de los clientes sobre los beneficios que se quieren conseguir con la creación de un nuevo software u otro proyecto. Estas historias, se desglosan en pequeñas tareas que no deberían llevar mucho tiempo en ser puestas en marcha. Tareas cortas que puedan ser desarrolladas en uno o varios días y ya listas para el QA, en el caso de que la historia sea muy compleja y pueda llevarnos más tiempo, la desglosamos en varias tareas más pequeñas, todo para que el ciclo de testing empiece antes y nos dé antes feedback acerca de las casuísticas de uso. El tiempo de realización de estas tareas puede verse influenciado por tres factores:

 

  • La necesidad de un gran esfuerzo para poderla llevar a cabo de la manera más fiel posible y consiguiendo la mejor experiencia final del usuario.
  • La necesidad de un estudio previo a su puesta en marcha, que puede implicar un retraso en la producción.
  • La espera de un feedback externo para aclarar ciertos puntos que nos impiden avanzar.

 

Es importante no confundir las historias de usuario con las tareas. Las historias, deben ser creadas por el cliente (un PO) y siempre pensando en una finalidad del producto, mientras que las tareas, será la manera en que los desarrolladores consigan paso a paso cumplir estos requisitos optimizando los resultados. Gracias a esta práctica, podemos sensibilizarnos con el producto, entender su misión y en base a esto, tomar unas decisiones u otras.

Por otro lado, no solo se consigue un mayor conocimiento sobre el producto, sino que nos ayudará a mejorar nuestra relación con el cliente, haciendo que este sea más participativo y dándole la posibilidad de encarrilar el proyecto de una manera específica. Nos permite crear y evolucionar a la par que el proyecto crece, puesto que las historias no son únicas, sino que en función de la fase de nuestro proyecto, se pueden ir reajustando, ya que son pequeñas peticiones que no implican largos períodos de trabajo. Aportan una información imprescindible para poder llevar a cabo proyectos únicos y mejorar el entorno de trabajo puesto que hace partícipe de una forma mucho más íntima a los miembros de equipo.

Podríamos decir que las Historias de usuario consta de tres fases:

  1. En primer lugar, el cliente nos hará llegar un pequeño escrito con las funcionalidades que considere necesarias, de forma esquemática.
  2. A posteriori, se hace una reunión de equipo, donde se establecen prioridades y se le da feedback al cliente, de manera que nos aclara cómo poder resolver según qué situaciones o poder hacer consultas sobre puntos incoherentes de las historias creadas.
  3. Por último, la comprobación y validación de que una historia se ha creado con éxito

 

Características de las historias de usuario: invest 

 

  • Independiente, Una historia no depende del resto de historias, de forma que se pueden clasificar por prioridad, como se desee, pues no tienen un orden lógico.
  • Negociable, Las historias como tal, en su primera fase, son ideas, o conceptos, pero se deben desarrollar en la fase de comunicación.
  • Valiosa, Las historias deben tener valor por sí solas para el cliente, usuario o comprador.
  • Estimable, una vez finalizada la conversación debemos poder estimar las historias, si no son estimables será necesario una segunda puesta en común.
  • Pequeña, una buena historia debería poderse realizar en una semana, por lo que no suelen ser extensas.
  • Testable, es necesario probar una historia para ver si se ha resuelto con éxito.

 

Requisitos de una tarjeta 

 

Las tarjetas forman parte de la primera entrega de la historia de usuario, donde se especifica de manera escueta la necesidad a tratar en el sprint, no sólo deben ser breves y precisas, sino que deben responder a tres preguntas que normalmente se sitúan en el reverso de la tarjeta.

  • ¿Cómo quién? Donde se especifique el tipo de usuario para quién se hace la funcionalidad.
  • ¿Qué? Aclarando cuales son los objetivos a los que tenemos que enfrentarnos.
  • ¿Para qué? Definiendo el motivo del lado de negocio por el cual se ha creado la historia.

Además se puede incluir una nota de prioridad para tener una visión global de la importancia de cada tarjeta.

 

Limitaciones de las historias de usuario

 

No todo son ventajas, aunque si es verdad, que los pocos inconvenientes que tienen estas prácticas, son fácilmente solucionables.

  • Es difícil de medir la eficacia de un proyecto con los resultados de una historia, aunque estos hayan sido positivos, pues necesitaremos una visión más global para poder clasificar un proyecto terminado como correcto.
  • Necesitaremos desarrolladores cualificados que tengan una visión muy clara sobre sus posibilidades y cómo conseguir objetivos a corto plazo, puesto que las historias se desglosan en pequeñas tareas.
  • Para poder asumir la escalabilidad de un proyecto grande, necesitaremos de profesionales, pues las historias nos dan pistas, pero es necesario tener visión a largo plazo para agrupar las historias y ofrecer datos más precisos.
  • Es necesario un continuo feedback con el cliente para resolver posibles dudas o incluso para ir agregando historias a nuestros sprints.

Espero que te haya servido de ayuda este artículo y que a partir de ahora pongas en práctica metodologías ágiles y puedas trabajar cómodamente con las historias de usuario.

 

Si te gustó este artículo, te puede gustar:

Los beneficios de la tecnología Scrum 

Beneficios de la tecnología Agil

Metodo Kanban Principios y Ventajas 

Beneficios de la integración contínua

Beneficios de TDD

¿Porque debería usar Docker en mi proyecto de desarrollo?

Beneficios de la pruebas unitarias

Suscríbete a nuestro newsletter para estar al día de los eventos, meet ups y demás artículos!