Divide et impera: ‘divide y vencerás’.
Frase atribuida a Julio César.
 |
| FreeDigitalPhoto.Net |
Los proyectos de construcción de software deben responder
con prontitud a los cambios frecuentes e inesperados tanto en los requisitos
del negocio como en la tecnología de implementación. Es habitual que en estos
proyectos haya una gran incertidumbre en cuanto al alcance, a la fecha de
entrega y al presupuesto requerido, lo que conlleva un alto número de riesgos
que obstaculizan la consecución de los objetivos propuestos.
Por ejemplo, es un grave error con consecuencias atroces,
asumir que los usuarios –generalmente personas de mandos medios y altos– son
capaces de suministrar al equipo del proyecto información oportuna y precisa de
todos los requisitos para un sistema de software. Además, uno de los problemas
principales de la construcción de software tradicional recae en el hecho de que
quienes han estado involucrados en ello hasta la fecha no están dispuestos a
reconocer que esta actividad es, la mayoría de las veces, un asunto de
planeación ocupacional y organizacional.
Corresponde precisamente al gerente del proyecto lidiar
con todos estos factores que entorpecen la evolución normal de un proyecto de
software. Es el gerente del proyecto quien sabe que los procedimientos
tradicionales seguidos tienen un conjunto de riesgos tácitos “indetectables”
dada la propia naturaleza del ciclo de vida de los proyectos. Los proyectos iterativos propician la detección
temprana de los riesgos y facilitan su manejo anticipado por parte de los
responsables. Pero ¿qué es realmente un proyecto iterativo? Para entenderlo,
veamos lo fundamental.
¿Qué es una Iteración?
Una iteración es un mini-proyecto con una salida bien
definida: una versión incrementada, estable, probada e integrada del producto
de software, con su documentación asociada.
Esta definición lleva implícito un concepto muy
importante: la versión o porción de software que se produce en una iteración tiene
tales cualidades que se podría no solo mostrar al usuario sino poner en
producción. De hecho, en fases avanzadas del proyecto, esto ocurre con
regularidad; es decir, en un proyecto iterativo es posible tener versiones del
software funcionando antes de terminar el proyecto.
Características de las
Iteraciones
Ahora bien, como cualquier proyecto (de software), una
iteración pasa por todas las etapas de un proyecto tradicional: inicio,
planeación, ejecución y control, y cierre. En el caso particular de los
proyectos de software, durante la etapa de ejecución y control de una iteración
encontramos el ciclo tradicional del software: modelado de requisitos, análisis
y diseño, implementación, pruebas, integración y, opcionalmente, despliegue,
aunque una iteración no necesariamente cubre todas las etapas.
Pero la verdadera esencia de las iteraciones radica en otros
aspectos que buscan disminuir la incertidumbre en los proyectos, aumentar el
desempeño, mitigar los riesgos, sobre todo reducir los riesgos técnicos en las
primeras iteraciones, y recibir retroalimentación continua y efectiva de los
usuarios. El primero de estos aspectos es la duración de las iteraciones: de
unos pocos días hasta unas pocas semanas es lo más eficaz, aunque también
depende del tamaño del equipo y de la duración total estimada del proyecto.
Figura 1: esquema de
una iteración típica. Cada iteración es un mini-proyecto con todo lo que ello
implica.
Excepto quizás en proyectos grandes con más de 40 o 50
personas, la idea es no tener iteraciones de varios meses, ya que en ese tiempo
puede ocurrir lo que sucede en los proyectos ejecutados en cascada: hay poca o
ninguna mitigación de riesgos técnicos, puesto que no hay entregas “visibles”
para los usuarios, recibimos poca retroalimentación de ellos y así no medimos
eficientemente el progreso del proyecto, o no podemos reaccionar a tiempo ante
una mala decisión técnica que conduzca a un retraso en el proyecto.
Duración de las iteraciones
Número de personas
|
Duración
|
2
a 15
|
2
a 4 semanas
|
15
a 30
|
4
a 6 semanas
|
30
a 50
|
6
a 8 semanas
|
Fuente:
Bittner, K. Spence, I. Managing Iterative software Development Projects. Addison Wesley Professional. Junio 27, 2006.
Otro aspecto importante es que la duración de las
iteraciones no tiene que ser la misma, pero la desviación debe ser pequeña. La
idea es no tener iteraciones de dos semanas y otras de seis o más. Scrum, una metodología ágil ampliamente usada
hoy día, por ejemplo, promulga iteraciones de 30 días, llamadas Sprint, con equipos de menos de 10
personas. Y ya que menciono Scrum, me parece importante aclarar que no todos
los proyectos iterativos son ágiles, pero todos los proyectos ágiles son
iterativos; la iteración es una propiedad intrínseca de las metodologías ágiles
de construcción de software.
Gestión iterativa de
proyectos
Otra de las características principales de este tipo de
proyectos es que en las primeras iteraciones se construye la porción de
producto que es significativa para la arquitectura del software. El gerente del
proyecto se apoya en el arquitecto y en los ingenieros de requisitos para tomar
la decisión de cuántas iteraciones “arquitectónicas” tendrá el proyecto,
normalmente de 1 a 3, y qué funcionalidad será implementada, de tal manera que
al final de esta fase (llamada de Elaboración, de Planeación o de Arquitectura,
según la metodología que se use), no solo existe un documento de arquitectura o
de diseño de alto nivel, sino que hay software funcionando cuyo propósito es
demostrar que esa es la arquitectura correcta para el producto.
Figura 2: Perfil de los riesgos durante la
gestión iterativa de proyectos. Los riesgos técnicos disminuyen en las primeras
iteraciones. Contrario a lo que sucedía con el método en cascada, donde los
riesgos disminuían al final del proyecto, durante las pruebas en el mejor de
los casos.
La gestión iterativa de proyectos puede tomar muchas
formas, dependiendo de las metas del proyecto: el desarrollo iterativo de prototipos puede ayudar a evolucionar
una interfaz de usuario. El desarrollo ágil
es una forma de involucrar muy de cerca un usuario en un proceso que podría
repetirse diariamente. Entre tanto, el desarrollo incremental permite al equipo del proyecto a producir incrementos
semanales o en cortos períodos de tiempo, mientras que un modelo en espiral puede ayudar al equipo a
confrontar y a mitigar los riesgos de un producto en evolución.
En estos casos es el gerente del proyecto quien toma la
decisión de la estrategia a seguir, teniendo en cuenta el valor de distintas
variables: tamaño del proyecto, tamaño del equipo, experiencia del equipo y de
los usuarios, criticidad y complejidad del proyecto, los riesgos técnicos y
administrativos, el grado de volatilidad detectada de los requisitos y las
herramientas de apoyo disponibles.
 |
| Foto de FreeDigitalPhoto.Net |
La gestión iterativa ayuda a superar las barreras de
especificación y de comunicación entre los usuarios y el equipo de trabajo con
el único objetivo de alcanzar la más alta satisfacción de los primeros. El
factor clave es precisamente que las personas del negocio entiendan los
requisitos y retroalimenten a las personas de tecnología. En este apartado, el
papel del gerente es de mediador, por lo que debería incluir elementos de
comunicación efectiva, como la tolerancia –cuando no se confunde con la
pasividad–, la imparcialidad y la empatía, para construir confianza y
disciplina entre unos y otros.
Corresponde al Gerente del Proyecto integrar el equipo de
trabajo con todos los involucrados tanto
internos como externos y la gestión iterativa posibilita una integración paso a
paso. Para lograrlo, el gerente del proyecto debe tener en cuenta algo que está
fuera de su control: una infraestructura cambiante y un proceso de negocio
inestable. También se debe vincular la estructura del proyecto (iterativo) con
el éxito del proyecto, de esta forma, no habrá espacio para la ruina del
proyecto.
Esto se logra mediante la motivación interna del equipo
de trabajo, el desarrollo de competencias blandas (negociación, técnicas de
comunicación –escrita, verbal y no verbal–, manejo eficaz del tiempo,
creatividad, trabajo en equipo, entre otras) y la “implantación no invasiva de
chips de alta efectividad”, como la proactividad
y la sinergia.
Ahora bien, puede haber muchas desviaciones de un plan de
proyecto de desarrollo de software. En estos casos, el gerente de proyecto
decide cómo manejarlas, puesto que cada retraso requiere de una acción de su
parte. Sin embargo, las opciones del gerente son muchas veces limitadas y una
de las estrategias que puede seguir es esta de la agenda iterativa. Esto
permite corregir o ajustar los planes de trabajo a medida que se desvían de las
medidas iniciales.
Por ejemplo, si una iteración toma más tiempo del
programado debido a un problema técnico que el equipo del proyecto tardó en
responder o a la toma de una decisión por parte del usuario, el gerente puede
reprogramar las iteraciones subsiguientes de tal forma que el plan original
global del proyecto no se vea afectado.
En cualquier caso, todas las formas de gestión iterativa
proporcionan una manera de:
- Integrar y validar la evolución del producto continuamente
- Demostrar progreso en cortos períodos de tiempo
- Alertar pronto al equipo del proyecto de los problemas suscitados
- Entregar funcionalidad de manera temprana
- Incorporar sistemáticamente el re-trabajo inevitable que ocurre en el desarrollo de software
En resumen, la gestión Iterativa de proyectos facilita procedimientos
para el desarrollo exitoso de aplicaciones y minimizan tanto los riesgos como
los costos, combinando técnicas de administración bien estructuradas de métodos
en cascada con técnicas de validación temprana del modelo evolutivo. Este
proceso es más adaptable a situaciones diversas en proyectos de software y da al
gerente la flexibilidad necesaria para acomodarse a un rango dinámico de
alternativas técnicas.
Información
Este artículo fue publicado originalmente por la Revista de la Asociación Española de Profesionales en Dirección de Proyectos, en marzo de 2012. Para acceder al artículo original, pueden hacer clic aquí.
Para alcanzarla, para establecer una verdadera Cultura Ágil, debemos revisar las ideas que tenemos de los enfoques tradicionalistas e iniciar un camino que quizás sea o se vea poco confortable para muchos en la organización, puesto que ese camino hacia la cultura ágil expone las debilidades existentes no solo en la estructura sino en el comportamiento organizacional, es como si el ojo del Gran Hermano se posara sobre todos los miembros de la organización y les permitiera observarse a sí mismos, como en un espejo virtual, y al resto del entorno: clientes, proveedores, socios de negocio y mercado potencial, a observarlos desde el exterior.
