PROVINCIA DE BUENOS AIRES

DIRECCIÓN GENERAL DE CULTURA Y EDUCACIÓN

DIRECCIÓN DE EDUCACIÓN SUPERIOR
INSTITUTO SUPERIOR DE FORMACIÓN TÉCNICA N° 172

TECNICATURA SUPERIOR EN ANÁLISIS DE SISTEMAS

PRÁCTICAS PROFESIONALIZANTES I
UNIDAD 2: ACTIVIDAD PROFESIONAL
UNIDAD TEMÁTICA: HISTORIAS DE USUARIOS

PROFESORES:
JAVIER POZZO
DIEGO VIOLA
PROVINCIA DE BUENOS AIRES
ÍNCIDE
1. METODOLOGÍAS ÁGILES: HISTORIA DE USUARIO (USER STORY) ........................................................................... 3

2. HISTORIA DE USUARIO (USER STORY)......................................................................................................................... 4

3 COMPONENTES DE UNA HISTORIA DE USUARIO (USER STORY) ............................................................................. 4

4. REDACCIÓN DE UNA HISTORIA DE USUARIO (USER STORY) ................................................................................... 4

5. MODELO INVEST .............................................................................................................................................................. 7

6. PUNTOS DE HISTORIA (STORY POINTS)....................................................................................................................... 7

6.1. ¿CÓMO “DECODIFICAR” LAS ESTIMACIONES? ......................................................................................................... 7

7. FLUJO DE UNA HISTORIA DE USUARIO (USER STORY) DEL SPRINT EN EL BOARD .............................................. 8

BIBLIOGRAFÍA ..................................................................................................................................................................... 10
1. METODOLOGÍAS ÁGILES: HISTORIA DE USUARIO (USER STORY)
SCRUM:

(Figura número 1, elaboración propia)

Product backlog:

(Figura número 2, elaboración propia)

2. HISTORIA DE USUARIO (USER STORY)
Una historia de usuario (user story) es una descripción corta de una funcionalidad, valuada por un usuario o cliente
de un sistema. En cada iteración los requerimientos que hay que desarrollar se expresan mediante historias de usuarios
(user stories). Las historias de usuarios (user stories) forman parte de un enfoque ágil que ayuda a cambiar el enfoque de
escribir sobre los requerimientos a hablar de ellos.

3 COMPONENTES DE UNA HISTORIA DE USUARIO (USER STORY)

Una historia de usuario (user story) se compone te tres elementos, también conocidos como “las tres Cs” de las
historias de usuario (user stories):

1. Card (tarjeta): Toda historia de usuario (user story) debe poder describirse en una ficha de papel pequeña (postic).
Si una historia de usuario (user story) no puede describirse en ese tamaño, es una señal de que estamos traspasando
las fronteras y comunicando demasiada información que debería compartirse cara a cara.
2. Conversation (conversación): Toda historia de usuario (user story) debe tener una conversación entre el equipo
de desarrollo (ED) y el Product Owner (PO). Una comunicación cara a cara que intercambia no sólo información sino
también pensamientos, opiniones y sentimientos. Esta conversación permite asegurar que este bien lo definido en
la historia de usuario (user story). Se alinea el "qué quiero hacer" (PO) con el "cómo se puede hacer" (ED).
3. Confirmation (confirmación): Toda historia de usuario (user story) debe estar lo suficientemente explicada para
que el equipo de desarrollo (ED) sepa qué es lo que debe construir y qué es lo que el Product Owner (PO) espera.
Esto se conoce también como pruebas de aceptación.

4. REDACCIÓN DE UNA HISTORIA DE USUARIO (USER STORY)

El autor Mike Cohn sugiere una determinada forma de redactar historias de usuario (user stories) bajo el siguiente
formato:

como <nombre del rol> (representa quién necesita el requerimiento)

yo puedo <actividad> (permite segmentación de la funcionalidad el producto y ayuda a identificar otros roles)

de forma tal que <valor de negocio que recibo> (comunica porqué es necesaria la actividad, para qué se utilizará en el
negocio)

(Figura número 3, elaboración propia)

Criterios de aceptación: Se define el alcance.

Pruebas: Condiciones habituales en las que se va a utilizar la funcionalidad requerida.

Ejemplos de una historias de usuario (user stories):

Ejemplo 1°:

Como Conductor quiero buscar un destino a partir de sus coordenadas para conocer el camino a recorrer y así llegar
destino deseado.

Criterios de Aceptación: Las coordenadas se representan con tres números que indican longitud y tres números que
indican latitud. Cada número representa los grados, minutos y segundos respectivamente. Además se debe indicar la
orientación (norte, sur, este, oeste).

• Probar buscar un destino en un país y ciudad existentes, de dos coordenadas existentes (pasa).
• Probar buscar un destino en un país y ciudad existentes, de una coordenada inexistente (falla).
• Probar buscar un destino en un país y ciudad existentes, de dos coordenadas existentes sin indicar la orientación
(falla).
• Probar ingresar coordenadas de latitud y longitud válidas (pasa).
• Probar ingresar coordenadas de latitud y longitud inválidas (falla).

Ejemplo 2°:

Como usuario de OBI deseo conocer qué saldo real tengo disponible al momento de transferir en el caso de que el importe
ingresado no se permita para poder avanzar con la operación.

Consideraciones:

• Se deberá ajustar la validación contra saldo ( al momento de ingresar el importe de la transferencia) tomando el
campo "Operativo_con_bloqueo" según devuelva la API (a confirmar)
• Se deberá ajustar el mensaje "El importe ingresado es superior al saldo en tu cuenta." indicándole cuál es su saldo
disponible ( Mensaje :
"Saldo insuficiente. Tu disponible es de $ [Operativo con bloqueo] (sin contemplar acuerdos)" para el caso de CC,
y el mensaje "Saldo insuficiente. Tu disponible es de $ [Operativo con bloqueo]" para el caso de CA.
• No se deberá modificar ningún comportamiento ya desarrollado para el resto del flujo de transferencias.

Criterios de aceptación:

• Dado un usuario que ingresa a OBI y , para la cuenta seleccionada CA$ 100-2981703-2, API devuelve en el
campo "Operativo_con_bloqueo" un saldo de $1500 cuando ingresa un importe de $2000 entonces no puede
avanzar en el flujo y visualiza un mensaje
• Dado un usuario que ingresa a OBI y , para la cuenta seleccionada CA$ 100-2981703-2, API devuelve en el
campo "Operativo_con_bloqueo" un saldo de $1500 cuando ingresa un importe de $1000 entonces puede
avanzar en el flujo habilitándose el botón Continuar.
• Dado un usuario que ingresa a OBI y , para la cuenta seleccionada CC$ 100-2981703-2, API devuelve en el
campo "Operativo_con_bloqueo" un saldo de $1500 cuando ingresa un importe de $2000 entonces no puede
avanzar en el flujo y visualiza un mensaje
 • Dado un usuario que ingresa a OBI y , para la cuenta seleccionada CC$ 100-2981703-2, API devuelve en el
campo "Operativo_con_bloqueo" un saldo de $1500 cuando ingresa un importe de $1000 entonces puede
avanzar en el flujo habilitándose el botón Continuar.
• Dado un usuario que ingresa a OBI y , para la cuenta seleccionada CC$ 100-2981703-2, API devuelve en el
campo "Operativo_con_bloqueo" un saldo de - $2500 (negativo) cuando ingresa un importe de
$2000 entonces no puede avanzar en el flujo y visualiza un mensaje.
• Dado un usuario que ingresa a OBI y , para la cuenta seleccionada CC$ 100-2981703-2, API devuelve en el
campo "Operativo_con_bloqueo" un saldo de $1500 y la suma de los acuerdos es de $1000 cuando ingresa un
importe de $2000 entonces puede avanzar en el flujo habilitándose el botón Continuar.

Ejemplo 3°:

Se requiere que por BO se genere un nuevo campo de cupo diario que permita limitar la cantidad de veces que se muestra
el banner de ingreso a la encuesta de medición del NPS de OBI.

Escenario 1:

Cupo diario > 0 ingresos

• Dado un usuario de OBI cuando realiza el logout de la aplicación, la encuesta esta encendida y aún no se
cumplió el cupo diario entonces deberá visualizar la invitación para responder la encuesta.
• Dado un usuario de OBI cuando realiza el logout de la aplicación, la encuesta esta encendida y el cupo diario
ya está cubierto entonces no deberá visualizar la invitación para responder la encuesta.
• Dado un usuario de OBI cuando realiza el logout de la aplicación, la encuesta esta apagada entonces no
deberá visualizar la invitación para responder la encuesta.

Definición técnica:

• el contador deberá acumular solamente cuando el cliente seleccionó ingresar a responder la encuesta, caso
contrario no se deberá incrementar.
• El cupo se renueva diariamente.
• Se deberá mantener el mismo comportamiento para los días de descanso, tanto para el que ingresó (hoy en 90
dias) como para el cliente que seleccionó "En otro momento" (hoy en 15 dias)

Historias que entregan valor:

(Figura número 4, elaboración propia)

Las ventajas de escribir las historias de usuario (user stories) de esta forma son, principalmente:

• Primera persona: La redacción en primera persona de la historia de usuario (user story) invita a quien la lee a
ponerse en el lugar del usuario.
• Priorización: Tener esta estructura para redactar la historia de usuario (user story) ayuda al responsable del
producto a priorizar. Le permite visualizar mejor cuál es la funcionalidad, quien se beneficia y cuál es el valor de esta.
• Propósito: Conocer el propósito de una funcionalidad permite al equipo de desarrollo plantear alternativas que
cumplan con el mismo objetivo en el caso de que el costo de la funcionalidad solicitada sea alto o su construcción
no sea viable.

5. MODELO INVEST
El modelo INVEST es conjunto de características recomendadas para evaluar la calidad de una historia de usuario
(user story), el uso de la regla mnemotécnica “INVEST”, ayuda a su recordación:

• Independientes: Las historias de usuario (user stories) deben ser independientes de forma tal que no se
superpongan en funcionalidades y que puedan planificarse y desarrollarse en cualquier orden.
• Negociable: Una buena historia de usuario (user story) es negociable. No es un contrato explicito por el cual se
debe entregar todo-o-nada.
• Valuable: Debe tener valor para el cliente y para el negocio del cliente.
• Estimable: Debe poder asignarse un indicador de peso a esa historia de usuario (user story).
• Small (Pequeña): Su tamaño debe ser tal que puede terminarse y entregarse en el tiempo comprometido (iteración).
• Testeable (verificable): Poder demostrar que una historia de usuario (user story) fue implementada.

6. PUNTOS DE HISTORIA (STORY POINTS)

Es una unidad de medida específica (del equipo) de: complejidad, riesgo y esfuerzo, es lo que el "kilo" a la
unidad de nuestro sistema de medición de peso. El punto de historia (story point) da idea del "peso" de cada historia de
usuario (user story) y decide cuán grande (compleja) es.

6.1. ¿CÓMO “DECODIFICAR” LAS ESTIMACIONES?

• 0: Quizás Ud. no tenga idea de su producto o funcionalidad en este punto.
• 1/2, 1: funcionalidad pequeña (usualmente cosmética).
• 2-3: funcionalidad pequeña a mediana. Es lo que queremos.
• 5: Funcionalidad media. Es lo que queremos.
• 8: Funcionalidad grande, de todas formas lo podemos hacer, pero hay que preguntarse si no se puede partir o dividir
en algo más pequeño. No es lo mejor, pero todavía.
• 13: Alguien puede explicar por qué no lo podemos dividir?
• 20: Cuál es la razón de negocio que justifica semejante story y más fuerte aún, por qué no se puede dividir?
• 40: no hay forma de hacer esto en un sprint.
• 100: confirmación de que está algo muy mal. Mejor ni arrancar.
7. FLUJO DE UNA HISTORIA DE USUARIO (USER STORY) DEL SPRINT EN EL BOARD

1. La US antes de ser incluida en el Sprint debe contener toda la información correspondiente:

a. Título corto y simple de la funcionalidad con el formato "Yo como un [Rol], necesito [Descripción de la
funcionalidad], con la finalidad de [Descripción de la consecuencia]".
b. Descripción corta para proveer contexto.
c. Criterios de aceptación para validar la implementación de la US.
d. Pantallas definidas por el equipo de diseño (captura de la imagen o link a alguna herramienta).
e. Dependencias a Apis u otros servicios si correspondiese.
f. Toggleabilidad en caso de que corresponda.
2. Un detalle para tener en cuenta que la US no debe tener bloqueantes y las dependencias deben estar resueltas.
3. También la US deberá estimarse y en caso de que tenga una estimación de más de 3 puntos, deberá dividirse en
2 o más US.
4. Los puntos 1, 2 y 3 constituyen el DOR (Definition of Ready), lo que significa que son los requisitos esenciales que
debe tener una US en el Backlog para ser incluida en el Sprint Backlog.
5. Luego de iniciado el sprint, dentro de cada US deberán incluirse las subtareas correspondientes que irán
definiendo el trabajo a realizar sobre la misma:
a. Escenarios en Gherkin.
b. Acuerdos de contrato (en caso de que la tarea tenga desarrollo de back y front).
c. Desarrollo (front y back según corresponda).
d. Tésting
e. Documentación en Confluence si corresponde.
f. Accesibilidad
6. Luego de verificar que las US que se agregaron al Sprint poseen las tareas correspondientes, se pueden comenzar
a tomar por el equipo.
7. Los puntos siguientes detallan el flujo por el que debe pasar una US y Tareas dentro del tablero.
8. Al tomar la primera tarea de la US (pasando a la columna "En Progreso" de Jira), también significará que debe
colocarse la US "En Progreso", sumado a esto se debe asignar la tarea al desarrollador.
9. La primera tarea que debe abordarse de la US es la referida a los Escenarios, donde deberán incluirse en el
Feature correspondiente en el proyecto de test. Aquí deberá tenerse en cuenta el escenario del flujo principal
(camino feliz) del requerimiento (Caso de uso de la US), y algunos caminos alternativos que podrían ser posibles
errores de negocio. Asociado a esta tarea se deberá definir en Jira cuáles serán los escenarios a automatizar.
10. La segunda tarea a tomar será la de Acuerdos de contrato, que se realizará con integrantes del equipo tanto de
front como de back para acordar de qué manera y con qué formato se enviarán y recibirán los datos entre los
artefactos.
11. Luego podrán tomarse las tareas de Desarrollo paralelamente entre los equipos de trabajo.
12. Al finalizar una tarea, ésta debe pasar del estado "En Progreso" a "Hecho".
13. Cuando todas las tareas de la US pasan a "Hecho", la US pasará a la columna "En Testing", luego se deberá
realizar los releases correspondientes a los artefactos afectados e incluir los números de versión en la tarjeta de
jira. Aclaración: Las tarjetas que requieran testing o se puedan testear deberán cargarse como US y no como
Tarea.
14. Luego el equipo de testing realizará el deploy para que esté disponible su implementación en el ambiente de
testing.
15. La persona de Testing se encargará de probar la US en su ambiente, y de ser necesario también realizará la
prueba en el ambiente local de test para validar todas las casuísticas específicas.
16. Luego de que la US haya sido aprobada en el testing se deberá acordar una Validación por parte del PO (en caso
de que la complejidad de la US lo requiera) en una call junto al tester (y algún desarrollador en caso de que se
necesite) y poder validar que lo que se muestra en el sistema sea lo solicitado.
17. Luego de la correcta validación se moverá la US a la columna "Disponible para Prod", que derivará a la carga del
Smart para la solicitud de la implementación en el ambiente de Producción.
18. Por último, luego de que la US se haya implementado en Producción, deberá moverse a la columna de "Hecho"
en Jira.
19. Los puntos 15, 16 y 17 y 18 constituyen en parte el DOD (Definition of Done), lo que significa que las US (y por
consiguiente sus SubTareas) cumplieron todos los requisitos necesarios para ser implementadas en producción
(La US fue validada, verificada, se cumplieron los estándares de calidad y se encuentra implementada
correctamente en producción).
20. Será recomendable realizar un seguimiento de posibles errores o flujos erróneos ocurridos luego de la
implementación (verificar en logs de Kibana, métricas, logs de BD, etc)
BIBLIOGRAFÍA
Cohn, M. (2004). User Stories Applied. Addison Wesley.

Jeffries, R. (2001). Card, Conversation, Confirmation, recuperado de:

http://www.xprogramming.com/xpmag/expCardConversationConfirmation. [Consulta: 12/08/2021].

Wake, W. (2003). INVEST in Good Stories, and SMART Tasks, recuperado de: http://xp123.com/xplor/xp0308/index.shtml.
[Consulta: 12/08/2021].