@@sudoticrd es incorrecto que los analistas de Software hagan la Historia de usuario, debe ser el Product Owner, con ayuda de los que saben cómo redactarla
Me encantó como explicas el tema, lo mejor es que lo comprendí bastante bien y me da mayor seguridad para postularme a mi primer empleo (siendo estudiante del 3er semestre de informática).
Disfruto cada video porque la explicación es clara y concisa y los ejemplos muy buenos. Por otro lado, muestra mucho carisma y entusiasmo al hablar. Bien hecho!
Muchas gracias y una manera muy ágil de explicar los conceptos. Las historias de usuario las crean los stakeholders (interesados clave) junto con el product owner (quien además les brinda asesoría para hacerlo)
Gracias por la retroalimentación Gabriel! En cuanto a lo que compartes de las historias de usuario el Scrum Master tiene que apoyarlos en enseñarles como llenar historias de usuario o algún agile coach que tengan en la empresa. Realmente es responsabilidad del SM enseñar sobre el framework y eso incluye como se llenan las historias. Adicional, recuerda que tambien el development team puede ayudar al PO en el llenado de las historias. Saludos!
Muchas gracias!!!, como Analista de negocio estaba acostumbrada a los documentos largos de requerimientos y hacerlos simples en user stories se me hacia complicado., muy buena explicación!
Gran aporte Jorge, te felicito y agradezco por subir este contenido. Como sugerencia, la música me parece muy alta, e incluso si no etuviera sería mejor. Tienes una muy buena dicción y didáctica asi que no creo que necesites relleno musical, con tu voz y el contenido que es valiosísimo es suficiente
Muchas gracias Jorge por tan buen video. Claro que en videos tan breves, se abren muchas reflexiones, y la mía va en el acuerdo que las necesidades surgen de esas historias de usuario, muchas veces esas historias tendrían solución con capacitación cuando el sistema ya cuenta con ello o hay procesos que el usuario no quiere seguir, pero pensemos que ese filtro se pasa. Ahora llega al desarrollo, mis desarrolladores tienen el entrenamiento suficiente como para saber que van a construir adecuadamente ? en que momento quitamos el riesgo que usuario y desarrollador se vuelvan creadores de Frankestein y les de por sentirse empoderados para seguir montando piezas donde no debería ser? por donde re estructurar, refactorizar un sistema lleno de parches y satelites?
que buena exposicion, queria hacerle una consulta que opina del libro User Story Mapping DISCOVER THE WHOLE STORY, BUILD THE RIGHT PRODUCT lo recomienda?
Hola Jorge muy bueno el video y la información que enseñas te agradezco que hagas estos videos, te quiero realizar una consulta, si me puedes explicar ¿como diferencias entre una "regla" y un "requerimiento no funcional"? por favor Jorge atento a tus comentarios,, Saludos
Muchas gracias Carlos! Yo siempre he visto las reglas como "esto va porque va" por ejemplo si haces una app de una pizzeria y esa pizzeria previo a tener app siempre los viernes hacia una promoción del 30%, en la app que hagas tienes que implementar que los viernes de cada semana se agregue automáticamente el 30% a la compra. Son reglas "del negocio" con o sin sistema. En cuanto a los req no funcionales son más como adjetivos o adverbios, bonito, barato, rápido, seguro, confiable, usable. Algunos req no funcionales: "confiabilidad, seguridad, usabilidad" todo lo que termina con ilidad hahaha entonces cuando tengas por ejemplo, "que la pantalla sea fácil de usar y que pueda hacer tal acción con un click" al ver la palabra fácil (que por cierto es ambigua) tienes un req no funcional. Espero te sirva. =)
@@jorgeruizagile296 Gracias, es que ya iba a hacer un sprint 0 pero leí en tu blog que eso no existe y comentas acerca del Visioning Sprint pero así como explicas las cosas es mejor verlo en un vídeo con el enfoque de tu experiencia, mi tema es como comenzar a implementar SCRUM cuando ya agarras un proyecto empezado, gracias
La técnica está bien pero las frases están mal, eso de puedo tiene muchos significados y muchas veces se confunde uno, es mejor cambiar el puedo por el, necesito, después poner así podre.... Entonces pensando en un login por decir, quedaría como ejemplo: "como un administrador" necesito "crear nuevos usuarios" así podre " aumentar mis usuarios" porque si le pones el puedo, realmente no se sabe si si se va a poder o no, ya que en una técnica scrum todo cambia, se actualiza o se mejora, así que es mejor definir la idea lo más claro posible por la necesidad del usuario y no de su poder
Gracias por la explicación, tengo la duda de que pasa cuando queremos explicar un proceso donde no interviene un rol, ¿se puede indicar otro tipo de entidad? ya que es un proceso automático que no interviene una persona
Que lindo explicas! Hablas rápido pero no se nota XD, cosa que no logro... cuando expongo siento que corro mucho u_u... También la canción de fondo ayuda
Buenas tardes. @JorgeRuizAgile, Me encuentro realizando las historias de usuario, pero en el proceso de entendimiento con el usuario, presentó 3 escenarios diferentes en una liquidación. A nivel de front, la plantilla es la misma, sin embargo, por base de datos, los cálculos pueden ser diferentes debido a los escenarios planteados. Para este caso, agradezco tu orientación e n cómo plasmar estas situaciones, porque no sé si redactarlas como historias de usuario independientes o como criterios de aceptación, sin confundirse estas últimas con los escenarios de prueba que redacta el QA.
Hola estoy empezando en este mundo ágil empapándome de información, tu video está excelente. Por otro lado, me surgen dudas, espero puedas dilucidarlas. ¿Cuál sería la diferencia entre una historia de usuario y un caso de uso?, y si uso Scrum ¿me olvido completamente de los casos de uso, su documentación, sus diagramas y todo lo que a continuación conlleva? ¿es suficiente las historias de usuario para empezar a desarrollar el sistema entregando al final de cada sprint un incremento?, el tema del modelado del sistema, diagrama de clases, diagrama de actividades, etc. ¿también se realiza?. Espero puedas contestarme alguna de estas preguntas o todas, como estoy ingresando a este nuevo mundo, hay algunas cosas que no me quedan claras. Gracias de antemano por la respuesta.
Que tal Martín. Me da gusto fuera de valor el vídeo! Mira, comúnmente yo trabajo con historias de usuario más que con casos de uso por la facilidad al escribirlo y entenderlo. Pero te puedo decir que son similares en cierto aspecto, ya que los criterios de aceptación cubren los resultados esperados, y cuando una historia de usuario es muy grande o compleja, comúnmente la partimos en varias historias considerando roles o flujos como comúnmente pasa con los casos de uso. Yo te sugiero probar con solo las historias, no dupliques, y observa el valor que estas te dan con el equipo, el PO y los stakeholders. En cuanto a los diagramas o temas de arquitectura o diseño, yo sugiero que hagan una arquitectura inicial, a final de cuentas es necesaria, y que lo establezca en su definición de terminado. Espero te sirva! =)
@@jorgeruizagile296 en primer lugar, muchas gracias por el tiempo que le tomó en responderme. En segundo lugar, tomaré su sugerencia de usar únicamente las historias de usuario y es que la duda se me vino por que revisando información me topé con algunos que mezclaban ambas formas y la respuesta que usted me dio fue clave. ¡Gracias!
Hola, Jorge. Me acabo de suscribir a tu canal, me gustaron mucho tus vídeos. Excelentes las explicaciones. Quiero preguntarte... Soy analista de negocios en una empresa que esta implementando Agile. Originalmente generamos especificación de casos de uso, el documento enorme y muy detallado que lleva mucho tiempo en realizar; ahora con este cambio de metodología, este documento que es el insumo del equipo de desarrollo va a desaparecer. ¿Existe algún artefacto parecido a este documento en el Framework de Scrum? O serían tal cual las historias de usuario que se ven en este vídeo?
Hola María! muchas gracias por suscribirte al canal, te lo agradezco y gracias por el feedback positivo. En cuanto a tu pregunta, parte del "Análisis" si es trabajar en la creación de historias de usuario, tener comunicación constante con stakeholders para poder refinar estas historias, incorporar requerimientos No funcionales e incluso reglas de negocio (cosas que se hacen en un análisis tradicional) en las conversaciones de tus historias. En el framework Scrum no se habla de un documento como tal, se habla de un Product Backlog que contiene diversos elementos, pero esto no significa que no te puedas apoyar de otros documentos o información que sea de valor para actualizar tus historias. A final de cuentas, Scrum es un framework, por lo que te sugiero vivir los valores ágiles al desarrollar tu documentación de requerimientos que de igual forma te sugiero experimentar con la creación de historias. Espero te sea de valor este comentario, saludos!.
Hola un gusto recien estoy empezando a crear historias de usuarios .Y este video me ayudo mucho ya que como estudiante necesito esta información. ¿Se puede crear una historia de usuario como estudiante? Gracias.
Que tal Andrés, no lo sugiero, la idea de que los criterios vayan adelante y en un lugar tan pequeño es 1, para que lo visualices rápido ya que es de mucho valor tener criterios a la vista y 2, para ser muy concisos en los criterios, más de 3 criterios probablemente nos obligaran a partir esa historia en más historias de usuario por lo grande. En el reverso te sugiero agregues información adicional, requerimientos no funcionales (seguridad, usabilidad, etc) y reglas de negocio. Si tienes más dudas aquí estaré.
Hola , excelente video, felicitaciones !!! Jorge me podrías ayudar con la siguientes 2 dudas: 1. Si una historia de usuario tiene muchas reglas de negocio y además de esto tiene muchas datos que registrarle como requerimientos no funcionales etc. una tarjeta tan pequeña no me va a alcanzar, en este caso no hay problema en llenar otra tarjeta solo "CONVERSACION" ?. 2. si debemos crear por ejemplo un formulario para cumplir con la historia de usuario, en que parte de la historia de usuario registramos los campos que debe tener dicho formulario, que tipo de dato es, su longitud, descripción etc ?, mil gracias por tu tiempo.
Que tal Alexandre! disculpa por la "super tardanza" jaja. Mira, yo creo que es muy importante asegurarte que has partido bien tus historias de usuario, porque a veces tienes mucha información que llenar porque aún sigue siendo una Epica. De igual forma si pudieras anexar alguna otra información sin problema, solo asegúrate de que sea algo de valor y no te claves tanto con el tamaño, solo que para ti sea algo necesario y lo mínimo necesario para que puedan arrancar a desarrollarla. Espero te sirva! saludos!
¿La historia de usuario tanto en la parte del reverso como de frente es completada (o rellenada) por el product owner? ¿El equipo de desarrollo no interviene?
Que tal Pol! de hecho el PO la rellena pero debe dejar cierto espacio en la conversación para que el equipo tambien proponga en el evento de Refinement Meeting. De hecho no esta mal que el PO se apoye del equipo para realizar las historias de usuario. A mi parecer es mucho más enriquecedor y debe de darse =)
En efecto el Product Owner es el encargado de escribirlas, pero eso no significa que el equipo no vaya a ayudar en complementarlas y en algunos casos ayudarle a escribir algunas. Si tu Product Owner no tiene tiempo para hacerlo creo que es un buen momento de reflexionar si es el PO adecuado, o incluso puedes tener a alguien de apoyo transversal entre el PO y el Dev Team para apoyo en la escritura de las mismas =)
@@jorgeruizagile296, fijate que ando entrando en este mundo de scrum hice proyectos en cascada y ahora voy a lanzarme a entrar en una empresa como PM (se que en scrum no hay PM) quieren empezar a aplicar scrum el equipo de desarrollo son 4 personas por fa como diablos puede empezar con scrum sin que me de dolores de cabeza que me los va a dar pero que sean menos pero si estoy viendo que tu sabes del tema si me puedes ayudar muy agradecido hermano
@@yosmargarcia8222 hola! te sugiero primero que leas este artículo: jorgeruizagile.com/2018/08/15/los-7-errores-mas-comunes-en-una-adopcion-agil/ y después va a ser muy importante que entiendas la guía de Scrum en español que puedes bajar de Aquí: www.scrumguides.org/
@@yosmargarcia8222 Asegúrate de arrancar con una visión del equipo con el que trabajaras, con un backlog elaborado por el Product Owner y crea junto con el equipo un tablero Kanban para arrancar. y de pasadita dale un vistazo a mi vídeo de Scrum en menos de 7 minutos :) espero te sea de valor
Me encanta el contenido pero la musica de background podría tener menos volumen :( compite la atención entre tu voz y musica…. Y tu voz y sabiduría son mucho más importante que el volumen de la musica de fondo!
En buena onda, tu video parece mensaje cristiano del evangelio, con la música de fondo y el reverb que le pones a tu micrófono..... . Te falta sólo pedir dinero, sino dios no nos ayudará. Por otro lado, hay personas que le gusta todo eso, así es que buena suerte amigo y gracias por la información.
¿Quien en tu trabajo esta creando las historias de usuario? ¿Quien crees o quienes crees que deberían crearlas? me gustaría leer sus opiniones!
Los Analistas de Software con experiencia en SCRUM
@@sudoticrd que tal Miguel! así es actualmente en tu trabajo o es quien crees que debe crearlas?
En mi caso veo una confusión en mi organización en cuanto a éste punto.
@@sudoticrd es incorrecto que los analistas de Software hagan la Historia de usuario, debe ser el Product Owner, con ayuda de los que saben cómo redactarla
Raúl Andrade en mi caso yo era quien las creaba junto con el product owner
qué buena explicación, simple y precisa gracias!
Apreciado Jorge, por fin encuentro una descripción sencilla pero completa para elaborar una historia de usuario. Gracias
Excelente! que gusto que te diera valor!
Me encantó como explicas el tema, lo mejor es que lo comprendí bastante bien y me da mayor seguridad para postularme a mi primer empleo (siendo estudiante del 3er semestre de informática).
Disfruto cada video porque la explicación es clara y concisa y los ejemplos muy buenos.
Por otro lado, muestra mucho carisma y entusiasmo al hablar.
Bien hecho!
Muchas gracias y una manera muy ágil de explicar los conceptos.
Las historias de usuario las crean los stakeholders (interesados clave) junto con el product owner (quien además les brinda asesoría para hacerlo)
Gracias por la retroalimentación Gabriel! En cuanto a lo que compartes de las historias de usuario el Scrum Master tiene que apoyarlos en enseñarles como llenar historias de usuario o algún agile coach que tengan en la empresa. Realmente es responsabilidad del SM enseñar sobre el framework y eso incluye como se llenan las historias. Adicional, recuerda que tambien el development team puede ayudar al PO en el llenado de las historias. Saludos!
Jorge es la mejor explicación que he visto de Historia de Usuario. Felicitaciones
Muchas gracias Carlos! Me motiva a seguir haciendo videos. Éxito!
@@jorgeruizagile296 quien hace los historias de usuario?
Excelente el hecho de poner un ejemplo, que nos ayude a asentar el conocimiento adquirido a lo largo del vídeo.
Gracias Hugo! que bueno que te gusto!
Muchas gracias!!!, como Analista de negocio estaba acostumbrada a los documentos largos de requerimientos y hacerlos simples en user stories se me hacia complicado., muy buena explicación!
Estoy de acuerdo con Jorge, como decía mi mamá : "Más claro no canta un gallo". Te agradezco inmensamente la explicación, éxitos.
Muchas gracias!! =)
Excelente aporte, gracias por compartir con nosotros esta informacion!
La mejor explicación que he visto,mil gracias
Muy buena explicación estimado entendí bastante bien, se agradece el contenido. saludos desde Chile.
Gracias Andrés! Un abrazo desde México!
Excelente contenido. Me encantó poder ser partícipe del aprendizaje de este tema. Muchas gracias, Jorge :)
Excelente explicación, gracias por compartir
Bien tu explicación amigo.
Gracias.
Gracias por la explicación. Super claro y muy útil
Muy clara la explicación y los ejemplos. Gracias!
Muchas gracias Jorge, me encanto este resumen
Muchas gracias Paulina!! Te mando un abrazote!
Excelente explicación!
Gracias por el aporte!!
nooooooooooo increible videos, espectacular tu explicacion, bien claro y consiso
Muchas gracias Damian! me motiva mucho! seguiré compartiendo!
Gran aporte Jorge, te felicito y agradezco por subir este contenido.
Como sugerencia, la música me parece muy alta, e incluso si no etuviera sería mejor. Tienes una muy buena dicción y didáctica asi que no creo que necesites relleno musical, con tu voz y el contenido que es valiosísimo es suficiente
excelente forma de explicar este tema, mucha gracias!
Gracias por la retro Sugei! =)
gracias por compartir tus conocimientos!!!
Gracias a tí por apoyarme! te mando un abrazo!
Gracias Jorge!, excelente video muy lúdico.. Suscrito a tu canal.
Maravilloso video, gracias por el valor aportado. ❤️
Excelente explicación
Muchas Gracias, se entendió a la perfección 😁
Excelente Jorge, gracias.
Gracias Agustin!
Muchas gracias Jorge por tan buen video. Claro que en videos tan breves, se abren muchas reflexiones, y la mía va en el acuerdo que las necesidades surgen de esas historias de usuario, muchas veces esas historias tendrían solución con capacitación cuando el sistema ya cuenta con ello o hay procesos que el usuario no quiere seguir, pero pensemos que ese filtro se pasa. Ahora llega al desarrollo, mis desarrolladores tienen el entrenamiento suficiente como para saber que van a construir adecuadamente ? en que momento quitamos el riesgo que usuario y desarrollador se vuelvan creadores de Frankestein y les de por sentirse empoderados para seguir montando piezas donde no debería ser? por donde re estructurar, refactorizar un sistema lleno de parches y satelites?
Excelentemente bien explicado! Muchas gracias!
Gracias!! =)
Hermosa explicacion, muchisimas gracias
Muchas gracias Nicolas! un placer! me da gusto que te haya sido de valor!
Saludos!! Me gusto mucho tú vídeo, explicas muy bien todo y paso a paso. Mucho Éxito para tu canal.
que buena exposicion, queria hacerle una consulta que opina del libro User Story Mapping DISCOVER THE WHOLE STORY, BUILD THE RIGHT PRODUCT lo recomienda?
Excelente explicación, muchas gracias Jorge.
Muchas gracias Hector!
Muy ueno amigo, gracias y saludos desde Argentina....
Excelente video y explicación!
Muy bueno, muchas gracias...
Jorge eres la ostia tío. Me has salvado
jajaja espero te haya sido de valor! =)
Me gustó mucho tu video
Gracias!!!
Que bien explicado, muchas gracias y felicidades! Ya mismo te sigo!
Muchas gracias Bren!! Me motiva =)
Hola Jorge muy bueno el video y la información que enseñas te agradezco que hagas estos videos, te quiero realizar una consulta, si me puedes explicar ¿como diferencias entre una "regla" y un "requerimiento no funcional"? por favor Jorge atento a tus comentarios,, Saludos
Muchas gracias Carlos! Yo siempre he visto las reglas como "esto va porque va" por ejemplo si haces una app de una pizzeria y esa pizzeria previo a tener app siempre los viernes hacia una promoción del 30%, en la app que hagas tienes que implementar que los viernes de cada semana se agregue automáticamente el 30% a la compra. Son reglas "del negocio" con o sin sistema. En cuanto a los req no funcionales son más como adjetivos o adverbios, bonito, barato, rápido, seguro, confiable, usable. Algunos req no funcionales: "confiabilidad, seguridad, usabilidad" todo lo que termina con ilidad hahaha entonces cuando tengas por ejemplo, "que la pantalla sea fácil de usar y que pueda hacer tal acción con un click" al ver la palabra fácil (que por cierto es ambigua) tienes un req no funcional. Espero te sirva. =)
Muy buena Jorge. Gracias
Muy buena tu explicación, haz un video de Visioning Sprint por favor
Muchas gracias Raúl! de hecho creo que ese será mi siguiente vídeo! Espero tenerlo listo este fin de semana.
@@jorgeruizagile296 Gracias, es que ya iba a hacer un sprint 0 pero leí en tu blog que eso no existe y comentas acerca del Visioning Sprint pero así como explicas las cosas es mejor verlo en un vídeo con el enfoque de tu experiencia, mi tema es como comenzar a implementar SCRUM cuando ya agarras un proyecto empezado, gracias
Muy buena explicación
La técnica está bien pero las frases están mal, eso de puedo tiene muchos significados y muchas veces se confunde uno, es mejor cambiar el puedo por el, necesito, después poner así podre.... Entonces pensando en un login por decir, quedaría como ejemplo: "como un administrador" necesito "crear nuevos usuarios" así podre " aumentar mis usuarios" porque si le pones el puedo, realmente no se sabe si si se va a poder o no, ya que en una técnica scrum todo cambia, se actualiza o se mejora, así que es mejor definir la idea lo más claro posible por la necesidad del usuario y no de su poder
Gracias por la explicación, tengo la duda de que pasa cuando queremos explicar un proceso donde no interviene un rol, ¿se puede indicar otro tipo de entidad? ya que es un proceso automático que no interviene una persona
puedes usar la guia pmbok, ya que es enfocado en procesos. El scrum es enfocado en los roles.
Que lindo explicas! Hablas rápido pero no se nota XD, cosa que no logro... cuando expongo siento que corro mucho u_u... También la canción de fondo ayuda
Muchas gracias María! te agradezco el feedback! Mientras más tengas oportunidad de exponer y prácticas hazlo, eso ayuda muchísimo! Un abrazo!
excelente jorge felicitaciones
Muchas gracias Yosmar! seguiré echándole ganas!
Buenas tardes. @JorgeRuizAgile, Me encuentro realizando las historias de usuario, pero en el proceso de entendimiento con el usuario, presentó 3 escenarios diferentes en una liquidación. A nivel de front, la plantilla es la misma, sin embargo, por base de datos, los cálculos pueden ser diferentes debido a los escenarios planteados. Para este caso, agradezco tu orientación e n cómo plasmar estas situaciones, porque no sé si redactarlas como historias de usuario independientes o como criterios de aceptación, sin confundirse estas últimas con los escenarios de prueba que redacta el QA.
Excelente. Muchas gracias
Gracias Noelia! 😊
Hola estoy empezando en este mundo ágil empapándome de información, tu video está excelente. Por otro lado, me surgen dudas, espero puedas dilucidarlas. ¿Cuál sería la diferencia entre una historia de usuario y un caso de uso?, y si uso Scrum ¿me olvido completamente de los casos de uso, su documentación, sus diagramas y todo lo que a continuación conlleva? ¿es suficiente las historias de usuario para empezar a desarrollar el sistema entregando al final de cada sprint un incremento?, el tema del modelado del sistema, diagrama de clases, diagrama de actividades, etc. ¿también se realiza?. Espero puedas contestarme alguna de estas preguntas o todas, como estoy ingresando a este nuevo mundo, hay algunas cosas que no me quedan claras. Gracias de antemano por la respuesta.
Que tal Martín. Me da gusto fuera de valor el vídeo! Mira, comúnmente yo trabajo con historias de usuario más que con casos de uso por la facilidad al escribirlo y entenderlo. Pero te puedo decir que son similares en cierto aspecto, ya que los criterios de aceptación cubren los resultados esperados, y cuando una historia de usuario es muy grande o compleja, comúnmente la partimos en varias historias considerando roles o flujos como comúnmente pasa con los casos de uso. Yo te sugiero probar con solo las historias, no dupliques, y observa el valor que estas te dan con el equipo, el PO y los stakeholders. En cuanto a los diagramas o temas de arquitectura o diseño, yo sugiero que hagan una arquitectura inicial, a final de cuentas es necesaria, y que lo establezca en su definición de terminado. Espero te sirva! =)
@@jorgeruizagile296 en primer lugar, muchas gracias por el tiempo que le tomó en responderme. En segundo lugar, tomaré su sugerencia de usar únicamente las historias de usuario y es que la duda se me vino por que revisando información me topé con algunos que mezclaban ambas formas y la respuesta que usted me dio fue clave. ¡Gracias!
Buenas noches, tengo que hacer historias de usuario, cómo inicio?
Gracias
Hola, Jorge. Me acabo de suscribir a tu canal, me gustaron mucho tus vídeos. Excelentes las explicaciones. Quiero preguntarte... Soy analista de negocios en una empresa que esta implementando Agile. Originalmente generamos especificación de casos de uso, el documento enorme y muy detallado que lleva mucho tiempo en realizar; ahora con este cambio de metodología, este documento que es el insumo del equipo de desarrollo va a desaparecer. ¿Existe algún artefacto parecido a este documento en el Framework de Scrum? O serían tal cual las historias de usuario que se ven en este vídeo?
Hola María! muchas gracias por suscribirte al canal, te lo agradezco y gracias por el feedback positivo. En cuanto a tu pregunta, parte del "Análisis" si es trabajar en la creación de historias de usuario, tener comunicación constante con stakeholders para poder refinar estas historias, incorporar requerimientos No funcionales e incluso reglas de negocio (cosas que se hacen en un análisis tradicional) en las conversaciones de tus historias. En el framework Scrum no se habla de un documento como tal, se habla de un Product Backlog que contiene diversos elementos, pero esto no significa que no te puedas apoyar de otros documentos o información que sea de valor para actualizar tus historias. A final de cuentas, Scrum es un framework, por lo que te sugiero vivir los valores ágiles al desarrollar tu documentación de requerimientos que de igual forma te sugiero experimentar con la creación de historias. Espero te sea de valor este comentario, saludos!.
Mi profesor se explica como la callampa, gracias por el video crack
Que bueno que te gusto Elias! Saludos!
Gracias muy aleccionador
Hola un gusto recien estoy empezando a crear historias de usuarios .Y este video me ayudo mucho ya que como estudiante necesito esta información. ¿Se puede crear una historia de usuario como estudiante? Gracias.
Buen trabajo, pero el reverso de la tarjeta no entran como criterios de aceptación, tambien?
Que tal Andrés, no lo sugiero, la idea de que los criterios vayan adelante y en un lugar tan pequeño es 1, para que lo visualices rápido ya que es de mucho valor tener criterios a la vista y 2, para ser muy concisos en los criterios, más de 3 criterios probablemente nos obligaran a partir esa historia en más historias de usuario por lo grande. En el reverso te sugiero agregues información adicional, requerimientos no funcionales (seguridad, usabilidad, etc) y reglas de negocio. Si tienes más dudas aquí estaré.
Gracias me salvaste de un posible 0 en mis clases
Gracias !!!
a ti por el apoyo!
Hola , excelente video, felicitaciones !!! Jorge me podrías ayudar con la siguientes 2 dudas: 1. Si una historia de usuario tiene muchas reglas de negocio y además de esto tiene muchas datos que registrarle como requerimientos no funcionales etc. una tarjeta tan pequeña no me va a alcanzar, en este caso no hay problema en llenar otra tarjeta solo "CONVERSACION" ?. 2. si debemos crear por ejemplo un formulario para cumplir con la historia de usuario, en que parte de la historia de usuario registramos los campos que debe tener dicho formulario, que tipo de dato es, su longitud, descripción etc ?, mil gracias por tu tiempo.
Que tal Alexandre! disculpa por la "super tardanza" jaja. Mira, yo creo que es muy importante asegurarte que has partido bien tus historias de usuario, porque a veces tienes mucha información que llenar porque aún sigue siendo una Epica. De igual forma si pudieras anexar alguna otra información sin problema, solo asegúrate de que sea algo de valor y no te claves tanto con el tamaño, solo que para ti sea algo necesario y lo mínimo necesario para que puedan arrancar a desarrollarla. Espero te sirva! saludos!
Excelente!!!
Esta padre tu voz, como la colocas
La explicación estuvo muy bien hecha fue fácil de entender, pero la música de fondo es un poco molesta.
Buen video! 😊
¿La historia de usuario tanto en la parte del reverso como de frente es completada (o rellenada) por el product owner?
¿El equipo de desarrollo no interviene?
Que tal Pol! de hecho el PO la rellena pero debe dejar cierto espacio en la conversación para que el equipo tambien proponga en el evento de Refinement Meeting. De hecho no esta mal que el PO se apoye del equipo para realizar las historias de usuario. A mi parecer es mucho más enriquecedor y debe de darse =)
Quien sabe o debe saber cómo quiere o requiere que funcione el negocio? Por esa razón debe ser el usuario el que redacta la historia de usuario
Muy bueno
Gracias!
Jorge estas historias de usuario y product backlog quien se encarga de elaborarlas el product owner ??
En efecto el Product Owner es el encargado de escribirlas, pero eso no significa que el equipo no vaya a ayudar en complementarlas y en algunos casos ayudarle a escribir algunas. Si tu Product Owner no tiene tiempo para hacerlo creo que es un buen momento de reflexionar si es el PO adecuado, o incluso puedes tener a alguien de apoyo transversal entre el PO y el Dev Team para apoyo en la escritura de las mismas =)
@@jorgeruizagile296, fijate que ando entrando en este mundo de scrum hice proyectos en cascada y ahora voy a lanzarme a entrar en una empresa como PM (se que en scrum no hay PM) quieren empezar a aplicar scrum el equipo de desarrollo son 4 personas por fa como diablos puede empezar con scrum sin que me de dolores de cabeza que me los va a dar pero que sean menos pero si estoy viendo que tu sabes del tema si me puedes ayudar muy agradecido hermano
@@yosmargarcia8222 hola! te sugiero primero que leas este artículo: jorgeruizagile.com/2018/08/15/los-7-errores-mas-comunes-en-una-adopcion-agil/ y después va a ser muy importante que entiendas la guía de Scrum en español que puedes bajar de Aquí: www.scrumguides.org/
@@yosmargarcia8222 Asegúrate de arrancar con una visión del equipo con el que trabajaras, con un backlog elaborado por el Product Owner y crea junto con el equipo un tablero Kanban para arrancar. y de pasadita dale un vistazo a mi vídeo de Scrum en menos de 7 minutos :) espero te sea de valor
@@Bladth7 gracias Jorge ya con esto va aclarando todo el camino
Para los próximos videos, bájele a la música de fondo.
Me encanta el contenido pero la musica de background podría tener menos volumen :( compite la atención entre tu voz y musica…. Y tu voz y sabiduría son mucho más importante que el volumen de la musica de fondo!
Todo bien, pero la musica esta alta, gracias!
Que mania la de ponerle musica de fondo a los videos. Solo ese molesto detalle, despues genial. Buena info.
Ejemplossssss
=)!!
En buena onda, tu video parece mensaje cristiano del evangelio, con la música de fondo y el reverb que le pones a tu micrófono..... . Te falta sólo pedir dinero, sino dios no nos ayudará. Por otro lado, hay personas que le gusta todo eso, así es que buena suerte amigo y gracias por la información.
El ejemplo me parece muy general, no creo que en la vida real se así
Super el video @arangomora
Excelente explicación
Excelente explicación