Las historias de usuario forman parte de muchas metodologías de desarrollo ágil. Estas surgen en eXtremme Programing (XP) como respuesta a una de las situaciones habituales en el desarrollo de software: la documentación de los requerimientos o las especificaciones funcionales, en este tipo de documentos se describe todo lo que se necesita que haga el software, en los modelos tradicionales no existe o es muy poca la comunicación que hay entre los miembros del equipo y el cliente, cada requerimiento o especificación funcional del software está conformado de interpretaciones que realiza el líder del proyecto de una necesidad, cada uno de estos se establece de manera fija, es decir en el transcurso de la ejecución del proyecto este no cambia ya que sobre este se realizó una planificación previa, y una modificación puede alterar el riesgo del proyecto.

La principal razón del porqué en las metodologías ágiles la utilización de documentos extensivos que describen las funcionalidades del software carecen de importancia, es porque las mismas no conducen a resultados satisfactorios, ya que solo cubren por así decir, un porcentaje mínimo (7%)  en la comunicación humana. Según Albert Mehrabian, la comunicación humana se compone de tres partes:

  1. En un 7%: El contenido (las palabras, lo dicho)
  2. En un 38%: El tono de voz
  3. En un 55% las expresiones faciales.

Es decir, para mejores resultados no hay nada como una comunicación cara a cara, donde cliente, líder de proyecto y miembros del equipo de desarrollo participan en la elaboración de los “requerimientos funcionales”, los cuales deben ser cortos y precisos que describan en muy pocas palabras lo que se quiere y no como se debe realizar el producto, a esto se le conoce como Historias de usuario.

Una historia de usuario se compone  de tres elementos, también conocidos como “las tres Cs” de las historias de usuario:

  1. Card (Ficha): Toda historia de usuario debe poder describirse en una ficha de papel pequeña. Si esto no es posible, quiere decir que se está comunicando demasiada información.
  2. Conversación: Toda historia de usuario debe tener una conversación  respecto a su contenido con el Product Owner, hay que saber responder a cuestiones sobre el valor y sobre el resultado esperado de la implementación. Esta conversación puede ocurrir en cualquier momento, lo más común que sea durante la ejecución o selección del Backlog o el Sprint Planning.
  3. Confirmación: Toda historia de usuario debe estar explicada para que el equipo de trabajo sepa que es lo que se quiere realizar y que es lo que Product Owner espera. A este valor esperado se le conoce como criterios de aceptación.

¿Qué información debe estar en las historias de usuario?

Se sabe que las historias de usuario, deben ser cortas y precisas. No existe un formato para realizar las historias de usuario, solo hay que tomar en cuenta los componentes (Las tres Cs) y unos pocos campos que se consideren necesarios para describir de manera adecuada una Historia de Usuario. De esta forma, nuestra historia de usuario puede contener la siguiente información:

  • ID: identificador de la historia de usuario.
  • Título: título descriptivo de la historia de usuario.
  • Descripción: descripción sintetizada de la historia de usuario. Si bien el estilo puede ser libre, la historia de usuario debe responder a tres preguntas:

¿Quién se beneficia?

Busca entender qué rol de usuario va a necesitar desempeñar esta funcionalidad en el sistema. Cualquier persona que interactúe con el sistema debe encajar con alguno de los roles de usuario identificados, y estos pueden ir desde lo más general hasta lo más específico, dependiendo de la finalidad del sistema. Ejemplo: asistente, gerente de equipo, vendedor, técnico de recursos humanos, etc.

¿Qué se quiere?

Busca entender qué funcionalidad desea hacer el usuario a través de la utilización del sistema. Es muy importante destacar que esta parte de las user stories debe enfocarse en el qué, y no en el cómo, debido a que esto último es algo que debe responder el equipo de desarrollo cuando buscar dar soluciones a la user story.

¿Cuál es el beneficio?

Busca entender cuál es el valor añadido que tiene esta user story para el usuario del sistema. Muy probablemente esta sea la parte más olvidada de las user story, ya que los usuarios suelen sentir que simplemente se les está pidiendo una justificación para su requerimiento. Sin embargo, es esta la parte que informa al Product Owner cuánto valor añadido tendrá el sistema si esta user story fuese priorizada

Estimación: estimación del tiempo de implementación de la historia de usuario en unidades de desarrollo, conocidas como puntos de historia (estas unidades representarán el tiempo teórico de desarrollo/persona que se estipule al comienzo del proyecto).

Valor: valor (normalmente numérico) que aporta la historia de usuario al cliente o usuario. El objetivo del equipo es maximizar el valor y la satisfacción percibida por el cliente o usuario en cada iteración. Este campo determinará junto con el tiempo, el orden con el que las historias de usuario van a ser implementadas.

Dependencias: una historia de usuario no debería ser dependiente de otra historia, pero en ocasiones es necesario mantener la relación. En este campo se indicarían los identificadores de otras historias de las que depende.

Pruebas de aceptación: pruebas consensuadas entre el cliente o usuario y el equipo que el código debe superar para dar como finalizada la implementación de la historia de usuario. Este campo también se suele denominar “criterios o condiciones de aceptación”.

Redacción de una Historia de Usuario

Mike Cohn  sugiere una determinada forma de redactar Historias de Usuario bajo el siguiente formato:

Como (rol) Quiero (funcionalidad) Para (beneficio)

(Advantages of the “As a user,I want” user story template,Mike Cohn,2008)

La redacción se realiza en primera persona, de esta manera se invita a quien lee la historia de usuario a ponerse en el lugar del usuario.

#1
Registro de Notas
Como profesor, necesito registrar las notas de los estudiantes para llevar un control de los estudiantes aprobados y reprobados.

Estimación: 3                       Valor: 60                         Dependencias:

Condiciones de Aceptación:

–       Registro de notas por alumno (solo valores numéricos)

–       Aviso de Registro de notas satisfactorio

–       Cálculo del promedio de aprobados y reprobados

Ilustración Ficha Historia de Usuario.

¿Qué es INVEST? Características de una historia de usuario

Bill Wake en el 2003 describió en su artículo “INVEST in Good Stories, and SMART Tasks”, una manera de “comprobar” que una historia de usuario esté bien redactada. INVEST es el acrónimo de Independiente, Negociable, Valorable, Estimable, Small (Pequeña), y Testeable.

  • Independient (independiente): Es importante que cada historia de usuario pueda ser planificada e implementada en cualquier orden. Para ello deberían ser totalmente independientes. Las dependencias entre historias de usuario pueden reducirse combinándolas en una o dividiéndolas de manera diferente.
  • Negotiable (negociable): Una historia de usuario es una descripción corta de una necesidad que no incluye detalles. Las historias deben ser negociables ya que sus detalles serán acordados por el cliente/usuario y el equipo durante la fase de “conversación”. Por tanto, se debe evitar una historia de usuario con demasiados detalles porque limitaría la conversación acerca de la misma.
  • Valuable (valiosa): Una historia de usuario tiene que ser valiosa para el cliente o el usuario. Una manera de hacer una historia valiosa para el cliente o el usuario es que la escriba el mismo.
  • Estimable (estimable): Una buena historia de usuario debe ser estimada con la precisión suficiente para ayudar al cliente o usuario a priorizar y planificar su implementación. La estimación generalmente será realizada por el equipo de trabajo y está directamente relacionada con el tamaño de la historia de usuario (una historia de usuario de gran tamaño es más difícil de estimar) y con el conocimiento del equipo de la necesidad expresada (en el caso de falta de conocimiento, serán necesarias más fases de conversación acerca de la misma).
  • Small (pequeña): Las historias de usuario deberían englobar como mucho unas pocas semanas/persona de trabajo. Incluso hay equipos que las restringen a días/persona. Una descripción corta ayuda a disminuir el tamaño de una historia de usuario, facilitando su estimación.
  • Testable (comprobable): La historia de usuario debería ser capaz de ser probada (fase “confirmación” de la historia de usuario). Si el cliente o usuario no sabe como probar la historia de usuario significa que no es del todo clara o que no es valiosa. Si el equipo no puede probar una historia de usuario nunca sabrá si la ha terminado o no.

Pamela Brito Linked In