Etiqueta: demo

Sobre la Reunión de Revisión (Iteration Review)

Sobre la Reunión de Revisión (Iteration Review)

Allá por 2015 escribí una serie de artículos sobre esta reunión y este artículo me quedó a medio escribir en la carpeta de borradores. Ayer por la tarde una consulta de una colega me motivó a completar el borrador y publicarlo. Espero resulte útil.

Las reviews de mis proyectos suelen tener 2 partes a las que suelo denominar PPT y Demo.

La parte de Demo es donde se muestra el resultado del trabajo realizado. En términos de Scrum es el incremento de producto, en términos de desarrollo más genérico es el working software. Algunos puntos importantes: esta demostración del software se hace en un ambiente de Test/QA (o como gusten llamarle) es una ambiente con bastante estabilidad y definitivamente no es la máquina de un developer. Incluso en algún caso muy particular he hecho la demo directamente en el ambiente productivo.  Como mencioné en un artículo anterior, la Demo no puedo fallar pues no hay razón para que fallé: la estamos corriendo en un ambiente controlado, tenemos tiempo para prepararla y definir exactamente el flujo de acciones. Es cierto, puede haber algún imprevisto como que se caiga la red y por eso es que debemos tener un plan B. Dicho plan B puede ser correr la demo en otro ambiente o bien tener la demo grabada en video. Lo que el equipo considere necesario para asegurar poder mostrar el producto funcionando.

Por otro lado está la parte que suelo denominar PPT en referencia a las diapositivas que se suelen utilizar para guiar esta parte de la reunión. En esta parte de la review repasamos el compromiso, comentamos los eventos relevantes ocurridos durante la iteración y vemos algunas métricas. Finalmente cerramos con una sugerencia sobre los siguientes pasos. En algunos casos, dependiendo de la dinámica del proyecto, puede que también repasemos el estado de los riesgos del proyecto. Todas estas cuestiones se traducen en los siguientes slides:

  1. Portada: nombre del proyecto, número de iteración, fecha
  2. Slide 1: bullets con los hitos relevantes de la iteración y su estado (completo / incompleto)
  3. Slide 2: Burdown chart
  4. Slide 3: Detalle del backlog
  5. Slide 4: Sugerencia de siguientes pasos

Si la iteración incluyó algún entregable que no fuera código (como por ejemplo un spike o algún documento técnico) entonces hay un slide dedicado a esto.

Básicamente considero 3 alternativas para articular estas dos partes:

  1. Primero PPT y luego Demo
  2. Primero Demo y luego PPT
  3. PPT – Demo – PPT

Generalmente utilizo la variante 3.

Dependiendo de la dinámica del proyecto, puede que la demo la ejecute algún developer o directamente el producto owner.

La reunión olvidada: Iteration Review

En el desarrollo (ágil) de software actual hay 3 reuniones bien establecidas: iteration planning, iteration review y retrospectiva. (nota: si bien esta es la terminología propuesta por Scrum no estoy hablando particularmente de Scrum sino de desarrollo ágil en general)

Hay libros enteros dedicados a planning y también los hay dedicados a retrospectivas, pero no ocurre lo mismo con reviews. Al mismo tiempo he visto consultores/facilitadores colaborando en reuniones de planning y retrospectiva (retrospectivas sobre todo) pero no ocurre lo mismo con las reviews.

Curioso ¿no?. ¿Simple casualidad? Mmm, no creo.¿Será que la review es menos importante? No ¿será que la review es más fácil? Mmmmm, no creo. @egutter me dice que es porque la review es anterior al desarrollo ágil y al mismo tiempo la agilidad no ha introducido grandes cambios en esta reunión, como si lo ha hecho en la planning. Esta justificación me resulta bastante convincente.

Mientras escribo estas líneas caigo en la cuenta que en mi propio libro hay capítulos dedicados a planning y retrospectivas pero no dedicado a reviews, ¡Ja!

Personalmente la mayoría de las veces que he asistido a reviews ajenas (o sea de proyectos/equipos en los que no estaba involucrado) me fui decepcionado. Reuniones empezando tarde, demostraciones inentendibles (o directamente fallidas), usuarios/stakeholders ausentes, incluso miembros del equipo ausentes, pérdida del foco de la reunión, horario de finalización incierto, entre otras cuestiones.

Para mi la review es una reunión clave. O tal vez LA REUNION CLAVE. En la planning el equipo asume un compromiso pero es en la review donde se ve el resultado de ese compromiso. Es en la review donde tenemos la posibilidad de deleitar a nuestros stakeholders. Es en la review donde se juega la continuidad del proyecto.

Es por esto que en mi materia de ingeniería de software dedico una clase para que mis alumnos entiendan la importancia de esta reunión y sepan como prepararla y guiarla apropiadamente. Al mismo tiempo como parte de la materia los alumnos tienen que realizar al menos 4 reviews y su desempeño en esas reviews tiene impacto directo en la aprobación de la materia.

Continuará…