Actividad Q2 – Una retrospectiva real

Diseña una retrospectiva para un ámbito en el que participas (laboral, facultad)

Publicá el diseño (objetivo, duración, actividades, número participantes, contexto) – 5 puntos

Reporta el resultado (ROTI -retorno del tiempo invertido- o comentarios de los asistentes, éxito en cuanto a definición de accionables) – 10 puntos

Anuncios
Publicado en Sin categoría
38 comments on “Actividad Q2 – Una retrospectiva real
  1. Pablo Ascarza dice:

    Retrospectiva para el trabajo.

    Duración 2,5 horas.
    Participantes 12 personas, equipo frontend, backend, de analisis del proyecto.
    Contexto, proyecto sparl, con 3 equipos involucrados y sprints de 2 semanas de duracion.
    Objetivo mejorar de manera continua la productividad, y la calidad del proyecto ver en que cosas hay que mejorar y encontrar cuales fueron los cuello de botella.
    Actividades: revisión del backlog, que tareas se terminaron y cuales no, que problemas surgieron, anotar los principales problemas en post-it colocarlos en una pizarrón a la vista de todos.
    Seleccionar entre todos cuales parecieron ser los problemas mas graves mediante el método de votación directa, realizar una revisión por si surgen problemas ocultos en un principio.
    Permitir que el equipo pueda sugerir herramientas para encontrar las razones a estos problemas, utilizar tales herramientas para proponer soluciones.
    Elegir entre todos los integrantes mediante votación las soluciones mas afines al equipo.
    Generar las tareas necesarias para llegar a cabo estas soluciones, se escribirán en post-it y se pegaran en mismo nivel que el problema que resuelven y se relacionaran directamente con los problemas mediante flechas.
    Se iniciara un nuevo proceso de la misma forma utilizando post-it para ver que éxitos se tuvo en el sprint a evaluar, se pondrá en el pizarrón arriba de todo para que estén presenten en el equipo de trabajo.
    El facilitaron dara una conclucion al proceso observado.

  2. Joaquin Stankus dice:

    Objetivo: Identificar areas o tematicas susceptibles de mejora en el equipo de desarrollo de un producto de software.
    Duración: 2hs
    Numero de participantes: 7
    Contexto: Final del primer sprint de un equipo que acaba de duplicarse en tamaño para un producto en continuo estado de evolucion.
    Actividades:
    1- Preparar el escenario: Realizaremos la actividad de ESVP donde cada participante debe declararse como Explorador Shopper Vacacionista o Prisionero de manera anonima de acuerdo a su actitud frente a la retrospectiva. Se contara el numero de personas de cada tipo y se discutira que es lo que dicen estos datos. Es una actividad divertida que ayudara a que el equipo se conozca mas.
    2- Recabar datos: Llevaremos a cabo la actividad de Calendario (timeline) para ayudar a detectar patrones y relaciones a partir de la ubicacion de eventos significativos en una linea de tiempo.
    3- Generar entendimiento profundo: Haremos un analisis de espina de pescado (Ishikawa) donde identicaremos problemas y sus causas mediante la ubicacion de las mismas en areas o categorias.
    4- Decidir que hacer: Actividad de Objetivos SMART, para lograr que las acciones y mejoras sean priorizables y medibles,
    5- Cierre: Agradecimientos de todo el equipo hacia el resto.

  3. Este año se me ocurrió hacer una retro en el equipo de basquet en el que juego para ver en qué podemos mejorar para el próximo año.

    Objetivo: Llevar al equipo a jugar a lo mejor que podamos ser.
    Duración: 30 minutos
    Actividades: Se prepara el escenario (una habitación cómoda, con los asientos en forma de ronda para que todos se vean con todos). Se eligió una pelota como token, y sólo puede opinar quien tenga el token en su mano. La idea es que la pelota complete una ronda completa y que todos contesten las siguientes premisas:
    – Buscar un defecto o punto flojo personal (autocrítica) -> por ejemplo: no vine a entrenar mucho este año
    – Hacer una propuesta de mejora sobre se punto -> por ejemplo: voy a venir todas las semanas aunque sea una vez
    Luego se completa otra ronda cumpliendo estas premisas:
    – Mirar a cada uno de sus compañeros y decir algo “bueno” y algo “malo” de cada uno
    Por último se da un cierre agradeciendo a todos por participar.
    Número participantes: 15 personas
    Contexto: Final de las competencias, cierre del año previo a las vacaciones.

    El resultado fue positivo, la realidad es que al contrario de lo que yo pensaba que iba a pasar los comentarios “buenos” superaron ampliamente a los “malos”, y todos fueron más autocríticos que críticos hacia afuera. Quedó en evidencia que el problema principal de este año fue la falta de compromiso hacia los entrenamientos y la conclusión general fue mejorar ese punto.

  4. Pablo Oddo dice:

    El objetivo es encontrar puntos debiles o posibles de mejora en el equipo de desarrollo de una aplicacion desarrollada en Django
    La duracion de la reunion se estima en 1hs (sprint de 1 semana)
    Numero de participantes: 5
    Contexto: Terminado en primer sprint trabajando con una tecnologia nueva para varios intengrantes del equipo.

    Descripcion de las Actividades:
    Para Check-in: Utilizamos OneWord. Esta es una actividad sencilla que permite a los participantes expresar sus sentimientos. Se le da un papel a cada particiapante, donde debe escribir en el una palabra que describa su sentimientos. Luego se agrupan a la vista del publico los resultados

    Para hacer Restrospective: Utilizamos Anchors and Engine. Esta sencilla actividad ayuda al equipo a identificar las cosas que los hacen avanzar más rápido , y las cosas que hacen retrazar al equipo.
    Se le pide a los integrantes del equipo que escriban cosas que funcionan como conbustible para el equipo (Engine) y cosas que ellos consideren que producen retrasos (Anchors) en post-it. Luego esas notas se las agrupan en Anchors y Engines.

    Para Filtering: Utilizamos DotVoting. Esta es una excelente actividad para la gestión del tiempo y priorización. Se utiliza para enfocar la conversación en un número reducido de elementos, que generan el interés en el grupo.
    A cada intengrante se le da la posibilidad de asignar una cantidad determinadas de votos (5 en este caso). Los participantes votan los items sobre los cuales quieren que se discutan, asignando uno o mas votos a cada item (se representa con una marca de un punto por cada voto en el post-it). Los mas votados son los discutidos en la reunion.

    Para Check-out: Utilizamos One word before leaving. Esta actividad es perfecta para usar si se utilizo como check in One word. La metodoligia es la misma, y se usa para expresar las sensaciones despues de la reunion. Por lo general, hace que la gente altamente motivada contagie a los demás participantes justo antes de cerrar la reunión.

    El resultado fue bueno. El tiempo estimado de 1 hora se cumplio bien, las actividades se completaron todas de forma correcta.
    Sirvio para evaluar el estado de animo del equipo, que era bueno a pesar de tener que lidiar con una tecnologia no del todo conocida por todo el equipo. Ademas permitio contagiar la buena onda del la mayoria del equipo al resto, haciendo un refuerzo positivo del estado de animo.
    Tambien se pudieron identificar algunos problemas que retrasaban el avance del proyecto (dificultad con algunas herramientas) y se decidio el curso de accion a tomar en ese caso

  5. Duración 2 horas:

    Participantes: equipo técnico.

    Dinámica, se dan post-its verdes, rojos y azules a los participantes.

    Se recomienda preparar la reunion (o pensar las ideas a cada participante).

    Cada participante (son 6) tiene 10 minutos para transmitir lo que se hizo bien (en los post-it verdes), lo que se hizo mal o podria mejorarse (post it rojos) y los neutrales (propuestas, cambios, percepciones) en azul.
    Se pegan en una pizarra agrupados los positivos, los negativos y los neutros

    Si se coincide o ideas son muy parecidas, se pegan juntos los postits (o se pega uno solo y se pone un +1).

    Luego damos media hora al equipo para discutir las ideas en general.

    Luego 20 minutos para definir accionables con una salida (documento por ejemplo) sobre lso que se consideren mas importantes (tener encuenta la cantidad de “+1”).

    Los últimos 10 minutos se dedican a asignar responsables para los accionables.

    Si no se ponen responsables para todos los accionables se entiende que no se va a hacer esa actividad durante este período.

    La proxima retro, se dedican 15 minutos adicionales a revisar el resultado de los accionables

    • Continuación:

      ROTI.

      Comentarios obtenidos, o percepciones de la reunion:

      -Identificamos los problemas más importantes (de todas formas ya los conocíamos)
      -Identificamos buenas practicas y algunas asperesas dentro del equipo. Creemos que nos unió como grupo y mejoró la dinámica.
      -Nos tomamos el tiempo para definir accionables (esto sí fue una gran ganancia), definimos responsables y si bien algunos no pudieron cumplirse dentro del tiempo entre retros, otros fueron cumplidos satisfactoriamente.

  6. Sebastian Barreña dice:

    Objetivo: Identificar metodologías y herramientas utilizadas y realización de actividades tanto individuales como en equipo para mejorar en los sucesivos sprints para una materia de la facultad.
    Duración: 1 hs
    Número de participantes: 4
    Contexto: Finalización de un sprint, y su posterior entregable al cliente.

    Actividades:
    1- Preparar el escenario: Buscaremos un aula vacía y cómoda de la facultad para poder realizar la retrospectiva y utilizaremos Check In para repasar los objetivos y agenda y focalizarnos rápidamente en la retrospectiva. (5 minutos)
    2- Recabar datos: Para refrescar la memoria de los participantes elegiremos el método Calendario que ayuda a recordar qué pasó y cuando, estimulando la memoria de los presentes en la retrospectiva y escribiendo eventos significativos del sprint y armar un órden cronológico de los mismos. (20 minutos)
    3- Entendimiento: En esta etapa analizamos las causas raíces de lo que pasó utilizando el método de las Espinas de Pescado (Ishikawa) para identificar no solo los problemas sino las cosas que se hicieron bien, y proponer un plan de acciones para corregir dichas causas a los problemas y mejorar las cosas buenas.
    4- Decidir que hacer: Utilizaremos el método de Planificación de las Mejoras a realizar durante el próximo release y asignando un responsable a las mismas. (25 minutos)
    5- Cierre: Para cerrar la reunión elegimos Agradecimientos donde se cierra con una nota positiva la retro realizada. (10 minutos)

    El resultado fue muy bueno, ya que se pudieron identificar rápidamente los problemas y sus causas, y todos los participantes coincidieron sin dificultades tanto en lo mencionado anteriormente como en el plan de acciones a seguir en el futuro. El tiempo planificado se cumplió según según se había estimado. No hubo conflictos entre los participantes y todos tenían la misma visión en pos de mejorar para las siguientes iteraciones del proyecto, buscando crecer no solo como equipo, sino también la forma de llevar a cabo el proyecto pensando en el futuro.

  7. Sabrina Campa dice:

    En la empresa donde trabajo se empezó a implementar Scrum hace aproximadamente 11 meses.
    Inicialmente, la retrospectiva duraba 1 hora (a veces un poco más) y sólamente se mencionaban aspectos positivos y negativos del sprint sin ningún formato en particular (cabe destacar que la mayoría de mis compañeros no tienen experiencia en Scrum). No necesariamente todos hablaban (sólo los que tenían algo para decir) y como era todo muy informal, en general, nunca se tomaban acciones para mejorar los temas que surgían de la reunión.
    Por ese motivo, un compañero y yo planteamos una forma de hacer la retrospectiva que se sale un poco de lo tradicional pero que parece dar mejores resultados en comparación con no tener un formato establecido.
    En primer lugar, la retrospectiva tiene lugar después de la revisión, es decir, el equipo se toma unos minutos después de la demo para relajarse, buscar café y estar a gusto para la reunión que sigue, que está planeada para no durar más de 1 hora.

    A continuación enumero las actividades llevadas a cabo, en orden:

    -Actitud para la retrospectiva (5 minutos)
    Cada persona describe cuál es su actitud hacia la retrospectiva y lo escribe en un papel (debe ser anónimo):
    * Reflexivo: le interesa asistir a la retrospectiva para aprender cómo mejorar a partir de las ideas de los demás.
    * Especulador: asiste a la retrospectiva con dudas, sólo va a quedar satisfecho si saca algo bueno para mejorar.
    * Recreativo: no le interesa asistir a la retrospectiva, asiste únicamente porque lo encuentra como un recreo a su tarea habitual.
    * Obligado: siente que está obligado a asistir, preferiría estar haciendo otra cosa. Muchas veces ocurrió que había gente que no participaba porque no le interesaba estar ahí, ya sea porque tenía cosas pendientes del trabajo o de su vida personal que hacían que no pudiera focalizarse en los temas de la reunión.
    Se mezclan los papelitos y se leen de a uno. Se debate cómo van a afectar las actitudes de todos los presentes en la reunión.
    Las personas que se sienten ‘obligadas’ a estar pueden elegir involucrarse o no. Queda a criterio de ellas.
    Si ocurre el caso en el que todos se sienten obligados, se deduce que no es un buen momento para llevar a cabo la reunión, entonces se re-planifica para el día siguiente, antes de la planificación del siguiente sprint. Esto no representa una pérdida de tiempo, ya que sólo se necesitan 5 minutos para realizar la actividad. Consideramos que es mejor identificar de forma temprana si los invitados están motivados para hacer la reunión y no cuando ya se esté llevando a cabo, pues en ese caso tendría un impacto mucho mayor.

    -Experiencias del sprint (40 minutos)
    Esta actividad tiene como objetivo ayudar a que los miembros del equipo recuerden experiencias/situaciones concretas vividas en el sprint para que puedan ser comentadas y así cada uno pueda exponer su punto de vista en cuanto a si la percibió del mismo modo.
    Se tiene un tablero con 6 categorías: Útil, Divertido, Colaborativo, Inútil, Frustrante y Desmotivante.
    Se le solicita a cada miembro del equipo que escriba 6 tarjetas/post-its: 2 de cosas para dejar de hacer, 2 con cosas para empezar a hacer y 2 con cosas para seguir haciendo. Se dejan boca abajo en el medio de la mesa (la idea es que sean anónimas). Se mezclan las tarjetas, cada uno saca 6 (nadie sabe quién las escribió) y las ubica en la categoría del tablero que cree que mejor se ajusta a esa tarjeta (si le toca alguna que escribió ella misma no hay problema, la ubica en la categoría que le parezca).
    Una vez que todos ubicaron sus tarjetas, cada uno dice por qué le parece que las tarjetas que le tocaron van en esa categoría. La idea es que todos aporten ideas. Se pueden mover tarjetas de una categoría a otra si es que todos están de acuerdo en cambiarla.

    -Votación (15 minutos)
    El objetivo de esta actividad es votar por las situaciones que quedaron plasmadas en las tarjetas que terminaron en las categorías negativas de la actividad anterior (Inútil, Frustrante y Desmotivante) y obtener 2 o 3 como candidatas para mejorar para la próxima iteración.
    A cada participante se le da un fibrón de color rojo. Cada uno debe ir hasta el tablero y dibujar un punto en la tarjeta que quisiera que fuera tenida en cuenta para mejorar en el próximo sprint. Sólo se puede votar por 3 tarjetas. La votación no debe llevar más de 2 minutos, ya que las tarjetas fueron discutidas en la actividad anterior.
    Los últimos minutos son para leer en voz alta las tarjetas que van a ser tenidas en cuenta por el equipo en el próximo sprint (son las que más puntos rojos juntaron) y se hace un breve brainstorming para obtener action items de cómo hacer para mejorarlas.
    Estas tarjetas junto con los action items se pegan en una pared que queda visible desde el lugar en donde el equipo realiza las reuniones diarias, para no olvidarlas durante el sprint y determinar si el equipo está cumpliendo con lo pactado.

    Como resultado de su aplicación en estos últimos 3 meses, el equipo se motivó mucho más con estas actividades específicas de retrospectiva. Además, no se sienten cohibidos a hablar ni a irse si es que tienen algo importante que hacer y sienten que no van a poder aportar a la reunión.
    Antes no se tenían muy presentes las acciones que salían de las retrospectivas, sino que quedaban a la deriva. Ahora, tenerlas anotadas y visibles, ayuda al equipo a no perderlas de vista durante el sprint y a medir su grado de cumplimiento en la próxima retrospectiva. Por ahora, el cambio en la forma de llevar la reunión resultó positivo. Como punto negativo puedo mencionar que hubo varias reuniones en las que 1 hora resultó insuficiente para cerrar todas las actividades sin dificultades, aunque poco a poco el tiempo se está ajustando mejor (creo que debido a que los participantes ya están familiarizados con la estructura de la reunión).
    Hay que evaluar si, con el correr del tiempo, es necesario agregar/modificar alguna actividad para no perder la dinámica de las reuniones.

  8. Ramiro Doi dice:

    En la empresa donde trabajo no siempre se realizaban retrospectivas dado los tiempos cortos entre sprint y había veces que se realizaron no se llegó a nada concreto.
    Les comento a grandes rasgos lo que se propuso y los resultado.

    Objetico: realizar una reunión de retrospectiva siempre al finalizar el sprint, en caso de que no haya tiempo en ese día se planea otro, pero no puede no realizarse. Si por X motivo un integrante no puede estar al momento de la reunión se realizará de forma individual para comentarle lo revisado y decidido.
    Duración: 1 hora como máximo.
    Cantidad de participantes: 6
    Contexto: finalizado el sprint de 2 semanas.
    Actividades:
    a) se revisa lo que se trabajó en el sprint
    b) se realiza un análisis del tiempo estimado, tiempo real y tiempo de desvío.
    c) se comentan complicaciones durante el sprint y como se resolvieron (no necesariamente está enfocado a la parte técnica del problema)
    d) se comentan las cosas que salieron bien
    e) se comentan las cosas que salieron mal (en este punto el objetivo no es buscar culpables sino buscar puntos débiles)
    f) se realiza un brainstorming para lograr llegar a una solución conjunta
    g) se compromete todo el equipo a realizar lo hablado.

    En lo personal en la semana intermedia que no hay retrospectiva me gusta juntarme con el lider para verificar los puntos comprometidos y como viene la evolución. También para saber si algo nuevo sucedió ó algún punto se olvidó de tratar.

    Retorno: Antes de plantear esta metodología el equipo de trabajo estaba teniendo muchos problemas de comunicación, por ejemplo para iguales problemáticas cada persona optaba por resolverlo de forma diferente, a partir que todos nos estamos juntando en las retrospectivas estamos llegando a una única forma de operar y el cliente está muy contento porque sabe que los temas los tratamos entre todos y es una solución conjunta.
    Otro punto fue la cantidad de errores de desarrollo / gestión, al revisar los problemas y cosas que salieron mal se redujeron en un gran porcentaje los errores, por ejemplo se antes había 100 errores ahora estamos teniendo una taza de 10, lo que significa que el cliente está muy contento y nos apoya a que sigamos mejorando.

  9. Para un proyecto del trabajo en el cuál el equipo se compone de 6 personas solíamos tener errores recurrentes a lo largo de cada sprint. Así que decidimos cambiar un poco la retrospectiva.
    Propusimos una retrospectiva de 40 minutos en la que deseamos no cometer el mismo error de sprints anteriores.
    Para eso decidimos que de la retrospectiva salgan tareas específicas con un responsable en las que uno pueda trackear a los largo del siguiente sprint.
    La dinámica de la retrospectiva consiste en un análisis inicial del sprint que acaba de finalizar. Luego los participantes indican los problemas que observaron en el sprint y entre todos se decide mediante votación los más importantes a tratar en la retro. Luego entre todosse debaten los problemas y se proponen soluciones con responsable para ver el resultado en la siguiente retro.
    Pudimos observar que disminuyó mucho la reiteración de errores. En la siguiente retro todos los integrantes se mostraban conformes con los cambios realizados a la retro y destacaban la utilidad de los mismos.

  10. Hugo Chavar dice:

    RESTROSPECTIVA

    En un proyecto en curso se comenzó (o al menos se intentó) a usar scrum y luego de concluir el tiempo del primer sprint se realizó la restrospectiva.
    Debido a que se presentaron problemas en la comunicación de las tareas y sus alcances, y no se logró concluir todas los accionables del sprint a tiempo.

    Objetivo:
    Encontrar las mejores formas de definir y comunicar las tareas y sus alcances.

    Duración: 1,5hs

    Participantes: 11

    Actividades realizadas:

    Patrones y cambios (5 – 10 min)
    Para identificar el motivo cada participante genera uno o varios post-its indicando que cosa fue la causa de no haber llegado con el sprint.

    Por votación se definen cuales se continuarán analizando.

    5 por qué (10 – 20 min)
    En grupos de 3 o 4, utilizan esta técnica para llegar a las causas, luego cada grupo reporta el resultado.

    Acuerdos de trabajo (15 – 25 min)
    En grupos de 3 o 4 (pero no con los mismos integrantes de la actividad anterior) se definen que se debe hacer para cada uno de los problemas detectados y sus causas.
    Cada grupo seleccionará 2 o 3 comportamientos nuevos a implementar indicando su objetivo, y en que contexto se usarán.

    Accionables
    1 – Las tareas no fueron dimensionadas correctamente, en futuras planning se usará un método para validar que todos estén de acuerdo en el esfuerzo que implican.
    2 – Las tareas carecían de una explicación profunda, el scrummaster se encargará de reveer con el product owner
    3 – Hacer las dailys obligatoriamente, no se realizaban por lo que el problema de tiempos se presentó al final de sprint

    ROTI:

    5 I
    4 IIIII
    3 IIII
    2 I
    1

    Resultados
    Se logró consensuar accionables para futuros sprints, prestando más atención a los tiempos y al seguimiento diario.

  11. Dario Seminara dice:

    Retrospectiva para el trabajo (desarrollo de software), para mi caso particular, opte por definir objetivos muy especificos y una cantidad reducida de participantes (entre 3 y 4)

    Objetivo: mejorar el proceso de desarrollo de un grupo de componentes del backend clave en el producto, para lograr reducir el desperdicio
    Participantes: Arquitecto, 2 desarrolladores y una persona que pueda aportar una vision no-tecnica del problema
    Duracion: 120 minutos (aprox.)
    Contexto: En el dia a dia se observa gran cantidad de desperdicio: desarrollos hechos solo para tirar, componentes/features enteros desarrollados que nunca llegaron a produccion, etc…, .Todos en el equipo estan de acuerdo en que este problema existe, pero nunca nadie se preocupo en tratarlo, la reunion en teoria deberia servir para encontrar las causa de este tipo de problemas, intentar priorizarlos y plantear action items

    Preparacion del escenario (5 min): Se reserva una sala y se planifica la reunion con una semana de anticipacion. Solo se necesitan tantas sillas como participantes (cuatro serian suficientes) mas evidencia de los problemas que se pueden llegar a tratar, aunque esto ultimo tiene mas que ver con la recoleccion de datos previa a la reunion

    Recabar datos (20 min): se sugiere a los participantes de la retrospectiva que consigan la informacion de los problemas relacionados antes de la reunion. En la reunion se construye en calendario con eventos recientes de trabajo que cada quien considera WIP, el punto es que todos puedan acordar y enumerar en que desperdicio se invirtio el tiempo, adicionalmente tambien se enumeraria el trabajo que no quedo en desperdicio y que SI llego a generar valor

    Entendimiento (80 min): segun el valor de cada item de WIP de la lista acordada, cada integrante define una prioridad por puntos, los temas se van a tratar por orden de prioridad (sumada) de manera que los que tengan menos prioridad son los que queden afuera si no alcanza el tiempo de la reunion (sin descartar que se traten en una proxima reunion o que tengan una solucion compartida con otro tema que si se trato)
    Para analizar las causas de cada desperdicio generado o desarrollo atascado como WIP, se puede recurrir a realizar diagramas de espina de pescad

    Decidir que hacer (20 min): Siguiendo la practica de objetivos SMART y en base al analisis de la etapa anterior, para con los items que se analizaron y se acordaron que tenian que mejorar y como:
    * Se asgina un responsable a cada uno (esto NO tiene nada que ver con culpabilidades) afin al problema o el que tenga mas herramientas/skills/intencion a mano para resolverlo
    * Se define un objetivo puntual, que en este caso seria continuar el item hasta que llegue a su fase final donde genera valor, a priori podemos suponer que esto va a ir mas alla de simplemente “terminar” un desarrollo ya que hay que atacar todas las causas tecnicas y no-tecnicas

    Cierre (5 min): se agradece la participacion a todos los integrantes, y se propone otra proxima reunion donde se harian revisiones del avance en los objetivos planteados. Tambien se solicita un breve feedback acerca de si consideran que invirtieron bien el tiempo en la reunion

    ================
    Resultados
    ================

    La mayoria considero que el tiempo que invertieron en la reunion podria haber sido usado para resolver problemas puntuales, entre ellos incluso los que se trataron en la misma reunion, sin embargo, el planteo especifico de la retrospectiva no definia objetivos que optimizen directamente el tiempo, todo apuntaba a maximizar el valor entregado. Tras un brevisima reflexion, casi todos acordamos que se mejoraba la relacion valor entregado/tiempo ya que si lograbamos resolver estos problemas reduciriamos el tiempo invertido en desarrollos que no aportaban ningun valor por estar atascados

    En cuanto a la definicion de accionables, no se logro lo que me hubiera gustado. Si bien se pudieron individualizar, priorizar los items, generar action items puntuales y asignar responsables para resolverlos, muchos implicaban factores que escapaban al control de cualquiera que haya participado en la reunion (por ej, cierto tema relacionado con el sistema de deploys), de todas maneras esto igual es un avance, ya que es factible identificar aspectos en los que SI se puede avanzar para cada caso dejando pendiente “la cereza del postre”
    Una cosa positiva que no esperabamos, es que se planteo el problema de que estabamos aceptando demasiadas tareas de desarrollo sin cuestionarlas (una de las causas de que emprendamos desarrollos que finalmente se cancelan/pausan indefinidamente y no generan valor), no pudimos analizar muy en profundidad el tema, pero llegamos a la conclusion de que desarrollariamos un proceso de analisis del valor para evaluarlo antes de emprender cada tarea

  12. Nicolas Javier Pantazis 85977 dice:

    En una de las materias de este cuatrimestre nos vimos forzados a hacer una retro para mejorar la performance de las entregas del TP grupal

    Entre ellas esta se destaco la primera:
    Objetivo: Determinar las cosas buenas y las cosas malas que realizamos en el sprint anterior.
    Duración: 20 min

    Actividades:
    Nombrar 5 pros y 5 contras de la iteración anterior. Encontrar los porque de las contras ( Técnica de los “5 why`s” ) plantear una solución en la que la mayoría este de acuerdo para atacar al problema.

    Número participantes: 4
    Contexto: Trabajo práctico cuatrimestral que tiene front end y back end

    Accionables:
    -Juntarse obligatoria mente los Sábados a programar y coordinar.
    -Cambiar los medios de comunicación.
    -Responder mas rápidamente a los pedidos de los docentes.

    Reporta el resultado:
    Logramos ajustar numerosos issues luego del segunto sprint.
    Todos los accionables se ejecutaron con éxito.Estimativo de horas hombre de retorno 160 HH.

  13. En el trabajo se implementó una iniciativa de Brigadas por tecnologías. A mi me tocó ser lider de la brigada de Node.js

    Preparé esta retrospectiva para hacer con los participantes de la brigada.

    https://docs.google.com/spreadsheets/d/1W1XQ3ufYfCTCfc7ro7EGFAj1IkM8kvhnhR7dNYIhsx0/edit?usp=sharing0

    Cada etapa de la retro está en una hoja distinta del spreadsheet

  14. Joel Ruggieri dice:

    Objetivo: identificar cosas que valieron la pena del sprint, y cosas que no salieron bien y pueden ser mejoradas hacia el futuro (las ideas para mejorarlas).

    Participantes: Las 4 personas que componen el equipo. Uno de ellos además, actúa como PM del sprint y hace de moderador de la retrospectiva.

    Duración: 1 hora.

    Contexto: finalización de un sprint en el cual se deben entregar una demo con los avances, al cliente.

    1- Preparar escenario: Utilizaremos el patrón Check In , en el cual se da una bienvenida a todos los participantes, repasamos cuales son los objetivos finales de la retro (identificar qué cosas se hicieron bien durante el sprint y cuales mal, y cómo vamos a trabajar en mejorarlas). El moderador pide a los participantes que definan en una o dos palabras cómo les resultó este ultimo sprint. (duración: 5 minutos)

    2- Recabar datos: Utilizaremos el histograma de satisfacción, para el cual el moderador pedirá a los participantes que escriban en una hoja cómo creen que fue para ellos, el trabajo en equipo desarrollado durante el sprint, utilizando una escala de 1 a 5 , utilizando el 5 como máximo nivel de satisfacción. Luego el moderador, transcribe los resultados a una pizarra, para que lo vean todos. Por ejemplo:
    5- l
    4- l
    3-
    2- l
    1-
    (Duración 10 minutos)

    3- Generar entendimiento profundo: Utilizaremos la matriz de aprendizaje en donde cada participante colocará frases sobre lo que crea necesario en relación, con aquello que cree que salió bien del sprint, aquello que salió mal, ideas para mejorar hacia el futuro, y reconocimientos como equipo. Votamos para poder ponderar y decidir cuales pasan a la próxima etapa. (Duración: 20 minutos)

    4- Qué hacer: Utilizaremos Sujetos Breves, estableciendo, con cada una de las frases/acciones mas votadas en la tapa anterior, si la vamos a mantener/detener o cambiar o agregar. (Duración: 15 minutos)

    5- Cierre: Utilizaremos la herramienta de Agradecimientos, reconociendo lo positivo de la retro y agradeciéndose entre los participantes mutuamente. (Duración: 10 minutos)

    Resultados:
    Algunos puntos puntos importantes de las retro.

    * Cosas que salieron bien:
    – Comunicación dentro del equipo.
    – Se llego con lo planificado.
    – Nos pudimos adaptar rápidamente a las nuevas tecnologías.
    – Correcta división de tareas entre los integrantes del grupo.

    * Cosas que salieron mal:
    – Comunicación con el cliente.
    – Validar las cosas antes de hacerlas.
    – Tener un registros de las horas consumidas en el proyecto.
    – Estimaciones de las horas requeridas para la realización de las tareas.

    Se decidió mantener con el criterio para dividir las tareas y la forma en que se comunicaba el equipo.
    Por otro lado para mejorar y solucionar las cosas que salieron mal, la ideas mas votadas fueron llevar a cabo una propuesta de comunicación al cliente para poder establecer como manejar la situación en caso de no respuesta y ante imposibilidad de poder validar ciertas cuestiones con él.
    También, llevar a cabo un cuadro con el registro de las horas insumidas cada día por cada participante del equipo, y dividir las estimaciones de las historias de usuario en las tareas mas atómicas que estas comprende.

    En el sprint siguiente, la comunicación con el cliente fue mejor permitiendo validar todas las cosas que se hacían, y se volcó la curva de las horas insumidas por el equipo en un gráfico para comparar el desvío respecto de las estimaciones iniciales.

  15. Federico Quevedo dice:

    Dentro de mi empresa se realizo una retrospectiva con el fin de mejorar una aplicación que es un producto de la empresa, que partes se pueden mejorar y que “huecos” hay para rellenar

    Duración: 45 minutos
    Numero de participantes: 4
    Se prepara el escenario, que por cuestiones de comodidad va a ser una charla por skype. Se ponenen en común datos estadísticos sobre uso de la aplicación y demas datos relacionados para facilitar la toma de desiciones.
    Actividad: Cada persona dice un punto de la aplicación que esta andando muy bien y es muy usado y otro que no tiene mucho uso o tiene bastante que mejorar. A partir de eso se eligen por votación 2 aspectos de la aplicación y se hace brainstorming sobre posibles mejoras, una vez terminado se realiza una votación para ver que implementar.

    El resultado fue bueno, todos los participantes quedamos satisfechos con lo que se llego y no surgieron conflictos durante la ejecución.

  16. Para el cierre de la materia Taller de Desarrollo de Proyectos II, realizamos entre todo el curso(aproximadamente 40 personas) una retrospectiva de lo que habia sido la materia.

    La retroespectiva estuvo dividida en 4 etapas y tuvo una duración total de aproximadamente 50 minutos(lo cual cumplio con los tiempos estimados).

    Etapas:

    1) Introducción(5 minutos): La idea fue acordar las reglas que se debian respetar durante la retroespectiva y que cada uno de los participantes pudiera aportar su parte resumiendo en solo 2 palabras las sensaciones que le quedaban de la materia.
    Entre las reglas mencionadas se destacaban:
    – Apagar los celulares para evitar distracciones de los participantes
    – No criticar los comentarios de los demas, pues la idea era que cada uno aporte su punto de vista
    – Nadie estaba obligado a hablar si no queria hacerlo
    La idea de que cada uno contara en 2 palabras sus sensaciones de la materia tenia como objetivo ayudar a que todos se sintieran comodos para participar y dar una primera impresion de la imagen con la que se iban los alumnos de la materia.

    2) Calificacion cualitativa de distintos aspectos de la materia(10): Se dibujo en el pizarron un cuadro en el que habia 3 filas(cara feliz, cara indiferente y cara triste) y 5 columnas(docentes, clase de presentacion, clase de consultas con el cliente, reuniones formales, reuniones informales y ultima clase de presentaciones). La idea era que todos los alumnos indicaran para cada columna cuales habian sido sus sensaciones. De esta manera, se obtuvo una primera idea de cuales habian sido los aspectos mas destacados y en cuales habia que hacer foco para mejorarlos los proximos cuatrimestres.

    3) Penales(25 minutos): La idea era indicar cuales habian sido los goles(+), que cosas pegaron en los palos(+-) y que cosas se fueron afuera(-).
    Para esto se formaron grupos de a 5 y cada uno de ellos penso en aspectos de la materia para cada una de las categorias. Se escribieron en papeles de color las ideas planteadas para luego pegarlos en el lugar que correspondieran en el pizarron, donde habia dibujado un arco. Un representante de cada grupo pasó a explicar cada uno de los comentarios planteados y a pegar los comentarios en la parte del arco que correspondia. Esto permitio ver que habia comentarios comunes entre los disntintos grupos y otros puntos en los que se tenian opiniones muy diferentes. Pero en general quedo una idea mas acertada de porque se habian calificado de la manera en que se lo hizo los distintos aspectos de la materia en la etapa anterior.

    4) Resumen y comentarios mas relevantes y conclusiones(10 minutos): Se solicitó que todos los participantes indicaran que aspecto consideraban mas relevante mejorar. Cada alumno debía marcar con un palito(anotacion truco) el comentario que consideraba mas importante. Esto mostró, que habia dos puntos de la materia muy cuestionados por los alumnos. Por un lado, el excesivo esfuerzo requerido en el desarrollo de la aplicacion Android. A pesar de ser una materia mas orientada a la gestion de un proyecto, la mayor dificultad pasaba por el tiempo que habia que dedicarle a la programacion, dejando en segundo plano la gestion.
    Por otro lado, las presentaciones de la ultima clase, en la que cada grupo presentaba las lecciones aprendidas y una demo de la aplicacion desarrollada terminando resultando muy extensas por ser 9 los grupos que presentaron. Se propuso en este punto, dividir la clase en 2 clases distintas, de modo que resulte mas llevadera.

    Como resultado de la retrospectiva, creo que surgieron muchas cosas interesantes y confio en que los pedidos de los alumnos seran escuchados para mejorar la materia en los proximos cuatrimestres. Por otro lado, creo que tambien surgieron muchas cosas que los alumnos valoraron de la materia, por lo que tambien se pudo ver que cosas se deben mantener.

  17. jlara91 dice:

    En el proyecto actual en el que estoy, no utilizamos scrum. De todas maneras se decidió realizar una retro sobre el mismo con el siguiente diseño:

    – Objetivo: identificar los puntos fuertes y débiles de lo realizado durante el tiempo que lleva el proyecto

    – Duración: 1,5 horas

    – Número de participantes: 6 (todos los integrantes del proyecto)

    – Contexto: el proyecto no utiliza scrum. El proyecto se basa en el desarrollo y mantenimiento del backend de una app ajena a la empresa. El alcance no está del todo definido

    – Actividades

    1) Check in (10 min)
    Se da la bienvenida y se repasan los objetivos y la agenda. Cada participante debe describir en dos palabras cómo se siente frente al proyecto, para tener una noción general de cómo se siente cada uno respecto al trabajo realizado.

    2) Mad Sad Glad (20 min)
    Se les pide a los participantes que pongan qué les molestó, entristeció y enorgulleció de los siguientes temas propuestos, puediendose agregar más: Gestión, Alcance, Equipo, Estimaciones

    3) Priorizar con puntos (15 min)
    Se va a priorizar lo que se puso en la actividad anterior para decidir qué hacer en la siguiente actividad. Para eso, cada participante tiene 3 puntos y se los puede asignar a las mad/sad

    4) Brainstorming (20 min)
    Todos podemos tirar ideas sobre acciones a mejorar de lo que se priorizó anteriormente y se filtra mediante votación. Luego se asignan responsables de cada una de las acciones

    5) Feedback (10 min)
    Cada participante deberá dar su feedback sobre la retro. Si sirvió o no y por qué

    Esto tuvo una respuesta complemente positiva en el equipo ya que al no estar acostumbrados a hacerla, pudimos poner en común todos los problemas que veniamos teniendo en el desarrollo del proyecto.
    Todos coincidimos en que se debía volver a hacer en un futuro cercano y que sea periódicamente.

  18. Fabrizio Graffe dice:

    Objetivo: Identificar cosas que, en el anterior sprint, se han hecho bien para seguirlas haciendo y que cosas que se han hecho mal para no repetirlas y corregirlas. Así como también que nuevas propuestas de cambio pueden ser aplicadas en el siguiente sprint para lograr un mejor desempeño.
    Duración: 1 hora, 15 min.
    Cantidad de participantes: 4
    Contexto: Final de un sprint, proyecto para Taller de Desarrollo de Proyectos II

    Actividades:

    1. Preparar el escenario (5 min)
    Se procede a establecernos en el espacio que será utilizado para la reunión. Luego de varias retrospectivas encontramos un lugar donde nos sentimos cómodos y repetimos este para las próximas.
    Se utiliza “Check In” para comenzar la reunión repasar los objetivos y la agenda que se llevará adelante.

    2. Recabar datos (20 min)
    Una vez terminado completado el inicio de la reunión y ya estando todos los participantes atentos y espectantes, se procede a la siguiente etapa. En ésta utilizamos la herramienta “Calendario”, de manera que los participantes identifiquen cosas buenas y malas que fueron ocurriendo y en que momento del sprint se dieron de manera de identificar patrones y relaciones.

    3. Entendimiento (20 min)
    Una vez encontrados algunos puntos de interés o eventos que se dieron durante el sprint se procede a la siguiente fase, en la cual usamos la técnica de “Los 5 porqué” para identificar las causas raices de estos.

    4. Decidir que hacer (20 min)
    Una vez obtenidas las causas de los problemas y de los puntos altos de nuestro sprint, usamos la técnica de “Planificación de Mejoras” para ver de qué manera no volver a repetir viejos errores y como seguir haciendo y mejorando lo que hemos hecho bien.

    5. Cierre (10 min)
    Se procede al cierre de la retrospectiva utilizando “Agradecimientos” para expresarles a todos los participantes gratitud por haber estado presentes y haber participado de manera constructiva para mejorar nuestro desempeño en el próximo sprint.

    El resultado de retrospectiva fue altamente positivo. Se identificaron muchas cosas que se debían corregir, aunque también se hicieron notar cosas que se habían hecho correctamente y que se debían repetir o mejorar.
    Gracias a esta (y otras retrospectivas realizadas con un formato similar en el cuatrimestre) pudimos ir refinando y mejorando nuestro funcionamiento como equipo, la manera en que manejábamos la gestión del proyecto y la comunicación tanto interna como con el cliente.

  19. Gisela dice:

    Retrsopectiva para el trabajo
    Objetivo: Dar un feedback sobre el trabajo en el sprint recien culminado e identificar en que vamos encamindados, que estuvo mal y que items acrodamos que tenemos que hacer algo al respecto.

    Duracion: 60min

    Cantidad de participantes:8

    Contexto: Como la mitad del equipo se encuentra en EEUU los datos de la retrospectiva se vuelcan en un google doc y la charla y feedback se realiza desde skype y el idioma es en ingles.

    Actividades:

    Preparar el escenario: El scrum master el dia anterior a la reunion creara un documento en google docs con una tabla que incluya las siguientes columnas – Que se hizo bien, -Que se hizo mal, -Items que cambiarias, – Votos, -Acciones. Se envia por mail el archivo y creara un evento en el calendario con la fecha, hora y duracion de la reunion.
    El equipo puede aprovechar para llenar los datos de las primeras 2 columnas para ser mas dinamicos en la reunion.

    Recolectar datos: Se relizara la llamada de skype para relaizar la reunion de retrospectiva. Se leeran los feedbacks volcados en el gdoc y se le preguntara a los que no hayan llenado en documento y se completaran totalmente las primeras 2 columnas.

    Reflexionar: A partir de los datos recolectados se seleccionaran los items que mas se repiten o mas representativos del sprint a partir de una charla dandonos feedback entre todos. Se votaran los items seleccionados, teniendo 2 votos cada uno y se seleccionaran 3 items. Se volcara en el gdoc en las columnas de items que cambiaris y votos.

    Decidir qué hacer: Se aramara un plan de accion para los 3 items seleccionados, se asignaran personas del equipo que se haran cargo de que se cumplan (Quien) tambien se decidiran los pasos a seguir para poder realizarlo (Como) y cuando. Se actualizara el gdoc con las acciones y el responsable de realizarlo.

    Cerrar la retrospectiva: Se guardara el gdoc con todo lo decidido, se puede dar una conlcusion tmabien por parte de algun miembro del equipo.

    ———————————-
    Resultados

    La retrospectiva de este sprint fue positiva (Above average) con muchos items identificados por los participantes tanto buenos como a mejorar, se logro decidir en tomar 3 items que bloqueaban o hacian que tardemos mas en nuestro trabajo. La comunicacion fue buena, mas alla del impedimento del idioma.
    Logramos identificar comportamientos y acciones que retrasaban nuestro trabajo o que nos insumian tiempo y las identificamos como acciones a relizar para mejorar el trabajo en el proximo sprint.

    En cuanto a la definicion de accionables se decidieron 3 items como puntos a trabajar durante el proximo sprint. – Automatizar la regression de fin de sprint. -Participar mas en pull request. -Siempre tener los tickets actualizados en jira para poder saber en que estado estan. El primero se lo asigno al QA y decidio que comenzara a automatizarla creando los tickets por cada elemento a testear, tendra la mitad terminada para este sprint.
    La segunda es para todos los integrantes y se decidio que los pull request deberan tener reviews y approvals el 50% del equipo para poder mergearse a partir de el proximo sprint. La tercera igual que la anterior es para todos los miembros y se definio que en todas las dailys se mostrara el board del sprint para ver los estados de los tickets y deberan estar actualizados para entonces.

  20. Objetivo: Identificar cosas que, en el anterior sprint, se han hecho bien para seguirlas haciendo y que cosas que se han hecho mal para no repetirlas y corregirlas. Así como también que nuevas propuestas de cambio pueden ser aplicadas en el siguiente sprint para lograr un mejor desempeño.
    Duración: 1 hora, 15 min.
    Cantidad de participantes: 4
    Contexto: al final de un sprint que dura 3 semanas.

    Actividades:
    1) Preparar el escenario (10 min)
    Se buscará un espacio en donde haya wifi y enchufes para poder hacer la restrospectiva, ya sea la biblioteca, un aula o un starbucks. Una vez instalados, se acuerda cual es el objetivo de la reunión y se da comienzo.

    2) Recabar datos (20 min)
    En esta actividad vamos a recorrer las user stories del sprint para que los participantes digan que cosas buenas y malas ocurrieron en la realización de cada user story.

    3) Entendimiento (20 min)
    Se utilizará la tecnica “5 Whys” para encontrar las principales causas por las cuales se producen los hechos del sprint identificados en el punto anterior.

    4) Decidir que hacer (15 min)
    Se utilizará la técnica “Planificación de Mejoras” para buscar una forma de no repetir errores y seguir usando las prácticas que dieron buenos resultados y mejorando lo bien hecho.

    5) Cierre (10 min)
    Se cierra la retrospectiva de forma positiva mediante Agradecimientos por haber logrado llevar a cabo una tarea constructiva en grupo.

    Resultado: el uso de la retrospectiva tuvo muy buenos resultados a nivel equipo por darle la oportunidad a cada integrante de expresar sus inquietudes y opiniones acerca del sprint, es decir, decir de qué aspectos se siente orgulloso, qué aspectos corregiría y qué criticas tiene. Permitió a la vez hacer una mejora continua en el desarrollo de los distintos sprint para mejorar la forma de trabajo y organización dentro del equipo.

  21. gonchub dice:

    # Objetivo
    Identificar los problemas que sucedieron en el sprint que acaba de terminar, analizar las causas de esos problemas y proponer acciones a tomar que minimicen el impacto de las causas en el dia a dia.

    # Duración
    Alrededor de 1 hora

    # Actividades
    – Analizar tareas que no pudieron ser terminadas en el sprint (~10 min): Por qué no se terminaron?
    – Discutir qué cosas se hicieron bien dentro del sprint (~10 min)
    – Discutir qué cosas se hicieron mal dentro del sprint (~10 min)
    – Ṕroponer soluciones (~20 min): cada integrante del equipo toma una de las cosas que se hicieron mal (se puede repetir si hay pocas cosas) y piensa entre 1 y 3 soluciones a la misma. Al finalizar el tiempo, exponer las soluciones que cada uno encontró.
    – Asignar un responsable (~10 min): para cada uno de los problemas, realizar una votación de la mejor solución e identificar y asignarle la solución a un integrante del equipo. Evaluar la mejora en la próxima retrospectiva.

    # Número de participantes
    Máximo 7 (https://www.scruminc.com/scrum-keep-team-size-under-7/)

    # Contexto
    Luego de cerrar el Sprint de Scrum. Cualquier equipo que utilice la metodología y esté dispuesto a trabajar para mejorar puede realizar la retrospectiva.

  22. Jimena Tapia dice:

    1) Preparar el Terreno: Histograma de satisfacción (10 min)
    Planteamos una línea imaginaria con puntaje del 1 al 10 y cada uno se posicionó en la nota que sentía que representaba su satisfacción con el proyecto hasta el momento. Adicionamos la explicación de por qué no es un 10.
    Resultado:
    Integrante S: 7 — Quisiera mejorar la comunicación entre los integrantes del equipo.
    Integrante V: 10 — Puntuaba el resultado propio del proyecto hasta el momento y las ganas de mejora que notaba dentro del equipo.
    Integrante C: 9 — Quisiera más paciencia al momento de explicar un desarrollo o una propuesta.
    Integrante G: 10 — Puntuaba el resultado propio del proyecto hasta el momento y las ganas de mejora que notaba dentro del equipo.
    Integrante J: 9 — No puso 10 porque siempre se pueden mejorar cosas, la perfección no existe.

    2) Recabar Datos: Mad – Sad – Glad (20 min)
    Cada uno expuso que le molestó, lo entristeció y qué lo enorgulleció un poco acompañando el puntaje antes indicado.
    Resultado (Integrante-(Mad(M)/Sad(S)/Glad(g))):
    SM: No conocer el tiempo estipulado para la finalización del proyecto pero aún así estar corriendo para presentarlo “ya”.
    SS: No poder comprender y encontrar facilmente las tareas asignadas en la herramienta de gestión de incidencias.
    SG: Se viene avanzando cada vez más rápido.
    VM: Que el equipo piense en no poder llegar a cumplir con toda la funcionalidad pensada para el proyecto.
    VS: El estado de la incidencia no coincide con lo que se puede hacer con ella. No se sabe cuando está terminada y/o puede ser testeada.
    VG: Se lleva desarrollado más de lo esperado en el inicio del proyecto porque se incluyeron nuevas funcionalidades.
    CM: No terminar de entender algunas funcionalidades pero aún así tener que definirlas para presentar los casos de uso.
    CS: Tiempo que tarda en comprender y terminar un caso de uso.
    CG: Estado actual del proyecto.
    GM: Desestimación de las sugerencias realizadas por parte del equipo de desarrollo.
    GG: Módulo finalizado por completo que incluía funcionalidad planeada en el siguiente sprint.
    JM: Retrabajo generado por la burocracia de la aprobación de casos de uso sin previa puesta en común.
    JG: Se logró adelantar trabajo.

    3) Entendimiento: Brainstorming (30 min)
    Agrupamos el resultado del punto anterior por temas y entre todos sugerimos ideas de cómo solucionarlos o mejorarlos.

    4) Decidir qué hacer: Sujetos Breves (30 min)
    Se armó una lista de las tareas a realizar para las ideas que surgieron del punto anterior.
    Resultado:
    – Nomenclatura específica para los títulos de los jiras y así mejorar la rápida identificación de la incidencia.
    – Agrupación de jiras en componentes o subproyectos para separarlos y mejorar la búsqueda.
    – Envío del compromiso del sprint por mail a todo el equipo para que se sepa con certeza lo que se va a desarrollar y así puedan armarse más adecuadamente los casos de testeo.
    – Envío de mail con novedades, especialmente retrasos, a mitad del sprint.
    – Estado de “Propuesta de Solución” como listo para la prueba del tester.
    – Reuniones previas al armado del caso de uso para poder ajustarlo con sugerencias de todo el equipo, en especial ampliar aquellas que no se comprendan.
    – Revisión del caso de uso antes de ser incluido dentro de los listos para desarrollar.

    5) Cierre: Retorno tiempo invertido (8 min)
    Resultado:
    La suma total que obtuvimos fue 20 ya que los 5 participantes pusimos un 4. Coincidimos en que nos sirvió haber expresado las cosas que nos preocupaban para poder tomar acción sobre ellas y mejorarlas. Destacar lo bueno del proyecto también nos ayudó a motivar a aquellos que estaban más negativos hacia el proyecto.

  23. lucaspsimonelli dice:

    Duración:
    Alrededor de 45 min.

    Participantes:
    4 personas.

    Contexto:
    Grupo de amigos que se junta a tocar instrumentos.

    Objetivo:
    Mejorar la calidad de lo que se toca, conseguir que lo que se toque le guste a todos, detectar problemas de equipamiento.

    Actividades:
    – Elegir un facilitador al azar, que será quien guíe la reunión
    – Analizar grabación de lo tocado.
    – Cada integrante anota en privado hasta 3 cosas que le gustaron, 3 que no, 3 que les gustaría probar.
    – Se comparten los ítems y se discuten hasta que todos estén claros.
    – Cada integrante puede elegir un ítem a ignorar por el momento. Si todos están de acuerdo, se remueve de la lista.
    – Cada persona le pone un valor de 1 a 10 a cada ítem, dependiendo de qué tan prioritario lo considere.
    – Se toman los dos ítems más votados.
    – Sobre esos ítems, se discuten acciones a tomar, con responsables y fechas de revisión.
    – El facilitador da un cierre.

  24. Objetivo:

    Analizar y seleccionar nuevas herramientas y tecnologías de TI para aplicar en la empresa cumpliendo con la Arquitectura vigente.
    Fomentar el uso de nuevas cosas tratando de mantenerse a la vanguardia, pero siempre respetando las pautas, procesos y normas de la empresa.

    Duración: 2 horas.

    Cantidad de participantes: Max 9 personas (Tres áreas: Depto de Arquitectura de TI, Desarrollo, Calidad)

    Contexto: Reunion semestral de las distintas áreas que involucran la gerencia de sistemas de la empresa. Todos deben respetar la herramienta que se definen, se documentan y homologan para mantener un mejor mantenimiento y control de las herramientas deTI usadas.

    Actividades:
    1) Preparar el escenario (20 min)
    El área de Arquitectura brinda una oficina de reuniones, con proyector, pizarras para escribir y materiales para hacer dinámica y ágil la reunión. Se prepara cafe y se busca un horario cómodo para mejorar la predisposición de la gente.

    2) Recabar datos (20 min)
    Previamente cada integrante buscara y confeccionara un documento muy simple de cosas que les gustaría aplicar, cosas que les gustaría cambiar, cualquier idea que aporte a la reunión. Luego se sube a una carpeta compartida que brinda Arquitectura.

    3) Entendimiento (40 min)
    Se usa con frecuencia 5 Whys para encontrar las principales causas de las cosas que no gustan, que desean cambiarse o que desean aplicarse.
    Se utilizan postix y la pizarra para agrupar ideas y luego generar debates y dar tendencias a los cambios mas adecuados

    4) Decidir que hacer (20 min)
    Se decide entre todos las cosas a incorporar, cuales deben cambiarse o cuales no puden llegar a incorporarse ya que no cumplen con la arquitectura de la empresa.

    Se arman un documento por cada cosa planteada y después se formaliza, desde el area de Arquitectura, en forma de documento de homologación o documentos formales (existen plantillas)

    5) Cierre (20 min)
    Se cierra con un la retrospectiva documentado la Reunion en forma de minuta, luego se comparte entre todos.

    Resultado: Estas reuniones tuvieron hasta el momento muy buenos resultados, porque antes de las mismas cada area usaba las herramientas que consideraban buenas para ellos, traigan problemas a futuro por q aveces algunos pocos comprendan su uso, o generaban problemas en la arquitectura. Estas reuniones lograron que entre todos decidiéramos que herramientas usar, cuales no y porque debieran cambiarse cosas existentes.

  25. Tomás Franco dice:

    Equipo: Cuatro desarrolladores (2 Android y 2 IOS) y un líder.

    Objetivo: Analizar cómo había respondido el equipo a un cambio de metodología (de Scrum a una más parecida a Kanban) que se había producido para responder mejor a la aparición de bugs prioritarios antes de una salida a producción.

    Duración: 1 hora.

    Actividades:
    1) Preparar el escenario (5 minutos): Se reserva una sala cómoda con una pantalla en la que iba a ser más fácil ver a un miembro del equipo que estaba conectado en forma remota.
    2) Recabar datos (20 minutos): Cada miembro del equipo debía tener la lista de tareas que había completado así cómo un análisis de las dificultades con las que se encontraron en las mismas que no hubiesen resultado un problema tan grande en caso de haber trabajado de la manera tradicional.
    3) Entendimiendo (20 minutos): Cada miembro del equipo aporta dos cosas que le parecieron positivas y otras que le parecieron negativas del cambio de metodología.
    4) Decidir qué hacer (10 minutos): Se votan dos de las cosas negativas señaladas por el equipo y se brindan propuestas de mejora a implementar en el siguiente sprint.
    5) Cierre (5 minutos): Se documentan los resultados sacándole fotos al pizarrón sobre el que se había trabajado y se deja constancia del compromiso del equipo para mejorar en adelante.

    Resultado: En general se vio que el equipo había estado conforme con la adopción de la nueva metodología por tener esta menos formalismos que a veces se tornan molestos. Sin embargo, tres de los miembros coincidieron en que al ir apareciendo nuevas tareas sobre la marcha y al no analizar las mismas en una “planning”, se tornaba más difícil luego despejar determinadas dudas que en dicha reunión hubiesen sido despejadas en el momento al estar presente el PO y al contar inmediatamente con el punto de vista de los demás desarrolladores. Se llegó a la conclusión de que en el momento en que apareciese una nueva tarea todos los miembros del equipo se juntarían a hacer una “mini planning” y en caso de ser necesario se contactaría al PO durante la misma.

  26. Diseño:
    . Objetivo: Aumentar calidad de release y velocidad de implementación y testing.
    . Contexto: Necesidad de cambiar las retrospectivas en un proyecto interno de una mega software factory porque todos los participantes se aburrían y las mejoras nunca se llevaban a cabo.
    . Participantes: Equipo del proyecto (incluye todos los roles), 22 personas
    . Duración total: 1 hora 30 minutos
    . Actividades:
    1 – Preparar el escenario: ESVP
    2 – Recabar datos: Mad-Sad-Glad
    3 – Generar entendimiento profundo: Priorizar con puntos
    4 – Decidir qué hacer: Objetivos SMART
    5 – Cierre: Retorno tiempo invertido

    Resultado:
    Los valores obtenidos en todas las etapas fueron sumamente valiosos. Lo más llamativo de todo fue que en la actividad de ESVP hubo muchos casos que se caracterizaron como Prisioneros (obligados a hacer la retro), pero que en el cierre eligieron valores altos en la escala de Retorno de Tiempo Invertido.
    Por otro lado, lo que más se destacó de los comentarios fue que se logró no sólo identificar las posibles causas de los problemas, sino que además se los pudo plasmar en objetivos concisos, medibles y priorizables. Por último, cada rol se comprometió a trabajar sobre los puntos que le correspondían para cumplir con las metas propuestas.
    Esta retro fue hace ya más de un mes y debo decir que el release siguiente mejoró mucho. La velocidad de desarrollo y testing aumentó (aunque en poca medida) y el entregable resultó ser bastante estable.
    Poco tiempo después yo me fui de esta compañía, pero tengo entendido que estos resultados se mantuvieron en gran medida a través del tiempo. Si bien la retrospectiva que propuse y llevé a cabo en su momento fue sufriendo muchos cambios, adecuándose a lo que el equipo iba necesitando, sirvió muchísimo para cambiar la mentalidad con respecto a su valor al final de cada sprint.

  27. Objetivo: detectar actitudes que empeoran la comunicación y generan malos entendidos. Mejorar la comunicación del equipo.
    Contexto: Finalización de un sprint semanal.
    Duración: 1 hora.
    Participantes: 5. 2 desarrolladores y 3 funcionales.
    Definir un horario de la retrospectiva, un lugar físico para realizarla. Definir una persona que va a ser la encargada de dirigir la actividad.
    Organizar a los participantes de manera que queden sentados y enfrentados en un círculo, dos personas de un mismo equipo no tienen que quedar cerca.
    Cada persona tiene que resaltar algo positivo de la que está al lado y algo que cree que puede mejorar. La persona que recibe el comentario puede comprometerse a mejorar mediante una propuesta. Así hasta completar con los turnos de cada participante.
    Una vez que se termina la actividad se toman todas las propuestas y cosas a mejorar y se las pasa a un documento. Luego se decide por votación cuales se van a llevar a cabo para el próximo sprint.
    En el próximo sprint se evalúa si hubo una mejora en la comunicación del equipo.

    • Reporte de resultados:

      Horario de la retrospectiva: luego del almuerzo (13.30hs)
      Lugar: sala 1 de reuniones. Ya que en esa sala todos los participantes pueden sentarse formando un círculo intercalados cómodamente.
      Responsable de la actividad: D1. Él será quien lleve el registro de los votos y pase en limpio los resultados de la reunión.
      Resultado:
      F3: Resalta de D1 su compromiso por cumplir los plazos de entrega de las funcionalidades que comprenden el sprint en cuestión. Le pide mejorar la redacción de los informes de avance ya que para ellos como funcionales les resulta demasiado técnico.
      D1: Resalta de F1 su compromiso por cumplir los plazos de entrega de las definiciones de casos de uso. Le pide mejorar la redacción de los casos de uso porque si bien están en término, suelen estar incompletos o todavía con funcionalidades sin cerrar con el cliente.
      F1: Resalta de D2 su rápida resolución de jiras, incluso de los que se levantan cerca de la finalización del sprint. Le pide mejorar la paciencia al momento de recibir jiras o casos de uso incompletos o mal analizados.
      D2: Resalta de F1 su colaboración para la explicación de dudas y correcciones correspondientes a las consultas realizadas por el resto del equipo. Le pide mejorar la organización de las incidencias en la herramienta de gestión, especialmente en coordinación con el resto del equipo encargado del testing.
      F2: Resalta de F3 su actitud positiva frente a los cambios que realiza el usuario permanentemente. Le pide mejorar la comunicación de las tareas asignadas o en desarrollo para que no se superpongan y no se pierda tiempo en estar trabajando dos personas con la misma tarea.

      Tareas a llevar a cabo el próximo sprint:
      -Revisión cruzada de informes de avance entre desarrolladores. Antes de enviar el informe, el desarrollador que lo narró se lo pasa a otro desarrollador quien deberá revisar y corregir dicho informe. [Responsable: D1, Votos: 4]
      -Revisión cruzada de casos de uso entre funcionales. Antes de presentar el caso de uso a los desarrolladores, otro funcional tiene que revisar y corregir dicho caso de uso y proponer las mejoras a quien lo narró. [Responsable: F1, Votos: 5]
      -Revisión previa a la incorporación de la funcionalidad descripta en el caso de uso en el siguiente sprint. Antes de incorporar la funcionalidad dentro del sprint, se revisa el caso de uso junto con los desarrolladores. Se plantean dudas y mejoras que dejen al documento completo para que se entienda por cualquier integrante del equipo. [Responsable: F2, Votos: 5]
      -Generación de filtros y consultas que permitan buscar las incidencias según determinadas etiquetas dentro de la herramienta de gestión de incidencias. [Responsable: D2, Votos: 3]

  28. + Contexto:Fin de la iteración con un cliente que no quedo del todo conforme.

    + Objetivo: Identificar aciertos y errores en el desarrollo del proyecoto y evaluar el impacto de los cambios hechos para el sprint.

    + Duracion: 45 minutos.

    + Número de participantes: 4

    + Actividades:

    – Preparar el escenario: (5´) Se busca un lugar vacío donde se pueda charlar tranquilamente y que disponga conexión a Internet para actualizar los resultados.

    – Recabar datos: (15´) cada participante escribe un listado de cosas positivas y negativas que hayan ocurrido en el sprint, debe haber un mínimo de 3 para cada una.

    – Puesta en común de los resultados: (15´) cada uno expone lo que había escrito se discute brevemente y se anotan las conclusiones para poder priorizarlas.

    – Cierrre: (10´) Se anotan acciones a tomar sobre los temas mas importantes y se le asigna un responsable para hacer seguimiento de los distintos items.

    + Resultado:
    Se logro un mejor desarrollo del sprint, un desarrollo mas organizado y un planeamiento mas efectivo, ninguno de los miembros estuvo sobrecargado.
    Ademas se corrigió el tema de la comunicación tanto interna, que permitió que los integrantes del equipo estuviesen menos tiempo bloqueados, como externa, que permitió tener al cliente mas al tanto de lo que pasaba en el proyecto y cumplir de mejor manera sus requerimientos.

  29. Yamila Glinsek dice:

    En el proyecto de la materia Taller de Desarrollo de Proyectos II nuestro tutor nos recomendó realizar retrospectivas al finalizar cada sprint de forma tal de poder identificar y luego mejorar aquellos aspectos que lo necesitaran y fortalecer aquellos que creíamos que eran positivos para el equipo. En el primer sprint sentimos mucha desorganización, por lo tanto, decidimos tomar la recomendación. Las retrospectivas que realizamos siguieron la siguiente estructura:

    1. Preparar el escenario (5 min): Todos los integrantes del grupo (4 personas) nos reuníamos en un lugar y horario acordados previamente. Se realizaba una introducción sobre la retrospectiva y los puntos a tratar en la misma.

    2. Recabar datos (15 min): Cada uno exponía sus puntos de vista con respecto a la evolución del sprint pasado, y sustentando con datos objetivos si era posible. De esta forma se iban identificando las cosas positivas y las negativas del sprint.

    3. Entendimiento (20 min): Una vez obtenidos los aspectos positivos y negativos, se procedía a investigar el por qué de aquellas cosas negativas que pasaron, utilizando la técnica de los “5 por qué”. Así, lográbamos identificar las causas de las mismas y de esta forma lograr entender por qué pasaron.

    4. Decidir qué hacer (10 min): Luego de entender las causas de los aspectos negativos, podíamos proponer planes de acción para mejorarlas en el sprint siguiente. Para esta etapa utilizamos la técnica de “Planificación de Mejoras”.

    5. Cierre (5 min): Para finalizar la restrospectiva, se realizaba una evaluación final de lo negativo y lo positivo, haciendo hincapié en los logros y apuntando a las mejoras con energía.

    El resultado de las retrospectivas llevadas a cabo a lo largo de la materia fue muy positivo y por parte de todos los participantes nos pareció una práctica altamente recomendable para todo tipo de proyectos. El feedback presentado por parte de todos los integrantes del equipo fue muy valioso para identificar los puntos flojos y proponer mejoras. Ahora, ya finalizada la materia podemos ver lo mucho que nos ayudó para la gestión del proyecto que fue el punto más débil al inicio del mismo.

  30. Romina Casal dice:

    Cómo ya comenté en el post anterior Q1, en Taller de Proyectos II hicimos varias retrospectivas.

    En el sprint 3, que había sido bastante complicado hicimos lo siguiente:

    Objetivo: Ver qué cosas salieron bien en el sprint, que cosas no.. que cosas pueden mejorarse y de qué manera. Qué cosas están bien y deberían mantenerse.

    Participantes: 4, con el Scrum Master incluido

    Duración: 1 hora.

    Contexto: Finalización del sprint, luego de la reunión formal con el cliente, donde se presentaron los avances del proyecto.

    Preparar escenario: Definimos cómo íbamos a encarar la retro para hacerla más dinámica..A uno de los chicos se le ocurrió el método de patear al arco.
    10 min

    Definir los tiros: Cada uno escribió los goles, tiros al palo o afuera. Lo que reflejaban repectivamente, las cosasa que salieron bien, las que estaba ahí como para revisar y las cosas que le pifiamos mal..15 min

    Patear: Fuimos poniendo los papelitos y explicando cada uno qué era lo que había escrito en el paso anterior. 15 min

    Conclusiones: Charlamos entre todos y armamos el documento de la retro que les paso en el link. 20 min

    https://docs.google.com/document/d/161Mk8PUT-xGC4-W-Pw2p_QTaPp77czgPKk9tpF1MWAk/edit?usp=sharing

    Este es el material que se consulto

    https://www.dropbox.com/s/r8rd6ei4x4kl0r1/%23SesionesDeMejora%20-%20by%20Kleer.pdf?dl=0

  31. Agustin Rojas dice:

    ###Retrospectiva para un grupo de trabajo que utilice scrum

    – Duracion: 2 hs
    – Participantes: Equipo de desarrollo, Equipo de QA , Product Owner, Facilitador. 10 personas aproximadamente
    – Contexto: Finalizado un sprint con duración de 2 semanas
    – Objetivo: Poder determinar cuales fueron las causas que produjeron un impacto negativo en el desarrollo del sprint

    – Actividades

    * Puesta en escena (15′)
    – Se explica el objetivo de la retrospectiva y las actividades que se van a realizar

    * Identificación de problemas (30′)

    – Se hace un resumen de los objetivos del sprint, se hayan conseguido o no. Utilizando datos concretos y objetivos
    Se proponen otros problemas que hayan surgido desde los miembros del equipo. Para esto se puede utilizar un brainstorming
    – Agrupar y priorizar los problemas

    * Descubrimiento de causas (15′)
    – Analizar porque se están produciendo los problemas más votados

    * Plan de acción (30′)
    – Proponer soluciones para las causas que están produciendo los problemas.
    – Generar las tareas correspondientes para estas soluciones y asignar responsables

    * Qué ha funcionado bien (15′)
    – Reconocer que cosas se hicieron bien durante el desarrollo del proyecto

    * Conclusiones de la reunión (15′)
    – Se resumen las principales conclusiones y decisiones.
    – Se revisa si se ha conseguido el objetivo de la reunión.
    – Se analiza qué ha ido bien y qué hay que mejorar de la dinámica de la retrospectiva para que la próxima sea mejor

    • Agustin Rojas dice:

      *** Falto una parte del posteo

      ### Resultado

      Por ser la primera vez que se realiza está reunion, llevo un tiempo adaptarse a las actividades propuestas. Una vez logrado este objectivo, se saco provecho a lo propuesto y se pudo obtener un feedback de como se trabajo durante el desarrollo del sprint. Se detectaron algunos problemas que deben ser atendidos con mayor prioridad para no entorpecer el desarrollo del siguiente sprint. A su vez salieron a la luz varias modalidades que el equipo estaban realizando naturalmente y son sumamente positivas.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: