Comparación de los riesgos: metodologías ágiles vs.

una metodologías tradicionales

Metodologías ágiles:
En las metodologías ágiles se defiende que el código es el único entregable que
realmente importa, y se deja de lado el análisis y diseño en la creación de software. Los
métodos ágiles son criticados por ser poco sistemáticos y documentados; los críticos de
las metodologías ágiles argumentan que “el énfasis en el código puede conducir a la
pérdida de la memoria corporativa o conocimiento organizacional, porque hay poca
documentación y modelos para apoyar la creación y evolución de sistemas complejos”.
(Bozo J., Crawford B., 2003)
Las metodologías ágiles funcionan bien para proyectos donde los equipos de
desarrollo son pequeños, sería riesgoso utilizarlas en un proyecto en los que se cuenta con
un equipo de trabajo muy grande; ya que con equipos grandes, el número de revisiones
puede reducir su eficacia.
También es riesgoso utilizar metodologías ágiles en proyectos grandes y complejos;
esto porque al dejar el lado el análisis y diseño, se podrían dejar pasar aspectos
importantes, y puede haber aspectos de la arquitectura que son difíciles de cambiar; por
lo que el costo de cambio puede ser muy elevado.
Las metodologías ágiles no son recomendadas cuando el equipo de trabajo se
encuentra físicamente disperso, cuando los clientes y desarrolladores no pueden tener
reuniones personales; ya que se pueden malinterpretar los requerimientos, y por tanto la
implementación no será correcta.
En este tipo de metodologías el cliente se integra como parte del equipo, lo que
podría ser un riesgo; porque podría estar cambiando los requerimientos constantemente,
y se puede generar ambigüedad en lo que hay que hacer; pero de acuerdo con el
“manifiesto ágil” la prioridad es satisfacer al cliente y se debe dar la bienvenida a los
cambios.
Las metodologías ágiles no privilegian la reutilización de componentes y software,
debido a que se encuentran enfocados en software que soluciona un problema en
específico, entonces generalmente el producto de software obtenido no se puede utilizar
para la resolución de problemas generalizados.
Para la implementación de una metodología ágil, siempre se debe conocer a
profundidad la metodología y se debe implementar de una manera paulatina, que no
represente un cambio abrupto en la forma de trabajo para que sea bien recibida por el
equipo.
Al priorizar el desarrollo estas metodologías muchas veces olvidan la
documentación y cuando la aplicación está lista la generación de manuales técnicos y de
usuario puede convertirse en un gran problema.
Como ejemplo podemos mencionar Extreme Programming(XP), metodología que se
enfoca en el código y sus pruebas, trata de generar pequeñas características pero que
sean probadas conforme se desarrollan, tiene como requisito que el cliente forme parte
del equipo de trabajo y que los cambios que este decida se realicen automáticamente. XP
considera que la forma natural de un proyecto es cambiante y que se debe mantener de
esta forma por lo que la interacción con el cliente es indispensable y la apertura a cambios
debe ser lo más importante.
La metodología Extreme Programming se vuelve riesgosa cuando:
-El cliente no cuenta con disponibilidad o interés real.
-El equipo de trabajo no está preparado para entender las tareas.
-Las pruebas unitarias de una funcionalidad tardan en extremo.
-Los interesados denotan mucha importancia en la documentación del
proyecto.
-Al depender de pequeñas funcionalidades que conforman el proyecto si
alguna de las funcionalidades falla y es de importancia para otras el
proyecto puede fracasar.
-El equipo de trabajo es muy grande, si hay mala comunicación las
funcionalidades o cambios podrían no ser compatibles con lo desarrollado
previamente.

Metodología Scrum:
Otra metodología que podemos mencionar dentro de las metodologías ágiles es la
metodología SCRUM, la cual define de manera ágil y flexible cómo abordar un proceso que
implica el desarrollo de software, de forma tal que se pueden abordar proyectos que son
complejos y de naturaleza dinámica y cambiante, esta metodología se basa en entregas
parciales y de forma regular del producto final con el objetivo de dar valor a lo que se le ha
ofrecido al cliente.
La base primordial con la que esta tecnología trabaja es la división de
trabajo(ProductBacklog), se trabajan diferentes partes distribuidas en períodos cortos de
tiempo que son comúnmente llamados Sprints.
Ventajas:
● Se cumple las expectativas de los clientes debido a que ellos se involucran en cada
una de las iteraciones.
● Existe una mayor flexibilidad y adaptación en caso de que surjan cambios.
● Se obtienen resultados con anticipación, el cliente no necesita esperar hasta que el
producto esté finalizado para empezar a usar funcionalidades del proyecto.
● Los riesgos se manejan de manera inmediata gracias a la pronta intervención del
equipo de trabajo.
● Se obtiene una mayor calidad de software.
Desventajas:
● Su funcionalidad se limita a equipos reducidos de trabajo, la metodología pierde
efectividad , en una empresa grande se debe sectorizar con objetivos concretos.
● Se debe realizar una definición íntegra de las labores y los tiempos que se quieren
cumplir de lo contrario SCRUM se disipa.
● Demanda una alta formación, no es una metodología apta para grupos que no
cuenten con la suficiente preparación y experiencia.
● Se requiere un compromiso total por parte de cada uno de los miembros del equipo
de trabajo.
● Se complica retomar un proyecto después de que alguno de los miembros
abandona al equipo.

Metodologías tradicionales:
Las metodologías tradicionales se definen de la siguiente manera, “se caracterizan
por exponer procesos basados en planeación exhaustiva. Esta planeación se realiza
esperando que el resultado de cada proceso sea determinístico y predecible. La experiencia
ha mostrado que, como consecuencia de las características del software, los resultados de
los procesos no son siempre predecibles” (Hugo F. Arboleda Jiménez. MSc.)

La disciplina de trabajo respecto a las metodologías tradicionales es más de trabajo

sobre el desarrollo del software con tal de conseguir el más eficiente; centrándose más en
el proceso de definición de herramientas, roles, actividades y documentación, tomando en
cuenta la buena relación con el cliente y la confianza en las habilidades del equipo.

Las responsabilidades en las metodologías tradicionales las delega el cliente a cada

uno de los integrantes del equipo siendo este de gran extensión.

Algunas metodologías tradicionales son MSF, RUP y espiral. Esta última

metodología es sobre la cual vamos a desarrollar su funcionamiento y características.

Metodología Espiral:
La metodología Espiral consiste en un modelo que propicia el desarrollo iterativo de
software. En el mismo , se utiliza una línea secuencial que permite fijar el punto de
culminación de una iteración como un punto de nuevo inicio, validando en cada una de
estas los riesgos del proyecto. Para Fariño, este proceso comprende 4 pasos principales,
los cuales se definen a continuación:
● Determinar o fijar objetivos: Permite conocer limitaciones, riesgos y diseño de la
gestión del proyecto.
● Análisis de riesgo: Análisis, planificación y respuestas a los riesgos que puedan
tenerse durante el desarrollo del producto.
● Desarrollar, verificar y validar: Elección del paradigma de desarrollo.
● Planificar: Se toma la decisión de si es necesario iterar en la espiral, de la iteración.
(Fariño, 2011)
La principal característica de esta metodología de desarrollo es la gestión de riesgos y
dentro de las principales áreas que comprende se encuentran:
● Comunicación con el cliente.
● Planificación.
● Gestión del riesgo.
 ● Ingeniería.
● Construcción y Adaptación, es decir se realiza el producto y se le brinda
colaboración al usuario para asegurarse de que cumpla su función.
● Retroalimentación y evaluación por parte de los clientes y/o usuarios.
Ventajas:
● Menor probabilidad de riesgos que interrumpan o afecten en gran medida las
iteraciones.
● Muy adaptable a la evolución de la tecnología.
● No es necesaria la definición total de requerimientos para su inicio.
● Se considera una metodología muy realista al adaptarse a las fases del ciclo de
desarrollo software incorporando ciclos iterativos.
Desventajas:
● La evaluación de riesgos tiende a ser difícil.
● El cliente debe participar continua y activamente.
● Requiere de tiempo al mejorar el sistema cuando el software debe evolucionar.

TABLA COMPARATIVA METODOLOGÍAS TRADICIONALES vs METODOLOGÍAS ÁGILES

TRADICIONALES ÁGILES

Tiene cierta resistencia a los cambios en el Es más abierta a que se presenten cambios
desarrollo del proyecto. a lo largo del proyecto.

Más control del proceso, ya que tiene gran Tiene menos políticas lo que hace que sea
cantidad de políticas y normas. un proceso menos controlado.

Se definen varios roles de trabajo. No hay definición de muchos roles.

Se trabaja en grupos grandes. Los grupos de trabajo son más pequeños.

Trabaja con gran cantidad de La documentación en esta metodología es

documentación. muy poca.

Es limitado de ciclos. Hay muchos ciclos presentes.

La planificación por adelantado de la Hay muy poca planificación por

metodología es exhaustiva. adelantado.

Se trabaja bajo un contrato prefijado. El contrato es más flexible que el del

tradicional.

Su utilización en la actualidad ha Ha crecido la utilización de esta

disminuido. metodología.

TABLA COMPARATIVA DE ESPIRAL vs SCRUM

ESPIRAL SCRUM

Mejora a los ciclos de vida clásicos y de Ciclo de vida iterativo e incremental que
prototipos. finaliza con un prototipo operativo.

Puede combinarse con otros modelos de puede combinarse con otras metodologías
desarrollo como el cascada o el evolutivo. como PRINCE2 Y CMMI.

En cada giro se construye un modelo del Optimiza el plan de entregas y actualiza las
sistema completo. prioridades en colaboración con el cliente.

Incorpora objetivos de calidad y gestión de Optimiza procesos teniendo una

riesgos. retrospectiva después de cada iteración.

Elimina errores y opciones no favorables al Se detectan los problemas que signifiquen

comienzo del modelo. un atraso durante el análisis que realiza el
equipo de trabajo, eliminando obstáculos.

Permite iteraciones en cada vuelta. Divide el tiempo en iteraciones cortas de

longitud fija.
 Cada ciclo identifica objetivos, alternativas El ciclo de trabajo se repetirá hasta la
y restricciones. culminación del proyecto.

Divide la organización en equipos

pequeños de trabajo.

Bibliografía:
Bozo J., Crawford B. (2003). Métodos Ágiles como Alternativa al Proceso de Desarrollo
Web. Recuperado el 30 de marzo del 2017, de Escuela de Ingeniería Informática Pontificia
Universidad Católica de Valparaíso. Sitio web:
http://sedici.unlp.edu.ar/bitstream/handle/10915/22775/Documento_completo.pdf?seq
uence=1
Calderón A., Valverde S., Rebaza J. (2007). Metodologías Ágiles. Recuperado el 30 de
marzo del 2017, de Universidad Nacional de Trujillo. Sitio web:
https://uvirtual.unet.edu.ve/pluginfile.php/268695/mod_resource/content/1/Metodologi
as%20Agiles.pdf
Don Wells, (1999). Extreme Programming: A gentle introduction. Recuperado el 30 de
marzo de 2017, de XP sitio web: http://www.extremeprogramming.org/
EcuRed. (s.f). Modelo Espiral. Recuperado el 30 de marzo del 2017. Sitio web:
https://www.ecured.cu/Modelo_Espiral
Fariño, K. (2011). Modelo Espiral de un proyecto de desarrollo de software Administración
y Evaluación de Proyectos . Recuperado el 30 de marzo del 2017. Sitio web:
http://www.ojovisual.net/galofarino/modeloespiral.pdf

n.(2017). Metodologías Tradicionales o Ágiles. Qué metodología usar en mi proyecto.

Recuperado el 31 de Marzo del 2017. MDAP. Sitio web: http://www.uv-
mdap.com/blog/metodologias-tradicionales-o-agiles-que-metodologia-usar-en-un-
proyecto/

Ticona Condori Shirley Fabiola. Metodologías tradicionales, metodologías ágiles,

metodologías para juegos, metodologías educativas y metodologías para aplicaciones
móviles. Sitio web:
https://tallerinf281.wikispaces.com/file/view/METODOLOG%C3%8DAS+TRADICIONALES.p
df
Karol. (2009 ). Modelo Espiral. Jan 28, 2009 , de scribd Sitio web:
https://es.scribd.com/doc/11468208/Modelo-Espiral

“Usos y limitaciones de la tecnología SCRUM”, Harvard Deusto Business Review y EAE

Business School.(2017), recuperado de sitio web:
http://retos-directivos.eae.es/usos-y-limitaciones-de-la-metodologia-scrum/

“Descubre la metodología SRUM”, Desarrollo de software marketing online, (2016),

recuperado de sitio web:
http://alfatecsistemas.es/descubre-la-metodologia-scrum/

Kniberg, H. (2010). Kanan y Scrum. Obteniendo lo mejor de ambos. C4Media Inc. Estados
Unidos. Recuperado de:
http://www.proyectalis.com/documentos/KanbanVsScrum_Castellano_FINAL-printed.pdf