Hemos definido una iteración como un miniproyecto bastante completo, que pasa por todas las disciplinas principales y
resulta en la mayoría de casos en un sistema ejecutable, aunque incompleto: un release. Aunque el ciclo [editar,
compilar, probar, depurar] suena como una iteración, no es lo que queremos decir aquí. Las compilaciones diarias o
semanales que integran cada vez más, y prueban más y más elementos del sistema, también pueden parecer una iteración,
pero sólo es una porción de una iteración, tal como se utiliza aquí este término.
Una iteración empieza con la planificación y los requisitos, y acaba con un release, interno o externo.
La rapidez de la iteración depende principalmente del tamaño de la organización de desarrollo.
Por ejemplo:
-
Cinco personas pueden realizar la planificación el lunes por la mañana, comer juntos cada día para supervisar el
progreso, reasignar las tareas, empezar una compilación el jueves, y completar la iteración el viernes por la
tarde.
-
Pero esto será difícil de alcanzar con 20 personas. Se tardará más tiempo distribuyendo el trabajo, sincronizando
los subgrupos, integrando, etc. Una iteración puede tardar tres o cuatro semanas.
-
Con 40 personas, ya se tarda una semana para que el "influjo nervioso vaya del cerebro a las extremidades". Tiene
niveles intermediarios de gestión, la comprensión común del objetivo requerirá documentación más formal, más
ceremonia. Tres meses es una duración de iteración más razonable.
Otros factores entran en juego: el grado de familiaridad de la organización con el enfoque iterativo, incluyendo el
hecho de disponer de una organización estable y madura, el nivel de automatización que utiliza el equipo para gestionar
el código (por ejemplo, CM distribuida), distribuir información (por ejemplo, web interna), pruebas automatizadas, etc.
Tenga en cuenta que también hay unos ciertos gastos generales fijados en una iteración, en la planificación,
sincronización, análisis de los resultados, etc.
Así que, por un lado, convencido de las tremendas ventajas del enfoque repetitivo, puede que esté tentado de repetir
furiosamente, aunque los límites humanos de la organización ralentizarán su fervor.
Algunos datos empíricos:
SLOC
|
Número de desarrolladores
|
Duración de una iteración
|
10.000
|
5
|
1 semana
|
50.000
|
15
|
1 mes
|
500.000
|
45
|
6 meses
|
1.000.000
|
100
|
1 año
|
-
Iteraciones de más de 6 meses probablemente necesitan tener hitos intermedios incorporados para mantener el
proyecto al día. Considere reducir el ámbito de la iteración para reducir la longitud y garantizar un enfoque
claro.
-
Iteraciones de más de 12 meses crean su propio riesgo, ya que la iteración expande el ciclo económico anual.
Un proyecto que no ha producido nada visible en los últimos 12 meses corre el riesgo de perder sus fondos.
-
Iteraciones de menos de 1 mes deben tener un ámbito definido cuidadosamente. Habitualmente, las iteraciones
breves son más adecuadas para la fase de construcción, donde el grado de nueva funcionalidad que se debe incluir y
el grado de novedad son bajos. Las iteraciones breves pueden tener poco o no tener análisis formal, y pueden
simplemente mejorar incrementalmente una funcionalidad bien comprendida.
-
Todas las iteraciones no deben tener la misma longitud: su longitud variará de acuerdo con sus objetivos.
Habitualmente, las iteraciones de elaboración serán más largas que las iteraciones de construcción. Dentro de una
fase, las iteraciones tienen generalmente la misma longitud (simplifica la planificación).
Una vez que tenga una idea del número de iteraciones del plan sin detallar, deberá definir el contenido de cada
iteración. También es una buena idea encontrar un nombre o un título para calificar el producto que tiene al final de
cada iteración, para ayudar a obtener un enfoque más claro.
Ejemplo Iteraciones para una conmutación de teléfono privado
-
Iteración 1: llamada local.
-
Iteración 2: añadir llamadas externas y gestión del suscriptor.
-
Iteración 3: añadir correo por voz y teleconferencias.
Un proyecto muy simple puede tener sólo una iteración por fase:
-
Una iteración en la fase inicial, produce quizás un prototipo de prueba de concepto o una maqueta de la interfaz de
usuario o ninguna iteración, en los casos para el ejemplo de un ciclo de evolución.
-
Una iteración en la fase de elaboración para producir un prototipo arquitectónico.
-
Una iteración en la fase de construcción para compilar el producto (a un release "beta").
-
Una iteración en transición para finalizar el producto (release completo del producto).
Para un proyecto más sustancial, en el ciclo de desarrollo inicial la norma sería:
-
Una iteración en la fase inicial (posiblemente produciendo un prototipo).
-
Dos iteraciones en la fase de elaboración; una para un prototipo arquitectónico, y uno para la línea base de la
arquitectura.
-
Dos iteraciones en la fase de construcción para exponer un sistema parcial y madurarlo.
-
Una iteración en la fase de transición para ir de las capacidades operativas iniciales al release completo del
producto.
Para un proyecto grande, con muchos aspectos desconocidos, nuevas tecnologías, etc., se puede producir:
-
una iteración adicional en la fase inicial, para permitir la creación de más prototipos.
-
una iteración adicional en la fase de elaboración, para permitir la exploración de diferentes tecnologías.
-
una iteración adicional en la fase de construcción debido al tamaño total del producto.
-
una iteración adicional en la fase de transición, para permitir la información de retorno operativo.
Durante el ciclo de desarrollo, tenemos:
-
Baja: 3 iteraciones [0,1,1,1]
-
Típica: 6 [1, 2, 2, 1]
-
Alta: 9 [1, 3, 3, 2]
-
Muy alta: 10 [2, 3, 3, 2]
Así pues, en general, planee tener entre tres y diez iteraciones. Tenga en cuenta, sin embargo, que los límites
superior e inferior connotan circunstancias inusuales, así que la mayoría de desarrollos utilizarán entre seis y
ocho iteraciones.
Son posibles muchas variaciones dependiendo de los riesgos, el tamaño y la complejidad:
-
Si el producto está previsto para un dominio totalmente nuevo, puede ser necesario añadir algunas
iteraciones en la fase inicial para consolidar los conceptos, mostrar varias maquetas a una sección cruzada de
clientes o usuarios, o construir una respuesta sólida para solicitar una propuesta.
-
Si se debe desarrollar una nueva arquitectura, o hay una gran cantidad de modelado de caso de uso, o
aparecen riesgos apremiantes, debe planear tener dos o tres iteraciones en la fase de elaboración.
-
Si el producto es grande y complejo, y se desarrolla durante un largo periodo, debe planear tener tres o más
iteraciones en la fase de construcción.
-
Debe planear tener varias iteraciones en la fase de transición si, al tener que minimizar el tiempo de
comercialización, debe proporcionar el producto con un conjunto reducido de funcionalidades, o si considera que
necesitará más adaptaciones pequeñas para la base del usuario final tras un periodo de uso.
La secuencia de revisión por omisión para un proyecto de ciclo de vida en cascada tiene una revisión única principal de
productos de trabajo importantes, por ejemplo:
-
Revisión de requisitos del sistema (SRR), a la terminación de la especificación del sistema;
-
Revisión de especificación de software (SSR), a la terminación de la especificación de requisitos de
software;
-
revisión de diseño preliminar (PDR), a la terminación de las secciones de diseño arquitectónico de la
descripción de diseño de software;
-
Revisión de diseño importante (CDR), a la terminación de las secciones de diseño detalladas de la
descripción de diseño de software.
En Rational Unified Process, las partes de los productos de trabajo equivalentes se revisan a medida que se completan
en cada iteración, pero los hitos principales (y, por lo tanto, las revisiones) se alinean con la terminación de las
fases, el inicio, la elaboración, la construcción y la transición. Un gestor de proyectos que desee adoptar RUP tendrá
que encontrar un modo de reconciliar este conflicto aparente, debido a obligaciones contractuales. Idealmente, el
gestor de proyectos debe convencer al cliente de que el enfoque basado en fases e iteración en realidad proporciona una
visibilidad real superior en el progreso del proyecto, reduce riesgos, para que no exista necesidad de SRR, SSR, etc.
Sin embargo, esto no siempre es posible, y el gestor de proyectos debe planificar estas revisiones en los puntos
apropiados. Es posible, en RUP, ubicar los puntos en que estos productos de trabajo importantes (en realidad, sus
equivalentes en RUP) están prácticamente completados, aunque esto no siempre se alinea a la perfección con fases o
iteraciones.
Esto se realiza considerando que el esfuerzo relativo que se gastará en requisitos, diseño, y similares será
aproximadamente el mismo en RUP que en el ciclo de vida de cascada (ideal) - pero que el esfuerzo se distribuirá
diferentemente. El resultado es el siguiente:
Para eficacia, el gestor de proyectos, consultando con el cliente, debe intentar combinar estas tres revisiones con las
revisiones RUP prescritas. Esto es claramente posible para SRR y PDR, se pueden combinar con Objetivos del ciclo de vida Revisar y Arquitectura del ciclo de vida Revisar, respectivamente.
Al igual que el proceso de software recibe influencias de las características del proyecto, la organización del
proyecto también las recibe. La estructura por omisión presentada aquí (consulte la figura siguiente) tiene que
adaptarse para que refleje los efectos o factores como los que se listan:
-
El contexto empresarial
-
El tamaño de la tarea de desarrollo de software
-
El grado de novedad
-
Tipo de aplicación
-
El proceso de desarrollo actual
-
Factores organizativos
-
Complejidad técnica y de gestión
Estos son factores distintivos clave al analizar cómo, en conjunto, la organización debe adoptar un nuevo proceso de
desarrollo. Aquí examinaremos su efecto en la elección de la estructura del proyecto. La figura siguiente presenta una
organización de proyecto por omisión, mostrando como se asignan las responsabilidades a la estructura del equipo.
Figura que muestra la organización por omisión del proyecto. Tenga en cuenta que la antigüedad o la autoridad no son
significativas en la ordenación de los roles.
Esta figura es un punto de partida para considerar cómo se deben correlacionar los roles de nivel de proyecto y las
responsabilidades con una estructura de equipos. La figura también sirve para enfatizar qué roles (mostrados en los
recuadros amarillos) no son personas, sino "sombreros" que una persona (o equipo) se puede poner en el proyecto. Por
este motivo, varios roles (el gestor de proyectos, por ejemplo) aparecen más de una vez. Esto indica que, en algún
momento, el comportamiento del gestor de proyectos, tal como se define en RUP, puede aparecer en más de un equipo. Por
ejemplo, en un proyecto más grande, la tarea de preparar un informe de estado basado en una estructura detallada de
trabajo se puede delegar a una persona del equipo de administración. Sin embargo, esta es una responsabilidad
que RUP asigna al rol denominado gestor de proyectos.
En un proyecto pequeño, es probable que una persona nombrada gestor de proyectos efectúe todas las tareas del
rol denominado gestor de proyectos, en cuyo caso el equipo de administración se combina con el equipo de gestión
de software. La selección de la estructura del equipo estará influenciada por la naturaleza y el tamaño del proyecto,
pero debería matizarse con algunas normas de sentido común:
-
los equipos pequeños suelen ser más productivos; sin embargo, en grandes proyectos, esto debe equilibrarse contra
la cantidad de interacción cruzada dentro del equipo
-
Las jerarquías profundas deben evitarse
-
el intervalo del control de cualquier gestor o líder de equipo debe limitarse a siete más o menos dos
-
la estructura de equipo del desarrollo de software debe
dirigirla la arquitectura de software; una buena arquitectura, con cohesión elevada y bajo acoplamiento entre
subsistemas, permitirá que los equipos trabajen con más eficacia en paralelo
-
las pruebas, diferentes de las pruebas de unidad, debe efectuarlas de forma ideal un equipo aparte del equipo de
desarrollo. Tenga en cuenta, sin embargo, que esto no tendrá sentido económicamente en proyectos muy pequeños
-
la estructura debe permitir que todos los equipos y personas reciban autorizaciones y responsabilidades claramente
definidas. Esto es especialmente importante si la jerarquía supera tres niveles. Los gestores y líderes de equipo
en el medio de tales estructuras deben comprender qué se requiere de ellos para equilibrar las tareas técnicas y de
gestión.
-
la estructura debe dar soporte a las capacidades, experiencia y motivaciones del personal: por ejemplo, si un único
equipo debe efectuar el análisis, diseño e implementación, sin intermediarios, necesitarán todas las competencias
necesarias. Los analistas capacitados no son necesariamente buenos implementadores;
-
las estructuras del equipo no deben ser rígidas: las personas migrarán entre equipos durante el tiempo del vida del
proyecto y las responsabilidades de los equipos cambiarán a medida que el énfasis del proyecto cambie de fase a
fase.
Los fundamentos de la organización por omisión se discuten largamente en [ROY98].
Concretamente, la asignación de todas las responsabilidades de despliegue para el equipo de valoración de software
reconoce que, de todos los equipos del proyecto de desarrollo, el equipo de valoración de software está más expuesto al
software tal como lo verá el usuario.
Durante la vida de un proyecto, la organización evolucionará para proporcionar soporte a la estructura detallada de
trabajo en el plan del proyecto. Esto se muestra en la figura siguiente, que se toma de [ROY98].
Esta evolución enfatiza un conjunto diferente de tareas en cada fase:
-
el equipo inicial: una organización centrada en la planificación, con soporte suficiente de los otros equipos para
garantizar que los planes representan un consenso de todas las perspectivas;
-
el equipo de elaboración: una organización centrada en la arquitectura en que la orientación fuerza que el proyecto
resida en el equipo de arquitectura de software y reciben soporte de los equipos de desarrollo de software y de
valoración de software según sea necesario para alcanzar una línea base de arquitectura estable;
-
el equipo de construcción: una organización equilibrada en que la mayoría de tareas residen en los equipos de
desarrollo de software y de valoración de software;
-
el equipo de transición: una organización centrada en el cliente en que la información de retorno de utilización
orienta las tareas de despliegue.
La migración entre equipos durante esta evolución garantizará que el conocimiento y las capacidades se mantienen
durante el proyecto. Por ejemplo, cuando la elaboración se ha completado, algunos miembros del equipo de arquitectura
pueden dispersarse en los equipos de desarrollo, quizás para actuar como líderes de los equipos, o para desarrollar la
'visión' arquitectónica en el desarrollo. Más adelante, hacia el final de la fase de construcción, el enfoque cambia al
equipo de valoración, y se desplaza personal del equipo de desarrollo al equipo de valoración. También es importante en
este estadio, para evitar la pérdida de integridad arquitectónica en la base de la construcción, que la influencia del
equipo de arquitectura no decaiga cuando se mueva el "centro de gravedad" de proyecto. Mover algunos miembros del
equipo de arquitectura al equipo de valoración es un modo de hacerlo.
|