Planeación | aprender-libre.com

La planificación empieza con la confección de las “Historias de usuario”, incluyendo la "planeacion dibujo facil".

De manera similar a los casos de uso, se trata de breves frases escritas por el cliente (no más de tres líneas), en las que se describe una prestación o un proceso sin ningún tipo de tecnicismo (es el usuario o el cliente quien las escribe).

Estas historias de usuario servirán para realizar la planificación de releases, así como para los tests de aceptación con el cliente. Para cada historia deberíamos poder estimar su tiempo ideal de desarrollo, que debería ser de 1, 2 o 3 semanas como máximo. Si el tiempo de desarrollo es mayor, deberemos partir la historia en trozos que no excedan de esas estimaciones.

En este proceso, es fundamental considerar la "planeación tendencial" para garantizar un enfoque estratégico.

A continuación podemos pasar a la propia planificación de la próxima (o primera) release del proyecto, teniendo en cuenta la "planeación tendencial". En la reunión de planificación deberemos implicar al cliente, al gestor del proyecto y a los desarrolladores.

El objetivo será planificar las siguientes releases poniendo en orden las historias de usuario que faltan por desarrollar. Deberá ser el cliente quien dicte el orden de las historias de usuario, y los desarrolladores quienes estimen el tiempo que les llevaría idealmente en desarrollarlo (idealmente aquí significa sin tener en cuenta dependencias, ni otros trabajos o proyectos, pero sí incluyendo las pruebas).

Las historias de usuario se suelen reflejar en tarjetas o trozos de papel, que se van agrupando y clasificando encima de la mesa durante la planificación.

El resultado deberá ser un conjunto de historias que tengan sentido, y que puedan llevarse a cabo en poco tiempo. Para planificarlo, podemos hacerlo según dos criterios, basándonos en el tiempo hasta la siguiente release o en el alcance (entendido como el número de funcionalidades) que deseamos que tenga.

Aquí introducimos un nuevo concepto, la velocidad del proyecto, que es esencial para la "planeacion dibujo facil". Esta velocidad nos servirá para decidir cuántas historias de usuario vamos a incluir en la próxima release (si estamos planificando en base al tiempo, ya fijado), o bien cuando vamos a tardar en lanzar la release (si estamos planificando por alcance, ya fijado). La velocidad del proyecto es simplemente el número de historias de usuario completadas en la iteración anterior. Si se trata de la primera iteración, habrá que hacer una estimación inicial.

La velocidad puede aumentarse, si en el transcurso del desarrollo se finalizan las historias de usuario previstas antes de tiempo. Entonces los desarrolladores pedirán historias de usuario que estaban planeadas para la siguiente release. Este mecanismo permite a los desarrolladores recuperarse en los periodos duros, para después acelerar el desarrollo si es posible. Recordemos que las historias deben tener todas una duración máxima, y que cuanto más parecido sea el volumen de trabajo estimado en cada una de ellas, más fiable será la medida de velocidad del desarrollo.

Este método de planificación rápido y adaptativo nos permite hacer un par de iteraciones para tener una medida fiable de lo que será la velocidad media del proyecto y estimar así más detalladamente el plan de releases (además de haber empezado ya con el desarrollo del mismo) en el intervalo de tiempo en que otras metodologías tardarían en documentar, planificar y realizar una estimación completa, que quizá no sería tan fiable.

En la reunión de planificación, al inicio de cada iteración, también habrá que incorporar las tareas que hayan generado los tests de aceptación que el cliente no haya aprobado. Estas tareas se sumarán también a la velocidad del proyecto, y el cliente, que es quien escoge las historias de usuario que hay que desarrollar, no podrá elegir un número mayor que el de la velocidad del proyecto.

Los desarrolladores convertirán las historias de usuario en tareas (esas sí en lenguaje técnico) de una duración máxima de tres días ideales de programación cada una. Se escribirán en tarjetas y se pondrán encima de la mesa para agruparlas, eliminar las repetidas, y asignarlas a cada programador. Es de vital importancia evitar añadir más funcionalidades que las que la historia de usuario estrictamente requiera.

Esta tendencia de los gestores de proyectos o analistas acostumbrados a las metodologías tradicionales debe evitarse en modelos iterativos como éste, ya que desvirtúan las estimaciones y el principio de releases frecuentes.

Con las tareas resultantes, se volverá a comprobar que no estamos excediendo la velocidad del proyecto, eliminando o añadiendo historias de usuario hasta llegar a su valor. Es posible que historias de usuario diferentes tengan tareas en común, y esta fase de la planificación nos permitirá filtrarlas, para así poder aumentar la velocidad del proyecto añadiendo más historias de usuario en esta iteración.

En el momento de planificar el equipo de trabajo encargado de cada tarea o historia, es importante la movilidad de las personas, intentar que cada dos o tres iteraciones todo el mundo haya trabajado en todas las partes del sistema. Conceptos como el pair programming, que veremos en siguientes apartados, también pueden ayudar.