Control de las funcionalidades de un producto con Google Docs

23-06-2009 Luis Artola

Animado por el artículo de Enrique sobre el uso de Google Docs para la gestión funcional de un proyecto, publico un artículo que llevaba tiempo pensando sobre cómo lo estoy haciendo yo ahora mismo. Obviamente, el sistema que os expongo está basado en SCRUM, aunque no me atrevería a decir que estoy “haciendo SCRUM” precisamente. Si los términos que utilizo en el artículo (Product Backog, Iteration Backlog, etc…) te son nuevos, quizá te interese leerte éste estupendo libro de introducción a SCRUM. La captura que muestro a continuación, como se puede ver claramente, es inventada.

La razón por la que utilizamos Google Docs y no la clásica pizarra de SCRUM es porque el equipo no se encuentra físicamente en el mismo sitio. Quizá en el futuro utilicemos herramientas más específicas para la gestión de las user stories, iteration backlog e increment … pero a día de hoy éste sistema nos está funcionando por lo sencillo y visual que es.

El objetivo de la gestión es planificar, ejecutar y controlar. Veamos a continuación cómo planificamos, ejecutamos y controlamos el valor funcional de la aplicación.

Algunos apuntes sobre la ejecución:

• El documento recoge tanto el Iteration Backlog como el Increment. Pero es un documento que sólo ve el equipo. El cliente puede ver el Product Backlog (que está en un documento a parte) y se le envía una versión “más redactada” del Increment.
• Cada iteración está en una tabla. Las tablas se guardan todas en el mismo documento, de tal manera que si vamos bajando por el documento podremos ver el backlog de las anteriores iteraciones. Las iteraciones se nombran con el primer día que se ejecutan (Iteración 18-05-2009) . Suelen ser de dos semanas.
• Todos los proyectos son gestionados desde el mismo Iteration Backlog.
• Marcamos la prioridad de una funcionalidad dentro de una iteración con [1],[2] y [3].
• Se puede saber en qué estado está una Iteración porque:
  • Si está a la izquierda y sólo pone la prioridad([1]), es que está sin empezar.
  • Si está a la izquierda pero pone la prioridad  y un dueño ([1][Luis]), es que está empezada y la está haciendo Luis.
  • Si está a la derecha, es que está terminada.
• En el incremento, además de los items terminados en la iteración, se añaden los unplanned items ([U]), defectos ([D]) y cuestiones técnicas abordadas ([T]). Supongo que para los defectos sería mucho mejor utilizar un Issue Tracker, pero normalmente los clientes suelen querer comunicarse solo por teléfono, y bastante cuesta ya hacerles escribir un mail… como para intentar que se peguen con un Issue Tracker…
• Los defectos tienen siempre prioridad sobre el desarrollo de nuevas funcionalidades.
• La trazabilidad del proyecto es enorme, no sólo porque así tenemos un histórico de todas las iteraciones, sino porque el Google Docs guarda versiones de cada cambio que se hace.. así que podríamos retrotraernos a cualquier situación pasada del documento.

Forma de detectar cómo va la iteración (controlar):

• Si se están generando muchos Unplanned Items ([U]) es que algo se diseñó mal.
• Si se están generando muchos Defectos ([D]) es que la aplicación no está suficientemente probada.
• Si se están atacando funcionalidades de prioridad [2] sin haber terminado las de prioridad [1], o se están atacando funcionalidades sin haber corregido los Defectos, probablemente se esté programando en el orden incorrecto.
• Otras cuestiones muy relacionadas con las funcionalidades, las iteraciones, sería el control de costes y plazos: lo voy a dejar fuera del artículo por no extenderme.

Algunos apuntes sobre planificación de las funcionalidades que se incluyen en cada iteración. En cada iteración se meten una serie de funcionalidades de el/los Product Backlog. Esas funcionalides cumplen que:

• Es la mayor cantidad de funcionalidades que se pueden hacer en dos semanas.
• Son las funcionalidades que más valor añaden a la aplicación.
• Camino crítico: desarrollar esas funcionalidades ayudan a descubrir posibles nuevos requisitos de forma lo más temprana posible (aunque no sea la que más valor añade), eliminar incertidumbres y hacer pensar al cliente (feedback) en qué es lo que quiere realmente. Esto también puede incluir desarrollar funcionalidades que ayuden a descubrir el diseño técnico (orientación a objetos, patrones de diseño) de la aplicación.
• La que el cliente exija (a veces no hay más remedio: hay que implementar funcionalidades que el cliente exija aunque se le argumente que no son las que más valor añaden o las que más ayudan a descubrir la forma exacta de la aplicación).
• Se evita programar funcionalides que no puedan probarse o ponerse en producción cuanto antes. Ejemplo: “Informe anual de ventas”, implementar éste informe en la primera iteración del producto, cuando todavía la empresa no ha introducido ni una sola venta, hará que no pueda probarse correctamente y traerá problemas meses después.
• Resolver defectos tiene más prioridad que desarrollar nuevas funcionalidades, aunque dependerá de la gravedad del defecto. Los defectos son difíciles de planificar porque no sabes ni cuando ni cómo saldrán.
• Es importante saber dividir o juntar funcionalidades para poder adaptarlas al tamaño de la iteración. No sirve para nada hacer “Listar facturas”, si no tienes un “añadir facturas”. Deberán ir en la misma iteración. Quizá “buscar facturas” pueda ir en la siguiente iteración, pese a que todo ello fuera planificado originalmente como “gestionar facturas (listar, añadir, modificar, eliminar, buscar)”.