En esta fase se establece la prioridad de cada historia de usuario así como una estimación del esfuerzo necesario de cada una de ellas con el fin de determinar un cronograma de entregas.
Las estimaciones de esfuerzo asociado a la implementación de las historias se establecen utilizando como medida el punto. Un punto, equivale a una semana ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, se mantiene un registro de la “velocidad” de desarrollo, establecida en puntos por iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración.
La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto, determinándose cuántos puntos se pueden completar. Al planificar según alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su implementación.
Partiendo de las historias de usuario anteriores se realiza una planificación en cuatro iteraciones basándose en el tiempo y procurando agrupar la funcionalidad relacionada en la misma iteración.
En la Tabla 7.5, “Fechas de entrega” pueden verse las fechas reales en las que cada versión ha sido entregada a través del sitio web [Sourceforge]. El motivo por el que se crean nuevas versiones de alguno de los módulos puede ser cambios desde la última versión o simplemente actualización de las dependencias en otros módulos cuando una nueva versión de éstos últimos es entregada, para evitar posibles problemas. Con estos datos y teniendo en cuenta que el desarrollo como tal comenzó a finales del mes de abril se obtienen los datos reales de duración de cada iteración tal y como se muestran en cada apartado.
Tabla 7.5. Fechas de entrega
| 2ª semana julio | 4ª semana julio | 4ª semana agosto | 3ª semana septiembre | |
|---|---|---|---|---|
| common | 0.1 | 0.2 | 0.3 | |
| common-maven | 0.1-0.2[a] | 0.3 | 0.4 | |
| common-model | 0.1 | 0.2 | 0.3 | 0.4 |
| common-webapp-controller | 0.1 | 0.2 | 0.3 | 0.4 |
| common-webapp-taglib | 0.1 | |||
| common-webapp-view | 0.1 | 0.2 | 0.3 | |
| party-model | 0.1 | 0.2 | 0.3 | 0.4 |
| party-webapp | 0.1 | 0.2 | 0.3 | 0.4 |
| user-model | 0.1 | 0.2 | 0.3 | |
| user-webapp | 0.1 | 0.2 | 0.3 | |
| inventory-model | 0.1 | 0.2 | ||
| inventory-webapp | 0.1 | 0.2 | ||
| order-model | 0.1 | |||
| order-webapp | 0.1 | |||
[a] 0.2 es una versión de mantenimiento que soluciona problemas de integración de la versión anterior | ||||
En esta primera iteración se creará un prototipo con el que se comprobará la adecuación de la tecnología escogida y se intentará crear la mayor parte de la base de la arquitectura del sistema, que será encapsulada dentro de los módulos common. No se implementará una funcionalidad muy extensa tan sólo un mínimo para tener cuanto antes una demo que poder mostrar en el sitio web y así atraer posibles usuarios.
Como se puede comprobar, la duración real de esta iteración ha superado en dos semanas el tiempo estimado. Este retraso ha sido debido principalmente a la curva de aprendizaje de la tecnología usada.
En una segunda iteración se añadirá la funcionalidad necesaria para gestionar la autenticación y autorización de los usuarios, y se completará la gestión de contactos comenzada en la iteración anterior.
La duración real de la iteración ha sido muy breve gracias a que el núcleo del sistema ya había sido realizado en la iteración anterior con todo el esfuerzo de integración de tecnologías. Una vez hecho esto, la gestión de autenticación y autorización ha sido sencilla de integrar en el sistema, así como también ha sido breve la implementación de la gestión de contactos.
En esta tercera iteración se añadirá la funcionalidad relativa a la gestión de inventario. También se hará que el sistema sea accesible desde dispositivos móviles.
A pesar de problemas surgidos que han requerido la realización de cambios en el núcleo del sistema, la duración de la iteración no ha aumentado, lo que indica que se ha sobreestimado el esfuerzo de las historias de usuario.
La cuarta iteración conllevará la finalización del sistema tras la implementación de las historias correspondientes a la gestión de compras y ventas.
El tiempo real de desarrollo han sido dos semanas ya que la primera semana de septiembre no se ha dedicado al desarrollo del proyecto, reduciéndose lo estimado tal y como se podía extraer de anteriores planificaciones donde se ha constatado que la implementación de nueva funcionalidad es un proceso bastante ágil.