No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

¿Cómo hacemos Historias de Usuario a partir listas de requerimientos?

7/11
Recursos

Aportes 19

Preguntas 9

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Pasos para convertir requerimientos en HUs:

  1. Se descubren FUNCIONALIDADES en esos requerimientos
  2. Para cada una, se identifica el QUIEN (lo usaría)
  3. Para cada una se identifica el PARA QUÉ (Beneficio)
  4. A cada una se le establecen unos CRITERIOS DE ACEPTACIÓN
  5. Finalmente se identifica para cada una si existen REQUISITOS TÉCNICOS o FÓRMULAS que debamos tener en cuenta.

Una historia de usuario es la consecuencia de una análisis, es la consecuencia de ordenar las piezas de información que nos van llegando.

Resumen:
A cada item de la lista se le agrega el quien, para que, los criterios de aceptación, indica si tiene un requerimiento técnico y poner formulas.

Historias de usuarios:
Se base a los requerimientos o lista de peticiones de los usuarios.

Una lista es de una sola dimensión y es muy importante darle mas dimensiones y más categorías para tener historias de usuarios

Cuando se levanta información, se ve plana y parece una lista (una sola dimensión) A la lista de requerimientos se le debe agregar el quien y el para que y agregar los criterios de aceptación. Es opcional y posible agregar algún requerimiento tecnico si lo tiene o se deriva de el Es opcional también agregar formulas, en casos de que por ejemplo, se requieran agregar formulas o algoritmos específicos a la HU

Excelente recomendación la de tener presente si la US está relacionada a req tecnicos y/o conlleva formulas. Me encanto! Lo voy a empezar a aplicar. Gracias

creo que las formulas se ven mejor como un criterio de aceptación

  • hacer calculo con los datos 1 datos 2 y datos 3 usando la formula (dato1 + dato2)/2 ejemplo dato1 =4 dato2 =5 --> (4+5)/2 = 4.5
![](https://static.platzi.com/media/user_upload/image-40d12c26-47da-4561-996b-fce10ffdca42.jpg)

Ejemplo de una fórmula financiera simple:

**Fórmula del Interés Simple:
**

La fórmula del interés simple se utiliza para calcular la cantidad de dinero que se gana o se paga como interés en una inversión o préstamo, y se representa de la siguiente manera:

Interés Simple (I) = Capital Inicial § x Tasa de Interés ® x Tiempo (t)

Interés Simple (I): El monto de dinero ganado o pagado como interés.
Capital Inicial §: La cantidad de dinero principal en la inversión o préstamo.
Tasa de Interés ®: La tasa de interés por período (generalmente en forma decimal).
Tiempo (t): El número de períodos durante los cuales se aplica la tasa de interés.
Por ejemplo, si tienes un préstamo de $1,000 § a una tasa de interés del 5% (0.05 como r) durante 2 años (t), puedes calcular el interés simple de la siguiente manera:

I = 1,000 § x 0.05 ® x 2 (t) = $100

Por lo tanto, el interés simple en este préstamo sería de $100.

Muy buena explicacion !

La importancia de poner las historias con su contexto para minimizar los errores y tener una visión conjunta de lo que se va a realizar

En herramientas como Azure Boards, los work items se estructuran de la siguiente manera: 1. **Epics**: Representan los objetivos de alto nivel o grandes funcionalidades dentro de un proyecto. Agrupan múltiples Features. 2. **Features**: Son características específicas que brindan valor al usuario y que pueden ser desglosadas en User Stories. 3. **User Stories**: Detallan requerimientos desde la perspectiva del usuario, siguiendo la estructura "Como [tipo de usuario], quiero [acción] para [objetivo]". Aquí se especifica el quién y el para qué, alineándose con lo que aprendiste sobre su creación a partir de listas de requisitos. 4. **Tasks**: Son actividades específicas necesarias para implementar una User Story. Ayudan a desglosar el trabajo y suelen ser asignadas a miembros del equipo. Utilizando estas categorías, puedes organizar y planificar mejor los proyectos, facilitando la colaboración y visibilidad del progreso.

Particularmente siento que aunque útil los Tips los mismos deben ser reflejados en Tareas (Task) de la historia y justamente forman parte del análisis colaborativo que pueda realizar el dev team. En dichas tareas tiene que estar el desglose de los apartados técnicos incluyendo las especificaciones de cálculos de darse el caso. Con este insumo en teoría se debe tener claridad sobre el esfuerzo necesario para cumplirla. Finalmente esto da pie para poder valorar el tema del capacity y el velocity del equipo que seguramente estará en algún otro curso (espero)

Clase 7: ¿Cómo hacemos Historias de Usuario a partir listas de requerimientos?

Notas

  • La importancia de poner las historias con su contexto para minimizar los errores y tener una visión conjunta de lo que se va a realizar
  • Ayudar dar dimensiones al cliente, ayuda a sensibilizar y explicar el esfuerzo para lograr desarrollar el producto.
  • Necesitamos dar dimensiones y mas categorías al desarrollo si no tenemos algo claro, provocamos re-trabajos.
  • Siempre el primer Paso es tener la lista de funcionalidades
  • Error número 1, es tomar esa lista de funcionalidades y dar un tiempo y costo del producto
  • Recuerda tener toda la dimensiones claras, para que puedas identificar complejidad y atacarlas.

Forma de validar Hus

Lo que tengo entendido hsata ahora, es un requerimiento se puede desglosar en una o muchas HU. Esto hace que sea mas entedendible las funcionalidades
Los comentarios podrían deslizarse sin que suba el vídeo. Otro punto es que está muy grande la caja de escribir comentario y también sube el vídeo.

**Los requisitos de transición en Scrum **son como verificaciones o pruebas que se realizan para asegurarse de que una parte del proyecto está completa y funciona correctamente antes de pasar a la siguiente parte. Son como un control de calidad para garantizar que todo esté en orden antes de avanzar.

Evitemos la complejidad anunciadola con tiempo, para hacerno factibles y agregar valor

entender lo que los clientes nos piden y derivar ese esfuerzo en el derivado que es nuestro softwere pero es importante tener ademas uan dimension clara y no tener malos entendido.

entender categorizar y ordenar:
nunca nos van a dar toda la informacion ordenada y darle el orden a ese que encontramos funcionalidades, asi consideraremos el valor y el tiempo que tenemos que agregar.

seguidamente agregamos el quien y para que:
teniendo en cuenta tambien los criterios de aceptacion y ahora si tendriamos una dimension respetando la estructura del usuario

la importancia del contexto es ver las diferentes prespectivas:
sumar requerimientos tecnicos si se derivan del mismo, identificar formulas

con estas recomendaciones no solo pasamos de una lista a una historia sino en crear una verdadera planificacion colaborativa.