El ciclo de vida adaptativo

El modelo adaptativo está construido desde un punto de vista diferente. Aunque cíclico
como el modelo evolutivo, los nombres de la fase reflejan la naturaleza impredecible de
sistemas cada vez más complejos.

El desarrollo adaptativo va más allá de su herencia evolutiva en dos formas clave:

 Reemplaza explícitamente el determinismo con la emergencia.

 Va más allá de un cambio en el ciclo de vida a un cambio más profundo en el estilo
de gestión.

Las tres fases en el ciclo de vida de desarrollo de software adaptativo son:

 Speculate : Speculate reemplaza la planificación de palabras determinista, la

planificación de especificaciones de productos o la planificación de tareas de
gestión de proyectos.
 Colaborar : colaborar representa un equilibrio entre
o Gestión en el sentido tradicional de gestión de proyectos, y
o Crear y mantener el entorno colaborativo necesario para la emergencia.

Las actividades de colaboración crean productos, manteniendo el ritmo de los

cambios en el medio ambiente.
  Learn : Learn tiene como objetivo, tanto a los desarrolladores como a los clientes,
utilizar los resultados de cada ciclo de desarrollo para aprender la dirección del
siguiente.

Desarrollo de software adaptativo - Ciclo

de vida
El desarrollo de software adaptativo ha evolucionado a partir de las prácticas de RAD. Los
aspectos del equipo también se agregaron a estas prácticas. Las empresas de Nueva Zelanda
a Canadá, para una amplia gama de proyectos y tipos de productos, han utilizado el
desarrollo de software adaptativo.

Jim Highsmith publicó Adaptive Software Development en 2000.

Las prácticas de desarrollo de software adaptativo brindan la capacidad de adaptarse al

cambio y son adaptables en entornos turbulentos con productos que evolucionan con poca
planificación y aprendizaje.

Fases del ciclo de vida de ASD

El desarrollo de software adaptativo es cíclico como el modelo evolutivo, con los nombres
de fase que reflejan la imprevisibilidad en los sistemas complejos. Las fases en el ciclo de
vida del desarrollo adaptativo son:

 Especular
 Colaborar
 Aprender

Estas tres fases reflejan la naturaleza dinámica del desarrollo de software adaptativo. El
desarrollo adaptativo reemplaza explícitamente el determinismo con la emergencia. Va más
allá de un simple cambio en el ciclo de vida a un cambio más profundo en el estilo de
gestión. El desarrollo de software adaptativo tiene un ciclo de vida dinámico Speculate-
Collaborate-Learn.

El ciclo de vida de desarrollo de software adaptativo se centra en los resultados, no en las

tareas, y los resultados se identifican como características de la aplicación.
Especular

El término plan es demasiado determinista e indica un grado razonablemente alto de certeza

sobre el resultado deseado. El objetivo implícito y explícito de conformidad con el plan
restringe la capacidad del gerente para dirigir el proyecto en direcciones innovadoras.

En Desarrollo de software adaptativo, el término plan se reemplaza por el término

especular. Mientras especula, el equipo no abandona la planificación, pero reconoce la
realidad de la incertidumbre en problemas complejos. Especulate fomenta la exploración y
la experimentación. Se recomiendan iteraciones con ciclos cortos.

Colaborar

Las aplicaciones complejas no se crean, evolucionan. Las aplicaciones complejas requieren

que se recopile, analice y aplique un gran volumen de información al problema. Los
entornos turbulentos tienen altas tasas de flujo de información. Por lo tanto, las aplicaciones
complejas requieren que se recopile, analice y aplique un gran volumen de información al
problema. Esto da como resultado diversos requisitos de conocimiento que solo pueden
manejarse mediante la colaboración del equipo.

Colaborar requeriría la capacidad de trabajar conjuntamente para producir resultados,

compartir conocimientos o tomar decisiones.
En el contexto de la gestión de proyectos, la colaboración representa un equilibrio entre la
gestión con técnicas de gestión tradicionales y la creación y mantenimiento del entorno de
colaboración necesario para la emergencia.

Aprender

La parte de Aprendizaje del ciclo de vida es vital para el éxito del proyecto. El equipo tiene
que mejorar sus conocimientos constantemente, utilizando prácticas como:

 Revisiones técnicas
 Retrospectivas del proyecto
 Grupos de enfoque del cliente

Las revisiones deben hacerse después de cada iteración. Tanto los desarrolladores como los
clientes examinan sus suposiciones y usan los resultados de cada ciclo de desarrollo para
conocer la dirección del siguiente. El equipo aprende

 Sobre cambios de producto

 Cambios más fundamentales en los supuestos subyacentes sobre cómo se están
desarrollando los productos.

Las iteraciones deben ser cortas, para que el equipo pueda aprender de los errores pequeños
en lugar de los grandes.

Especular - Colaborar - Aprender el ciclo en su conjunto

Como se observa en el ciclo Speculate-Collaborate-Learn, dado anteriormente, es obvio

que las tres fases son no lineales y se superponen.

Observamos lo siguiente desde un marco adaptativo.

 Es difícil colaborar sin aprender o aprender sin colaborar.

 Es difícil especular sin aprender o aprender sin especular.
 Es difícil especular sin colaborar o colaborar sin especular.

Características del ciclo de vida

Adaptive Software Development Lifecycle tiene seis características básicas:

 Misión enfocada
 Basado en funciones
 Iterativo
 Caja de tiempo
 Impulsado por el riesgo
 Cambio tolerante
En este capítulo, comprenderá estas seis características del desarrollo de software
adaptativo.

Enfocado en la misión
Para muchos proyectos, la misión general que guía al equipo está bien articulada, aunque
los requisitos pueden ser inciertos al comienzo del proyecto. Las declaraciones de misión
actúan como guías que fomentan la exploración al principio pero tienen un enfoque
limitado en el transcurso de un proyecto. Una misión proporciona límites en lugar de un
destino fijo. Las declaraciones de misión y las discusiones que dan como resultado esas
declaraciones proporcionan dirección y criterios para tomar decisiones críticas de
intercambio de proyectos.

Sin una misión clara y una práctica constante de refinamiento de la misión, los ciclos de
vida iterativos se convierten en ciclos de vida oscilantes, oscilando de un lado a otro sin
progreso en el desarrollo.

Basado en funciones
Adaptive Software Development Lifecycle se basa en las características de la aplicación y
no en las tareas. Las características son la funcionalidad que se desarrolla durante una
iteración basada en las prioridades del cliente.

Las características pueden evolucionar a lo largo de varias iteraciones cuando los clientes
brindan comentarios.

Las características de la aplicación que proporcionan resultados directos al cliente después

de la implementación son primarias. Un documento orientado al cliente, como un manual
del usuario, también se considera una característica. Los otros documentos, como el modelo
de datos, incluso si se definen como entregables son siempre secundarios.

Iterativo
El ciclo de vida de desarrollo de software adaptativo es iterativo y se enfoca en
lanzamientos frecuentes para obtener comentarios, asimilar el aprendizaje resultante y
establecer la dirección correcta para un mayor desarrollo.

Caja de tiempo
En Adaptive Software Development Lifecycle, las iteraciones tienen una caja de tiempo.
Sin embargo, uno debe recordar que el boxeo de tiempo en Adaptive Software
Development no se trata de plazos de tiempo. No debe usarse para hacer que el equipo
trabaje durante largas horas desafiando un entorno de colaboración o comprometiendo la
calidad de los entregables.
En el desarrollo de software adaptativo, el time-boxing se considera como una dirección
para enfocar y forzar decisiones difíciles de compensación cuando sea necesario. En un
entorno incierto, en el que las tasas de cambio son altas, debe haber una función de
forzamiento periódica, como un timebox para finalizar el trabajo.

Impulsado por el riesgo

En el desarrollo de software adaptativo, las iteraciones se controlan identificando y
evaluando los riesgos críticos.

Tolerante al cambio
El desarrollo de software adaptativo es tolerante al cambio, y ve el cambio como la
capacidad de incorporar una ventaja competitiva, pero no como un problema para el
desarrollo.

Desarrollo de software adaptativo:

prácticas
Las prácticas de desarrollo de software adaptativo se basan en la creencia en la adaptación
continua, con el ciclo de vida equipado para aceptar el cambio continuo como la norma.

Adaptive Software Development Lifecycle se dedica a:

 Aprendizaje continuo
 Cambiar orientación
 Reevaluación
 Mirando hacia un futuro incierto
 Intensa colaboración entre desarrolladores, gerentes y clientes.

SDLC adaptativo
El desarrollo de software adaptativo combina RAD con las mejores prácticas de ingeniería
de software, tales como:

 Iniciación del proyecto.

 Planificación del ciclo adaptativo.
 Ingeniería concurrente de componentes.
 Revisión de calidad.
 Control de calidad final y lanzamiento.

Las prácticas de desarrollo de software adaptativo se pueden ilustrar de la siguiente manera:

Como se ilustra arriba, las prácticas de desarrollo de software adaptativo se extienden a
través de las tres fases de la siguiente manera:

 Especular - Iniciación y planificación

o Iniciacion de proyecto
o Establecer cronograma para todo el proyecto
o Decida el número de iteraciones y asigne un cuadro de tiempo a cada una.
o Desarrolle un tema u objetivo para cada una de las iteraciones.
o Asigna funciones a cada iteración
 Colaborar : desarrollo de funciones concurrentes
o Colaboración para equipos distribuidos.
o Colaboración para proyectos más pequeños.
o Colaboración para proyectos más grandes.
 Aprender - Revisión de calidad
o Calidad de resultados desde la perspectiva del cliente.
o Calidad de resultados desde una perspectiva técnica
o El funcionamiento del equipo de entrega y los miembros del equipo de
prácticas están utilizando
o El estado del proyecto.

Especular - Iniciación y planificación

En el desarrollo de software adaptativo, la fase especulativa tiene dos actividades:

 Iniciación
 Planificación

Speculate tiene cinco prácticas que pueden ejecutarse repetidamente durante la fase de
iniciación y planificación. Ellos son
  Iniciacion del proyecto
 Establecer cronograma para todo el proyecto
 Decida el número de iteraciones y asigne un cuadro de tiempo a cada una.
 Desarrolle un tema u objetivo para cada una de las iteraciones.
 Asigna funciones a cada iteración

Iniciacion de proyecto

La iniciación del proyecto implica:

 Establecer la misión y los objetivos del proyecto.

 Comprender las restricciones
 Establecimiento de la organización del proyecto.
 Identificación y descripción de los requisitos.
 Hacer estimaciones iniciales de tamaño y alcance
 Identificar los riesgos clave del proyecto.

Los datos de inicio del proyecto deben recopilarse en una sesión preliminar de JAD,
considerando la velocidad como el aspecto principal. La iniciación se puede completar en
un esfuerzo concentrado de dos a cinco días para proyectos pequeños a medianos, o en un
esfuerzo de dos a tres semanas para proyectos más grandes.

Durante las sesiones de JAD, los requisitos se recopilan con suficiente detalle para
identificar características y establecer una visión general del objeto, los datos u otro modelo
arquitectónico.

Establecer un cuadro de tiempo para todo el proyecto

El plazo para todo el proyecto debe establecerse, en función del alcance, los requisitos del
conjunto de características, las estimaciones y la disponibilidad de recursos que resultan del
trabajo de inicio del proyecto.

Como saben, especular no abandona la estimación, pero solo significa aceptar que las
estimaciones pueden salir mal.

Iterations y Time-box

Decida el número de iteraciones y las longitudes de iteración individuales en función del

alcance general del proyecto y el grado de incertidumbre.

Para una aplicación pequeña a mediana -

 Las iteraciones generalmente varían de cuatro a ocho semanas.

 Algunos proyectos funcionan mejor con iteraciones de dos semanas.
 Algunos proyectos pueden requerir más de ocho semanas.
Elija el tiempo, según lo que funcione para usted. Una vez que decida el número de
iteraciones y la duración de cada una de ellas, asigne un cronograma a cada una de las
iteraciones.

Desarrollar un tema u objetivo

Los miembros del equipo deben desarrollar un tema u objetivo para cada iteración. Esto es
algo similar al Objetivo Sprint en Scrum. Cada iteración debe ofrecer un conjunto de
características que puedan demostrar la funcionalidad del producto haciendo que el
producto sea visible para el cliente para permitir su revisión y comentarios.

Dentro de las iteraciones, las compilaciones deben ofrecer características de trabajo de

forma preferentemente diaria que permitan el proceso de integración y hagan que el
producto sea visible para el equipo de desarrollo. Las pruebas deberían ser una parte
continua e integral del desarrollo de características. No debe retrasarse hasta el final del
proyecto.

Asignar características

Los desarrolladores y los clientes deben asignar juntos características a cada iteración. El
criterio más importante para esta asignación de características es que cada iteración debe
entregar un conjunto visible de características con una funcionalidad considerable para el
cliente.

Durante la asignación de características a las iteraciones:

 El equipo de desarrollo debe presentar las estimaciones de características, los

riesgos y las dependencias y proporcionarlos al cliente.
 Los clientes deben decidir sobre la priorización de características, utilizando la
información proporcionada por el equipo de desarrollo.

Por lo tanto, la planificación de iteraciones se basa en características y se realiza en equipo

con desarrolladores y clientes. La experiencia ha demostrado que este tipo de planificación
proporciona una mejor comprensión del proyecto que una planificación basada en tareas
por parte del gerente del proyecto. Además, la planificación basada en características refleja
la singularidad de cada proyecto.

Colaborar ─ Desarrollo de funciones concurrentes

Durante la fase de colaboración, el foco está en el desarrollo. La fase de colaboración tiene
dos actividades:

 El equipo de desarrollo colabora y entrega software de trabajo.

 Los gerentes de proyecto facilitan la colaboración y las actividades de desarrollo
concurrentes.
La colaboración es un acto de creación compartida que abarca el equipo de desarrollo, los
clientes y los gerentes. La creación compartida es fomentada por la confianza y el respeto.

Los equipos deberían colaborar en -

 Problemas técnicos
 Requisitos comerciales
 Toma de decisiones rápida

Las siguientes son las prácticas relevantes para la fase de colaboración en el desarrollo de
software adaptativo:

 Colaboración para equipos distribuidos.

 Colaboración para proyectos más pequeños.
 Colaboración para proyectos más grandes.

Colaboración para equipos distribuidos

En los proyectos que involucran equipos distribuidos, se debe considerar lo siguiente:

 Diversos socios de la alianza

 Conocimiento de base amplia
 La forma en que las personas interactúan
 La forma en que manejan las interdependencias

Colaboración para proyectos pequeños

En los proyectos más pequeños, cuando los miembros del equipo están trabajando en
proximidad física, se debe alentar la colaboración con los chats informales en los pasillos y
los garabatos de la pizarra, ya que esto se considera efectivo.

Colaboración para proyectos más grandes

Los proyectos más grandes requieren prácticas adicionales, herramientas de colaboración e

interacción del gerente de proyecto y deben organizarse de forma contextual.

Aprender - Revisión de calidad

El desarrollo de software adaptativo fomenta el concepto de "Experimentar y aprender".

Aprender de los errores y la experimentación requiere que los miembros del equipo
compartan el código y los artefactos parcialmente completados temprano, a fin de:

 Encuentra errores
 Aprende de ellos
  Reduzca el retrabajo encontrando pequeños problemas antes de que se conviertan en
grandes.

Al final de cada iteración de desarrollo, hay cuatro categorías generales de cosas que
aprender:

 Calidad de resultados desde la perspectiva del cliente.

 Calidad de resultados desde una perspectiva técnica
 El funcionamiento del equipo de entrega y el equipo de prácticas.
 El estado del proyecto.

Calidad del resultado desde la perspectiva del cliente

En los proyectos de desarrollo de software adaptativo, obtener comentarios de los clientes

es la primera prioridad. La práctica recomendada para esto es un grupo de enfoque al
cliente. Estas sesiones están diseñadas para explorar un modelo de trabajo de la aplicación
y registrar las solicitudes de cambio de los clientes.

Las sesiones de grupos focales para clientes son sesiones facilitadas, similares a las
sesiones jad, pero en lugar de generar requisitos o definir planes de proyecto, están
diseñados para revisar la aplicación en sí. Los clientes brindan comentarios sobre el
software que funciona como resultado de una iteración.

Calidad del resultado desde una perspectiva técnica

En los proyectos de desarrollo de software adaptativo, se debe dar importancia a la revisión

periódica de los artefactos técnicos. Las revisiones de código deben hacerse de forma
continua. Las revisiones de otros artefactos técnicos, como la arquitectura técnica, se
pueden realizar semanalmente o al final de una iteración.

En los proyectos de desarrollo de software adaptativo, el equipo debe monitorear su propio

rendimiento periódicamente. Las retrospectivas alientan a los equipos a aprender sobre sí
mismos y su trabajo, juntos como un equipo.

Las retrospectivas de finalización de iteración facilitan la autoevaluación periódica del

rendimiento del equipo, como:

 Determina lo que no funciona.

 Lo que el equipo necesita hacer más.
 Lo que el equipo necesita hacer menos.

El estado del proyecto

La revisión del estado del proyecto ayuda a planificar más trabajo. En los proyectos de
desarrollo de software adaptativo, determinar el estado del proyecto es un enfoque basado
en características, el final de cada iteración marcado por características completadas que
dan como resultado un software que funciona.

La revisión del estado del proyecto debe incluir:

 Donde esta el proyecto

 ¿Dónde está el proyecto versus los planes?
 ¿Dónde debe estar el proyecto?

Como los planes en los proyectos de desarrollo de software adaptativo son especulativos,
más que la pregunta 2 anterior, la pregunta 3 es importante. Es decir, el equipo del proyecto
y los clientes deben preguntarse continuamente: "¿Qué hemos aprendido hasta ahora y
cambia nuestra perspectiva de hacia dónde debemos ir?"

Revisiones técnicas (TR):

Los TR están limitados en alcance y tiempo. Generalmente se centran en el componente

entregable que se ha identificado como parte del plan adoptado.

TR ha definido roles distintos:

1. Facilitador (líder): establece la Agenda, dirige la reunión de revisión y tiene

poderes para evitar que la reunión se desvíe o se desanime de su camino.
2. Productor - Desarrollando el producto de trabajo bajo revisión
3. Registrador : persona que toma notas escritas de los problemas planteados
4. Revisores : se toman el tiempo para examinar el producto de trabajo y dar
retroalimentación oportuna al productor. Su intención es encontrar errores o
misiones inconsistentes del producto de trabajo que están examinando.