agile methodology sdlc

Agile Vs Spiral Model para SDLC



methodology (6)

Ágil es espiral. Totalmente. En parte, el nombre fue cambiado con fines de comercialización.

El problema es que la espiral tiende a implicar un "gran diseño por adelantado", donde planifica muchas espirales, cada una en orden de importancia. La espiral, sin embargo, no es ágil: es solo una ejecución incremental por orden de riesgo.

Una gran distinción que agrega Agile es la de "no sobreescribir las cosas que no puedes saber todavía". Agile es espiral, pero usted crea planes detallados para un solo incremento a la vez.

Agile agrega muchas otras cosas, también. La espiral es un enfoque muy técnico. Ágil, sin embargo, reconoce que la tecnología está construida por personas. El Manifiesto Ágil tiene cuatro principios que van más allá del simple enfoque de gestión de riesgos de Boehm.

Creo que Agile no es más que otra implementación del Modelo espiral. Soy un gran defensor de Spiral (el modelo espiral es un proceso de desarrollo de software que combina elementos de diseño y creación de prototipos en etapas, en un esfuerzo por combinar las ventajas de los conceptos descendentes y ascendentes) desde sus comienzos y lo he visto ese montón de proyectos implementan Spiral sin saber que están operando en un mundo Espiral. Desde el día en que Agile comenzó a ganar popularidad, el concepto de espiral comenzó a pasarse por alto un poco. Estoy seguro de que para proyectos complejos, la espiral sigue siendo la mejor alternativa, pero me gustaría obtener una mejor comprensión de las similitudes y diferencias entre las técnicas Agile y Spiral. ¿Alguien puede explicar sus diferencias / similitudes?


First Agile es en realidad una serie de procesos diferentes que siguen una filosofía similar. Una de las filosofías que lo hace diferente es que cada iteración produce un producto que funciona. Podría describirse como iterativo e incremental. Se pone mucho énfasis en el producto de trabajo y en las pruebas. En muchos modelos ágiles las pruebas vienen antes de la codificación.

En el modelo espiral, el número de iteraciones es fijo, mientras que cada fase de un modelo ágil puede consistir en cualquier cantidad de iteraciones.

Tiene razón en que hay similitudes, pero la filosofía subyacente marca la diferencia. Esta página explica con más detalle y compara ágil con otros métodos.

Puede decir que los procesos ágiles se basan en el uso de casos ... poniendo mucho énfasis en las personas, el usuario final.


La diferencia básica, como yo lo veo, es que la mayoría de los modelos de desarrollo en espiral aún insisten en un diseño grande y directo. El énfasis está en saber todo lo que pueda sobre cómo se usará el sistema; descubriendo todos los casos de uso. Una vez que los conoce, diseña el sistema y lo descompone en fases que siguen un ciclo iterativo de diseño de detalle, implementación, prueba y refactorización. En Agile, hay una planificación inicial, tal vez recopilación de grandes conocimientos de granos (títulos de historias), para poder describir versiones razonables, pero cada lanzamiento se planifica de forma independiente y demoramos el descubrimiento de los detalles hasta que estemos listos para comenzar. implementación de esa versión. Esperamos un cambio y no intentemos saber todo primero.

Otra cosa que difiere es que las filosofías más ágiles involucran métodos de "prueba primero". Esto es diferente de la espiral, donde las pruebas a menudo son una actividad en sí misma y las pruebas no se desarrollan antes del código. En la mayoría de los casos, se planifican con antelación, pero se desarrollan en paralelo o después de la codificación. Muchos métodos ágiles insisten en desarrollar pruebas primero como la especificación para el código.

Son similares en el sentido de que son iterativos. Difieren en la implementación y la comprensión de lo que es una iteración.


No soy un experto para el Modelo espiral, pero a partir de la definición de wikipedia, me parece que hay algunas diferencias significativas.

Por ejemplo, en un proyecto Agile, al final de una iteración no se levanta un prototipo, sino un sistema completamente funcional, totalmente probado, potencialmente implementable (1), que contiene las características de mayor prioridad en la lista de características.

Los requisitos que se reúnen al inicio del proyecto deben ser apenas suficientes para comenzar (dar el siguiente paso) y se deben completar poco antes de que realmente se implementen. Los cambios son a los requisitos son bienvenidos.

Además, para Agile hay mucho más que solo desarrollo iterativo: un enfoque en la conversación cara a cara en lugar de la comunicación escrita, un enfoque en reunir a personas de negocios y técnicos en su trabajo diario. Un enfoque para maximizar el valor de forma colaborativa en lugar de definir y luego cumplir un contrato.

En caso de que aún no lo haya visto, eche un vistazo al Manifiesto Ágil , que básicamente es la definición de Desarrollo de Software Ágil.

(1) Eso no significa que tenga sentido comercial implementar el sistema, "solo" que sea técnicamente factible. Debe ser una decisión comercial pura si desplegar el sistema al final de una iteración.


Diría que espiral y ágil son similares. Sin embargo, últimamente ágil a menudo se ha convertido en un sistema de propaganda para excusar la codificación de vaquero. Es decir

  • Requisitos extremadamente mínimos
  • Mínimo análisis técnico
  • Documentación mínima
  • Sin comentarios de código
  • Bonificación especial: uso indebido de Domain Driven Design para complicar demasiado el modelo de objetos

Esta nunca fue la idea con espiral. Yo diría que tampoco es realmente el objetivo de Agile, aunque te sorprenderías cuántas veces lo he visto recientemente. Más y más desarrolladores / PM experimentados están empezando a ver la sabiduría de un enfoque más equilibrado entre cascada y "ágil"; quizás esto simplemente nos lleve de vuelta a la espiral.

Aunque hay algunas ideas útiles en el espacio mental ágil, a menudo parece como si se manifestara a partir de personas que estaban en organizaciones que tenían metodologías de diseño de software particularmente sobrecargadas / inútiles, y fue una reacción / reacción excesiva a eso.


Creo que Agile es un tipo de SDLC iterativo, mientras que spiral es un tipo de SDLC incremental. Scrum es uno de los tipos de Agile, otros son DSDM / FDD / XP, etc. Todos los SDLC después de cascada siguieron el mismo conjunto de actos (Análisis de requisitos, Diseño, Codificación y Pruebas) en algunas combinaciones diferentes. Por lo tanto, el conjunto de acciones básicas en secuencia O Iterativo O incremental son las mismas.

En lo que respecta a Agile y Spiral, ambos tienen una ventaja en común 1. Cambio en el manejo de requisitos 2. Versiones de corto plazo 3. La administración de riesgos es fácil debido a la menor duración del SDLC 4. El equipo Cross ayuda a que el producto y el proyecto vayan sin problemas