Errores comunes al implementar historias de usuario en Scrum
Contenido del curso
Conceptos de Scrum relacionados a las HU
Creación, dimensionamiento y planeación
Recomendaciones finales
Errores comunes al implementar historias de usuario en Scrum
Errores comunes al implementar historias de usuario en Scrum
Contenido del curso
Karla Sequen
Felipe Bernardo González Barranco
Claudia Luna Aristizabal
Jubrayth Camila Molano Herrera
Fausto Jimenez
Sergio Andres Villagran
Cristhian Rodrigo Alave Sanjines
Raul Oidor
Jonathan Chiza
Gustavo Scipioni
Yeni Alexandra Espinosa
Manuel Ledezma
Omar Daniel Centeno
Manuel Ledezma
Fdiclerico@altec.com.ar
Victor Sergio Zevallos Aguilar
Felipe Bernardo González Barranco
Vanessa Amaya
Profesor
Mauricio Mejia
Diaz Mauricio
CLAUDIA ANDREA CAMPO GRIJALBA
Vanessa Amaya
Profesorjhon portilla
Vanessa Amaya
Profesor
Eduardo Valadez Sánchez
Sandra Sierra
Daniela Galvis
Vanessa Amaya
ProfesorTANIA REYES
Vanessa Amaya
ProfesorJavier Marin Ayza
Diego Alfonso
Camilo Carrillo
Julian Bohorquez
Nicolás Kryvenki
En resumen las historias fracasan porque:
:clap: :clap: :clap:
Mis HU
Genial. me parece que son idoneas
Hola, gracias por compartir este aporte es de gran ayuda para afianzar el conocimiento.
saludes, fausto jimenez suarez
En mi experiencia, lo que mas hace fallar una historia de usuasrio es que no esten escritas a nivel de funciones sino a nivel de modulos.
Esto hace que la estimacion a su vez sea a alto nivel, mas abstracta, y no a un bajo nivel, mas concreta, de tal manera que nos de mayor confianza en el estimado.
Me encanto esta parte
Excelente
Esta es mi historia de usuario:
Envío mis historias de usuario. Mi herramienta preferida es Jira, aunque éstas las hice en Trello
¿Por qué fracasan los esfuerzos de implementar Historias de Usuario?
Porque falla la simplicidad
Porque subestimamos la simplicidad
Porque no solo de historias vive scrum
Una Historia de Usuario fracasa cuando no cumple con el invest reduciendo la complejidad y esfuerzo. Independiente - Negociable - Valor - Estimable - Small - Testeable
Geniales los recursos, creo que les faltó adjuntar el caso de estudio, saludos.
Hola
Seguro aparece el documento en breve. Mientras tanto te lo paso desde el enlace de drive ;)
saludos
Muchas gracias, Saludos
Hola, te recomiendo que seas especifico en que datos quieres cargar del cliente. Es obligatorio especificar cada unos de los datos que vas a cargar.
Que es una epica?
Hola! Una EPICA es una historia de usuario demasiado grande para ser estimable o ser completada en poco tiempo (2 o 3 días) Digamos que es una descripción de varias características y funcionalidades en formato de historia de usuario, pero una historia va independizada, es decir, describe una sola característica o funcionalidad.
MI historia de usuario:
Clave – Registro de ingresos mensuales
Quién Yo como <asesor comercial> Qué lo que quiero es <registrar los ingresos mensuales del cliente> Para qué Para lograr / con el objetivo de / para obtener el beneficio de <que el sistema calcule si es apto para credito > Criterios de aceptación 1 Que el valor ingresado sea positivo 2 Que el valor este en COP 3 Que el valor ingresado sea un numero entero 4 Debe existir solo 1 valor por cada cliente N Condición n
chevere
Buenas tardes profesora :)
Soy completamente nueva en este tema, vengo del curso de Scrum y me gustaría obtener consejos, sugerencias, oportunidades de mejora de mi trabajo.
Todos los comentarios que pueda hacerme para seguir aprendiendo.
Pd. Con que aplicación puedo hacerlo sin usar word?
Muchas gracias
Hola Claudia! gracias por la dedicación! aquí te pongo mis comentarios: La HU CFM001 es más una épica que una historia porque estas hablando de características en general de la aplicación. No está mal que exista, solo aprender a diferenciar una Historia a una épica. La HU - CFN003 en la descripción dice algo de que en la misma página se pueda crear una nueva, eso es más un criterio de aceptación.
En general te recomiendo afinar en las descripciones que quede claro el para qué, que no sea redundante con el qué... El Para qué de una historia es importante que transmita por qué esa historia existe y es importante.... es decir, qué se quiere lograr: decidir, mejorar, optimizar, provocar, motivar,....
que tan extensas pueden ser las HU , que margen de volumen puede ser un estandar?
Hola Jhon!
No hay un estándar, para respetar que sean simples lo que hay que cuidar es que describan una sola funcionalidad. Sobre la cantidad de criterios de aceptación no hay un estándar, lo que yo hago es que cuando hay más de 7 criterios de aceptación, reflexiono con el equipo si podríamos partir esa historia de usuario en mas de una historia.
¿Alguien que me ayude como subir mis imagenes? y ¿Quién los revisa para darle seguimiento de que estan bien? ve casos en los que la gente no leyeron el requerimiento y ponen sus crterios en base a una idea pero la actividad es leer y subir el ejercicio.
Eduardo, para subir una imagen, solo la arrastras a la cajita de aportes. Le puedes dar preview y ya luego clic en publicar.
Hola! Quisiera saber de qué parte exactamente del caso se construyen las historias de usuario. De los requerimientos funcionales ? de ahí se desglosan las historias de usuario? Es un campo totalmente nuevo para mi y aun me genera confusiones
Hola Daniela! Si, de los requisitos funcionales.
La historia de usuario describe una funcionalidad necesitada.
Comparto mi práctica, espero me haya quedado claro. Intente subir el archivo o imagen pero en ambos no me dejó. Entendí?
1 Como Ejecutivo comercial quiero capturar/digitalizar documentos de posibles clientes para poder validar el otorgamiento de un crédito. Criterios de aceptación 1 Se requiere capturar/digitalizar una identificación oficial, comprobante de ingresos y comprobante de domicilio. La identificación oficial, será válida cuando la fecha de vencimiento sea mayor a la fecha actual, la vigencia del comprobante de ingresos debe ser no mayor a un mes y la vigencia del comprobante de domicilio debe ser no mayor a tres meses. 2 Captura automática "Realizar el encuadre (mostrar marco guía en color llamativo), puesta en foco y disparo sin que el Ejecutivo comercial deba presionar ningún botón." Repetir toma Se debe permitir descartar la toma de un documento para poder repetir la toma en caso que sea necesario o no sea clara la imagen. 3 Tipo de identificación oficial Para la identificación oficial, existirán dos opciones: Credencial para votar con fotografía y Pasaporte. Además en caso que sea INE, se debeberá capturar anverso y reverso.
2 Como Ejecutivo de cuenta quiero crear una nueva solicitud para poder validar el otorgamiento de un crédito a un posible cliente. Criterios de aceptación 1 Ejecutivo de cuenta Solo el ejecutivo de cuenta podrá ingresar una nueva solicitud a la aplicación. 2 Identificador único A cada nueva solicitud que registre el Ejecutivo de cuenta, se le debe asignar un identificador único.
3 Como Ejecutivo de cuenta quiero consultar las solicitudes que han sido procesadas para dar seguimiento y consultar su estatus. Criterios de aceptación 1 Consulta Las solicitudes corresponderán únicamente aquellas que han sido procesadas por el Ejecutivo de Cuenta, así como su estatus. 2 Solicitud existente Si la opción elegida se trata de una solicitud existente, el aplicativo deberá permitir visualizar el estatus de su validación.
4 Como Ejecutivo de cuenta quiero guardar la huella digital del cliente para asegurar en futuros tratos que se trata de la misma persona. Criterios de aceptación 1 Cantidad de huellas Se deben de guardar de 2 a 5 huellas digitales. 2 Identificación vs huellas Se deben validar las huellas vs la identificación que se presente.
5 Como Ejecutivo de cuenta quiero registrar una prueba de vida del posible cliente para validar que la persona está yendo a entregar su documentación voluntariamente . Criterios de aceptación 1 Video Grabar un movimiento en vivo de su cara para validar la foto de la identificación oficial.
Si, está correcto. donde te sugiero, tanto para el ejercicio como para la vida real, buscar que haya por lo menos 3 criterios de aceptación para cada Historia. No es una regla, si tú considerasque con 1 o 2 está bien, adelante...
Hola tengo una duda, supongamos un típico programa con diversos tipos de usuarios: admin, editor, gestor, user, invitado... por decir algunos.
Al escribir la historia de usuario donde se indica por ejemplo la funcionalidad de borrar publicaciones teniendo en cuenta que admin, editor y gestor pueden y los otros 2 no.
Deberíamos escribir una historia de usuario por cada tipo de usuario. Es decir:
Como admin quiero borrar publicaciones para poder controlar que se publica en el programa.
Como gestor quiero borrar publicaciones para poder controlar que se publica en el programa.
Como editor quiero borrar publicaciones para poder controlar que se publica en el programa.
Serían 3 historias de usuario que son casi repetidas, imaginate un programa muy grande con diversos tipos de usuario.
Cada funcionalidad se debe crear una historia de usuario para cada tipo de usuario? o se realizaría de otro modo.
Me gustaria leerlos mejora la calidad de la imagen! por fa!
Debe describir una sola funcionalidad y no un modulo completo
Se subestima la funcionalidad de para que y para quien
Técnica del buyer persona, podrían servir para definir el para quien.
Se debe dejar claro el para que, el contexto
Documentar para podernos entender