lunes, 11 de enero de 2010

Planificando entregas con Scrum (I)


En el post que nos ocupa vamos a ver los pasos para realizar la planificación de las diferentes entregas o releases de un proyecto, utilizando Scrum (aunque este proceso podría fácilmente aplicarse a cualquier metodología iterativa).

Lo que se quiere conseguir es crear una planificación a mas largo plazo, de mas duración que una iteración y que abarque las diferentes entregas del proyecto (que pueden ser varias si se realiza por fases o puede ser una única entrega), y que permita definir una previsión de que funcionalidades se podrán tener finalizadas en una determinada fecha.

En su estado más básico, una planificación de entrega o de proyecto debería contar con como mínimo la siguiente información:

  • Una lista de historias de usuario, a ser posible estimadas y priorizadas (product backlog)
  • Los miembros del equipo que participan en el proyecto (desarrolladores, analistas, administradores de bbdd...)
  • Fecha de inicio de la primera iteración y fecha de fin de la última iteración.
Es importante indicar que este nivel de planificación no se debe caer en el error de intentar entrar en el detalle de que personas van a realizar que tareas, en que secuencia se van a realizar las mismas etc... Estos detalles deben dejarse para la planificación de cada iteración, momento en el que las historias de usuario se dividen en tareas a nivel técnico.

Los pasos generales para realizar la planificación de las entregas son los siguientes:

  • Determinar los criterios mas relevantes para el éxito del proyecto, por ejemplo entregar antes de una fecha determinada, tener un conjunto mínimo de funcionalidades pero una fecha flexible, una combinación de ambas...
  • Realizar la estimación de las historias de usuario, concretamente de aquellas que tienen una alta probabilidad de formar parte de la siguiente entrega. Este proceso se realiza entre el Product Owner y los miembros del equipo (¡¡Solo hace estimaciones el equipo!!) y se estima en puntos de historia o días ideales (y usando alguna técnica estilo Planning Poker)
  • Seleccionar la duración de las iteraciones, en base a la duración del proyecto. Lo normal es de 2 a 4 semanas, pero en proyectos de larga duración se pueden realizar iteraciones mas largas (aunque yo no lo recomiendo) o en proyectos muy cortos se pueden llegar a hacer iteraciones de una única semana.
  • Realizar una estimación de la velocidad, en puntos de historia (o días ideales) del equipo. Si este ya ha trabajado junto se puede utilizar la velocidad media en anteriores iteraciones, si no lo mejor es hacer una estimación con alguna de las técnicas existentes para ello y ir ajustándola a medida que avance el proyecto.
  • Priorizar las historias de usuario, de manera que siempre esté claro cual es la siguiente a desarrollar. Una buena manera de asegurar esto es utilizando el enfoque de Henrik Kniberg en su muy recomendable Scrum and XP For The Trenches, donde utiliza el atributo importancia, en lugar de prioridad. La priorización la decide el Product Owner, pero es aconsejable que escuche la opinión de los miembros del equipo, sobre todo en cuestiones relativa a la secuenciación de las historias de usuario.
  • Seleccionar las historias y la fecha de entrega, en base a la velocidad y a la estimación realizada. Si el factor mas importante en el proyecto es la fecha de entrega, lo que se hará será calcular el conjunto de funcionalidades que se preveen tener listas para esa fecha, si por el contrario, el factor importante son las funcionalidades mínimas, se deduce la fecha estimada de finalización.
  • Comprobar que se cumplen los criterios de éxito del proyecto. Si no es así se debe volver a los procesos de estimación y priorización, haciendo los cambios necesarios (subdividir historias en otras mas pequeñas, cambiando la priorización...) hasta conseguir dar con un grupo de funcionalidades para la entrega que cumpla con los criterios de éxito.

Otras cosa a tener en cuenta durante el proceso es la decisión de determinar por adelantado que funcionalidades se desarrollarán en cada iteración, o por el contrario sólo se deciden las funcionalidades a entregar en la iteración más próxima (de entre todas las planeadas para la entrega)

Cómo punto final, remarcar que es importantísimo que la planificación no sea un "papel colgado en la pared", sinó que hay que ir actualizándola y revisándola con cierta frecuencia, de manera que se pueda conocer rápidamente las desviaciones o los cambios que ocurren. Una buena opción es replanificar al inicio de cada iteración , justo antes de la planificación de la misma.

Aprovecho para hacer referencia al post anterior Calendario de Sprint
relacionando el concepto aquí explicado, con una de las reuniones propuestas en el mismo. Concretamente, la planificación de entregas seria lo que en el calendario llamabamos Project Planning (aunque en algunas organizaciones podría ser una fusión de las dos primeras reuniones explicadas, Project Review y Project Planning)

En el siguiente Post, mostraré un ejemplo práctico de cómo realizar la Planificación de Entregas de un proyecto sencillo.










1 comentario:

Anónimo dijo...

Buen aporte! Gracias Jasosa