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.
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:
|
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)