You are on page 1of 9

METODOLOGÍAS TRADICIONALES VS.

METODOLOGÍAS ÁGILES

Roberth G. Figueroa1, Camilo J. Solís2
Armando A. Cabrera3
Universidad Técnica Particular de Loja, Escuela de Ciencias en Computación

Resumen ⎯ Desarrollar un buen software depende de un METODOLOGÍA TRADICIONAL
sinnúmero de actividades y etapas, donde el impacto de
elegir la mejor metodología para un equipo, en un Al inicio el desarrollo de software era artesanal en su
determinado proyecto es trascendental para el éxito del totalidad, la fuerte necesidad de mejorar el proceso y llevar
producto. El papel preponderante de las metodologías es los proyectos a la meta deseada, tuvieron que importarse la
sin duda esencial en un proyecto y en el paso inicial, que concepción y fundamentos de metodologías existentes en
debe encajar en el equipo, guiar y organizar actividades otras áreas y adaptarlas al desarrollo de software. Esta
que conlleven a las metas trazadas en el grupo. nueva etapa de adaptación contenía el desarrollo dividido
En el presente trabajo se detallan los dos grandes en etapas de manera secuencial que de algo mejoraba la
enfoques, tanto metodologías tradicionales y metodologías necesidad latente en el campo del software.
ágiles, las primeras están pensadas para el uso exhaustivo
de documentación durante todo el ciclo del proyecto Entre las principales metodologías tradicionales tenemos
mientras que las segundas ponen vital importancia en la los ya tan conocidos RUP y MSF entre otros, que centran
capacidad de respuesta a los cambios, la confianza en las su atención en llevar una documentación exhaustiva de
habilidades del equipo y al mantener una buena relación todo el proyecto y centran su atención en cumplir con un
con el cliente. Se verán diferencias, ventajas, desventajas plan de proyecto, definido todo esto, en la fase inicial del
y cual puede encajar en un proyecto de software, es por desarrollo del proyecto.
ello que, ofrecemos una guía dejando libertad de elección
para el lector el poder juzgar y elegir la mejor Otra de las características importantes dentro de este
metodología que se adapte a su equipo de desarrollo. enfoque tenemos los altos costos al implementar un
cambio y al no ofrecer una buena solución para proyectos
Palabras Claves ⎯ Metodología, RUP, MSF AUP, Scrum, donde el entorno es volátil.
Metodología Tradicional, Metodología Ágil
Las metodologías tradicionales (formales) se focalizan en
INTRODUCCIÓN documentación, planificación y procesos. (Plantillas,
técnicas de administración, revisiones, etc.), a
Dentro del desarrollo de software y a la altiva necesidad de continuación se detalla RUP uno de los métodos más
que los proyectos lleguen al éxito y obtener un producto usados dentro de los métodos tradicionales
de gran valor para nuestros clientes, generan grandes
cambios en las metodologías adoptadas por los equipos RATIONAL UNIFIED PROCESS (RUP)
para cumplir sus objetivos, puesto que, unas se adaptan
mejor que otras, al contexto del proyecto brindando FIGURA1.
mejores ventajas. PROCESO UNIFICADO RATIONAL

Es por eso de la importancia de una metodología robusta
que ajustada en un equipo cumpla con sus metas, y
satisfaga mas allá de las necesidades definidas al inicio del
proyecto.

El éxito del producto depende en gran parte de la
metodología escogida por el equipo, ya sea tradicional o
ágil, donde los equipos maximicen su potencial, aumenten
la calidad del producto con los recursos y tiempos
establecidos.

1
Roberth G. Figueroa, UTPL, Loja, rgfigueroa@utpl.edu.ec
2
Camilo J. Solís, UTPL, Loja, cjsolis@utpl.edu.ec
3
Armando Cabrera S,Docente-Investigador UTPL,Loja, aacabrera@utpl.edu.ec

1

(Customización). fases. Se definen los líderes y necesarios a la hora de desarrollar el responsables del proyecto. El equipo debe tener una visión clara de lo que quisiera lograr para el • Funciona bien en proyectos de innovación. Es guiado por casos de uso y centrado en la arquitectura. se puede realizar algún trabajo administración de proyectos se refiere. Implantación: • Implantación. sin embargo.gpicr. adicionalmente se identifican software. proyecto de tecnología de información. Su objetivo es asegurar la producción de software de alta calidad que satisfaga los requerimientos de los usuarios finales (respetando cronograma y presupuesto). disciplinado para asignar tareas y responsabilidades dentro MODELO DE EQUIPO DE MSF de una organización de desarrollo. pruebas de esta etapa enfatizan el uso y operación bajo • Planificación. especificaciones funcionales. estas últimas se deben • Seguimiento detallado en cada una de las respetar durante la ejecución del proyecto en su totalidad.RUP es un proceso formal: Provee un acercamiento FIGURA 2. y está integrado con toda la suite Rational de herramientas. Puede ser adaptado y extendido para satisfacer las necesidades de la organización que lo adopte. entregables del proyecto. realiza el proceso de diseño • Nuestro cliente deberá ser capaz de describir y de la solución. y se realiza la evaluación inicial de riesgos del proyecto. La es una serie de modelos que puede adaptarse a cualquier infraestructura también es desarrollada durante esta fase. la unificación de objetivos del equipo detrás de una visión común.com/msf. El equipo prepara las situación que puede ser muy incómoda para él. MICROSOFT SOLUTION FRAMEWORK (MSF)4 Desarrollo: Descripción Durante esta fase el equipo realice la mayor parte de la construcción de los componentes (tanto documentación MSF es un compendio de las mejores prácticas en cuanto a como código). (en línea). entender a un gran nivel de detalle para poder estimaciones de costos y cronogramas de los diferentes acordar un alcance del proyecto con él. resolver errores y preparar la solución para el lanzamiento. cliente y ser capaz de indicarlo en términos que motivarán • Es sencillo. Desventajas Planificación: • La evaluación de riesgos es compleja • Excesiva flexibilidad para algunos proyectos Es en esta fase es cuando la mayor parte de la planeación • Estamos poniendo a nuestro cliente en una para el proyecto es terminada. las metas y objetivos a alcanzar. y prepara los planes de trabajo.aspx 2 . • Estabilización. Fue desarrollado por Rational Software. Fases Las cuatro fases del ciclo de vida son: • Concepción • Elaboración • Construcción • Transición Visión y Alcances: Ventajas La fase de visión y alcances trata uno de los requisitos más • Evaluación en cada fase que permite cambios fundamentales para el éxito del proyecto. El equipo se enfoca en priorizar y • Desarrollo. disponible en http://www. MSF respuesta a los resultados de las pruebas. Durante esta fase el equipo implanta la tecnología base y 4 los componentes relacionados. Más que una de desarrollo durante la etapa de estabilización en metodología rígida de administración de proyectos. estabiliza la instalación. y utiliza UML como lenguaje de notación. ya que sigue los pasos intuitivos a todo el equipo y al cliente. condiciones realistas. Estabilización: Todo proyecto es separado en cinco principales fases: En esta fase se conducen pruebas sobre la solución. Microsoft Solution Framework. las • Visión y Alcances.

número de personas documento dinámico. donde se roles. a continuación se describe el contenido de escenarios a simular. mayor número de agentes implicados en el tiempo o coste definitivo que puede suponer esta fase. El modelo de equipos de MSF tiene seis roles que Fase 2 . con óvalos del mismo tamaño para todos los Arquitectura: es el documento principal. se deberá hacer por direcciones. muestra que no es un modelo jerárquico y que cada describen en detalle los aspectos funcionales y todos los roles son igualmente importantes en su aporte al operativos de la nueva plataforma. La aprobación proyecto. Si en el La comunicación se pone en el centro del círculo para curso de las fases sucesivas fuera necesario mostrar que está integrada en la estructura y fluye en todas revisar estos contenidos. Los mecanismos y protocolos de desarrollado para compensar algunas de las desventajas intercambio de información y coordinación deben impuestas por las estructuras jerárquicas de los equipos en quedar suficientemente bien establecidos y los proyectos tradicionales. Consultor de Microsoft junto con el equipo de trabajo que formen El cliente y el Partner. la estructura circular • Documento de Planificación y Diseño de del modelo. y Laboratorio. un control de incidencias y las métricas de calidad detalle de acciones concretas y estimación de carga de son objetivos a cubrir en este documento. Ejemplo de metodología MSF aplicada • Documento de Plan de Laboratorio .Estrategia y alcance Documento de Alcance y Estrategia. de laboratorio concluye cuando la maqueta ofrece todos los servicios y funciones descritos en el Fase 1 . para mantenerse enfocados en el proyecto que están Para un proyecto de migración a Windows 2000 podría desarrollando. • Elaboración y aprobación del Documento de Alcance y Estrategia definitivo: debe ser un Habitualmente. ineludiblemente. deben ser consistentes con esta Guía. los criterios de validez. en concreto. En este documento quedarán otras experiencias anteriores se puede obtener una relación definitivamente reflejadas las funcionalidades y de trabajos sólo a título orientativo. en las propuestas de preventa no se pueden documento de consenso con la participación del indicar con precisión parámetros como el esfuerzo técnico. Pruebas de la Planificación y Diseño. y su grado de estabilidad y rendimiento es considerado como En esta fase deberían tener lugar los siguientes trabajos: "suficiente". Comparten una visión común del proyecto estimarse que los trabajos indicados pueden requerir en y se enfocan en implementar la solución. De proyecto. • Formación del Equipo de Trabajo y distribución de competencias y responsabilidades: El cómputo de jornadas para la relación de actividades generalmente se definen como áreas principales descritas (que como se observa sólo recogen las relativas a la de Diseño de Arquitectura. con altos torno a 20 jornadas de trabajo y la intervención de un estándares de calidad y deseos de aprender. El proyecto ejemplo se y la experiencia práctica al llevarla a cabo en trata de una implantación de infraestructuras. Documentación. y supone la directriz última de todos los ninguno puede ser omitido. debe ofrecer la revisado y acordado por todas las partes: solución a implantar. • Elaboración de la matriz de Riesgos y Plan de Los equipos organizados bajo este modelo son pequeños y Contingencia: los principales riesgos detectados multidisciplinarios. a partir de ese momento. los diversos un proyecto. Logística y obtiene la aprobación final del cliente. el cada una de las fases y. El modelo apoya la comunicación efectiva y acuerdo y conocimiento de todo el equipo de es esencial para el funcionamiento del mismo trabajo y se llevará un registro de versiones que permita hacer un seguimiento adecuado de estas revisiones. entorno controlado y aislado. La etapa de prueba migración a Windows 2000 de una red de servidores. Cada rol puede estar Deben alcanzarse los siguientes objetivos e hitos: compuestos por una o más personas. en la medida de lo posible. y deja aparte las necesarias para 3 . fase. Coordinación. en el que se recoge la idea implicadas y perfil de las mismas. Es un trabajo en términos de jornadas. consensuados. en los cuales los miembros comparten deben tener un plan de mitigación y actuación y responsabilidades y balancean las destrezas del equipo revisarse con periodicidad. Aunque los roles pueden tener diferentes niveles de este documento es el hito principal de esta de actividad durante las diversas etapas del proyecto.Prueba de Concepto: la descripción del contenido del Como ejemplo de una aplicación de metodología MSF a laboratorio de prueba de concepto.traspasa el proyecto al personal soporte y operaciones. que. y que debe ser servicios que. Modelo de roles • Elaboración del Plan de Trabajo: deben marcarse fechas y contenidos para esta fase y las El modelo de equipos de MSF (MSF team model) fue siguientes.Planificación y Prueba de Concepto corresponden a las metas principales de un proyecto y son responsables por las mismas. trabajos técnicos.

en esta fase deben (incluyendo factores de oportunidad política o de negocio) elaborarse las Guías de Usuario. con o sin apertura de nuevo proyecto en establecido en las Métricas de Calidad. procedimientos de validación y método personas) de control de incidencias. Administración. al menos • Entrega de los documentos definitivos acordados en sus líneas principales. el éxito de la siguientes: prueba piloto dependerá de que se forme un • Continuación con las labores de recepción de sistema de recogida de incidentes (helpdesk o incidencias. resolución similar). 2 • Elaboración del Plan de Formación: con personas) anterioridad al despliegue definitivo. y otros cuyos La experiencia demuestra que no hay una relación directa contenidos deben acordarse previamente. los habrá iniciado en la fase anterior. la plataforma. puesta en servicio de todas las funciones. En el Plan deben identificarse las Jornadas totales: 80 (aprox. principalmente el de despliegue y el de sino una fase de observación en la que es formación. estrategia de implantación. debe haberse aprobado el Plan de Formación orientado Fase 3 – Estabilización a usuarios finales y administradores. y distribución de faxes o intervención on-site. Los factores más relevantes en el cálculo consensuar la fecha de finalización de la fase suelen ser la dispersión o concentración geográfica. de atención al usuario (formación. documentación de los mismos (versionado de la funcionalidades no cubiertas y novedades a plataforma). tratamiento. incluyendo mejoras aportadas por los Arquitectura: el documento de Planificación y fabricantes de software (nuevas versiones o Diseño de Arquitectura se puede ver alterado Service Packs. incorporar en sucesivas versiones de la • Revisión de la documentación final de plataforma. En proyectos de máquinas y usuarios que entrarán en la prueba. fechas. El • Revisión de las Guías y manuales de usuario. y las condiciones de calidad que debe complejidad del proceso de migración. no puede establecerse a priori. supone rectificación de errores y obtención de los el principal documento del Proyecto y la documentos de formación definitivos. La dimensión de la muestra tiene también que calcularse. además de los obvios (implantación de efectivos de tratamiento de los errores. • Gestión de Incidencias: aunque esta labor se formación a los usuarios y administradores). culminación de los trabajos de diseño. en este caso. la Piloto. las en marcha se muestre estable y el número de métricas de calidad y establecimiento de los incidencias graves (de intervención o de estándares de calidad y SLA definitivos. base a la información y experiencia obtenidas. entre número de máquinas y tiempo necesario para el • Elaboración del Plan de Despliegue: se debe despliegue. por ejemplo) parcialmente como resultado de esta fase. 4 meses) fases. entrega del Proyecto y cierre del consideradas leves quede por debajo de un límite mismo. Los hitos y objetivos fundamentales de propia solución. considerará definitivo cuando la solución puesta • Revisión (si procede) de la matriz de riesgos. las "paso-a-paso". como es la adecuada selección del esta fase son: entorno de prueba y el momento del año en que tenga • Selección del entorno de prueba piloto: se lugar (evitando que coincida con periodos de vacaciones o acordará la composición y ubicación del conjunto puntas de trabajo críticas como Fin de Año). aprobado por consenso. Depende de post proyecto y los programas de formación a numerosos factores externos al propio proyecto usuarios y administradores. consultas) y de resolución de problemas y • Registro de mejoras y sugerencias.elaborar el plan de Migración). la experiencia y nivel de los 4 . clasificación. restringido en número de usuarios y en El tiempo necesario para abordar esta fase es variable y condiciones tales que se pueda llevar un control efectivo depende en parte de factores ajenos a la complejidad de la de la situación. documento final. y debe hacerse compatible con los ritmos acordados en La solución implantada en la maqueta se pasa a un entorno el Plan de Despliegue. anterior. sin perder de vista que la Se llevarán a cabo en esta fase los planes diseñados en la prueba piloto no es el despliegue propiamente. real de explotación. de similar envergadura se ha llegado al momento "Error Esta selección se recomienda que se haga Free Versión" en 30 jornadas de trabajo (aproximadamente atendiendo a la mayor variedad posible de casos. mes y medio) con una muestra de 50 usuarios. tareas a Jornadas / técnico del PARTNER: 150 jornadas (2 realizar. el grado de cumplir la solución final para iniciar el automatización alcanzado. puesto que debe Formación y Operaciones: con vistas al soporte planificarse. Los principales trabajos e hitos a conseguir absolutamente crítico establecer unos cauces son. Este documento se como "deliverables" en la fase de Vision Scope. resolución) sea nulo y la cantidad de las • Finalmente. de que pueden retardar o acelerar la conclusión. de manera que puedan aflorar el máximo de incidentes potenciales en el menor tiempo Fase 4 – Despliegue posible. • Elaboración de la documentación de La duración fase de despliegue. ofrecería este resultado: despliegue. Jornadas / técnico del CLIENTE: 110 jornadas (Max.

estaremos transformando el proyecto en un conjunto de proyectos pequeños. que nace como más sensible. “Manifiesto Ágil”. Donald. el retrasar las decisiones y que es el más aceptado dentro del desarrollo de SW la planificación adaptativa. sino de el cambio ya que lo hemos introducido en nuestro proceso otros tipos (las fechas-objetivo suelen marcarse por de desarrollo. UCLA.técnicos que realizan la operación y condicionantes de La planificación adaptativa permite estar preparados para calendario. ü Reduce el número de cambios necesario Las características fundamentales del método son: en el proyecto. Ágil5 cuyas principales ideas son: MODELO DE EXTREME PROGRAMMING • Los individuos y las interacciones entre ellos son más importantes que las herramientas y los procesos empleados. unas tras otras. (en línea). Scrum. disponible en Extrem Porgramming(XP). • Desarrollo iterativo e incremental: pequeñas ü Reduce el coste del cambio mejoras.manifiestoagile.XProgramming. sea ante inconvenientes que aceleren o respuesta a los problemas detallados anteriormente y se retrasen nuestro producto. Iconix.com http://www. • La colaboración con el cliente debe prevalecer sobre la negociación de contratos. • Es más importante crear un producto software que funcione que escribir documentación exhaustiva. permitiendo potencia aún más el desarrollo de software a gran escala. AUP entre otras. el retrasar las requisitos sobre la marcha son un aspecto natural. • Pruebas unitarias continuas. a menudo con restricciones no técnicas. Esta planificación a corto plazo nos permitirá tener Luego de varias opiniones tanto a favor como en contra de software disponible para nuestros clientes y además ir las metodologías tradicionales se genera un nuevo aprendiendo del feedback para hacer nuestra planificación enfoque denominado. Disponible en www. inversión que se toman. METODOLOGÍAS ÁGILES. EXTREME PROGRAMMING (XP) Como resultado de esta nueva teoría se crea un Manifiesto FIGURA 36. principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Entre los principales métodos ágiles tenemos el XP (eXtreme Programming). Retrasar las decisiones y Planificación Adaptativa Los defensores de XP consideran que los cambios de Es el eje en cual gira la metodología ágil. La programación competitiva y porque estar preparados para el cambio extrema se diferencia de las metodologías tradicionales significar reducir su coste. Cristal Methods. decisiones tan como sea posible de manera responsable inevitable e incluso deseable del desarrollo de proyectos. frecuentemente repetidas y automatizadas. Nos lo proponen porque Es la más destacada de los procesos ágiles de desarrollo de para muchos clientes esta flexibilidad será una ventaja software formulada por Kent Beck. A continuación se detalla el XP basa en dos aspectos puntuales. además hacer una planificación adaptativa criterios de oportunidad de negocio). Estas metodologías ponen de relevancia que la capacidad de respuesta a un cambio es más importante que el seguimiento estricto de un plan. métodos ágiles. las principales una aproximación mejor y más realista que intentar definir ventajas de retrasar las decisiones son: todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los ü Reduce el número de decisiones de alta requisitos.com 5 . consiste en tomar decisiones a lo largo del proyecto. incluyendo pruebas de 5 6 Pires. • La capacidad de respuesta ante un cambio es más importante que el seguimiento estricto de un plan. Creen que ser capaz de adaptarse a los cambios de lo cual permite siempre mantener una satisfacción en el requisitos en cualquier punto de la vida del proyecto es cliente y por ende el éxito del producto. será ventajoso tanto para el cliente como para la empresa.

Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo. es decir. significa reducir su coste. del software basado en el Proceso Unificado Rational • Simplicidad en el código: es la mejor manera de de IBM (RUP). Con más comunicación resulta más fácil • Entorno identificar qué se debe y qué no se debe hacer. menos tendrá que comunicar SCRUM sobre este. FIGURA 5. conocen las fechas de entrega de funcionalidades. Las frecuentes pruebas de regresión garantizan El AUP es un acercamiento aerodinámico a desarrollo que los posibles errores serán detectados. Mientras más simple es el sistema. especialmente si se puede reducir el equipo de ESQUEMA DE TRABAJO SCRUM programadores. regresión. La proyectos grandes es serial mientras que en los programación extrema apuesta que en más pequeños es iterativo. • Despliegue • Administración de la configuración La simplicidad y la comunicación son extraordinariamente • Administración o gerencia del Proyecto complementarias.es más importante que la posible pérdida alto nivel basado en la experiencia. El ciclo de vida en podrá añadir funcionalidad si es necesario. trabaje junto al equipo de desarrollo. de productividad inmediata. • Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos. Se supone que la cliente mayor calidad del código escrito de esta manera - el código es revisado y discutido mientras se Para mitigar esta desventaja se plantea definir un alcance a escribe. Se aconseja escribir el código de la • La presión esta a lo largo de todo el proyecto prueba antes de la codificación. y no en una entrega final • Programación por parejas: se recomienda que Desventajas las tareas de desarrollo se lleven a cabo por dos • Delimitar el alcance del proyecto con nuestro personas en un mismo puesto. este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Se recomienda que un representante del cliente FIGURA 4. • Planificación más transparente para nuestros clientes. Vital para su negocio • Permitirá definir en cada iteración cuales son los objetivos de la siguiente • Permite tener realimentación de los usuarios muy útil. lo que lleva a una comunicación más completa. Hacer entregas frecuentes. ESQUEMA DE TRABAJO AUP • Corrección de todos los errores antes de añadir nueva funcionalidad. 6 . Cuando todo funcione se incrementales con el tiempo. Las disciplinas de Aup son: sencillo hacer algo simple y tener un poco de • Modelado trabajo extra para cambiarlo si se requiere. • Refactorización del código. basado en disciplinas y entregables que las cosas funcionen. • Frecuente interacción del equipo de AUP (AGIL UNIFIED PROCESS) programación con el cliente o usuario. reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. que • Implementación realizar algo complicado y quizás nunca • Prueba utilizarlo. Ventajas • Apropiado para entornos volátiles • Estar preparados para el cambio.

Scrum es un proceso ágil y liviano que sirve para FIGURA 6. adaptación. los desarrolladores encuentran un ámbito cambios durante el proyecto Impuestas externamente Impuestas internamente (por el propicio para desarrollar sus capacidades profesionales y equipo) esto resulta en un incremento en la motivación de los Proceso mucho más controlado. Este proceso La arquitectura del software es Menos énfasis en la arquitectura también hace uso aerodinámico del UML mientras guarda esencial y se del software expresa mediante modelos un enfoque afilado en el seguimiento de requisitos. Está diseñado especialmente para adaptarse a los cambios en los requerimientos. 1. distribuidos integrantes) y trabajando en el También es relativamente pequeño y firme. Scrum se focaliza en priorizar el trabajo en función del valor que tenga para el negocio. Proceso menos controlado. y productivos posible. qué no y en qué orden) y en remover cualquier enfoque es flexible y abierto. auto-gestión e innovación. específico y casos de uso fácilmente realmente resuelva las necesidades. Cada ciclo o iteración termina con una pieza de software ejecutable que incorpora nueva funcionalidad. Existe un contrato prefijado No existe contrato tradicional o al menos es bastante flexible 7 . maximizando la utilidad de lo que se construye y el retorno de inversión. El construir. Por el otro lado. esto produce un necesidades del cliente. el proceso se queda igual a la visión original de tiempo real el producto que se está construyendo a las Jacobson del manejo de casos de uso. por ejemplo en un mercado de alta competitividad. administrar y controlar el desarrollo de software. Se busca entregar software que resultado concreto. con integrantes del equipo. Los requerimientos y las prioridades se revisan y ajustan durante el proyecto en intervalos muy cortos y regulares. El cliente interactúa con el El cliente es parte del equipo de equipo de desarrollo mediante desarrollo ICONIX reuniones Más artefactos Pocos artefactos Más roles Pocos roles El proceso de ICONIX maneja casos de uso. El ESQUEMA DE TRABAJO ICONIX desarrollo se realiza en forma iterativa e incremental (una iteración es un ciclo corto de construcción repetitivo). De esta forma se puede adaptar en Y. entorno de desarrollo producción de código Cierta resistencia a los cambios Especialmente preparados para Por otro lado. La Figura 6 muestra el cuadro del proceso. la gestión software. Las iteraciones en general tienen una duración entre 2 y 4 semanas. El diagrama retrata la En Scrum. Diferencias: Scrum tiene un conjunto de reglas muy pequeño y muy TABLA 1. que un equipo de un proyecto puede usar para satisfacción del cliente. aumentando la entendible. siempre se puede seleccionar obstáculo que pudiera entorpecer la tarea del equipo de de los otros aspectos del UML para complementar los desarrollo. como XP. Se busca que los equipos sean lo más efectivos materiales básicos. Scrum se utiliza como marco para otras prácticas de ingeniería de software como RUP o Extreme Programming. el equipo se focaliza en una única cosa: esencia del enfoque aerodinámico al desarrollo del construir software de calidad. pero le falta mucho para llegar al nivel del RUP. pero mismo sitio no desecha el análisis y diseño que hace XP. DIFERENCIAS ENTRE METODOLOGÍA TRADICIONALES Y ÁGILES simple y está basado en los principios de inspección continua. El cliente Metodologías Metodologías Agiles se entusiasma y se compromete con el proyecto dado que Tradicionales ve crecer el producto iteración a iteración y encuentra las Basadas en normas provenientes Basadas en heurísticas herramientas para alinear el desarrollo con los objetivos de de estándares seguidos por el provenientes de prácticas de negocio de su empresa. conducir el esfuerzo hacia un desarrollo real. con numerosas políticas/normas pocos principios. que incluye un juego mínimo de diagramas de de un proyecto Scrum se focaliza en definir cuales son las UML y algunas valiosas técnicas que se toman de los características que debe tener el producto a construir (qué casos del uso para codificar rápida y eficazmente. como el Grupos grandes y posiblemente Grupos pequeños (<10 RUP.

altamente motivados y con Ø Por las características del Proyecto gran innovación Modelo Tamaño Tamaño Complejidad de del del del Problema • Las metodologías ágiles permiten disminuir costos y Proceso Proceso Equipo brindar flexibilidad a los proyectos de software donde RUP Medio / Medio / Medio / Alto la incertidumbre está presente Extenso Extenso • El uso de metodologías tradicionales es esencial al ICONIX Pequeño / Pequeño / Pequeño / Medio inicio en un equipo de desarrollo de software Medio Medio • Las metodologías ágiles se deberían aplicar en XP Pequeño / Pequeño Medio / Alto proyectos donde exista mucha incertidumbre donde el Medio entorno es volátil. ya que la experiencia Además presentamos un cuadro de comparación por cada es la que predomina en los mementos cruciales del aspecto analizado y lo ponemos a consideración: proyecto. vemos que los Extensible + Documentación modelos + Mínima + modelos ágiles. que se incorporen de complejidad. es el caso de XP y SCRUM. • ¿Alguna recomendación para los lectores de este analizamos el tamaño del proceso. Segundo. además debe tener la capacidad de ser equipos auto-gestionados. del equipo y la Artículo? complejidad del problema para cada uno de los modelos. de alta ingeniería de software. lleno métodos de calidad en sus procesos y que la forma más eficiente y efectiva de hacer las cosas. Desarrollo Codificación Transferencia de individual con conocimiento: facilitando aplicar con mayor efectividad esta Roles y Programación en metodología. Podemos resaltar que: con un pequeño equipo de Primero. • El retrasar las decisiones en un proyecto de software control]: Orientado Colaboración: a los hitos + empoderamiento permite potenciar el valor del producto tanto para el Puesta en cliente como al equipo o empresa que desarrolla Gestión Producción +auto-organización miniproyectos • Para que un grupo de desarrollo adopte una metodología ágil debe poseer experiencia trabajando con metodologías tradicionales. de aprendizaje de integración Externo DIFERENCIAS POR ETAPAS Y ENFOQUE METODOLOGICO Proceso RUP Lenta Alto Soporte Alto MODELOS ETAPA MODELOS Soporte RIGUROSOS AGILES ICONIX Rápida Algún Soporte Algún Disponible Soporte Análisis de Disponible requerimientos Planificación XP Rápida No mencionado Algún Planificación adpatativa:Entregas predictiva y frecuentes + Soporte “aislada” colaboración del Disponible cliente SCRUM Rápida No mencionado Algún Soporte Planificación Disponible Diseño flexible y Diseño Diseño Simple: Con respecto a la curva de aprendizaje. Modelo Curva de Herramienta Soporte TABLA 2. donde los requisitos no se conocen SCRUM Pequeño / Pequeño Medio / Alto con exactitud. que conozcan y apliquen las técnicas de desarrollo se puede realizar grandes proyectos. mientras que las metodologías Medio tradicionales obligan al cliente a tomar las decisiones al inicio del proyecto.Ofrecemos una comparativa entre cada uno de las etapas más comunes del desarrollo de SW y los enfoques de Ø Por la curva de Aprendizaje metodologías revisados. En este cuadro se presenta una comparativa de las modelos REFLEXIÓN de proceso en cuanto a las características del proyecto. es hacerlas bien a la primera vez y con ello daremos un 8 . ya que aun no hay sido explotadas a exhaustiva comunicación gran escala como lo es RUP que posee alto soporte y herramientas integrales que nos guían a través del mismo. nos ofrecen una mayor ventaja pero con Documentación Focalizado en la ciertas limitaciones. permitiendo aprovecharla al máximo responsabilidades pares + estrictas conocimiento colectivo CONCLUSIONES Actividades de Pruebas Liderazgo.

con su valor intacto. debemos reconocer que estamos hechos de personas.gran giro a la industria del software. puede venderla y recuperar su inversión. Como industria. Por último.com/articles/article.com [ 3 ] ICONIX (En línea). el dueño de una fábrica de software.spinec. que entiendan la importancia de la gente. Disponible en: www. Lo único que tiene son escritorios y unas máquinas depreciadas.org/wp-content/ICONIX. BIBLIOGRAFÍA [ 1 ] Metodologías Ágiles: La ventaja competitiva de estar preparado para tomar decisiones lo más tarde posible y cambiarlas en cualquier momento.asp?p=1 67902&rl=1 9 . Así que debemos tenerlas bien “aceitadas” (a través de capacitación y motivación) para obtener su máximo rendimiento.informit.org/wp- content/metodologiasagiles_01.pdf [ 4 ] Extreme Programming Refactored: The Case Against XP.spinec. Con este fin voy a hacer una última analogía: el dueño de una fábrica de coches sale a las 6 de la tarde. está descapitalizado. (En línea). Disponible en: www.pdf [ 2 ] Metodologías ágiles (En línea) . y que éstas son nuestro principal activo. y ahí tiene su fábrica. Disponible en: http://www. En cambio. Disponible en Formato chm [ 5 ] Introducción a Iconix (En línea). MATT Stephens and DOUG Rosenberg. a las 8 de la noche que sus empleados ya se fueron a su casa.Disponible en: http://www.agile-spain.