No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Estrategias para poder habilitar HUs de manera efectiva

4/11
Recursos

Aportes 26

Preguntas 15

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

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.

Estrategias para poder habilitar HU de manera efectiva:

  • Contexto 鈫 Las historias de usuario como centro:

    • Entendimiento del problema: Saber que problema est谩 resolviendo, o que soluci贸n se est谩 implementando.
    • Objetivos de negocio: Entender que el retrabajo, la falta de entendimiento y la falta de calidad afecta a nuestro negocio.
    • Requerimientos t茅cnicos: Debemos entender la funcionalidad como centro, pero alrededor debemos considerar requerimientos t茅cnicos derivados (Backend).
    • Requerimientos de Transici贸n: Todas las tareas que se necesitan hacer dentro del equipo, proyecto y con el cliente para pasar de 鈥測a termin茅鈥, a 鈥測a entregu茅鈥. Temas de administraci贸n, t茅cnico(cambio de ambientes).
  • INVEST:

    • Independent: La HU debe estar lo mas independizada posible. Muchas funcionalidades = HU 茅pica.
    • Negotiable: Poder descartar historias conforme vamos avanzando en los sprints una no es tan valiosa. Poder negociar 鈫 quitar y tambi茅n priorizar cuales son las m谩s importantes.
    • Valuable: Cuando queda claro y entendido el para qu茅, nos permite saber que una historia es valiosa y saber cual es su beneficio.
    • Estimable: Para que algo sea estimable, el equipo o la persona que har谩 realidad esa funcionalidad tiene que poder decir cuanto tiempo o esfuerzo considera que le demandar谩. Si por el contrario no es capaz de estimar cuanto tiempo/esfuerzo le pueda tomar, significa que esa historia no es estimable y le falta claridad y reforzar entendimiento de la HU y refinarla.
    • Small: Se procura que sea peque帽a porque es importante darle peso al entendimiento y la conversaci贸n, no a la especificaci贸n. Lo hacemos peque帽o para provocar conversaciones que alimenten el contexto.
    • Testable: Hacerla comprobable, cuando los criterios de aceptaci贸n existen y entonces se verifica si esa HU se est谩 haciendo correcta o incorrectamente.

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谩

Siguiendo las recomendaciones, aca van un par de HU refinadas:

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

Estrategias

  1. DIMENSIONAMIENTO
  • Poder del contexto
    1. Entendimiento del problema: Entender el origen de lo que me est谩n pidiendo.
    2. Establecer objetivos del negocio: Todos debemos conocer de que manera impactan los objetivos.
    3. Requerimientos t茅cnicos: Lo que es necesario para entregar el producto.
    4. Requerimientos de Transici贸n: Considerar que entre ambientes pasan eventualidades que pueden provocar fallos inesperados.
  1. PROPIEDADES IVEST
  • Estas propiedades estan relacionadas con las historias de usuario.
  • Verificar que cada Historia de Usuario tenga estas propiedades.
    • I : Independent. Cuidar que no sean Epicas.
    • N: Negotiable. Poder de descartar historias no valiosas, negociar el orden y la priorizaci贸n.
    • V: Valuable. Toda historia de usuaria debe ser valiosa cuando queda claro el 鈥減ara que鈥.
    • E: Estimable. El equipo de desarrollo, debe de calcular el tiempo y esfuerzo que le llevara cumplir con la HU.
    • S: Small. Se da mas peso a la conversaci贸n que nos alimenten el contexto.
    • T: Testeable. Valida que los criterios de aceptaci贸n, y especifica si la HU esta siendo 鈥渃orrecta鈥 o 鈥渋ncorrecta鈥.

Clase 4: Estrategias para poder habilitar HUs de manera efectiva

4 Partes importantes:

  • 1er -> Entendimiento del problema 贸 entender el origen -> Porque nos piden el sistema
  • 2do -> Objetivos del Negocio -> Nuestro trabajo de cada d铆a afecta el negocio.
  • 3er -> Requerimientos T茅cnicos -> Se desea saber lo necesario para poder desarrollar nuestro producto.
  • 4to -> Requerimientos de transici贸n -> elementos que necesitamos saber para poder consolidar el desarrollo final de nuestro producto, es evitar que todo funciona en mi m谩quina.

Propiesdades INVEST

  • Independent: La HU debe estar lo mas independizada posible. Muchas funcionalidades = HU 茅pica.
  • Negotiable: Poder descartar historias conforme vamos avanzando en los sprints una no es tan valiosa. Poder negociar 鈫 quitar y tambi茅n priorizar cuales son las m谩s importantes.
  • Valuable: Cuando queda claro y entendido el para qu茅, nos permite saber que una historia es valiosa y saber cual es su beneficio.
  • Estimable: Para que algo sea estimable, el equipo o la persona que har谩 realidad esa funcionalidad tiene que poder decir cuanto tiempo o esfuerzo considera que le demandar谩. Si por el contrario no es capaz de estimar cuanto tiempo/esfuerzo le pueda tomar, significa que esa historia no es estimable y le falta claridad y reforzar entendimiento de la HU y refinarla.
  • Small: Se procura que sea peque帽a porque es importante darle peso al entendimiento y la conversaci贸n, no a la especificaci贸n. Lo hacemos peque帽o para provocar conversaciones que alimenten el contexto.
  • Testable: Hacerla comprobable, cuando los criterios de aceptaci贸n existen y entonces se verifica si esa HU se est谩 haciendo correcta o incorrectamente.

Nota

  • Cuidado con todo URGE es un sistema que nada es importante
  • Toda HU debe tener una historia valiosa
  • Esto es para internos colaborativos, debemos darle voz y voto a todos los colaboradores
  • Deben ser historias peque帽as, para poder ser entendible y f谩cil de dirigir
  • El Scrum te dice el qu茅 pero NO el como!!!

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.

Debemos tener el contexto total de lo que hacemos y saber que las historias viven en un conjunto donde confluyen con otras decisiones

Estrategias para poder habilitar HUs de manera efectiva

Las historias de usuario como centro, la funcionalidad como centro

4 partes a consideras:

  1. Entendimiento del problema: Entender el origen del problema que el cliente est谩 pidiendo
  2. Objetivos de negocios.
  3. Requerimientos t茅cnicos
  4. Requerimientos de transici贸n: todo lo que se necesita para pasar de 鈥測a termine鈥 a 鈥測a entregu茅鈥.

Propiedad INVEST

I - Independent (independiente)
N - Negotiable (negociable)
V - Valuable (valiosa)
E - Estimable (estimable)
S - Small (peque帽a)
T - Testable (comprobable)

De acuerdo a mi experiencia si he identificado cuando no se estima correctamente o quedan cosas no correctas en las HU hace que la negociaci贸n se m谩s compleja porque puede darse que tenga que crear o abrir HU y otras como dices no se sabe para que fueron creadas, todo efectivamente con lleva retrabajos.

que super nivel de pedagogia de este caredratico mis respetos si todo urge es porque no estamos priorizando

El dise帽o tiene que tener un objeto de ser, para requerimiento t茅cnico.

las historias de usuario deben tener propiedad INVEST, independiente, negociable, valiosa, estimable, Small, testeable

Les comparto mis apuntes sobre Propiedad INVEST:

Independiente: La historia de usuario debe estar lo m谩s simple e independiente de otras en lo posible del caso. Saber diferenciarla y no convertirla en una 茅pica.
Negociable: Se debe tomar en cuenta que no todo lo que se nos ocurre se puede llevar a cabo. Hay historias que se pueden quitar o cambiar de orden y tambi茅n saber priorizar durante el transcurso de los Spring.
Valiosa: Cuando queda claro y entendido el 鈥減ara qu茅鈥. Hay que justificar lo valiosa que puede ser una historia.
Estimable: El equipo/persona que va a llevar a cabo la tarea debe poder decir cu谩nto tiempo y esfuerzo le puede llevar, de lo contrario la historia no es estimable y que no est谩 claro o que no est谩 siendo entendida la actividad, se debe dar voz y voto al equipo/persona que va a llevar a cabo la actividad y evitar que una sola persona tome el rol de 鈥渏uicio experto鈥 y estime los tiempos y esfuerzos sin ser la que directamente la ejecute.
Peque帽a: El tama帽o de la historia debe ser peque帽a, es m谩s importante el entendiendo y conversaci贸n antes que la especificaci贸n.
Testeable/Comprobable: Cuando los criterios de aceptaci贸n existen, para validar si la historia se est谩 haciendo correcta o incorrectamente.

Para que algo sea estimable, el equipo la persona que va a hacer realidad esa funcionalidad, tiene que atreverse a decir, cuanto tiempo y cuanto esfuerzo considera que le va a llevar. Cuando una persona no tiene idea ni de que tan complejo puede ser ni de cuanto tiempo le puede llevar, es que no es estimable esa historia y lo que nos est谩 diciendo es que le falta claridad, le falta reforzar entendimiento y tenemos que rebotar estas ideas con la persona que lo va a ejecutar.

Toda historia debe ser valiosa, toda historia debe contar con un para que.

Para que algo sea estimable, el equipo o la persona que va a hacer realidad esa funcionalidad, tiene que atreverse a decir cu谩nto tiempo y cu谩nto esfuerzo considera que va a gastar.

las historias de usuario deben ser el centro del contexto conformado por el entendimiento del problema a partir del origen de esa solucion solicitada por el cliente, cual es la oportunidad de mejora o innovacion en el mercado que se quiere aprovechar. Despues de entender y comprender el problema se estabecen los objetivos del negocio hay que conocerlos para asi trabajar en conjunto por su logro, independiente de nuestro rol dentro del equipo scrum y no ser un retroceso por su desconocimiento o falta de calidad en su realizacion. Los requerimientos t茅cnicos es nuestro aporte con el conocimientos de los diferentes lengjuajes y frameworks. Por ultimo el tiempo de transicion entre el teimpo en el que el producto esta creado al producto esta entregado, segun el analisis de negocio se requieren unoc conocimientos de transicion. (actividades administrativas y tecnicas (cambios de ambientes o SO) ).

La meta es llegar a construir Historias de Usuario Independientes, Negociables, Con valor, estimables es decir que halla conocimiento tecnico y cientifico de los tiempos de ejecucion y pasos de realizacion, peque帽as y testiables o comprobables.

Independiente: que no dependa una HU de otra, que no sea en cascada (terminar 1 para empezar 2)
Negociable: en la conversaci贸n definir qu茅 tendr谩 y qu茅 no
Valiosa: que una HU no dependa de otra para generar valor
Estimable: identificar dificualtades y esfuerzos para definir bien el Sprint
Small: Debe ser peque帽a, es decir que el esfuerzo no sea demasiado, lo ideal es que sea lo m谩s peque帽a posible.
Testeable: que se pueda decir cuando la UH est谩 lista y verificarlo; que se puedan hacer pruebas y entregas de prototipos para dar lugar a modificaciones y mejora continua.

INVEST:

Independent: La HU debe estar lo mas independizada posible. Muchas funcionalidades = HU 茅pica.
Negotiable: Poder descartar historias conforme vamos avanzando en los sprints una no es tan valiosa. Poder negociar 鈫 quitar y tambi茅n priorizar cuales son las m谩s importantes.
Valuable: Cuando queda claro y entendido el para qu茅, nos permite saber que una historia es valiosa y saber cual es su beneficio.
Estimable: Para que algo sea estimable, el equipo o la persona que har谩 realidad esa funcionalidad tiene que poder decir cuanto tiempo o esfuerzo considera que le demandar谩. Si por el contrario no es capaz de estimar cuanto tiempo/esfuerzo le pueda tomar, significa que esa historia no es estimable y le falta claridad y reforzar entendimiento de la HU y refinarla.
Small: Se procura que sea peque帽a porque es importante darle peso al entendimiento y la conversaci贸n, no a la especificaci贸n. Lo hacemos peque帽o para provocar conversaciones que alimenten el contexto.
Testable: Hacerla comprobable, cuando los criterios de aceptaci贸n existen y entonces se verifica si esa HU se est谩 haciendo correcta o incorrectamente.

e. t7gi?
che 0uedo t0bw4 una svif99cnsl

Propiedades INVEST para una HU

Me gusta tambi茅n pensar que cuando todo urge, quiz谩s si tiene un impacto significativo para la organizaci贸n y de debe hacer de manera r谩pida. Sin embargo, esto deja en evidencia la mala gesti贸n de las actividades, recurso y tiempo de las organizaciones que permitieron que estas actividades llegar谩n a ser urgentes.