Tabla comparativa entre Metodologías Tradicionales y Ágiles

Hola a todos

Aunque hace algún tiempo había recopilado una comparación gráfica entre metodologías ágiles y tradicionales (clic aquí para ver -> ), quiero compartir hoy un cuadro comparativo que realicé. Espero les sirva de ayuda.

Aspecto	Robusta o tradicional	Ágiles
Requisitos	Requieren los requisitos detallados desde el inicio del proyecto.  Los requisitos no pueden cambiar	Los requisitos son muy cambiantes. La verdad es que en software los requisitos cambian continuamente, y se requiere de un feedback sobre un resultado obtenido para determinar si es lo requerido o no.
Requisitos (funcionalidades innecesarias)	Debido a la recolección inicial de requisitos es frecuente que se soliciten funcionalidades innecesarias	El enfoque continuo en el valor para el negocio no permite que se incluyan funcionalidades innecesarias
Cambios	Hacer un cambio al alcance requiere de un proceso formal de control de cambios	El cambio es bienvenido en cualquier momento del proyecto
Tiempo	Existe un compromiso respecto al tiempo de entrega del proyecto  (no siempre se cumple esta meta)	Existe incertidumbre respecto al tiempo de entrega de todo el producto. Lo cierto es que máximo cada 2 meses (máximo un mes en scrum) hay entrega de producto de valor para el cliente
Costo	El costo del proyecto es definido para el proyecto	Existe incertidumbre respecto al costo del proyecto. Se invierte en las funcionalidades que más valor le dan al cliente y ciclicamente se avanza hasta que se logre, ya sea: el producto deseado se acabe el presupuesto
Documentación	Atención exhaustiva a la documentación.	Solo se genera la documentación que genera valor al cliente y al proyecto
El cliente	El cliente apoya el desarrollo del producto mediante la participación en reuniones.	Involucración directa del cliente en el desarrollo del producto El cliente es parte de equipo.
Iteraciones	Pocas iteraciones que generan gran volumen de información y software para construcción del producto.	Utilización de múltiples iteraciones de desarrollo para aprender y evolucionar el producto
Riesgos	Los riesgos son asumidos por el proveedor	Voluntad del cliente para compartir la responsabilidad en las decisiones y riesgos[1]
Se valora más	El proceso	El individuo y las interacciones de los mismos
La planeación	Requieren un plan detallado desde el inicio del proyecto	Se va planeando a medida que se avanza en el proyecto. Planeación gradual y constante.
El éxito del proyecto	Es dado por el seguimiento del plan	Es dado por la entrega continua de valor y funcionalidad al cliente
Elaboración de entregables	Se generan entregables que requieren mucho tiempo de elaboración.	Se centran en hacer entregables en tiempos cortos con alta calidad inmersa
La retroalimentación del cliente	Es conocida al final, pudiendo generar insatisfacción.	Es constante a lo largo del proyecto
Participación del equipo	Empodera al Gerente de proyecto para el éxito del mismo, este decide si participa de este poder o no al equipo o no.	Empodera al equipo para trabajar de forma creativa e innovadora.
Proceso(Plantillas)	Innumerables plantillas y artefactos para cumplir con el proceso	Pocas plantillas y artefactos  (solo los estrictamente necesarios para construir el producto)
Roles	Muchos roles para ejecutar el proyecto	Pocos roles
Arquitectura	Es un ejercicio que se realiza al inicio o en una etapa del proyecto.	Es un ejercicio constante durante el proyecto

---

-[1] Software Engineering Institute. CMMI®  para Desarrollo, Versión 1.3 . [en línea] Disponible en:

<http://resources.sei.cmu.edu/asset_files/WhitePaper/2010_019_001_28782.pdf > (Citada el 9 de julio de 2014)

-[2] http://datateca.unad.edu.co/contenidos/301569/guia_de_ingenieria_del_software.pdf