Trabajo en equipo con Scrum Masters y Scrum Developers
Clase 7 de 12 • Curso de Fundamentos de Product Owner
Contenido del curso
Arles A. Pinzon Molina
student•
hace 4 años
Felipe Bernardo González Barranco
student•
hace 4 años
Clase 7 de 12 • Curso de Fundamentos de Product Owner
Contenido del curso
Arles A. Pinzon Molina
Felipe Bernardo González Barranco
Joan S.TrianaV
Marylin Giugni Ortega
Yeni Alexandra Espinosa
Marylin Giugni Ortega
Jonathan Quiros Barquero
David Esteban Urrutia Rodríguez
Dani Landa
Vanessa Amaya
mhalabi
Jorge Abraham Maldonado Bazán
Silvia Isabel Lozano Argel
Maria Alejandra Naranjo
Manuel Lopez
Cesar Geovanny Rojas Mejía
Cesar Geovanny Rojas Mejía
Eleonora Peña Rodriguez
Juan Carlos Javier Vargas
Jonathan Quiros Barquero
Edwar Y. Castillo B.
Emanuel Simon Zepeda
Nilson .
Los 4 valores que salen en el manifiesto ágil:
:clap: :clap: :clap:
TRABAJO EN EQUIPO CON SCRUM MASTERS Y SCRUM DEVELOPERS
Los 4 valores que salen en el manifiesto ágil: • Individuos e interacciones sobre procesos y herramientas. • Software funcionando sobre documentación extensiva. • Comunicación con el cliente sobre negociación contractual. • Respuesta ante el cambio en lugar de seguir un plan.
Los agilistas se enfocan en individuos e interacciones sobre procesos y herramientas, no quiere decir que no se tengan procesos y no se usen herramienta, sino que para que un proceso sea efectivo, sus interacciones deben de ser de calidad y para que una herramienta cumpla su objetivo las interacciones con la herramienta son fundamentales.
Como Product Owner interactuamos mucho con diferentes perfiles, el principal objetivo que se tiene es representar la voz del cliente y hacer que se cuide, por ello, todas nuestras interacciones, todas nuestras acciones deben traer claridad, porque como Product Owner se es responsable del ¿Qué?, y este ¿Qué? Debe estar claro, y en todas las interacciones se debe de alimentar esa claridad.
La principal medida de progreso y avance es el Software funcionando, la documentación es importante pero no la extensiva o la documentación de justificación o burocrática, la documentación que se cuida es la que se enfoca en entendernos, documentar para crear una base de conocimientos que sirva para crear producto y tomar decisiones de acciones.
Los contratos son muy importantes pero la parte colaborativa es la que se procura cuidar, en la parte de colaboración con el cliente, es donde el Product Owner tiene la parte más activa porque representa al cliente, su voz, su opinión dentro de los equipos.
La agilidad es planeación a corto plazo con visión a un objetivo de largo plazo, el Product Owner cuida que cada uno de esos planes a corto plazo realmente estén enfocados al objetivo mayor y ayudar al equipo a poder adaptarse para responder a los cambios. La mejor manera de que un Product Owner pueda ayudar a responder al cambio, es explicar el origen y contexto del cambio, que al equipo le quede claro cual es el origen del cambio para poder establecer una mejor solución.
Principios fundamentales del manifiesto ágil en función del Product Owner:
• Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor: nos orienta al cliente, tener una entrega lo más temprano posible, no esperar tener un producto perfecto porque este no existe, el valor se va creando y el Product Owner máxima el valor y asegura que se pueda entregar y sobre todo recuerda para quien estamos trabajando. • Los responsables de negocio y los desarrolladores trabajamos juntos, de manera cotidiana durante todo el proyecto: se debe romper la jerarquía, se debe unir, trabajar sin intermediarios pero con moderadores. • La atención continua a la excelencia técnica y al buen diseño mejora la agilidad: el buen diseño y la excelencia técnica viene de un buen análisis, ese análisis y especificación proviene de los Product Owners, crear entornos de análisis colaborativo y poder todos cuidar la excelencia técnica y el buen diseño. Lo técnico no solo es influido por el equipo de desarrollo de software, es influido por la especificación también.
En el marco Scrum, interacciones principales que se van teniendo:
• Cuando se tiene un Backlog o pila de producto, en esta creación de backlog se debe tener en cuenta la perspectiva del equipo, por lo tanto acá ya se empieza a interactuar. • En el primer evento de scrum, sprint planning o planeación del spring se activa la planeación y estimación colaborativa para poder elegir con que elementos de trabajo se va a enfocar en el sprint siguiente. • Día a día pueden surgir cosas, lo que se desea que ocurra es avance, en algunas ocasiones ocurren impedimentos que hacen más lento o bloquean el equipo, el Product Owner puede ayudar a clarificar si es que algún impedimento tiene que ver con una especificación o con un tema de priorización y mientras el equipo va desarrollando los elementos de trabajos elegidos en la planeación el Product Owner esta refinando los elementos de trabajo que vienen para tener listos los elementos de trabajo que siguen en el próximo sprint. • Se acaba el sprint de desarrollo, y se revisa que se hizo, en la revisión del sprint el Product Owner se encarga de invitar a otros involucrados de la empresa u otros involucrados relevantes para que juntos hagan la inspección de que fue lo que el equipo trabajo, el Product Owner también debe participar de las daylis lo más que se pueda. • Antes de irse a planear otra vez, se debe de hacer una retrospectiva donde el equipo analiza las mejoras en función a como nos comunicamos y como estamos trabajando juntos.
Los conflictos que obsevo en el escenario 2, está el enfoque o la prioridad que le están dando al aplicativo, y se están ubicando cada uno en su área y sin intersección.
En el escenario 2: Se nota el conflicto de que los responsables del negocio y el desarrollo de la solución, cada uno trabaja por su lado y no hay trabajo en equipo. Están dejando de lado el valor de individuos e interacciones sobre procesos y herramientas, ya que están pensando solo en la herramienta.
En el escenario 3: Están cometiendo un error al dejar por fuera a los encargados del análisis funcional lo que puede afectar al cliente final ya que la apliación puede no cumplir con los requisitos necesarios
En el escenario 3 se está dejando fuera de las reuniones a los que participaron en el análisis funcional, por lo tanto se podría tener un producto que no cumpla con los requerimientos
Escenario 3: Equipo con experiencia mixta y poca cultura ágil
➤ Conflictos que se pueden generar:
Solución Agile:
Me ha encantado este curso! Profe Vanessa pregunta, Soy nuevo en el rol de product owner y no tengo aún conocimientos muy técnicos sobre desarrollo de software... es una buena idea invitar a los desarrolladores a las charlas con los clientes? con el fin de que ellos puedan de primera mano entender el requerimiento en aspectos tecnológicos pero adicionalmente dar una luz sobre si es viable o no? quedo atento, mil grtacias!
¡Hola David! Puedes elegir a un jefe técnico que te ayude con esa cuestión. Adicional, puedes tomar los cursos de Platzi para que te ayuden a fortalecer tus habilidades técnicas. ¡Saludos!
Hola David!
En este nuevo camino que inicias como PO necesitas entender el mundo de tu cliente y el mundo del desarrollo de software, por lo tanto te recomiendo:
Sin iniciar / Blackloge o pila de producto. Qué tiene que tener como características un elemento de trabajo para poderlo tomar y pasar a en proceso.
Sprint backlog / sprint planning: activamos la planeación y estimación colaborativa para poder elegir con qué elementos de trabajo nos vamos a enfocar en el sprint siguiente.
Daily Scrum: día con día ocurren cosas e impedimentos que hacen más lento o bloquean el equipo. Impedimentos con especificación y priorización. PO refina los requerimientos para tener listos los elementos de trabajo para los próximos sprints.
Sprint review: Ver qué fue lo que hicimos. PO se encarga de invitar a otros involucrados para que juntos hagan inspección para que vean como el equipo trabaja. Involucramiento diario. Retrospectiva: Todos los partidos están involucrados en para interactuar.
en proceso: cuando un entregable lo empiezan a hacer realidad. Qué criterios tenemos que tomar en cuenta para llegar a terminado. Verificar que algo se terminó y puede ser entregado. (está en cero por ciento porque no está terminado).
En pruebas:
Terminado: Conjunto de terminados.
Esta es una de las mejores clases de este curso, y de los cursos disponibles de SCRUM.
Reto: Que clase de conflictos puede haber dentro de las interacciones de roles principales en escenario 2 y 3 : En el escenario 2 Susana y Sergio han escogido diferentes enfoques en cuanto a público objetivo de la app para las estrategias de marketing y para la priorización de requisitos a desarrollar. En el escenario 3. Santiago no se esta relacionando con Luz y Gustavo para no hacer reuniones muy largas que le pudieran quitar mucho tiempo en la creación del diseño de experiencia de usuario lo cual puede generar desconexion y reprocesos mas adelante.
Definitivamente, me encanta este curso!
En el escenario 2, estan trabajando individualmente en una estrategia en lugar de discutirlo. En el escenario 3, se esta dejando por fuera parte del equipo durante el desarrollo del producto que puede acarrear consecuencias como un producto sin un MVP o sin testear
No esperarnos a tener "productos" perfectos!
Individuos sobre procesos e interacciones sobre herramientas... Perfecto!
Las historias de usuario son fundamentales en el rol del Product Owner (PO) dentro de Scrum. Estas permiten capturar los requisitos desde la perspectiva del usuario, facilitando la comunicación entre el equipo y las partes interesadas. El PO es responsable de definir, priorizar y gestionar estas historias para asegurar que el desarrollo se alinee con las necesidades del cliente y del negocio. Esto no solo mejora la calidad del producto, sino que también ayuda en la planificación y ejecución efectiva del trabajo del equipo.
Estimada profesora Bajo su experiencia ¿Cómo el PO podría involucrase sin afecta la comunicación entre el equipo de desarrolladores? -Entiendo que la última versión de la guía Scrum indica que los dayli para los desarrolladores pero sin obligar a que cualquier otro como el PO pueda asistir (y no participar) -Además de su asistencia que puede afectar en la comunicación de los desarrolladores y esto puede romper con el pilar de transparencia y con el valor de coraje (por no decir la verdad sobre los errores que pudieron tener).
Y si me puede dar una recomendación de donde llevar el programa y donde certificarme como Agile Coach y/o Líder agile.
Muchas Gracias
Escenario 2: Desalineación inicial (marketing vs ventas)
➤ Conflictos que se pueden generar:
Solución Agile: El Product Owner (Sergio) debe alinear objetivos de negocio, priorizar lo que aporta valor al usuario principal (ejecutivo de ventas) y usar herramientas como Impact Mapping para que todos vean el “Why” compartido.
1. Relación con el Scrum Master
El Scrum Master es un facilitador y coach del marco Scrum, no un jefe del equipo. El Product Owner debe trabajar con él para:
Ejemplo de buena práctica:
El Scrum Master facilita una reunión con gerencia para que el PO justifique la priorización del backlog usando métricas de valor.
2. Relación con los Scrum Developers
Los Scrum Developers son responsables de entregar el incremento de producto de calidad. El Product Owner debe trabajar con ellos para:
Ejemplo de buena práctica:
El PO presenta la visión de producto en la Sprint Planning y los Developers sugieren dividir una épica en tres historias más pequeñas para asegurar su entrega en el sprint.
3. Principios para un trabajo en equipo efectivo
En el caso de que algun Scrum Developer tenga dudas respecto a su Historia de Usuario asignada, puede contactar directamente con los usuarios que harán uso de esa funcionalidad en el producto de software, o solo deben contactar al Product Owner..???