En la fase inicial, los riesgos más importantes son empresariales o técnicos. El principal riesgo empresarial en estas
primeras fases suele ser garantizar los fondos para el proyecto. Por ello, un prototipo de prueba de concepto suele ser
el resultado de una fase inicial. El prototipo de prueba de concepto sirve para demostrar sus funciones principales o
algún aspecto tecnológico esencial.
La primera iteración de un nuevo producto suele ser la más difícil. Hay muchos aspectos nuevos que debe conseguir una
primera iteración además de la producción de software: por ejemplo, ubicar el proyecto, crear el equipo, comprender un
nuevo dominio, familiarizarse con nuevas herramientas, etc. Es preferible ser prudente con las expectativas respecto a
qué proporción de la arquitectura se puede sustanciar, o el grado de funcionalidad utilizable que se puede alcanzar. Si
las expectativas son demasiado optimistas, se corre el riego de retrasar la finalización de la primera iteración, con
lo que se reduce el número total de iteraciones y de esa forma se reducirán las ventajas del enfoque iterativo. Las
primeras iteraciones deben centrarse en obtener una arquitectura sólida. Por ello, debe implicar a los arquitectos de
software en el proceso de planificación de las iteraciones iniciales.
En la elaboración, las iteraciones se centran en la definición de una arquitectura estable, en el diseño e
implementación del comportamiento esencial del sistema y en la exploración de cuestiones técnicas de la arquitectura
mediante una serie de prototipos arquitectónicos. Los casos de ejemplo que son "arquitectónicamente significativos" son
subflujos que ejercitan la arquitectura del sistema para la definición de las formas.
Hacia el final de la elaboración, y durante la construcción y la transición, las solicitudes de cambio (también
denominadas pedidos de cambio de software o SCO) empiezan a dirigir el proceso de iteración. Los SCO son el resultado
de lo siguiente:
-
solicitudes de mejora
-
solicitudes de cambio cuyo ámbito supera el paquete o la clase individual.
-
cambios en el ámbito y los objetivos de la iteración.
-
cambios en los requisitos que proponen cambios en su línea base o la incorporación de un cambio aceptado a la línea
base de los requisitos.
Estos SCO se equilibran contra el plan de proyecto existente, los planes de iteración y la lista de riesgos existente.
Los SCO pueden hacer que se vuelva a evaluar la prioridad de los requisitos, o puede dirigir los cambios en la
priorización de los riesgos. Sin embargo, los SCO deben gestionarse con cuidado, o se perderá el control sobre el
proyecto.
Durante la construcción y la transición, la atención se centra en la sustanciación de la arquitectura y la
implementación de todos los requisitos restantes.
A diferencia del modelo de cascada, en el que se considera la totalidad del sistema a la vez, sólo consideramos una
parte de las funciones del sistema en cada iteración. Durante cada iteración, se analiza, se diseña y se implementa un
subconjunto del sistema total. La elección de lo que debe ser el subconjunto y de la profundidad a la que ahondar es
fundamental para reducir el riesgo en iteraciones posteriores. Hay dos estrategias básicas: amplia/superficial y
delimitada/profunda.
En la estrategia amplia/superficial, se analiza todo el problema, pero sólo se consideran los detalles superficiales.
Se definen todos los guiones de uso y la mayoría se sustancian con mucho detalle, para llegar a comprender con claridad
el problema que nos ocupa. La arquitectura se define también en sentido amplio, y se definen los mecanismos y servicios
principales que ofrecen los componentes arquitectónicos; se definen las interfaces de los subsistemas, pero sus
detalles internos sólo se detallan cuando deben gestionarse incertidumbre o riesgos significativos. Se implementa muy
poco hasta la construcción, en la que se produce la mayoría de la iteración.
La estrategia amplia/superficial es adecuada cuando:
-
El equipo no tiene mucha experiencia, sea en el dominio del problema o en un área tecnológica (incluida la
metodología o el proceso).
-
Se establece como requisito fundamental una arquitectura sólida para las funciones futuras, pero esa arquitectura
no cuenta con precedentes.
Sin embargo, la estrategia tiene algunas dificultades potenciales:
-
El equipo puede verse atrapado por la parálisis de análisis (la sensación irracional de que, a menos que el
diseño sea perfecto, no se puede implementar nada).
-
Los resultados iniciales suelen ser necesarios para fomentar la confianza y la credibilidad; cuanto más lejos
llegue el equipo sin producir nada ejecutable, menos confianza tendrá sobre su capacidad de conseguirlo.
-
No se ha expuesto un número suficiente de detalles técnicos y de retos de la arquitectura para llegar a formarse
una imagen de los riesgos técnicos reales.
En la estrategia delimitada/profunda, una porción del dominio del problema se analiza en profundidad. Se definen
los guiones de uso relacionados con esta porción delimitada y se sustancian con mucho detalle, para llegar a comprender
con claridad el problema que nos ocupa. Se define la arquitectura que se necesita para dar soporte la comportamiento
deseado y el sistema se diseña y se implementa. Las iteraciones posteriores se centran en el análisis, diseño e
implementación de porciones verticales adicionales.
La estrategia delimitada/profunda es adecuada cuando:
-
Deben demostrarse resultados muy tempranos para superar un riesgo dominante, almacenar soporte o probar la
viabilidad.
-
Los requisitos están en continua evolución, lo que dificulta la definición completa de todos los requisitos antes
de empezar con el diseño detallado y el trabajo de implementación.
-
La fecha límite es obligatoria, hasta el punto que un inicio temprano del desarrollo en crucial de cara a
una entrega satisfactoria.
-
Un alto grado de reutilización es posible, lo que posibilitará un mayor grado de entrega incremental.
La estrategia tiene sus inconvenientes:
-
Esta estrategia tiene tendencia a que cada iteración desarrolle software que está integrado verticalmente pero es
incompatible horizontalmente. Este fenómeno se denomina a veces el síndrome de tobera (stovepipe), ya hace
que sea difícil entregar el sistema.
-
No es adecuado para sistemas que se desarrollen en un dominio de problemas completamente nuevos, o que se basan en
una arquitectura sin precedentes, ya que una buena parte de la funcionalidad de un sistema debe probarse para
alcanzar una arquitectura equilibrada.
Generalmente, las iteraciones iniciales tendrán más elementos de la estrategia amplia/superficial, mientras que las
iteraciones posteriores (en las que se ha desarrollado una arquitectura estable) tienden a seguir la estrategia
delimitada/profunda.
La primera iteración suele ser la más difícil, ya que precisa la totalidad del entorno de desarrollo y que la mayoría
del equipo de desarrollo esté en su sitio. Las cuestiones relacionadas con la integración de las herramientas y la
creación del equipo aumentan la complejidad de la primera iteración. Centrarse en las cuestiones arquitectónicas puede
ayudar a no perder la perspectiva y evitar que el equipo empiece a perder ritmo con los detalles demasiado pronto.
-
Estrategia delimitada/profunda utilizada en la fase inicial
Cuando la explotación de una nueva tecnología es esencial para la viabilidad fundamental del proyecto.
Muchos proyectos de e-business precisan la exploración de nuevas tecnologías con una profundidad mucho
mayor de lo que se puede hacer tradicionalmente. El prototipo de prueba de concepto se sigue considerando
de "deshecho" y se limita a explorar la viabilidad del concepto del proyecto.
-
Estrategia amplia/superficial utilizada en la fase inicial
Esta estrategia se sigue para llegar a comprender el ámbito del sistema y para probar la extensión de las
funciones del sistema para garantizar que la arquitectura es capaz de entregar las funciones deseadas.
-
Estrategia amplia/superficial utilizada en la elaboración
Este enfoque puede ser útil para el desarrollo de una arquitectura sólida, con una atención delimitada/profunda
selectiva para abordar riesgos técnicos específicos. En la construcción, con una arquitectura sólida
establecida, la atención puede volver a situarse en la estrategia delimitada/profunda, en la que las funciones
se desarrollan y se entregan en una serie de incrementos integrados.
-
Estrategia delimitada/profunda utilizada en la construcción
Las iteraciones de construcción son siempre del tipo delimitada/profunda, con los equipos trabajando en
paralelo para desarrollar y entregar las funciones necesarias.
Los equipos nuevos suelen ser demasiado optimistas al principio respecto a lo que pueden conseguir. Para equilibrar
esta sensación, y para evitar los problemas potenciales de ánimo que se producen cuando los resultados reales no
satisfacen esas expectativas optimistas, debe ser modesto en la cantidad de funcionalidad que puede lograrse en una
primera iteración. Intentar acumular experiencia a la vez que intenta conseguir la sensación de que el proyecto va por
buen camino y que el trabajo es satisfactorio.
Si el entorno de desarrollo o los métodos son nuevos para el equipo, reduzca la funcionalidad de la primera iteración
al mínimo. Centre la atención en integrar y ajustar el entorno y conseguir dominar las herramientas y, a continuación,
vaya aumentando el contenido de la funcionalidad en las sucesivas iteraciones.
La revisión es buena, pero hasta cierto punto. Una de las más claras ventajas de un desarrollo iterativo es
precisamente que permite los errores y la experimentación, pero lo bastante pronto como para puedan tomarse acciones
correctivas. Sin embargo, los técnicos en n particular tienden a 'rizar el rizo' y rehacen el trabajo intentando
alcanzar la perfección entre una iteración y la siguiente.
Al final de cada iteración, durante la evaluación de la iteración, el equipo debe decidir qué parte del release actual
debe revisarse. Espere que la revisión se asigne entre las fases en los porcentajes siguientes, en relación al sistema
total:
-
Principio, 40%-100%. En este punto se pueden desarrollar prototipos desechables, de exploración.
-
Elaboración, 25%-60% en las primeras iteraciones, menos del 25% en las iteraciones posteriores o para un ciclo de
evolución.
-
Construcción, después de la línea base de arquitectura, 10% o menos por iteración y 25% en total.
-
Transición, menos del 5%.
La revisión es inevitable. Si nadie aprecia la necesidad de una revisión, debe sospechar. Ello puede deberse a:
-
Una planificación con excesiva presión.
-
Falta de pruebas o valoraciones reales.
-
Falta de motivación o atención.
-
Percepción negativa de la revisión como algo malo, un desperdicio de recursos o la admisión de la incompetencia o
el error.
Un exceso de revisión debe ser causa de alarma. Puede deberse a que se 'riza el rizo' o a un nivel inaceptable de
cambios en los requisitos. Debe establecerse un caso de negocio que evalúe la necesidad de alguna revisión.
Tenga en cuenta que no se está incluyendo el trabajo que excedía el ámbito de la iteración anterior (a causa del
enfoque con un plazo fijo de tiempo a la gestión de iteraciones) en la categoría de 'revisión'. El gestor de proyectos
debe incluir este trabajo suplementario en el grupo de funcionalidades de los que deberá definir el contenido de la
siguiente iteración. Obviamente, este tipo de trabajo tendrá una prioridad alta. El gestor de proyectos también deberá
descubrir y considerar con atención las razones del error en la iteración anterior a la hora de alcanzar los objetivos
que había planificado. Por ejemplo, aunque no es recomendable añadir arbitrariamente personal en un intento desesperado
de cumplir la planificación, la ejecución de un proyecto crónicamente corto de personal, a la vez que se hacen
planes ambiciones para cada iteración, no es una práctica razonable. Suele conducir a mermar el ánimo del equipo y a
contrariar al cliente. Debe buscarse el equilibrio justo, y los modelos de estimación como COCOMO II (consulte [BOE00]) pueden ser de ayuda. Con cada iteración, un proyecto crea un historial de
logros de productividad y de calidad. Un buen indicador para el gestor de proyectos, a la hora de planificar la
iteración siguiente, es lo que se ha conseguido en la anterior.
Cuando se ha completado el primer plan de iteración, los responsables del equipo, tal vez junto con el gestor de
proyectos, pueden perfeccionarlo y hacerlo un plan de trabajo para el nivel de tareas. Las plantillas de Microsoft®
Project (para el nivel de tarea) muestran la apariencia que puede tener esto. Sin embargo, tenga en cuenta que estos
planes de trabajo se derivan del plan de iteración, no son productos de trabajo independientes producidos
separadamente. Es importante, si el gestor de proyectos desea mantener el control, que los planes de trabajo se puedan
recopilar para indicar el estado del plan de iteración del gestor de proyectos.
|