Agile Retrospectives: cómo mejorar
Escrito por Luix hace 2 meses
bajo una licencia de Creative Commons
289 visitas. Etiquetas: retrospective, scrum, agile
En una pequeña serie de artículos resumiré lo que encontré recientemente en el libro que abajo se referencia referente a cómo mejorar las reuniones retrospectivas (qué mal suena; no, no estoy hablando de Retrospector ni nada relacionado con La Hora Chanante).
¿Qué es un ‘retrospective’?
Una retrospección en la vida es pararse por un momento, mirar hacia atrás y reflexionar sobre el camino trazado hasta la fecha, evaluando las cosas buenas y las malas, y aprendiendo de todo ello para ser mejor persona.
Esto, que muchos seres humanos que andan sueltos por ahí deberían hacer a menudo, en las metodologías de desarrollo ágil de software se llama “retrospective” y en un modelo de desarrollo iterativo viene muy bien para evaluar cada una de esas iteraciones que se realizan. En nuestro caso particular orientaremos el discurso hacia SCRUM, quizá la metodología ágil más conocida y extendida, junto con eXtreme Programming.
Fases de un ‘retrospective’
Una buena reunión retrospectiva debería constar de las siguientes fases:
- Establecer el escenario.
- Recoger datos y métricas.
- Generar reflexiones y opiniones.
- Decidir qué hacer.
- Cerrar el retrospective.
Estas fases, no parecen nada del otro mundo y muchos equipos las llevan a cabo, en mayor o menor medida. ¿Por qué aun así no hacen buenos retrospectives? Bueno, quizá el problema está en el cómo y no en el qué.
¿Quién dirige un ‘retrospective’?
Un retrospective puede estar dirigido por el gestor del equipo o por cualquier miembro del mismo, o incluso ir variando en cada ocasión. Quien dirige la reunión deberá mantenerse lo más al margen posible, porque el poder subyacente que posee quien dirige la reunión puede coartar a los demás miembros a participar. Esto es especialmente apblicable al gestor, que en cualquier caso se mantendrá lo más al margen posible de la discusión, debido a que su estátus puede influir en las opiniones del equipo y romper la dinámica del grupo.
Es importante identificar qué parámetros se han de analizar en un retrospective. Algunos buenos ejemplos:
- Buscar modos de mejorar las prácticas.
- Descubrir qué se hizo bien.
- Entender las razones subyacentes por las que no se cumplieron los objetivos.
- Buscar modos de mejorar la responsabilidad de cara a los clientes.
- Reconstruir relaciones maltrechas.
- …
Y para terminar esta sección, dos máximas que deben cumplirse durante una reunión retrospectiva:
- Evitar culpabilizar a sujetos por el incumplimiento de un objetivo.
- Facilitar el que todo el mundo hable.
¿Cuánto debe durar un retrospective?
Depende.
De la duración del sprint, de la complejidad de la tecnología que se maneja en dicho sprint, del tamaño del equipo y del nivel de conflictos y controversias en las opiniones de los miembros. Como guía: cada semana de sprint, una hora de reunión retrospectiva.
Acortar el tiempo de la reunión es hacer trampa y engañarse uno mismo; sin embargo, si los objetivos se cumplieron se puede acortar la reunión.
Por otro lado, los retrospectives deben prepararse previamente. El equipo debe entrar en la sala de reuniones con algo mínimamente preparado, un adelanto de lo que se va a hablar.
¿Cómo preparar retrospectives?
Ver http://luixrodriguezneches.wordpress.com/
¿Como hacer que el equipo prepare la reunión?
Ver http://luixrodriguezneches.wordpress.com/
¿Y después de la reunión?
Ver http://luixrodriguezneches.wordpress.com/
Y en la próxima entrega…
He dado un rodeo a propósito para no explicar detalladamente las fases de una reunión retrospectiva. Mi objetivo aquí ha sido el de sentar las bases, dar unos primeros consejos y establecer algunas ideas. En la próxima entrega explicaré detalladamente en qué consiste cada fase.
Y en siguientes entregas explicaremos una serie de actividades que pueden realizarse durante la reunión retrospectiva y cuyo objetivo primordial es fomentar la participación. Fuera aparte de las ideas que surjan, de las decisiones tomadas y todo lo demás. Lo principal es hacer que todo el mundo participe. Lo demás vendrá sólo.
Referencias:
Agile Retrospectives – Making good teams great
Esther Derby, Diana Larsen
Artículos Relacionados
- Agile Retrospectives (II): Fases
- Agile Retrospectives (III): Actividades (I)
- Scrum, una metodología Ágil (I)
- Scrum, una metodología Ágil (II)
- Categorización de Code-Smells
Grupos relacionados
Ingeniero Informático por la Universidad de Valladolid (España). Me interesa la programación, gestión de proyectos, patrones, metodologías..., la seguridad y la administración de redes y sistemas operativos. Actualmente trabajo en Códice Software, una empresa vallisoletana que desarrolla PlasticSCM, una herramienta de control de versiones, además de consultoría a clientes sobre temas relacionados con la Gestión de Configuraciones. http://luixrodriguezneches.wordpress.com
2 comentarios en "Agile Retrospectives: cómo mejorar"
Leonardo_ escribió
hace 2 meses
josecgil escribió
hace 2 meses
En el desarrollo de videojuegos algunos estudios hacen algo que tiene un ligero parecido. Lo llaman "postmortem" y consiste en analizar qué fue bien y qué fue mal después de terminar un proyecto (no en cada iteración). Un par de ejemplos: Dark Age of Camelot y Age of empires II.
© Copyright 2008-2009 debug_mode=ON | Aviso legal | Contacto | FAQ | ¿Quiénes somos?
|
#1
Desde que empecé a trabajar en una ingeniería, hace ya mucho tiempo soy consciente del poco esfuerzo que suelen dedicar los diversos departamentos a tareas de investigación.
Suelen dejan de lado las tareas de formación e investigación postergadas.
Está claro que la empresa está orientada a la obtención de beneficios.
Introducir en la empresa técnicas sistemáticas que favorecen la evolución más o menos contínuna creo que es un avance conceptual importante.
Una retrospectiva tras la fase de pruebas de cada solución informática, orientada sobre todo al análisis de costes y criterios de calidad, mejora las técnicas de desarrollo.