¿Es Agile una variante de RAD?

Wikipedia dice que Agile es un tipo de "RAD" que supongo que es incorrecto. Por lo que sé, Agile se desarrolló porque RAD en sí mismo no fue tan exitoso en los años 90 (demasiado rígido para los cambios). ¿O estoy equivocado?

(Observación: aparentemente, el artículo de Wikipedia sobre el desarrollo de software ágil se mejoró en el medio, solo enumera a RAD como un predecesor de Agile, no como un superconjunto).

Una referencia de un libro Radical Project Management (Thomsett)

"... nueva moda de desarrollo como RAD, ágil, orientado a objetos ..."

Auditor del Sistema de Información Certificado CISA:

..consciente de dos software alternativo dev. métodos: desarrollo de aplicaciones ágil y rápido

Gestión ágil para software:

Los métodos ágiles se derivan principalmente del enfoque ligero de RAD.

Mejores prácticas de estimación de software:

Los principales métodos de sw. dev. se puede resumir de la siguiente manera:
1. Cascada ..
4. RAD
5. Ágil

El punto de esta pregunta es:
¿Es el tipo ágil de RAD o un enfoque de desarrollo independiente?

RAD como término es anterior a Agile como término por unos diez años, pero en realidad no es un "padre" de Agile. Ambos fueron creados como reacciones a las deficiencias percibidas con las técnicas tradicionales de gestión del desarrollo de software. Sin embargo, RAD es un método prescriptivo para escribir software, utilizando prototipos sucesivos para obtener requisitos y refinar la aplicación. Ágil, en la forma introducida originalmente, es una posición filosófica que describe la diferencia entre los enfoques tradicionales y los valores centrados en los profesionales ágiles.

Entonces, no, el desarrollo ágil de software no es un tipo de RAD; abordan problemas en diferentes niveles de abstracción.

No creo que sea correcto clasificar las metodologías de desarrollo en las jerarquías. Por lo tanto, ninguna metodología está "debajo" o "arriba" de ninguna otra. Es mucho más lógico pensar en puntos comunes de metodologías. Muy a menudo, la aplicación de la metodología en el mundo real implica la combinación de muchas metodologías similares y depende de los gerentes proponer un modelo de desarrollo funcional.

En el caso de RAD (con el que no tengo experiencia) frente a Agile, parece que solo lo común es el desarrollo iterativo. RAD parece preferir fases rígidas con objetivos y resultados específicos. Ágil se trata más de una sola fase de desarrollo donde sucede todo. Además, Agile desarrolla software directamente con la posibilidad de eliminar funciones en lugar de crear prototipos de antemano. (que podría terminar igual que ágil, porque muy a menudo los prototipos se integran inmediatamente en el software de trabajo, en lugar de hacerlo correctamente una vez más)

La metodología ágil es de un modo más maquinilla de afeitar porque está orientada a crear aplicaciones en modelos iterativos con demostraciones iterativas rápidas para los interesados. No exime a los desarrolladores de mantener paradigmas de diseño (modularidad, especialmente), pero no lo enfatiza directamente, mientras se concentra en la entrega continua de iteraciones y la reacción rápida ante el cambio rápido de los requisitos comerciales. Está orientado de facto al desarrollo de un producto aislado y funciona en los marcos del producto, pero no requiere reutilizar claramente los componentes de las soluciones y, además, construir una plataforma común para la familia de productos a nivel de empresa. Ningún gerente técnico propondrá repetir el mismo trabajo N veces. Afortunadamente, RAD separa el desarrollo por dominios, módulos y su integración, y desde el punto de vista técnico, es más aplicable para la organización técnica del modelo de desarrollo, que es razonable desde el punto de vista de la gestión técnica de una empresa. Esto hace que el modelo sea más flexible y reutilizable y adaptable a la solución para otros productos. Finalmente, una empresa no es una comunidad de trabajadores independientes y tiene una vida más larga que la vida útil de un solo producto. Sin embargo, si una empresa produce un solo producto sin ninguna migración y modificación, entonces el papel de RAD no es tan expresivo. Pero normalmente, las fortalezas comerciales de Agile se combinan de manera excelente con las fortalezas de organización técnica de RAD. Finalmente, una empresa no es una comunidad de trabajadores independientes y tiene una vida más larga que la vida útil de un solo producto. Sin embargo, si una empresa produce un solo producto sin ninguna migración y modificación, entonces el papel de RAD no es tan expresivo. Pero normalmente, las fortalezas comerciales de Agile se combinan de manera excelente con las fortalezas de organización técnica de RAD. Finalmente, una empresa no es una comunidad de trabajadores independientes y tiene una vida más larga que la vida útil de un solo producto. Sin embargo, si una empresa produce un solo producto sin ninguna migración y modificación, entonces el papel de RAD no es tan expresivo. Pero normalmente, las fortalezas comerciales de Agile se combinan de manera excelente con las fortalezas de organización técnica de RAD.