Planificación, Refinamiento, Sprints y el Rol del Product Manager / Owner | Ep. 113

[@sandravalle4197]

Excelente

[@CoffeePower]

Muchas Gracias! Saludos ☕️🔌

[@jhonnyramirezzeballos9106]

25:00 me convenciste de cambiar el Sprint por el Release.

[@sandravalle4197]

Podrian hacer uno sobre lus indicadores

[@CoffeePower]

Claro que si, vamos a poner a nuestro equipo a trabajar en eso ☕️🔌

[@Diego_UG]

Un lugar donde disfrute de una metodología de desarrollo fue en SIIGO, aunque no pegue en el tema de las tecnologías que estaban manejando (cuento de otro comentario), la metodología era genial, la disfrute mucho, y aunque era la parte final del proceso (el desarrollador) si lograba entender todo el proceso, me hacían parte del proceso mismo, nos capacitaban, nos explicaban las decisiones, ese solo echo hacia que me sintiera motivado a realizar ese desarrollo

[@Diego_UG]

Refinamiento, como dijiste, esta es la clave

[@davedelgadodigital]

Me gustó el episodio. Como dice Tito: Contenido de Calidad 💯. Tuve la fortuna de trabajar con Oz y coincido con su metodología de los releases completos en lugar de los Sprints, hacen que el valor entregado sea efectivo y los objetivos estén claros lo cual lo motiva a uno a encontrar formas de lograrlos 🎯 💪. Super importante la comunicación 🗝️ para manejar el cambio constante e imprevistos que puedan surgir y que el área de negocio esté informada 🗨️. En cuanto a herramientas para gestion de tareas, me gusta ClickUp entre todas, aunque vuelve locos a muchos 😂

[@CoffeePower]

Crack Dave, saludos

[@Diego_UG]

Me gusta mucho el tema de los indicadores, creo que la clave del exito de un producto es la medición, y como dices, una medición de producto, de diseño o de negocio puede apalancarse con los indicadores técnicos, genial

[@Diego_UG]

y claro, estos indicadores son capaces de conectar equipos, mejorar la comunicacion

[@Diego_UG]

Creo que un buen MVP que cualquiera puede practicar es gestionar su vida, su familia, TechLead empatico, eficiente, comunicativo, en general hasta puede tener equipos, finanzas, producto, desarrollo, etc, o bueno asi me gusta practicar :D mientras soy dev

[@Diego_UG]

ha y bueno, mentoreo a mis amigos a programar usando proyectos, no les hago, los guió para trabajar en equipo, tengo 3 proyectos marchando con esta metodología, y si bien no es a gran escala se puede trabajar en equipo y se hereda el conocimiento

[@juansebastiantrillosmelo6259]

Hola! los sigo hace unas semanas y me ha encantando el contenido que hacen en este canal, sobre todo por la cercanía y el conocmiento que tienen del negocio. Tengo una pregunta frente al tema de los KPIs técnicos: existen un sin número de KPIs relevantes para entender el comportamiento de los equipos de desarrollo de SW, mi pregunta va orientada a entender cuales deberían ser los más prioritarios?, hace sentido darle seguimiento 50+ indicadores técnicos? Gracias!!

[@CoffeePower]

¡Hola Juan Sebastian! Excelente pregunta. Es cierto que hay muchos KPIs técnicos, pero te recomendaría enfocarte en los principales que realmente aporten valor. Los DORA metrics (Frecuencia de Despliegue, Tiempo de Ciclo de Cambio, Tiempo de Recuperación y Tasa de Falla de Cambio) son un excelente punto de partida. En nuestra última Masterclass hablamos de ellos en profundidad. Recuerda que no se trata de medir todo, sino de medir lo que realmente importa y te ayudará a mejorar. ¡Gracias por tu pregunta y espero que sigas disfrutando del contenido del canal!

[@Diego_UG]

que genial la idea de cambiar el sprint por el release, a esto se le puede aplicar la metodología del MVP? para prevenir que se agrande un montón, que dure un montón, que opinas?

[@Diego_UG]

y bueno, el tito me genero otra pregunta, que cosas deberían salir con el release? (monitoreo, métricas, indicadores) o puede salir de forma posterior, o un MVP de indicadores, no se?

[@Diego_UG]

otra pregunta que me generaste, las metodologías pueden evolucionar? de kamban a sprint release? o cual seria la forma

[@CoffeePower]

Hola Diego, gracias por tu pregunta. Veo que estás haciendo una conexión interesante entre algunos conceptos importantes de desarrollo de software: sprints, releases y el Producto Mínimo Viable (MVP, por sus siglas en inglés). Primero, recordemos que un "sprint" es una unidad de tiempo (generalmente de 1 a 4 semanas) durante la cual se planea y se completa un conjunto de trabajo en un marco de trabajo de desarrollo de software ágil como Scrum. Un "release", por otro lado, es cuando se entrega un conjunto de funcionalidades que se consideran listas para ser utilizadas por los usuarios finales. En términos de MVP, es una estrategia de desarrollo de producto en la que se lanza una nueva producto o característica con suficientes características para atraer a los primeros usuarios y proporcionar retroalimentación para el desarrollo futuro. La idea es lanzar un producto mínimo que funcione y agregar características y funcionalidades con el tiempo en función de la retroalimentación y los datos recopilados de los usuarios. Sí, puedes aplicar la metodología del MVP al cambiar el enfoque de sprint a release. Esto implica pensar en términos de entregables funcionales completos que agreguen valor a los usuarios, en lugar de simplemente marcar tareas como completadas en un sprint. Así puedes prevenir que se agrande demasiado un proyecto o que se alargue demasiado el tiempo. Es importante tener en cuenta que la implementación de esta estrategia requiere una comunicación clara y abierta entre todas las partes interesadas, incluyendo los desarrolladores, el equipo de gestión de proyectos y los usuarios finales. También necesitarás tener un buen entendimiento de tus usuarios y sus necesidades para poder determinar cuál es el MVP adecuado. Espero que esto aclare tu duda. Si tienes alguna otra pregunta, no dudes en hacerla.

[@Diego_UG]

la metodología de OKR resultados claves que se ajusta por Q hay que saberla enseñar para que las personas no se sientan presionadas, si no que se sientan motivadas a empujar al producto, a la empresa, y todo eso es un reto, pero creo que un TechLead hábil es capaz de transformarse para impulsar a todos los miembros del equipo no importando su personalidad

[@Diego_UG]

respecto a las herramientas de administración e proyectos he conocido 3, trello (simple pero eficiente), Azure Devops (robusto, interesante, me gusto, el punto completo es la configuración pero apenas esta queda uff, se puede adaptar a las necesidades del equipo) y clickup (me tiene loco, me confunde mucho) pero como dices no se trata tanto de la herramienta si no mas bien de la necesidad del producto, a mi me gusta mucho las historias de usuario, criterios de aceptación, creo que esta bien gestionada es brutal

[@Diego_UG]

Pregunta: un teckLead desarrolla? la respuesta primera es si (para mi) pero creo que este es muy importante en el refinamiento, y esto podría quitarle mucho tiempo en el prework, si?

[@CoffeePower]

Hola Diego, La pregunta que planteas sobre si un Tech Lead desarrolla es bastante común y la respuesta puede variar dependiendo de la organización, el tamaño del equipo y el proyecto. En general, se espera que un Tech Lead tenga la capacidad de desarrollar, ya que su papel principal es proporcionar orientación técnica y toma de decisiones en un proyecto de desarrollo. Sin embargo, la cantidad de tiempo que pasa efectivamente escribiendo código puede variar. En algunos casos, un Tech Lead podría pasar la mayor parte de su tiempo en actividades de liderazgo y gestión, tales como la planificación y la coordinación de tareas, la revisión de código, la resolución de problemas técnicos, la toma de decisiones arquitectónicas, la mentoría de otros desarrolladores, y sí, como mencionaste, en el refinamiento y la definición de los requisitos y las historias de usuario. Por otro lado, en otros casos, especialmente en equipos más pequeños o en etapas iniciales de un proyecto, un Tech Lead podría pasar una cantidad significativa de tiempo desarrollando y escribiendo código. Por lo tanto, sí, es probable que el tiempo dedicado a las tareas de liderazgo y gestión, incluyendo el refinamiento, pueda reducir la cantidad de tiempo que un Tech Lead pasa desarrollando. Sin embargo, es parte de su rol asegurarse de que el equipo esté bien coordinado y trabajando de manera eficiente, por lo que es una parte importante de su trabajo. Además, es importante tener en cuenta que ser un Tech Lead no solo trata de tener habilidades técnicas, sino también habilidades de liderazgo y gestión. Por lo tanto, aunque puedan pasar menos tiempo escribiendo código, su contribución al equipo y al proyecto puede ser igualmente o incluso más valiosa.

[@Diego_UG]

Me siento solo, he motivado donde trabajo a que usen muchas de estas practicas, pero nada, no pasa, no quiero reconocimiento, solo quiero que entreguemos un producto mejor, me gustaría poder responder esta pregunta, como ayudo a mi equipo, a mi empresa a que use estas metodologías? me va tocar el master class pronto, me estoy planeando para esto, voy a explorar esta respuesta.

[@Diego_UG]

disculpen por atacar los comentarios, muchas gracias, que genial charla tuve con ustedes, un saludo

[@CoffeePower]

Hola Diego, lamento escuchar que te sientes solo en este camino. A veces, impulsar el cambio puede ser un desafío. Pero tu motivación y compromiso son cruciales. Te recomendaría que te unas a nuestro próximo Masterclass. Te proporcionará herramientas y estrategias para ayudar a implementar estas prácticas en tu equipo y empresa. Recuerda que los cupos son limitados, ¡así que no pierdas la oportunidad! Usa este código para que tengas un 30% OFF "CAFETERO30". Tu dedicación a entregar un producto mejor es admirable, y estoy seguro de que tendrás un impacto positivo. ¡Sigue adelante!

[@errrzarrr]

Siempre me han parecido extraños y rimbombantes esos términos tipo Product OWNER, Scrum MÁSTER. Usando un término gringo, dan un _"cringe"_ fuerte y un tufillo a secta religiosa.