Logra una comunicación efectiva entre el equipo y el negocio

Clase 8 de 30 • Introducción a las Metodologías Ágiles 2017

Resumen

La comunicación es fundamental, es un vínculo entre todas las partes involucradas.

Stakeholder, se le comunican tiempos, costos, problemas.
Negocio-Equipo, un vínculo entre roadmap y historias de usuario

Stakeholders, todas las personas que nos supervisan

Juan Lafuente

student•

La comunicación es esencial para cualquier implementación de metodologías agiles, es la base del flujo de información entre los miembros del equipo y el negocio, es un vínculo entre una parte y otra, los miembros del equipo o los que están involucrados (Stakeholders) los dueños del negocio/producto, la comunicación siempre debe estar presente en cada uno de los proyectos de agile.

Para una comunicación de calidad dentro de los miembros hay que identificarlos, en las metodologías agiles tenemos:

Los Stakeholders, Es el dueño del negocio/producto y personas que supervisan desde el punto de vista administrativo que tiene interés en el proyecto, basados en 3 puntos fundamentales de la comunicación:
- ¿Estamos en tiempo?
  - Esto quiere decir que se basa en resultados, que se ha terminado hasta el momento.
  - Si estamos a tiempo, si no lo estamos, que es lo que falta, que es lo que se ha terminado, etc
- ¿Estamos en costo?
  - Tenemos todavía cabida dentro del presupuesto, que puede ser predecible si llegamos a tener una estimación correcta al momento de hacer las iteraciones (sprints).
  - Estamos dentro del presupuesto o si no lo estamos, si es un contrato fijo o si es un contrato que se puede extender o si tenemos alguna perdida monetaria
- ¿Problemas?
  - Si hay algún tipo de problema que a mayor predicción de lo que tenemos que hacer menores van a ser estos defectos o problemas que se puedan presentar.
  - Si hay problemas como se pueden solucionar, si hay un camino recorrido para buscar una solución eficiente o si se debe canalizar a otra parte para que se pueda encontrar dicha solución.
Product Owner (Duseño del Negocio), es alguien designado específicamente para supervisar y asesorar desde el punto de vista del cliente al equipo.
Equipo, que son todos los diseñadores, desarrolladores, tester, devops, etc., que hacen todas las tareas dentro del backlog.

Por parte del Negocio y el Equipo, hay un canal de comunicación muy específico,

Roadmap (CLIENTE), Es una descripción del valor del producto, es decir, es una descripción de lo que el cliente espera o que es lo que el cliente quiere hacer.
Historias de Usuario (EQUIPO), Es la personificación de cada uno de estos requerimientos y el equipo dice: “entendemos que quieres hacer esto”. Si la historia cumple con el criterio de aceptación, es decir, que espera el cliente de esa pequeña tarea se puede integrar una vez que se haya hecho de manera correcta.

Sofía Buendía Sterling

student•

GRACIAS SUPER BUENO ESTE RESUMEN

Jasan Azael Hernández Bautista

student•

Los Stakeholders no son los dueños del producto, simplemente tienen un interés monetario en una compañía u organización que pueden afectar o ser afectados por el negocio(son como inversionistas). El dueño del producto puede ser el Product Owner o el cliente final.

Pedro Mugartegui.

student•

La comunicación es la base de toda metodología Agile, sin la comunicación constante puede que nuestro proceso en la metodología tenga problemas a futuro.

Carlos Salazar

student•

Buen vídeo para entrar en contexto!

Óscar Moreno

student•

Esto es muy importante ya que la mayoria de las veces el Equipo de trabajo desconoce el core del negocio. y se enfocan en sus tareas particulares sin ver la importancia de su labor dentro del Global del proyecto.

Liseth Lopez

student•

Para una comunicación de calidad dentro de los miembros hay que identificarlos.

Stakeholders, todas las personas que nos supervisan basados en tres puntos fundamentales (tiempo, costo y problemas)
Produc owner
Equipo

Carlos Eduardo Céspedes Angulo

student•

¿Alguien puede compartir por acá un modelo de ese roadmap mencionado por el Prof. Daniel? :) ¡Mil gracias!

Luis Felipe Panta Vilchez

student•

No entiendo algo, osea creo la historia de usuario, luego la desarrollo en codigo y despues le aviso al product owner que ya esta listo? o primero creo la historia de usuario y sin crear nada codigo le aviso al product owner que asi es como lo voy a hacer?

islasdavBIT

student•

Tengo entendido que la parte de historia de usuario es tu interpretación del requerimiento (no la programación del código), se la envías al Product Owner para su aprobación, en el caso de ser aceptada se integra al Release.

CRISTIAN VALENCIA VARGAS

student•

Tal cual lo menciona @islasdavBIT lo entendí yo. En esto momentos del curso estamos dimensionando todo el proceso de comunicación, por ello creo que no tienes que desarrollar código en esta parte del proceso.

Luis Enrique Bados Salas

student•

Roadmap

Víctor Hugo Pérez Gómez

student•

Conversaciones todo el tiempo: A mayor predicción, menor número de problemas.

Jean Paul Zuñiga Maradiegue

student•

No explicaron ni incluyerón al scrum master…

Celina

student•

Daniel, en la comunicación efectiva. en las actividades que realizó considero que siempre hago dos papeles de Stakeholders y product owner(conozco requerimientos del cliente y los comunicó)
Crees que esto hace algún problema

Enrique Alexis Lopez Araujo

student•

Pudieras ser un rol que aun no se ha mencionado y muy importante que es es el BA o Subject Material Expert, son personas que saben del negocio y ayudan al equipo de desarrollo a interpretar en lenguaje para el equipo de desarrollo que se requiere, realmente el PO (Product owner) es el que financia el equipo de desarrollo o founder del producto, sabe del negocio y tiene claro la vision del producto el financia el proyecto.

Celina

student•

Estas partes involucradas me interesa comprenderlas bien, para sacarles el provecho y redireccionarla hacia las actividades que yo realizo.

Julian Osorio

student•

Es muy importante desde el inicio del proyecto identificar bien todos estos Stackeholders ya que estos son los que saben de las funcionalidades que se van a desarrollar en el proyecto, si no se identifican a tiempo se presta para que mas adelanten en el proyecto hayan reprocesos o feedbacks que no permitan continuar con la ejecución correcta de este.

Marco Antonio Guerrero Alfaro

student•

Muy útil lo del roadmap, ese feedback, que se le da al usuario de que esto fue lo que se entendió por parte del equipo es base para empezar a trabajar el proyecto, sino el usuario asumirá que le entendiste algo que el no supo ni explicar a veces y que se presenten ese tipo de observaciones a final del py es fatal.

José Alberto Ortiz Vargas

student•

NOTAS DE LA CLASE

La comunicación es esencial para cualquier implementación de metodologías agiles, es la base del flujo de información entre los miembros del equipo y el negocio.
La comunicación es un vínculo entre una parte y otra, puede ser entre miembros del equipo o los que están involucrados. En este caso los Stakeholders, los dueños del negocio/producto y el equipo.
Un stakeholder es esa parte involucrada desde el punto de vista administrativo que tiene interés en el proyecto, la comunicación siempre debe ser presente en cada uno de los proyectos de agile.
El stakeholder se basa en 3 puntos fundamentales de comunicación:

¿Estamos en tiempo? Esto quiere decir que se basa en resultados, que se ha terminado hasta el momento.
¿Estamos en costo? Tenemos todavía cabida dentro del presupuesto, que puede ser predecible si llegamos a tener una estimación correcta al momento de hacer las iteraciones.
¿Problemas? Si hay algún tipo de problema que a mayor predicción de lo que tenemos que hacer menores van a ser estos defectos o problemas que se puedan presentar.
Por parte del Negocio y el Equipo, hay un canal de comunicación muy específico, a través de un roadmap que es una descripción del valor del producto, es decir, es una descripción de lo que el cliente espera o que es lo que el cliente quiere hacer. Y el equipo le contesta con historias de usuario, personifica cada uno de estos requerimientos y el equipo le dice, nosotros entendemos que quieres hacer esto. Si la historia cumple con el criterio de aceptación, es decir, que espera el cliente de esa pequeña tarea se puede integrar una vez que se haya hecho de manera correcta, si no, se regresa a lo que es el backlog y se vuelve a iniciar el ciclo.
Nosotros entendemos lo que quiere el cliente, si el cliente lo aprueba se integra propiamente al reléase, si no, se vuelve a integrar al backlog y se hace la iteración las veces que sean necesarias hasta que el cliente este satisfecho con lo que se realizó.
Para una comunicación de calidad dentro de los miembros hay que identificarlos, hasta ahorita en las metodologías agiles tenemos:
Los Stakeholders que son todas aquellas personas que supervisan desde un punto de vista de estado, si estamos a tiempo, si no lo estamos, que es lo que falta, que es lo que se ha terminado, etc.
Desde un punto de vista de costos, estamos dentro del presupuesto o si no lo estamos, si s un contrato fijo o si es un contrato que se puede extender o si tenemos alguna perdida monetaria.
Y desde el punto de vista de los problemas, si hay problemas como se pueden solucionar, si hay un camino recorrido para buscar una solución eficiente o si se debe canalizar a otra parte para que se pueda encontrar dicha solución.
Cualquier miembro del equipo puede abordar al Stakeholders y viceversa para tener una uniformidad de la información y que sea una transparencia.
También tenemos al Product Owner (Duseño del Negocio) que es alguien designado específicamente para supervisar y asesorar desde el punto de vista del cliente al equipo.
Y tenemos a nuestro equipo que son todos los diseñadores, desarrolladores, tester, devops, etc., que hacen todas las tareas dentro del backlog.

Osvaldo Romero

student•

Yo tenía entendido que el product owner es el que escribe las historias de usuario, define su criterio de aceptación y las va priorizando. El equipo con esta información la estima y retroalimenta la historia, pero en si no genera la historia. Se contradice un poco en lo que explica en este video.

Melisa Lozano

student•

Hola ovaromero, te comparto que son los desarrolladores quienes construyen la historia y los Product Owners escriben las pruebas de aceptación. Saludos!

edwar enrique vilchez serrano

student•

Yo cambiaria la palabra predicción por estimación. Para poder ubicarnos en el contexto de lo que estamos trabajando

Melisa Lozano

student•

Hola, el profesor se refiere a “predecir” lo que se tiene que hacer (carga de trabajo) para dismuniur los problemas que se pueden presentar, con predicción no solo se refiere a la estimación de los costos. Saludos!

Luís Hernández

student•

Estimación va guiada más a costos