Estrategias Efectivas para Historias de Usuario en Proyectos Ágiles
Contenido del curso
Karla Sequen
Vanessa Amaya
Profesor
Felipe Bernardo González Barranco
Nicolás Kryvenki
Felipe Bernardo González Barranco
Beder Danilo Casa Condori
Yeiner Morales
Luis Arturo Valdivieso
Nestor Perez
Beder Danilo Casa Condori
Sandra Sierra
Ángel Alberto Jarrín Rivas
Vanessa Amaya
ProfesorÁngel Alberto Jarrín Rivas
Julian Bohorquez
Camilo Cubides
Vanessa Amaya
Profesor
Gustavo Scipioni
LEONARD CUENCA
Alexandra Cáceres
Ogden Gómez
Diaz Mauricio
Felipe Bernardo González Barranco
Diaz Mauricio
Lina María Rojas Gómez
Alejandro Palacio Wilches
Company_adminAlejandro Palacio Wilches
Company_adminKelly Natalia Gonzalez Artunduaga
Miguel Ángel Santana Guzmán
Dani Landa
DIEGO FERNANDOCASTAÑEDALOAIZA
Vanessa Amaya
ProfesorDIEGO FERNANDOCASTAÑEDALOAIZA
Jonathan Rosales
Cuando todo urge nada realmente importa, porque si todo urge tiene la misma importancia y si tiene la misma importancia no importa el orden en que lo hago.
Amen. :)
:clap: :clap: :clap: :clap:
++Estrategias para poder habilitar HU de manera efectiva:++
Contexto → Las historias de usuario como centro:
INVEST:
Gracias!
buen resumen
Requerimientos de transicción : Los pasamos muchas veces por alto por ejemplo el tema de los ambientes de desarrollo. \n
Propiedad INVEST
I - Independent (Independiente : Muchas funcionalidades igual a HU Épica)
N - Negotiable (Negociable)
V - Valuable (Valiosa : Toda historia debe contar en un para que)
E - Estimable (Cuanto tiempo puede llevar desarrollar la HU. Si no es estimable es muy posible que le falte claridad a la Historia de Usuario)
S - Small (pequeña )
T - Testeable (Comprobable)
Si todo Urge nos falta dar prioridades a las HU.
Solo aportaria como necesario un enfoque adicional , el tema de diseño (UX/UI) como complemento a la perspectiva técnica y de negocio ya que al no considerarlo podríamos perder de vista el objetivo final, que es la experiencia que el usuario final tendrá
Estrategias
genial
Siguiendo las recomendaciones, aca van un par de HU refinadas:
¿Es válido plantear que los criterios de aceptación deben ir términos de necesidad?
¿Si el equipo de desarrollo es lo bastante experto y hábil es necesario realizar especificaciones cómo por ejemplo la estructura de un correo (en la historia de usuario)?
¿En una historia de usuario donde se requiera hacer búsqueda de información debería ser necesario plantear cómo debería ser el comportamiento? o ¿es una tarea que queda a la creatividad y decisión del UX?
Muchas gracias.
Hola Angel! Los criterios de aceptación van más en el términos de calidad, es decir, condiciones que necesitan existir para considerar que esa funcionalidad en especial se va a realizar correctamente. Dentro de esas condiciones podrían estar comportamientos esperados y ya el equipo de UX resolverá como alcanzar esos comportamientos. Recuerda que las Historias de Usuario son generadas por los Product Owners quienes se encargan del "QUE" y el equipo se encarga del "COMO".
Lo más importante de las Historias de Usuario no es su redacción sino su conversación, no son especificaciones que pasan de unas manos a otras, con conversaciones que nos ayudan a entender hacia donde vamos.
Ahora, no todo va en una historia de usuario, ejemplo, si una funcionalidad está relacionada a una fórmula matemática muy compleja, no se pone esa fórmula en la Historia pero se puede hacer referencia a ella y contar con un anexo que la explique o una hoja de cálculo que simule la fórmula para que quede claro cómo programarla y qué datos necesitamos.
Espero haya aclarado tu duda, si no, dime :)
Excelenta Vanessa. Creo que me has respondido.
No obstante, te cuento que aveces no logro entender esa "delgada línea" entre la conversación y especificar a profundidad ciertos criterios (como un comportamiento específico). Es una confusión que últimamente está presente, esto porque pasé de una empresa del sector financiero donde apenas estaban aprendiendo de HU, y normalmente se acostumbraba y me acostumbraba a la documentación extensiva. Ahora hago para de un Agile Team en una fábrica de Software y trabajamos con HU, pero siempre queda esa sensación de que la HU queda incompleta así esté completa ¿me hago entender?
¿Habría alguna sugerencia que podrías brindarnos a quienes hayamos trabajado con documentación extensiva y estemos ahora trabajando de lleno con HU?
Mil gracias por tu respuesta.
El objetivo es asegurar el entendimiento del problema y llegar a la solución correcta
Se debe entender el problema… esto es muy importante, tener el contexto claro sobre cual es la oportunidad de mejora que se quiere aprovechar, entender el origen, entender porque están pidiendo esto.
Establecer objetivos de negocio… los productos son para hacer negocio.
Requerimientos técnicos. Todo lo que hay que hacer técnicamente y muchas veces no se ve.
Requerimientos de transición, todo lo que hay que hacer para desplegar o asegurar la entrega del desarrollo,vistos buenos, procesos, cambio de ambiente, despliegue, pull request, pruebas, entre otros.
Estrategia INVEST
la historia de usuario debe ser
Independiente: debe ser una funcionalidad independiente, simple e independiente, lo mas posible.
Negociable: Poder negociar orden, priorización, funcionalidades que se hacen innecesarias.
Cuando todo urge, nada realmente importa = síntoma de que todo se esta priorizando
Valiosa: toda HU debe de ser valiosa, esto se logra dejando claro el para que de esa HU.
Estimable: debe poderse decir cuanto tiempo, esfuerzo va a tomar esa HU.
Small, pequeña: las hu deben ser como un post-it debe ser pequeña, no debe ser un documento muy largo. Debe darle prioridad a que se entienda y no a que sea especifico.
Testeable/comprobable: esto esta basado en los criterios de aceptación, se debe poder comprobar que se cumplió, basado en los criterios fe aceptación
¿Qué tal esta hu?
Hola!
Lo único que veo fuera de lo común al hacer historias de usuario es la pregunta de ¿cómo opera el sistema actualmente? y la pregunta de ¿Qué problema ayudará a resolver? va incluída en el PARA, es decir, en la estructura de la HU la parte del PARA cubre el beneficio de tener esa funcionalidad o esa característica.
En los Criterios de aceptación, evaluar si es posible agregar algo cuantitativo a cada criterio o una aclaración concreta y necesaria, por ejemplo: Se generará un identificador único para cada solicitud de crédito con el formato AA100. Se podrá ver el listado de solicitudes de crédito y su estatus, los estatus pueden ser X, Y Z. Se podrá editar una solicitud de crédito siempre y cuando XXXXXXX.
Aparte de hablar de lo que se puede, evaluar si es importante aclarar alguna restricción, es decir, algo que no se debe de permitir hacer.
Las especificaciones no se hacen solo con Historias de Usuario, si es necesario, la HU puede hacer referencia en los criterios de aceptación a otros documentos o anexos.
Estrategias para poder habilitar HUs de manera efectiva
Las historias de usuario como centro, la funcionalidad como centro
4 partes a consideras:
Propiedad INVEST
I - Independent (independiente) N - Negotiable (negociable) V - Valuable (valiosa) E - Estimable (estimable) S - Small (pequeña) T - Testable (comprobable)
Clase 4: Estrategias para poder habilitar HUs de manera efectiva
4 Partes importantes:
Propiesdades INVEST
Nota
Gracias por este apunte
Aconsejo que solo se de contexto y velar por la mejora de los desarrolladores porque si se les pone carga de negocio afecta su seguridad psicológica. Y esta última es crucial para un equipo de alto rendimiento.
Gracias
Debemos tener el contexto total de lo que hacemos y saber que las historias viven en un conjunto donde confluyen con otras decisiones
Gracias
En mi trabajo debo realizar historia de usuario por modulo, entiendo que en ese sentido cuando debo abocar varias funcionalidades hablo de una épica, ¿Cuál es el mejor camino? ¿Trabajar historias de usuario por cada funcionalidad? ¿Cómo trabajar épicas de manera clara y sencilla?
Mejorando prompt del agente IA basado en esta clase:
1. Actúa como un Product Owner profesional con conocimiento profundo de la solución XYZ.
2. Cada vez que recibas un requerimiento o idea de mejora, responde siguiendo esta estructura para generar una historia de usuario o épica, alineada a la estructura esperada por nuestro product owner y equipo de desarrollo:
A. Título: Genera un título corto pero suficientemente claro que permita entender fácilmente la funcionalidad solicitada al leer este título.
B. Objetivo del desarrollo:
- Describe el problema que se intenta resolver, por ejemplo demoras administrativas, errores en digitación, y en general consecuencias de no tener la funcionalidad propuesta implementada.
- A partir del problema mencionado en el punto anterior, describe el valor que aporta el requerimiento desde la perspectiva del usuario. En lo posible complementar con el objetivo de negocio de este requerimiento.
- Relaciona este beneficio con caracteristicas de "XYZ"como productividad, eficiencia operativa, visibilidad, control o experiencia de cliente.
- Casifica el requerimiento como de "Alto impacto", "Medio impacto", o "Bajo impacto" según el beneficio para los usuarios. Si es de "Bajo impacto" recomienda al usuario revisar nuevamente si la propuesta realmente debe ser tenida en cuenta y genera el valor suficiente al producto.
C. Alcance de la historia de usuario:
- Presenta un resumen de la solicitud con la estructura:
COMO: [Rol del usuario al que aplica la nueva funcionalidad]
QUIERO: [Funcionalidad deseada]
PARA: [Situación o necesidad que se quiere resolver]
- Enumerar los criterios de aceptación (condiciones para aceptar la funcionalidad como usuario).
- Incluir información adicional relevante para el endendimiento de la historia de usuario.
- Especificar detalladamente el alcance funcional del requerimiento, desde la perspectiva del usuario final como herramienta para facilitar el refinamiento de la historia de usuario.
- Indicar si hay funcionalidades existentes que serán ajustadas, complementadas o si se trata de una funcionalidad nueva. En caso de no poder establecer esto omitir este punto.
- Generar un estimado de tiempo de desarrollo en horas, teniendo en cuenta la complejidad de la historia, la cantidad de trabajo requerido, si con las funcionalidades actuales se tiene experiencia en la construcción y agrega tiempo basado en incertidumbre. Simula un Poker donde 5 programadores hacen una votación de las horas estimadas.
- Si la historia de usuario generada es una historía épica, es decir, contiene múltiples alcances funcionales o un módulo nuevo, recomendar historias de usuario segmentadas para separar en sprints a manera de listado. El propósito es guiar al equipo de desarrollo para implementar módulos de manera progresiva separando bloques funcionales en historias de usuario.
- Incluir un resumen a alto nivel, de los requerimientos técnicos para implementar la funcionalidad.
- Si la funcionalidad impacta al usuario de manera directa, recomendar el manejo de cambio para colaboradores y clientes (recomendar capacitación a los usuarios, una campaña previa informando el cambio, entre otros).
D. Alcance resumido para el cliente: con la estructura:
[ALCANCE]: Resume el alcance en lenguaje claro y no técnico, enfocado en los beneficios para la operación y si es posible, indicar como el desarrollo retorna la inversión.
[ENTREGABLE]: Indica qué se implementará, no debe ser muy detallado pero lo suficientemente claro para evitar reclamaciones al momento de entregar el desarrollo al cliente.
3. Mantén cada bloque claramente separado con títulos, sin usar negrilla o caractéres especiales.
4. Si el requerimiento es ambiguo, hacer preguntas 1 la vez, para tener completa claridad antes de redactar la respuesta.
5. Busca el material adjunto para endender mejor el producto, y puedes hacer búsquedas en internet sobre el sitio xyz.com u otras fuentes relevantes.
Toma una respiración profunda y trabaja este problema paso a paso. Si es necesario investiga en internet mejores prácticas de proveedores que ofrecen funcionalidades similares para proponer una historia de usuario de alto impacto que genere una propuesta de mayor valor.
Con las nuevas tecnologías de IA que están en fase de experimentación se hace dificil estimar las US, no porque no sean claras, sino por lo nuevo de la tecnología a usar.
Profe una pregunta es recomendable manejar el sprint por horas o por objetivos ?
En la parte del benefico de una HU, ¿Se podía responder a un "porque" en lugar de "para qué"?
Sí y no. Responder ¿para qué? Habla de ventajas, beneficios de hacer algo. Responder ¿por qué? Llena motivaciones, razones.
¡Saludos!
Hola, Vanessa. Me gustaría recibir tu recomendación en cuanto a la redacción de los diferentes criterios de aceptación ¿es recomendable inciar cada criterio de aceptación con un verbo en infinitivo? Ejemplo:
permitir solo caracteres numéricos en el campo documento
permitir solo 10 caracteres en el campo documento.
Muchas gracias por tu ayuda y conocimiento.
¡Hola Diego! Más que el verbo, te recomiendo lo siguiente: Aclarar lo que se debe permitir y lo que no siendo lo más concreto posibles. Aclarar cómo nos vamos a dar cuenta de que estamos desarrollando la funcionalidad correcta, es decir ¿qué condiciones se van a revisar por el Product Owner, por quien haga las pruebas y por el usuario final? para asegurar la calidad. Si algún criterio de aceptación es demasiado amplio, podemos apuntar a un anexo fuera de la Historia de Usuario, ejemplo: Apegarse al Layout A56. Y en el Layout A56 especificar todos los campos.
Espero esto te ayude, dime si quedó claro con confianza.
Saludos!
Mil gracias, Vanessa. Fuiste completamente clara en tu explicación y resolviste mi inquietud. Lo pondré en práctica.
Saludos!
¿Algún consejo que me puedan brindar para lograr que las historias sean lo suficientemente pequeñas (S) sin que pierdan su valor (V)?
Si una historia depende sí o sí de otra, ¿deja de cumplir la 'I' de Independiente? ¿Cómo se manejaria eso?
