Desarrollo adaptativo S / W - Guía rápida

Desarrollo adaptativo S / W - Introducción

¿Qué es ágil?

En términos literarios, la palabra "ágil" significa alguien que puede moverse rápida y fácilmente o alguien que puede pensar y actuar rápida y claramente. En los negocios, "ágil" se utiliza para describir formas de planificar y realizar trabajos en los que se entiende que realizar los cambios necesarios es una parte importante del trabajo. La "agilidad" empresarial significa que una empresa siempre está en condiciones de tener en cuenta los cambios del mercado.

En el desarrollo de software, el término "ágil" se adapta para significar "la capacidad de responder a los cambios: cambios de requisitos, tecnología y personas".

Manifiesto Ágil

El Manifiesto Ágil fue publicado por un equipo de desarrolladores de software en 2001, destacando la importancia del equipo de desarrollo, teniendo en cuenta los requisitos cambiantes y la participación del cliente.

El Manifiesto Ágil es:

Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo, hemos llegado a valorar:

  • Individuos e interacciones sobre procesos y herramientas.
  • Software de trabajo sobre documentación completa.
  • Colaboración del cliente sobre la negociación del contrato.
  • Responde al cambio sobre el siguiente plan.

Es decir, si bien hay valor en los elementos de la derecha, valoramos más los elementos de la izquierda.

Características de la agilidad.

Las siguientes son las características de la agilidad:

  • La agilidad en el desarrollo de software ágil se centra en la cultura de todo el equipo con equipos multidisciplinarios e interfuncionales que están capacitados y se autoorganizan.

  • Fomenta la responsabilidad compartida y la rendición de cuentas.

  • Facilita la comunicación efectiva y la colaboración continua.

  • El enfoque de todo el equipo evita demoras y tiempos de espera.

  • Las entregas frecuentes y continuas garantizan comentarios rápidos que a su vez permiten que el equipo se alinee con los requisitos.

  • La colaboración facilita la combinación oportuna de diferentes perspectivas en la implementación, la corrección de defectos y la modificación de cambios.

  • El progreso es constante, sostenible y predecible enfatizando la transparencia.

Metodologías ágiles

Las primeras implementaciones de métodos ágiles incluyen Rational Unified Process, Scrum, Crystal Clear, Extreme Programming, Adaptive Software Development, Feature Driven Development y Dynamic Systems Development Method (DSDM). Ahora se conocen colectivamente como las metodologías ágiles, después de que se publicara el manifiesto ágil en 2001.

En este tutorial, aprenderemos la metodología ágil: desarrollo de software adaptativo .

¿Qué es el desarrollo de software adaptativo?

El desarrollo de software adaptativo es un movimiento hacia prácticas adaptativas, dejando las prácticas deterministas en el contexto de sistemas complejos y entornos complejos. El desarrollo de software adaptativo se centra en la colaboración y el aprendizaje como una técnica para construir sistemas complejos. Se desarrolló a partir de las mejores prácticas de desarrollo rápido de aplicaciones (RAD) y ciclos de vida evolutivos. El desarrollo de software adaptativo se extendió para incluir enfoques adaptativos para la gestión, con la especulación reemplazando la planificación.

Ciclo de vida de ASD

Jim Highsmith publicó un libro sobre Desarrollo de software adaptativo en 2000. En palabras de Highsmith:

“El desarrollo de software adaptativo es cíclico como el modelo evolutivo, con los nombres de fase Especular, colaborar, aprender reflejando el ámbito impredecible de sistemas cada vez más complejos. El desarrollo adaptativo va más allá de su herencia evolutiva en dos formas clave. Primero, reemplaza explícitamente el determinismo con la emergencia. En segundo lugar, va más allá de un cambio en el ciclo de vida a un cambio más profundo en el estilo de gestión ".

Modelos SDLC - Evolución

Un modelo de Ciclo de vida de desarrollo de software (SDLC) es un marco que describe las actividades realizadas en cada etapa de un proyecto de desarrollo de software.

En un ciclo de vida de desarrollo de software, las actividades se realizan en cinco fases:

  • Recopilación de requisitos: se recopilan los requisitos para desarrollar un software. Estos requisitos estarán en un idioma que el cliente / usuario entienda. Se recomienda la terminología específica del dominio.

  • Análisis : los requisitos reunidos se analizan desde el punto de vista de la implementación y las especificaciones del software se escriben para cubrir tanto los requisitos funcionales como los requisitos no funcionales.

  • Diseño : esta fase implica llegar a la arquitectura del software y los detalles de implementación basados en la tecnología elegida para el desarrollo.

  • Construcción : en esta fase, se desarrolla el código, se prueba la unidad, se integra, se prueba la integración y se produce la construcción.

  • Pruebas : las pruebas funcionales del software creado se realizan en esta fase. Esto también incluye la prueba de requisitos no funcionales.

Hay dos enfoques para realizar estas actividades:

  • Prescriptivo : los modelos SDLC que le proporcionarán formas de realizar las actividades de una manera prescrita según lo definido por el marco.

  • Adaptativo : los modelos SDLC que le brindarán flexibilidad para realizar las actividades, con ciertas reglas que deben seguirse. Los métodos ágiles en su mayoría siguen este enfoque, y cada uno tiene sus reglas. Sin embargo, seguir un enfoque adaptativo o ágil no significa que el software se desarrolle sin seguir ninguna disciplina. Esto llevaría a un caos.

Debe comprender que no podemos decir que un modelo SDLC específico sea bueno o malo. Cada uno de ellos tiene sus propias fortalezas y debilidades y, por lo tanto, son adecuados en ciertos contextos.

Cuando elige un modelo SDLC para su proyecto, debe comprender:

  • El contexto de su organización
  • Tu contexto tecnológico
  • La composición de tu equipo
  • Su contexto de cliente

Por ejemplo, si el desarrollo del software es predecible, puede utilizar un enfoque prescriptivo. Por otro lado, si el desarrollo del software es impredecible, es decir, los requisitos no se conocen por completo, o el equipo de desarrollo no tiene una exposición previa al dominio o la tecnología actual, etc., entonces el enfoque adaptativo es la mejor opción.

En las siguientes secciones, comprenderá los modelos SDLC más frecuentes que se desarrollan durante la ejecución de proyectos de desarrollo de software en toda la industria. También conocerá las fortalezas y debilidades de cada uno de ellos y en qué contextos son adecuados.

SDLC - Modelo de cascada

El modelo Waterfall es un modelo SDLC clásico que es ampliamente conocido, comprendido y utilizado comúnmente. Fue presentado por Royce en 1970 y todavía se sigue como un enfoque común para el desarrollo de software en varias organizaciones de la industria.

En el modelo Waterfall, cada fase del ciclo de vida puede comenzar solo después de que se complete la fase del ciclo de vida anterior. Por lo tanto, es un modelo lineal sin bucles de retroalimentación.

Ciclo de vida de la cascada

Modelo de cascada - Fortalezas

Los puntos fuertes del modelo Cascada son:

  • Fácil de entender, fácil de usar.
  • Proporciona estructura al equipo de desarrollo sin experiencia.
  • Los hitos son bien entendidos.
  • Establece requisitos de estabilidad.
  • Ideal para el control de gestión (planificación, seguimiento, informes).
  • Funciona bien cuando la calidad es más importante que el costo o el cronograma.

Modelo de cascada - Debilidades

Las debilidades o las desventajas del modelo Waterfall son:

  • Idealizado: no coincide bien con la realidad.

  • Poco realista: no se pueden esperar requisitos precisos al principio del proyecto.

  • No refleja la naturaleza iterativa del desarrollo exploratorio que es más común.

  • Difícil y costoso hacer cambios.

  • El software se entrega solo al final del proyecto. Debido a esto

    • Retrasa el descubrimiento de defectos graves.

    • Posibilidad de entrega de requisitos obsoletos.

  • Gastos generales de gestión significativos, que pueden ser costosos para pequeños equipos y proyectos.

  • Requiere recursos experimentados en cada fase: analistas, diseñadores, desarrolladores, probadores.

  • Las pruebas comienzan solo después de que se completa el desarrollo y los evaluadores no participan en ninguna de las fases anteriores.

  • La experiencia de los equipos multifuncionales no se comparte ya que cada fase se ejecuta en silos.

¿Cuándo usar el modelo de cascada?

Puede usar el modelo Cascada si:

  • Los requisitos son muy conocidos.

  • La definición del producto es estable.

  • La tecnología se entiende bien.

  • Nueva versión de un producto existente.

  • Portar un producto existente a una nueva plataforma.

  • Gran organización con equipos estructurados y multifuncionales.

  • Los canales de comunicación están bien establecidos dentro de la organización y también con el cliente.

Modelo evolutivo de prototipos

En el desarrollo de software usando el modelo de Prototipos Evolutivos, los desarrolladores construyen un prototipo durante la fase de requisitos. Los usuarios finales luego evalúan el prototipo y dan su opinión. La retroalimentación puede ser correcciones al prototipo o funcionalidad adicional. Según los comentarios, los desarrolladores refinan aún más el prototipo.

Por lo tanto, el producto evoluciona a través del Prototipo → Comentarios → Ciclos de prototipos refinados y de ahí el nombre Prototipos evolutivos. Cuando el usuario está satisfecho con la funcionalidad y el funcionamiento del producto, el código prototipo se ajusta a los estándares requeridos para la entrega del producto final.

Entrega de producto final

Modelo evolutivo de prototipos - Fortalezas

Los puntos fuertes o las ventajas de un modelo de prototipos evolutivos son:

  • Los clientes / usuarios finales pueden visualizar los requisitos del sistema a medida que se reúnen mirando el prototipo.

  • Los desarrolladores aprenden de los clientes y, por lo tanto, no tienen ambigüedades con respecto al dominio o entorno de producción.

  • Permite un diseño y desarrollo flexible.

  • La interacción con el prototipo estimula la conciencia de la funcionalidad adicional necesaria.

  • Los requisitos inesperados y los cambios de requisitos se acomodan fácilmente.

  • Se producen signos constantes y visibles de progreso.

  • Entrega de un producto final preciso y fácil de mantener.

Modelo de prototipos evolutivos: debilidades

Las debilidades o desventajas del modelo de prototipos evolutivos son las siguientes:

  • Tendencia a abandonar el desarrollo estructurado en el desarrollo de código y arreglo, aunque no es lo que prescribe el modelo.

  • Este modelo recibió mala reputación por los métodos rápidos y sucios.

  • Posiblemente se pueda pasar por alto la mantenibilidad general.

  • El cliente posiblemente puede solicitar la entrega del prototipo como final, sin dar la oportunidad a los desarrolladores de ejecutar el paso final, es decir, la estandarización del producto final.

  • El proyecto puede continuar para siempre (con un avance continuo del alcance) y la administración puede no apreciarlo.

¿Cuándo utilizar el modelo de prototipos evolutivos?

Puede usar el modelo de prototipos evolutivos:

  • Cuando los requisitos son inestables o deben aclararse
  • Como la etapa de clarificación de requisitos de un modelo en cascada
  • Desarrollar interfaces de usuario.
  • Para demostraciones de corta duración
  • Para desarrollo nuevo u original
  • Para implementar una nueva tecnología

SDLC - Modelo incremental iterativo

En un modelo incremental iterativo, inicialmente, se construye una implementación parcial de un sistema total para que esté en un estado entregable. Se agrega mayor funcionalidad. Los defectos, si los hay, de la entrega anterior se corrigen y se entrega el producto en funcionamiento. El proceso se repite hasta que se completa todo el desarrollo del producto. Las repeticiones de estos procesos se llaman iteraciones. Al final de cada iteración, se entrega un incremento de producto.

Iteraciones

Modelo incremental iterativo - Fortalezas

Las ventajas o fortalezas del modelo incremental iterativo son:

  • Puede desarrollar requisitos priorizados primero.

  • La entrega inicial del producto es más rápida.

  • Los clientes obtienen funcionalidad importante temprano.

  • Reduce el costo de entrega inicial.

  • Cada lanzamiento es un incremento del producto, de modo que el cliente tendrá un producto que funcione a la mano todo el tiempo.

  • El cliente puede proporcionar comentarios a cada incremento de producto, evitando así sorpresas al final del desarrollo.

  • Los cambios de requisitos se pueden acomodar fácilmente.

Modelo incremental iterativo: debilidades

Las desventajas del modelo incremental iterativo son:

  • Requiere una planificación efectiva de las iteraciones.

  • Requiere un diseño eficiente para garantizar la inclusión de la funcionalidad requerida y la provisión para cambios posteriores.

  • Requiere la definición temprana de un sistema completo y completamente funcional para permitir la definición de incrementos.

  • Se requieren interfaces de módulo bien definidas, ya que algunas se desarrollan mucho antes que otras.

  • El costo total del sistema completo no es menor.

¿Cuándo utilizar el modelo incremental iterativo?

El modelo incremental iterativo se puede usar cuando:

  • La mayoría de los requisitos se conocen por adelantado, pero se espera que evolucionen con el tiempo.

  • Los requisitos tienen prioridad.

  • Es necesario que la funcionalidad básica se entregue rápidamente.

  • Un proyecto tiene largos cronogramas de desarrollo.

  • Un proyecto tiene nueva tecnología.

  • El dominio es nuevo para el equipo.

SDLC - Modelo de desarrollo rápido de aplicaciones

El modelo de desarrollo rápido de aplicaciones (RAD) tiene las siguientes fases:

  • Fase de planificación de requisitos : en la fase de planificación de requisitos, se debe realizar un taller de trabajo para analizar los problemas comerciales de manera estructurada.

  • Fase de descripción del usuario : en la fase de descripción del usuario, se utilizan herramientas automatizadas para capturar información de los usuarios.

  • Fase de construcción : en la fase de construcción, las herramientas de productividad, como los generadores de código, los generadores de pantalla, etc. se utilizan dentro de un cuadro de tiempo, con un enfoque de "Hacer hasta que se haga".

  • Fase de corte: en la fase de corte, se realiza la instalación del sistema, las pruebas de aceptación del usuario y la capacitación del usuario.

Fases RAD

Modelo de desarrollo rápido de aplicaciones: fortalezas

Las ventajas o fortalezas del modelo de Desarrollo rápido de aplicaciones son las siguientes:

  • El tiempo de ciclo reducido y la productividad mejorada con menos miembros del equipo significarían costos más bajos.

  • La participación del cliente durante todo el ciclo minimiza el riesgo de no lograr la satisfacción del cliente y el valor comercial.

  • El foco se mueve al código en un modo "lo que ves es lo que obtienes" (WYSIWYG). Esto aporta claridad sobre lo que se está construyendo es lo correcto.

  • Utiliza conceptos de modelado para capturar información sobre negocios, datos y procesos.

Modelo de desarrollo rápido de aplicaciones: debilidades

Las desventajas o fortalezas del modelo de Desarrollo rápido de aplicaciones son las siguientes:

  • El proceso de desarrollo acelerado debe dar respuestas rápidas al usuario.

  • Riesgo de nunca lograr el cierre.

  • Difícil de usar con sistemas heredados.

  • Los desarrolladores y los clientes deben comprometerse con actividades rápidas en un marco de tiempo abreviado.

¿Cuándo utilizar el modelo de desarrollo rápido de aplicaciones?

El modelo de desarrollo rápido de aplicaciones se puede usar cuando:

  • El usuario puede participar durante todo el ciclo de vida.
  • El proyecto puede tener una caja de tiempo.
  • La funcionalidad se puede entregar en incrementos.

Aunque se aprecian los puntos fuertes del modelo de Desarrollo rápido de aplicaciones, se usa con moderación en la industria.

SDLC - Modelo en espiral

El modelo en espiral agrega análisis de riesgos y creación de prototipos RAD al modelo en cascada. Cada ciclo implica la misma secuencia de pasos que el modelo Cascada.

Modelo espiral

El modelo en espiral tiene cuatro cuadrantes. Discutamos en detalle.

Cuadrante 1: determinar objetivos, alternativas y limitaciones

  • Objetivos : funcionalidad, rendimiento, interfaz de hardware / software, factores críticos de éxito, etc.

  • Alternativas : construir, reutilizar, comprar, subcontratar, etc.

  • Restricciones - Costo, horario, interfaz, etc.

Cuadrante 2: evaluar alternativas, identificar y resolver riesgos

  • Estudiar alternativas relativas a los objetivos y limitaciones que se determinan.

  • Identifique riesgos como falta de experiencia, nueva tecnología, horarios ajustados, etc.

  • Resolver los riesgos identificados evaluando su impacto en el proyecto, identificando los planes de mitigación y contingencia necesarios e implementándolos. Los riesgos siempre necesitan ser monitoreados.

Cuadrante 3 - Desarrollar producto de siguiente nivel

Las actividades típicas incluyen:

  • Crea un diseño
  • Revisar diseño
  • Desarrollar código
  • Inspeccionar código
  • Producto de prueba

Cuadrante 4 - Planifique la próxima fase

Las actividades típicas incluyen:

  • Desarrollar plan de proyecto
  • Desarrollar un plan de gestión de la configuración.
  • Desarrollar un plan de prueba.
  • Desarrollar un plan de instalación.

Modelo en espiral - Fortalezas

Las ventajas o fortalezas del método Espiral son:

  • Proporciona una indicación temprana de los riesgos, sin implicar mucho costo.
  • Los usuarios pueden ver el sistema temprano debido a las herramientas de creación rápida de prototipos.
  • Las funciones críticas de alto riesgo se desarrollan primero.
  • El diseño no tiene que ser perfecto.
  • Los usuarios pueden participar estrechamente en todos los pasos del ciclo de vida.
  • Comentarios tempranos y frecuentes de los usuarios.
  • Costos acumulados evaluados con frecuencia.

Modelo en espiral - Debilidades

Las desventajas o debilidades del método espiral son:

  • Puede ser difícil definir objetivos, hitos verificables que indiquen la disposición para proceder a la siguiente iteración.

  • El tiempo dedicado a la planificación, restablecimiento de objetivos, análisis de riesgos y creación de prototipos puede ser una sobrecarga.

  • El tiempo dedicado a evaluar los riesgos puede ser demasiado grande para proyectos pequeños o de bajo riesgo.

  • El modelo espiral es complejo de entender para los nuevos miembros del equipo.

  • Se requiere experiencia en evaluación de riesgos.

  • La espiral puede continuar indefinidamente.

  • Los desarrolladores deben ser reasignados durante las actividades de la fase de no desarrollo.

¿Cuándo usar el modelo en espiral?

El modelo espiral se puede usar cuando:

  • La creación de un prototipo es apropiada.
  • La evaluación de riesgos es importante.
  • Un proyecto es de riesgo medio a alto.
  • Los usuarios no están seguros de sus necesidades.
  • Los requisitos son complejos.
  • La línea de productos es nueva.
  • Se esperan cambios significativos durante la exploración.
  • Compromiso de proyecto a largo plazo imprudente debido a posibles cambios comerciales.

SDLC - Métodos ágiles

Los métodos ágiles se basan en el manifiesto ágil y son de naturaleza adaptativa. Los métodos ágiles aseguran:

  • Colaboración en equipo.
  • Colaboración con el cliente.
  • Comunicación constante y continua.
  • Respuesta a los cambios.
  • Disponibilidad de un producto en funcionamiento.

Varios métodos ágiles surgieron, promoviendo el desarrollo iterativo e incremental con iteraciones de tiempo. Aunque los métodos ágiles son adaptativos, las reglas del método específico no pueden pasarse por alto y, por lo tanto, requieren una implementación disciplinada.

Métodos ágiles - Fortalezas

Las ventajas o fortalezas del método ágil son:

  • Lanzamientos tempranos y frecuentes.
  • Acomodación de requisitos cambiantes.
  • Comunicación diaria entre el cliente y los desarrolladores.
  • Proyectos construidos alrededor de individuos motivados.
  • Equipos autoorganizados.
  • Simplicidad, centrándose en lo que se requiere de inmediato.
  • Ningún edificio para el futuro o sobrecargar el código.
  • Reflexión regular para ajustar el comportamiento para mejorar la efectividad.

Métodos ágiles - debilidades

Las desventajas o debilidades del método Spiral son:

  • La disponibilidad del cliente puede no ser posible.

  • Los equipos deben tener experiencia para seguir las reglas del método.

  • Se requiere una planificación adecuada para decidir rápidamente sobre la funcionalidad que debe entregarse en una iteración.

  • Se espera que el equipo tenga habilidades de estimación y negociación.

  • El equipo debe tener habilidades de comunicación efectivas.

  • Es posible que los nuevos equipos no puedan organizarse.

  • Requiere disciplina para desarrollarse y entregarse en iteraciones de caja de tiempo.

  • El diseño debe mantenerse simple y fácil de mantener, lo que requiere habilidades de diseño efectivas.

¿Cuándo usar métodos ágiles?

Los métodos ágiles se pueden usar cuando:

  • La aplicación es de tiempo crítico.

  • El alcance es limitado y menos formal (está en marcha la ampliación de métodos ágiles a proyectos más grandes, con ciertas extensiones a algunos de los métodos ágiles).

  • La organización emplea métodos disciplinados.

Desarrollo de software adaptativo - Evolución

Los modelos SDLC anteriores están más orientados a las prácticas de estabilidad, previsibilidad y rendimientos decrecientes. La industria, como las plataformas de Internet, se ha estado moviendo para aumentar los entornos de retorno, enfoques impredecibles, no lineales y rápidos.

El desarrollo de software adaptativo (ASD) ha evolucionado para abordar estos problemas. Se centra en la emergencia como el factor más importante desde la perspectiva de la administración, para mejorar la capacidad de administrar el desarrollo de productos.

En palabras de Jim Highsmith, “El marco de desarrollo de software adaptativo se basa en años de experiencia con metodologías tradicionales de desarrollo de software, consultoría, práctica y escritura sobre técnicas de desarrollo rápido de aplicaciones (RAD) y trabajo con compañías de software de alta tecnología en la gestión del desarrollo de sus productos. prácticas ".

Se encuentra que el modelo de cascada se caracteriza por la linealidad y la previsibilidad, con una escasa retroalimentación. Se puede ver como una secuencia de Plan → Construir → Implementar .

Modelo de cascada

Los modelos del ciclo de vida evolutivo, como el modelo espiral, trasladaron el enfoque determinista al adaptativo, con Plan → Construir → Revisar ciclos .

Ciclo de vida evolutivo

Sin embargo, la mentalidad de los practicantes se mantuvo determinista con una previsibilidad a largo plazo que se convirtió en previsibilidad a corto plazo. Las prácticas de los modelos del ciclo de vida evolutivo, como RAD, son menos deterministas.

El ciclo de vida adaptativo

El modelo adaptativo se construye 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.

Ciclo de vida de desarrollo adaptativo S / W

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

    • Gestión en el sentido tradicional de gestión de proyectos, y

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

En este capítulo, entenderemos los diversos conceptos del desarrollo de software adaptativo.

Teoría de sistemas adaptativos complejos (CAS)

Brian Arthur y sus colegas, en el instituto Santa Fe, utilizaron la teoría de los Sistemas Adaptativos Complejos (CAS) para revolucionar la comprensión de la Física, la Biología, la Evolución y la Economía.

Brian Arthur culminó sus más de dos décadas tratando de convencer a los economistas de la corriente principal de que su punto de vista, dominado por supuestos fundamentales de rendimientos decrecientes, equilibrio y dinámicas deterministas, ya no era suficiente para comprender la realidad. El nuevo mundo es uno de rendimientos crecientes, inestabilidad e incapacidad para determinar causa y efecto.

Los dos mundos difieren en comportamiento, estilo y cultura. Piden

  • Diferentes técnicas de gestión
  • Diferentes estrategias
  • Diferente comprensión

Desarrollo de software complejo

Con el alcance de las aplicaciones de software en expansión, incluso las organizaciones de desarrollo de software están acumulando contradicciones similares a las mencionadas anteriormente.

  • One World está representado por el desarrollo determinista, derivado de prácticas de gestión basadas en los principios básicos de estabilidad y previsibilidad (que en términos de Arthur significa rendimientos decrecientes)

  • Second World está representado por las industrias que pasan de entornos de retorno decrecientes a crecientes que son impredecibles, no lineales y rápidos.

Para abordar los problemas de este segundo mundo, Jig Highsmith ofreció un marco de desarrollo de software adaptable que es diferente del desarrollo de software determinista.

El desarrollo de software adaptativo se centra en abordar los sistemas complejos:

  • Desarrollo de software adaptativo para el ciclo de vida del desarrollo.

  • Técnicas de gestión adaptativa que requieren una mentalidad diferente de la de las prácticas tradicionales de gestión de proyectos.

En este tutorial, puede comprender ambas implementaciones.

El desarrollo de software adaptativo (ASD) se basa en dos perspectivas:

  • Perspectiva conceptual basada en la teoría de Sistemas Adaptativos Complejos (CAS), como se da en la primera sección de este capítulo.

  • Perspectiva práctica basada en

    • Años de experiencia con metodologías deterministas de desarrollo de software.

    • Consul , practicar y escribir sobre técnicas de Desarrollo rápido de aplicaciones (RAD); y trabajando con compañías de software de alta tecnología para gestionar el desarrollo de sus productos.

En este capítulo, comprenderá la perspectiva conceptual del desarrollo de software adaptativo.

Conceptos de sistemas adaptativos complejos (CAS)

La teoría de los Sistemas Adaptativos Complejos (CAS) tiene muchos conceptos. El desarrollo de software adaptativo se basa en dos de estos conceptos:

  • Aparición
  • Complejidad

Aparición

En proyectos complejos de desarrollo de productos de software, los resultados son inherentemente impredecibles. Sin embargo, los productos exitosos emergen de tales entornos todo el tiempo.

Esto puede suceder por Emergencia, como se ilustra en la teoría de los Sistemas Adaptativos Complejos (CAS). Se puede entender con un simple ejemplo, el comportamiento de bandada de las aves.

Cuando observa una bandada de pájaros, nota que:

  • Cada pájaro intenta

    • Mantenga una distancia mínima de otros objetos en el medio ambiente, incluidas otras aves.

    • Haga coincidir las velocidades con las aves de su vecindario.

    • Avanzar hacia el centro de masa de aves percibido en su vecindario.

  • No hay reglas de comportamiento para el grupo. Las únicas reglas son sobre el comportamiento de las aves individuales.

  • Sin embargo, existe un comportamiento emergente, el agrupamiento de aves. Cuando las aves errantes se apresuran a ponerse al día, la bandada se divide alrededor de obstáculos y reformas en el otro lado.

Esto muestra el requisito de los cambios de modelo mental más difíciles en el Desarrollo Adaptativo: desde las formas de gestionar y organizar esa libertad individual hasta la noción de que un nuevo orden creativo emerge impredeciblemente de la autoorganización espontánea.

Además del desarrollo, la emergencia es el concepto más importante desde la perspectiva de gestión también.

Complejidad

En el contexto del desarrollo de software, la complejidad se trata de:

  • Los individuos de un equipo, como los desarrolladores, clientes, proveedores, competidores y accionistas, sus números y su velocidad.

  • Tamaño y complejidad tecnológica.

Prácticas de desarrollo de software adaptativo

Adaptive Software Development ofrece una perspectiva diferente sobre las prácticas de gestión de software. En las secciones siguientes, puede comprender las dos prácticas importantes: Calidad y RAD, que tienen ramificaciones para reunir los requisitos.

Puede encontrar los detalles de todas las prácticas en el capítulo Prácticas de desarrollo de software adaptativo en este tutorial.

Calidad

En un entorno complejo, la antigua práctica de "Hazlo bien la primera vez" no funciona, ya que no puedes predecir lo que es correcto al principio. Debe tener el objetivo de producir el valor correcto. Sin embargo, en un entorno complejo, las combinaciones y permutaciones de componentes de valor como el alcance (características, rendimiento, niveles de defectos), la programación y los recursos son tan grandes que nunca puede haber un valor óptimo. Por lo tanto, el objetivo es cambiar para ofrecer el mejor valor en el mercado competitivo.

Prácticas RAD

Las prácticas RAD generalmente implican una combinación de lo siguiente:

  • Ciclo de vida evolutivo
  • Grupos de enfoque de clientes, sesiones JAD, revisiones técnicas
  • Gestión de proyectos en cajas de tiempo
  • Ingeniería continua de software
  • Equipos dedicados con salas de guerra

Los proyectos RAD tienen un sabor inherente adaptativo y emergente. Muchas organizaciones de TI están en contra de RAD. Sin embargo, Microsoft y otros han producido un software increíblemente grande y complejo utilizando técnicas comparables a RAD porque plantea preguntas sobre su visión fundamental del mundo.

Las prácticas de RAD y el proceso de Microsoft son ejemplos de desarrollo adaptativo en acción. Darles una etiqueta (es decir, Desarrollo adaptativo) y darse cuenta de que hay un creciente cuerpo de conocimiento científico (es decir, teoría CAS) explica por qué funcionan. Esto debería proporcionar una base para un uso más extenso de estas prácticas.

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 los TEA

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. Adaptive Software Development 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.

Ciclo de vida de desarrollo de software adaptativo

Especular

El término plan es demasiado determinista e indica un grado de certeza razonablemente alto sobre el resultado deseado. El objetivo implícito y explícito de conformidad con el plan restringe la capacidad del gerente de dirigir el proyecto en direcciones innovadoras.

En Adaptive Software Development, 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 supuestos 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 alientan 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 para comprometer la calidad de los entregables.

En Adaptive Software Development, 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, es necesario que haya una función de forzamiento periódica, como un timebox para terminar 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:

Practica Learning Loop

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

    • Iniciacion de proyecto

    • Establecer un calendario 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

  • Colaborar : desarrollo de funciones concurrentes

    • Colaboración para equipos distribuidos.

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

    • Colaboración para proyectos más grandes.

  • Aprender - Revisión de calidad

    • Calidad de resultados desde la perspectiva del cliente.

    • Calidad de resultados desde una perspectiva técnica.

    • El funcionamiento del equipo de entrega y los miembros del equipo de prácticas están utilizando

    • 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 inicio y planificación. Ellos son

  • Iniciacion del proyecto
  • Establecer un calendario 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 o 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

Se debe establecer el cronograma para todo el proyecto, 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 proponer estimaciones de características, riesgos y dependencias y proporcionarlas 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 más pequeños

En los proyectos más pequeños, cuando los miembros del equipo trabajan en proximidad física, se debe alentar la colaboración con los chats informales en los pasillos y los garabatos en la pizarra, ya que se considera que esto es 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 con anticipación, para:

  • 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 de 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 por ejemplo:

  • 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?"

Desarrollo adaptativo S / W - Gestión

A continuación se muestra un diagrama de flujo de la gestión de software tradicional.

Reevaluación

La gestión de software tradicional se ha caracterizado por el término control de comando.

Muchas organizaciones están inmersas en una tradición de optimización, eficiencia, previsibilidad, control, rigor y mejora de procesos. Sin embargo, la economía emergente de la era de la información requiere adaptabilidad, velocidad, colaboración, improvisación, flexibilidad, innovación y flexibilidad.

Los libros de revisión y gestión empresarial de Harvard han creado términos como empoderamiento, gestión participativa, organización de aprendizaje, gestión centrada en el ser humano, etc., pero ninguno de estos se está poniendo en la gestión de organizaciones modernas.

En el contexto del desarrollo de software adaptativo, la brecha se ve mucho más amplia y es necesario considerar las técnicas de gestión adaptativa que han demostrado ser exitosas en otros campos.

Manejo adaptativo

La gestión adaptativa ha demostrado ser exitosa en los entornos en los que los gerentes de recursos trabajaron junto con las partes interesadas y los científicos en equipo, con los siguientes objetivos:

  • Aprender cómo los sistemas gestionados responden a las intervenciones humanas.

  • Para mejorar las políticas y prácticas de recursos en el futuro.

El principio detrás del manejo adaptativo es que muchas actividades de manejo de recursos son experimentos ya que sus resultados no pueden predecirse de manera confiable de antemano. Estos experimentos se utilizan como oportunidades de aprendizaje para las mejoras en el futuro.

La gestión adaptativa está destinada a aumentar la capacidad de responder oportunamente ante la nueva información y en un entorno de objetivos y preferencias variados de los interesados. Alienta a las partes interesadas a resolver disputas y discutirlas de manera ordenada mientras se investigan y entienden mejor las incertidumbres ambientales.

La gestión adaptativa ayuda a las partes interesadas, los gerentes y otros tomadores de decisiones a reconocer los límites del conocimiento y la necesidad de actuar sobre la información imperfecta.

La gestión adaptativa ayuda a cambiar las decisiones tomadas al dejar en claro que:

  • Las decisiones son provisionales.
  • La decisión de una gerencia no siempre tiene que ser correcta.
  • Se esperan modificaciones.

Hay dos tipos de enfoques de gestión adaptativa:

  • Gestión adaptativa pasiva.
  • Gestión adaptativa activa.

Gestión pasiva adaptativa

La gestión adaptativa tiene como objetivo mejorar el conocimiento científico y, por lo tanto, reducir las incertidumbres.

Pasiva adaptativa

Dentro de la gestión adaptativa pasiva, se selecciona un único curso de acción preferido, basado en la información y comprensión existentes. Los resultados de las acciones de gestión se supervisan y las decisiones posteriores se ajustan en función de los resultados.

Este enfoque contribuye al aprendizaje y la gestión eficaz. Sin embargo, tiene una capacidad limitada para mejorar las capacidades científicas y de gestión de las condiciones que van más allá del curso de acción seleccionado.

Gestión adaptativa activa

Un enfoque de gestión adaptativo activo revisa la información antes de tomar medidas de gestión.

Activo Adaptativo

Luego se desarrolla una gama de modelos de sistemas alternativos competitivos de ecosistema y respuestas relacionadas (por ejemplo, cambios demográficos; usos recreativos), en lugar de un solo modelo. Las opciones de gestión se eligen en función de las evaluaciones de estos modelos alternativos.

Gestión de Liderazgo-Colaboración

La gestión adaptativa es la más adecuada para el desarrollo de software adaptativo. El enfoque requiere gerentes de recursos, es decir, gerentes que pueden trabajar con personas, permitir intervenciones humanas y crear un ambiente amigable.

En el desarrollo de software, los líderes a menudo asumen estas responsabilidades. Necesitamos líderes más que los comandantes. Los líderes son colaboradores y trabajan junto con el equipo. Liderazgo colaborativo es la práctica más buscada en el desarrollo adaptativo.

Los líderes tienen las siguientes cualidades:

  • Agarrar y establecer la dirección.

  • Influir en las personas involucradas y brindar orientación.

  • Colabora, facilita y macrogestiona el equipo.

  • Proveer direccion.

  • Cree entornos en los que las personas con talento puedan ser innovadoras, creativas y tomar decisiones efectivas.

  • Comprende que ocasionalmente necesitan mandar, pero ese no es su estilo predominante.