viernes, 16 de diciembre de 2016
INTRODUCCIÓN
En un desarrollo iterativo e incremental el proyecto se
planifica en diversos bloques temporales (en el caso de Scrum de un mes natural
o hasta de dos semanas, si así se necesita) llamados iteraciones.
Las iteraciones se pueden entender como miniproyectos: en
todas las iteraciones se repite un proceso de trabajo similar (de ahí el nombre
“iterativo”) para proporcionar un resultado completo sobre producto final, de
manera que el cliente pueda obtener los beneficios del proyecto de forma
incremental. Para ello, cada requisito se debe completar en una única
iteración: el equipo debe realizar todas las tareas necesarias para completarlo
(incluyendo pruebas y documentación) y que esté preparado para ser entregado al
cliente con el mínimo esfuerzo necesario. De esta manera no se deja para el
final del proyecto ninguna actividad arriesgada relacionada con la entrega de
requisitos.
Modelo de Desarrollo de
Software Interactivo Incremental
En cada iteración el equipo evoluciona el producto (hace
una entrega incremental) a partir de los resultados completados en las
iteraciones anteriores, añadiendo nuevos objetivos/requisitos o mejorando los
que ya fueron completados. Un aspecto fundamental para guiar el desarrollo
iterativo e incremental es la priorización de los objetivos/requisitos en
función del valor que aportan al cliente.
Beneficios
Se puede gestionar las expectativas del cliente
(requisitos desarrollados, velocidad de desarrollo, calidad) de manera regular,
puede tomar decisiones en cada iteración. Esto es especialmente interesante
cuando el cliente no sabe exactamente qué es lo que necesita, lo va sabiendo
conforme va viendo cuales son los resultados del proyecto. El cliente necesita
hacer cambios a corto plazo (nuevos requisitos o a cambios en los ya
realizados) por:
ü Cambios en las
condiciones del mercado (por un cambio de necesidades, por un nuevo producto
que ha lanzado la competencia, urgencias).
ü La reacción y aceptación
del mercado respecto al uso de los primeros resultados del proyecto.
ü Cualquier cambio en el
entorno (recursos, etc.), que pueda incluso finalizar el proyecto manteniendo
como mínimo los resultados alcanzados hasta ese momento.
El equipo necesita saber si lo que ha entendido es lo que
el cliente espera, el cliente puede comenzar el proyecto con requisitos de alto
nivel, quizás no del todo completos, de manera que se vayan refinando en
sucesivas iteraciones. Sólo es necesario conocer con más detalle los requisitos
de las primeras iteraciones, los que más valor aportan. No es necesario
realizar una recolección completa y detallada de todos los requisitos antes de
empezar el desarrollo del proyecto.
El cliente puede obtener resultados importantes y usables
ya desde las primeras iteraciones. Se puede gestionar de manera natural los
cambios que van apareciendo durante el proyecto. La finalización de cada
iteración es el lugar natural donde el cliente puede proporcionar su feedback
tras examinar el resultado obtenido (ver control empírico y demostración). Con
esta información ya es posible planificar los cambios necesarios para alinearse
con las expectativas del cliente desde las primeras iteraciones, de manera que
al finalizar el proyecto el cliente obtenga los objetivos esperados.
El cliente como máximo puede perder los recursos
dedicados a una iteración, no los de todo el proyecto. La finalización de cada
iteración es el lugar natural donde el equipo puede decidir cómo mejorar su
proceso de trabajo, en función de la experiencia obtenida. Con esta información
ya es posible planificar los cambios necesarios para aumentar la productividad
y calidad desde las primeras iteraciones.
Permite conocer el progreso real del proyecto desde las
primeras iteraciones y extrapolar si su finalización es viable en la fecha prevista.
El cliente puede decidir priorizar los requisitos del proyecto, añadir nuevos
equipos, cancelarlo, etc, permite mitigar desde el inicio los riesgos del
proyecto. Desde la primera iteración el equipo tiene que gestionar los
problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes
estos riesgos, es posible iniciar su
mitigación de manera anticipada.
Permite gestionar la complejidad del proyecto.
ü En una iteración sólo se
trabaja en los requisitos que aportan más valor en ese momento.
ü Se puede dividir la
complejidad para que cada parte sea resuelta en diferentes iteraciones.
Dado que cada iteración debe dar como resultado
requisitos terminados, se minimiza el número de errores que se producen en el
desarrollo y se aumentar la calidad.
Restricciones
La disponibilidad del cliente debe ser alta durante todo
el proyecto dado que participa de manera continua:
ü El inicio de una
iteración, el cliente ha de detallar (o haber detallado previamente) los
requisitos que se van a desarrollar.
ü En la finalización de
cada iteración, el cliente ha de revisar los requisitos desarrollados.
La relación con el cliente ha de estar basada en los
principios de colaboración y ganar/ganar más que tratarse de una relación
contractual en la cual cada parte únicamente defiende su beneficio a corto
plazo. Cada iteración debe dar como resultado requisitos terminados, de manera
que el resultado sea realmente útil para el cliente y no deje tareas pendientes
para futuras iteraciones o para la finalización del proyecto.
Cada iteración ha de aportar un valor al cliente,
entregar unos resultados cerrados que sean susceptibles de ser utilizados por
él, es necesario disponer de técnicas y herramientas que permitan hacer cambios
fácilmente en el producto, de manera que pueda crecer en cada iteración de
manera incremental sin hacer un gran esfuerzo adicional, manteniendo su
complejidad minimizada y su calidad.
Recomendaciones
Utilizar iteraciones cortas de 2 a 4 semanas incrementa
la productividad del proyecto, dado que el equipo trabaja de forma más
eficiente cuando tiene objetivos a corto plazo. Asimismo, con iteraciones
cortas la precisión de las estimaciones aumenta. El tamaño depende de:
ü Los condicionantes del
proyecto.
ü La necesidad de tener
feedback más o menos rápido.
ü Que no se degrade la
relación trabajo útil / gestión operativa (por ejemplo reuniones, actividades
necesarias que no producen valor directo, etc.).
Utilizar iteraciones regulares, de manera que todas sean
un timebox de la misma duración. El equipo aprende a calcular la velocidad de
desarrollo, la cantidad de trabajo que puede hacer en una iteración (sin tener
que hacer extrapolaciones si las iteraciones no fuesen regulares), el cliente
puede proyectar cuantas iteraciones se necesitan para tener cada entrega, en
función de la velocidad de desarrollo del equipo (el trabajo que pudo completar
en iteraciones anteriores del mismo tamaño), y tomar decisiones al respecto.
Permite gestionar y sincronizar de manera sencilla las
necesidades del proyecto con respecto a las de otros proyectos (integración con
el trabajo realizado por otros equipos, compartición de personas que son
difíciles de asignar a un único equipo), las iteraciones coincidiendo con meses
naturales permiten sincronizar el trabajo del equipo con el de otros
departamentos y con el resto de la organización (por ejemplo, la organización
puede tener medidas de resultados y objetivos a nivel trimestral o
cuatrimestral).
Ventajas
ü Con un paradigma
incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la
funcionalidad parcial.
ü También provee un impacto
ventajoso frente al cliente, que es la entrega temprana de partes operativas del
software.
ü Resulta más sencillo
acomodar cambios al acotar el tamaño de los incrementos.
Desventajas
ü Requiere de mucha
planeación, tanto administrativa como técnica.
ü Requiere de metas claras
para conocer el estado del proyecto.
