Directriz: Plan de iteración
Las iteraciones determinan la pauta del desarrollo de software moderno. Esta directriz propone estrategias para la planificación de las iteraciones.
Relaciones
Elementos relacionados
Descripción principal

Patrones de iteración

Iteraciones iniciales

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.

Iteraciones de elaboración

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.

Iteraciones de construcción y de transición

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.

Estrategias de iteración

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.

Amplia y superficial

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.

Delimitada y profunda

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.

Lecciones aprendidas de la experiencia

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.

Estrategias híbridas

  • 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.  

Consideraciones especiales para equipos nuevos

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.

Revisión prevista

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.

Nivel de planificación

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.