lunes, julio 14, 2014

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:

No hay comentarios.:

Publicar un comentario