No tienes acceso a esta clase

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

Trabajo en equipo con Scrum Masters y Scrum Developers

7/12
Recursos

Aportes 28

Preguntas 3

Ordenar por:

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

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.

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

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

como se resuelven lo entregado, pero que requiere mejoras?? (ya que el manifiesto 谩gil se basa en entregar, no en perfecci贸n)
Veo que en el segundo escenario, est谩n abordando la estrategia de manera independiente en lugar de hacer una discusi贸n conjunta. En el tercer escenario, se est谩 excluyendo a algunos miembros del equipo durante el desarrollo del producto, lo que podr铆a resultar en consecuencias negativas, como la ausencia de un Producto M铆nimo Viable (MVP) o la falta de pruebas.
El Daily debe ser una reuni贸n 谩gil de ah铆 deben salir tareas, pero no se deben atender temas t茅cnicos

El PRODUCT OWNER **tiene que refinar **los pr贸ximos requerimientos del siguiente Sprint

Los valores:
Individuos e interacciones
software funcionando
colaboraci贸n con el cliente
Respuesta ante el camnio

En los stand up meetings, tengo entendido que puede estar, pero no participa. (product owner

Interacciones

Que tipos de conflictos entre interacciones de roles principales:
Escenario 2:
No hay una colaboraci贸n para definici贸n del producto final cumpla con los requisitos del usuario y se alinee con los objetivos comerciales.

Escenario 3:
En las reuniones debe estar todo el equipo de Scrum, para garantizar la transparencia.
Habr谩 problemas de comunicaci贸n.

Susana y Sergio tienen enfoques diferentes, aunque tienen un objetivo en com煤n, sus visiones y prioridades difieren, van a tener que llegar a un acuerdo, consensuar un punto medio, de lo contrario el engranaje del grupo se ver谩 afectado desde estos roles tan importantes.

Hola, mis respuestas para el reto

Escenario 2 y 3:

  • Se vulnera el principio 4 - responsables de negocio y desarrolladores trabajamos juntos.
  • Se vulnera el valor 1, individuos e interacciones, ya que no est谩n conversando para tener la sinergia como equipo.
  • Se vulnera el principio 6, ya que el equipo no se est谩 comunicando para lograr el mejor an谩lisis posible

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.

Escenario 2:
Un conflicto es que Susana esta enfocando la estrategia en el marketing y enganchar a los clientes, mientras que Sergio se enfoca en la experiencia de los ejecutivos de venta. Si ambos no trabajan en equipo y priorizan teniendo en cuenta ambas perspectivas puede surgir un conflicto que desv铆e el optimo desarrollo de la aplicaci贸n.

Escenario 3:
Un problema est谩 en el no permitir que tanto Santiago el Dise帽ador UX , como Luz y Gustavo quienes hacen el an谩lisis funcional; compartan experiencia y faciliten el desarrollo de la UX.

En el escenario 2 , existe un grave problema de comunicacion que hace que las 2 personas que conocen mas del negocio esten trabajando cada uno por su lado violando a su ves un principio 谩gil Colaboraci贸n , el escenario 3 al no fluir la informaci贸n en todo el equipo existe un problema de transparencia la cual en agil铆simo es importante pues toda la informaci贸n debe ser conocida por todo el equipo.

En el escenario 2 est谩n trabajando por su lado soluciones al parecer de cada uno.
En el escenario 3 est谩n trabajando independientemente y no se esta enterando de los requerimientos del cliente.

No se est谩 cumpliendo trabajo en equipo con Scrum masters ni con Scrum developers. Las interacciones son fundamentales.
Como PO se tiene que representar la voz del cliente y todas sus interacciones deben llevar esa claridad, ya que es responsable del QUE.

No estoy de acuerdo en tener al PO en las dailys, si vamos al objetivo de la Daily, que es entender si el equipo de Desarrollo tiene un bloqueante, es el Scrum master quien debe luego gestionar con el PO si hay alguna duda, mas no en la daily, ya que se pierde el objeto de la reunion y se convierte en una reunion tecnica o reunion de seguimiento

Lo que veo es que en el escenario 2 Susana y Sergio no est谩n trabajando en conjunto, no hay comunicaci贸n de equipo.
En el escenario 3 se esta dejando de lado a Luz y Gustavo quienes son los que tienen los requerimientos del producto, por ende como lo van a poder dise帽ar?

Es un gran camino a realizar para que todo el proceso marche bien y todos los colaboradores est茅n en la misma via, sobre todo es dif铆cil de implementar una mentalidad agil en equipos de trabajo cerrados al cambio y que ya trabajan de cierta manera, pero todo proceso puede ser mejorable

Caso nro 2: Por estar al mismo nivel Susana y Sergio ningun de los dos estan escuchandose y eso hace que pierdan el enfoque que le estan dando a los productos de la empresa, como Opinion deberia de existir un Lider entre ellos.
Caso nro 3: Estan cometiendo un error en no incluir a Luz y a Gustavo, ya que ellos previamente habian realizado un analisis y saben cuales son los requeriiientos especificos del sistema.

Escenario 2: Sergio y Susana no estan trabajando en equipo y ak estar al mimo nivel en el organigrama ninguno escuchara la sugerencia del otro. Por eso considero que se debe establecer un responsable de la estrategia.
Escenario 3: Santiago, no cuenta con el tiempo necesario y es posible que no le este dedicando el tiempo que requiere el proyecto y no se esta enterando de los requerimientos del cliente, ni de los impedimentos del equipo.