See

discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/317840767

Análisis comparativo de las metodologías ágiles

en el desarrollo de software aplicadas en
Colombia

Article · October 2016

CITATIONS READS

0 258

3 authors, including:

Lina Maria Montoya Suarez Jorge MAURICIO Sepulveda Castaño

Universidad Católica Luis Amigó Corporación Universitaria Remington
14 PUBLICATIONS 1 CITATION 11 PUBLICATIONS 1 CITATION

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Ingeniería de Software View project

All content following this page was uploaded by Lina Maria Montoya Suarez on 23 June 2017.

The user has requested enhancement of the downloaded file.

_________________________________________________________________________
Lina Maria Montoya Suarez, Jorge Mauricio Sepúlveda Castaño, Luisa María
Jiménez Ramos
Corporación Universitaria Remington
Colombia

Ingeniera de Sistemas, Especialista en Ingeniería de

Software, Máster en Ingeniería de Software. Docente de Corporación
Universitaria Remington

Correspondencia: linam.montoya@uniremington.edu.co.

Ingeniero de Sistemas, Especialista en en Redes

Corporativas e Integración de Tecnologías, Estudiante de Maestría en en Ingeniería Línea
Teleinformática, Decano de Corporación Universitaria Remington
Correspondencia: jsepulveda@uniremington.edu.co

Ingeniera Informática, Especialista en Gerencia

Informática de la Corporación Universitaria Remington. Estudiante de Maestría en
Administración de Tecnologías de la Información del Instituto Tecnológico de Monterrey -
Tec de Monterrey, Ingeniera Docente de Tiempo completo de Corporación
Universitaria Remington
Correspondencia: luisa.jimenez@uniremington.edu.co

450 | P á g i n a
 Este presente artículo es de gran utilidad para el desarrollo del estudio previo porque
evidencia la importancia de tomar las mejores prácticas en cuanto a las metodologías ágiles
para facilitar el proceso en el desarrollo de proyectos, en este caso proyectos de Ingeniería
de software. Las Metodologías de desarrollo ágil permiten mejores resultados, es el trascurso
del ciclo de vida para el mejoramiento continuo en el desarrollo del producto basado en el
aprendizaje, innovación y cambios continuamente con el fin de mejorar la calidad, la
fiabilidad, y la seguridad del software.
En este artículo pretende evidenciar un estudio de las metodologías más utilizada en el
desarrollo de software mostrando las características, diferencias y un breve resumen.
: Metodología agiles de desarrollo, Ingeniería de Software, manifiesto
ágil de software, metodología agile en Colombia

This present article is useful for the development of the previous study because it
demonstrates the importance of taking the best practices in agile methodologies to facilitate
the process in project development, in this case software engineering projects. The agile
development methodologies allow better results, it is the course of the life cycle for
continuous improvement in product development based on learning, innovation and
continuous changes in order to improve the quality, reliability, and security software.
This article aims to show a survey of the most widely used software development showing
the characteristics, differences and some brief summary methodologies.
agile development methodology, software engineering, software Agile
Manifesto, agile methodology in Colombia

El desarrollo de software es un proceso riesgoso y difícil de controlar, y más si no se lleva

una metodología para esta actividad, el resultado que se va a obtener son clientes
insatisfechos, mala calidad del producto, exceso de tiempo y mal uso del presupuesto. Las
metodologías de desarrollo ágil evolucionaron a partir de los modelos tradicionales del ciclo

tipo de metodologías es dar mejores resultados en los productos de desarrollo. Estas

metodologías se enfocan en construir software que se pueda usar rápidamente, en lugar de
pasarse mucho tiempo al principio escribiendo todo tipo de especificaciones. El desarrollo
ágil se centra en equipos multifuncionales con capacidad para decidir por ellos mismos, en
vez de grandes jerarquías y divisiones por funcionalidad, y se caracteriza por iteraciones
rápidas, gran comunicación con el cliente dando su opinión continuamente.

451 | P á g i n a
 Los primeros desarrollos de software se hicieron de manera artesanal. Con la llegada y el
conocimiento de tecnología, nuevos modelos, métodos, metodologías, herramientas, etc
(Fowler & Highsmith, 2001), se inició un proceso de mejoramiento en la planeación y
seguimiento a los procesos de desarrollo de software. Hoy día toma especial importancia e
interés la utilización de Metodologías ágiles de desarrollo de software, por varias ventajas
que presentan en su desarrollo rápido, logrando la adaptabilidad y flexibilidad en los cambios
a los que están expuesto los proyectos de software actuales.
Las metodologías ágiles constituyen un conjunto de buenas prácticas para el desarrollo
de software, buscando construir soluciones de forma rápida y en el menor tiempo posible.
Por lo general las metodologías ágiles son iterativas e incrementales, son flexibles a los
cambios de último momento, lo cual las hacen adaptativas, presentando alta comunicación
entre el cliente y el desarrollador (Beck, 2000).
El objetivo principal de este trabajo de investigación es realizar un análisis sobre las
principales metodologías ágiles más usadas y conocer cuál o cuáles son los métodos de
programación ágil más destacados en el medio, así mismo la calidad del software resultante,
la satisfacción del cliente y sus puntos débiles.
Este manuscrito de investigación se estructura de la siguiente manera: En el capítulo 2 se
presentan el referente teórico haciendo una revisión exhaustiva de las metodologías agiles en
el desarrollo de Software. En el capítulo 3 análisis de los hallazgos sobre la revisión de la
literatura. Finalmente se presentan las conclusiones relacionadas con el ejercicio de búsqueda
realizada.
Referente teórico
Contextualización de modelo ágil de desarrollo software
Hoy por hoy las metodologías ágiles de desarrollo son sin duda uno de los temas de auge
en ingeniería del software que ha generado gran interés y controversia en las industria de
software, en los años 90 comenzó a impregnarse una definición moderna de desarrollo ágil
del software como una reacción contra las metodologías utilizadas hasta el momento, estas
metodologías fueron consideradas excesivamente pesadas, rígidas por su carácter normativo
y fuerte dependencia de planificaciones detalladas previas al desarrollo (Rodriguez
Gonzalez, 2008).
En el año 2001 diecisiete miembros y profesionales en el área de Ingenierías, incluyendo
algunos de los creadores o impulsores de las metodologías en software, se reunieron en Utah

nueva corriente de desarrollo, tiempo después, algunos de estos miembros formaron la

(Rodriguez Gonzalez, 2008), una organización sin ánimo de
lucro que promueve el desarrollo de Software ágil donde definieron unos 12 principios En la
socialización se afirmó que en la labor de desarrollar software debía valorarse mediante unos
postulados (Gimson Saravia, 2012) :
A los individuos y su interacción, por encima de los procesos y las
herramientas.
El software que funciona, por encima de la documentación exhaustiva.
La colaboración con el cliente, por encima de la negociación contractual.
452 | P á g i n a
 La respuesta al cambio, por encima del seguimiento de un plan.

Los cuatros postulados mencionados, inspiraron los doce principios del Manifiesto Ágil
que son características que diferencian un proceso ágil de uno tradicional que se describen a
continuación (Fowler & Highsmith, 2001, Beck et al., 2001).
1) La prioridad es satisfacer al cliente mediante entregas de software tempranas y
continuas;
2) Los cambios en los requerimientos son aceptados;
3) software que funcione se entrega frecuentemente, con el menor intervalo posible entre
entregas;
4) El cliente y los desarrolladores deben trabajar juntos a lo largo del proyecto;
5) El proyecto se construye en base a individuos motivados;
6) El dialogo cara a cara es el método más eficiente y efectivo para comunicar
información dentro del equipo;
7) El software que funcione es la medida principal del progreso;
8) Los procesos ágiles promueven el desarrollo sostenido;
9) La atención continua a la excelencia técnica y al buen diseño mejora la agilidad;
10) La simplicidad es esencial;
11) Las mejores arquitecturas, requerimientos y diseños surgen de equipos
autoorganizados, y
12) El equipo reflexiona en cómo ser más efectivos, y ajusta su comportamiento en
consecuencia.

mientos, técnicas, herramientas y

documentos auxiliares que ayudan a los desarrolladores de software en sus esfuerzos por
implementar nuevos sistemas de información. Una metodología está formada por fases, cada
una de las cuales se puede dividir en sub-fases, que guiarán a los desarrolladores de sistemas
a elegir las técnicas más apropiadas en cada momento del proyecto y también a planificarlo,
(Balaguera, 2015).
Diferencias entre metodologías ágiles y no ágiles
Metodologías Ágiles Metodologías Tradicionales
Basadas en heurísticas provenientes de Basadas en normas provenientes de estándares
prácticas de producción de código seguidos por el entorno de desarrollo
Especialmente preparados para cambios Cierta resistencia a los cambios
durante el proyecto
Impuestas internamente (por el equipo) Impuestas externamente
Proceso menos controlado, con pocos Proceso mucho más controlado, con numerosas
principios políticas/normas
No existe contrato tradicional o al menos es Existe un contrato prefijado
bastante flexible
El cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de desarrollo
mediante reuniones

453 | P á g i n a
 Metodologías Ágiles Metodologías Tradicionales
Grupos pequeños (<10 integrantes) y Grupos grandes y posiblemente distribuidos
trabajando en el mismo sitio
Pocos artefactos Más artefactos
Pocos roles Más roles
Menos énfasis en la arquitectura del software La arquitectura del software es esencial y se expresa
mediante modelos
Tabla 1: Diferencias entre metodologías ágiles y no ágiles (Beck et al., 2001)
Proceso de la metodología ágiles y metodología tradicional.

Figura 1. Proceso de la metodología ágiles y metodología tradicional.

Metodologías agiles más usadas
1. Programación extrema (extreme programming, XP)
Es una metodología ágil centrada en potenciar las relaciones interpersonales dentro del
equipo de trabajo, tiene como clave para lograr el éxito, el trabajo en equipo, preocupándose
por el aprendizaje de los desarrolladores, y propiciando un buen clima y se basa en lo
siguiente (Beck, 2000, Echeverry Tobón & Delgado Carmona, 2007):
XP es implementado adecuadamente para proyectos con requisitos imprecisos
y requisitos muy cambiantes, y donde puede existir un alto riesgo en la parte técnica.
XP tiene como principio la realimentación continua entre el cliente y el equipo
de desarrollo, partiendo de una comunicación fluida entre todos los participantes, manejo
de simplicidad en las soluciones implementadas y coraje para enfrentar los cambios.
XP trabaja y estructura una serie de valores y principios que deben tenerse en
cuenta y practicarlos durante el tiempo de desarrollo que dure el proyecto.
XP se considera una disciplina, la cual está sostenida por valores y principios
propios de las metodologías.
Valores

454 | P á g i n a
 Existen cuatro valores que cumplen su papel como pilares en el desarrollo de software
(Beck, 2000, Echeverry Tobón & Delgado Carmona, 2007, Letelier, 2006):
1. La comunicación. Se fundamenta en un ambiente de colaboración y
comunicación al interior del equipo de desarrollo, así como en la interacción de éste con
el cliente, la interacción con el cliente es tan estrecha, que es considerado parte del equipo
de desarrollo.
2. La simplicidad. Este valor se aplica en todos los aspectos. Desde diseños muy
sencillos donde lo más relevante es la funcionalidad necesaria que requiere el cliente,
hasta la simplificación del código mediante la refactorización del mismo, en la
metodología no utiliza sus recursos para la realización de actividades complejas, sólo se
desarrolla lo que el cliente demanda, de la forma más sencilla.
3. La retroalimentación. Se presenta desde el comienzo del proyecto, ayuda a
encaminarlo y darle forma. Ésta se presenta en los dos sentidos, por parte del equipo de
trabajo hacia el cliente, con el fin de brindarle información sobre la evolución del sistema,
y desde el cliente hacia el equipo en los aportes a la construcción del proyecto.
4. El coraje. El equipo de desarrollo se debe de preparar para enfrentarse a los
continuos cambios que se presentarán en el transcurso de las actividades plateadas. Cada
integrante debe tener el valor de exponer los problemas o dudas que halle en la realización
del proyecto. Aún con estas variaciones, las jornadas de trabajo deben proporcionar el
máximo rendimiento.

Proceso
XP inicia con una o varias reuniones con el cliente, en las cuales se da claridad a la
necesidad puntual del mismo a través de las historias de usuario, donde se tiene presente
(Beck, 2000, Rodriguez Gonzalez, 2008, Echeverry Tobón & Delgado Carmona, 2007,
Letelier, 2006):

Reuniones continuas y comunicación efectiva.

Los requisitos pueden (y van a) cambiar.
Prioridades en los requisitos.
Grupo pequeño y muy integrado (máximo 12 personas).
Equipo con formación elevada y capacidad de aprender.
Metodología basada en prueba y error.
La fundamentación de los Valores y Prácticas.
El equipo de trabajo tiene ideas generales de la aplicación a implementar.

Concluida el proceso ó etapa, se debe acordar un plan de entregas con el cliente del cual
surge el número inicial de iteraciones y duración de las mismas en la que se da claridad las
tareas a desarrollar, basándose en el plan de entregas.

455 | P á g i n a
 La metodología consiste en un conjunto de estrategias para el desarrollo donde se
caracteriza por estar centrado en las personas que conforma el equipo de desarrollo y cliente
teniendo presente la disminución al máximo del número de artefactos producidos (Huijbers
et al., 2004).
Es considerada un juego cooperativo de invención y comunicación, limitado por los
recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir
esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo bien
definidos contemplando el tamaño del equipo, estableciéndose una clasificación por ejemplo
Crystal Clear de 3 a 8 miembros y Crystal Orange de 25 a 50 miembros (Canós, Letelier, &
Penadés, 2003).
Esta metodología tiene siete proceso y propiedades que se deben establecerse para cada
proyecto, sólo tres son obligatorios; los otros cuatro es mas de prevención y seguridad,
Crystal comparten con la metodología XP en cuanto a la orientación humana, pero esta
centralización en la gente se hace de una manera diferente(Cockburn, Highsmith, Johansen,
& Jones, 2001).
Los siete procesos o propiedades son (Huijbers et al., 2004):
1. Entrega frecuente: Se hace prueba del desarrollo que se definieron en las
etapas de entregas, los usuarios serán capaces de ofrecer información sobre los requisitos
implementados, el cliente verá el progreso y los desarrolladores.
2. Mejora continua: dar tiempo para que el equipo plantee dificultades y sobre
poner a los retos trazados para mejorar las cosas que no funcionan.
3. Comunicación: Tener todo el equipo tan juntos (si posible en la mismo puesto)
con el fin de dar respuestas a las inquietudes y dificultades al instante.
4. Seguridad Personal: La personas que conforman el equipo se sienta segura de
hablar sin temor a represalias, que pueden dar críticas constructivas sobre el trabajo de
otras personas y admitir sus propios errores, lo que lleva a la honestidad y en última
instancia a la confianza.
5. Enfoque: Si todo el equipo tiene tiempo para centrarse en sus objetivos
prioritarios para dos horas al día, durante dos días consecutivos cada semana, sin ningún
tipo de distracciones sin perder el norte (como reuniones o de otro trabajo), el equipo
estará más enfocado y el trabajo.
6. Fácil acceso a usuarios expertos: Si los usuarios expertos están disponibles
para el equipo, pueden responder preguntas y ofrecer retroalimentación sobre la calidad
y el diseño sobre las decisiones a tomar.
7. Medio Ambiente, técnica de prueba automatizada, gestión e Integración
frecuente: Un entorno técnico adecuado donde las tareas sea controlados por las pruebas
y gestión de la configuración (versión - como hacer copias de seguridad y la fusión de
los cambios).

Roles
Executive Sponsor (Patrocinador Ejecutivo)

456 | P á g i n a
 Project Manager (Jefe de Proyecto
Domain Expert (Experto en el Dominio)
Usage Expert (Experto de uso)
Designer-Programmer (Programador Diseñador)
UI Designer (UI Diseñador)
Tester (Realizador de Pruebas)
Technical (Programador Técnico)

Esta metodología se estructuro para desarrollar productos en Japón, no se trata de un

concepto nuevo, sino que ya en 1987 Ikujiro Nonaka y Hirotaka Takeuchi (1986) acuñaron
este término, una estrategia utilizada en rugby en la que todos los integrantes del equipo
actúan juntos para avanzar la pelota y ganar el partido, para denominar un nuevo tipo de
proceso de desarrollo de productos.
Escogieron dicho nombre por las similitudes que consideraban que existían entre el juego
del rugby y el tipo de proceso que proponían: adaptable, rápido, auto-organizable y con pocos
descansos (Takeuchi & Nonaka, 1986)
Esta metodología es un proceso para la gestión y control del producto que trata de
eliminar la complejidad en áreas específicas que atribuye a la construcción de software con
el fin de satisfacer las necesidades de las organizaciones.
Uno de sus principios es lograr la simplicidad y escalabilidad, ya que no establece
prácticas de ingeniería del software, sino que se aplica o combina, fácilmente, con otras
prácticas ingenieriles, metodologías de desarrollo o estándares ya existentes en la
organización. Se concentra, principalmente, a nivel de las personas y equipo de desarrollo
que construye el producto. Su objetivo es que los miembros del equipo trabajen juntos y de
forma eficiente obteniendo productos complejos y sofisticados.

457 | P á g i n a
 Metodología Scrum

Figura 2. Metodología SCRUM.

Fuente. http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-
scrum-y-xp.php
Se puede entender SCRUM como una forma de la ingeniería social que pretende
conseguir la satisfacción de todos los que participan en el desarrollo, fomentando la
cooperación a través de la auto-organización. De esta forma se favorece la franqueza entre el
equipo y la visibilidad del producto. Pretende que no haya problemas ocultos, asuntos u
obstáculos que puedan poner en peligro el proyecto. Los equipos se guían por su
conocimiento y experiencia más que por planes de proyecto formalmente definidos. La
planificación detallada se realiza sobre cortos espacios de tiempo lo que permite una
constante retroalimentación que proporciona inspecciones simples y un ciclo de vida
adaptable. Así, el desarrollo de productos se produce de forma incremental y con un control
empírico del proceso que permite la mejora continua (Schwaber & Beedle, 2002).

Es una técnica creada por To

producción. Se ha convertido en un sinónimo de la aplicación justo a tiempo (JIT), que está

diseñada para el control de inventario y reducir los tiempo .
Kanban tiene como objetivo principal gestionar de manera general como se van
completando las actividades. Aunque Kanban no fue creada para la gestión de proyectos de
software, en la actualidad se usa esta metodología dentro de esta área (Anderson, 2010).
Esta metodología de desarrollo recoge la experiencia del Kanban de Toyota y la lleva al
mundo del desarrollo tecnológico siendo su expresión más común un tablero dividido en
columnas que señalan los estados de un flujo de trabajo y tarjetas que van señalizando como
fluyen los requerimientos dentro de un equipo de software.
Se basa en las siguientes propiedades fundamentales (Kniberg, Skarin, de Mary
Poppendieck, & Anderson, 2010):

458 | P á g i n a
 Visualizar el flujo de trabajo
Limitar el trabajo en progreso
Medir y manejar el flujo de trabajo
Explicitar las políticas del proceso
Usar modelos para mejorar oportunidades de mejora

Metodología Kanban

Figura 3. Tablero Kanban

Fuente: http://www.pmoinformatica.com/2014/03/sistema-kanban-desarrollo-de-
software.html
Según Pérez algunas características claves que hacen destacar a Kanban son (Pérez,
2016):
Requiere poco aprendizaje para generar valor: La capacitación de una persona
al uso del Kanban se reduce a enseñarle los códigos propios del equipo. Como en
Kanban las políticas del proceso son explícitas el acceso y la comprensión de éstas se
simplifica y disminuye los tiempos necesarios para que la persona entre en régimen.
Simple construcción y evolución: Al ser un tablero distribuido por zonas,
armar un Kanban puede tomar menos de cinco minutos en su versión más simple
(Kniberg & Skarin, 2010). Cambiar la distribución del tablero es sencillo y permite
que ésta evolucione ajustándose a las necesidades que el equipo desee implementar
en su flujo de trabajo. El tablero Kanban físico posee la flexibilidad necesaria para
adaptarse a las necesidades del equipo que lo utilizará.
Baja inversión inicial y operacional: Construir un tablero Kanban resulta ser
muy barato porque puede ser construido con materiales que se encuentran en
cualquier oficina. Por ejemplo, una versión sencilla puede construirse sobre una
muralla con cinta adhesiva de color para crear la distribución de zonas. Para operar
un Kanban se necesita un lápiz y papeles de colores (post-it), que son de bajo costo
en el mercado
Orientación a la generación de valor: La filosofía tras el Kanban sostiene que

conoce como modelo Pull. Este modelo, junto a la priorización de las tareas basado
en la cantidad de valor generado al cliente, garantizan que sólo se construirá lo que
se necesite evitando la acumulación de tareas y el desperdicio de tiempo.
459 | P á g i n a
 En la tabla 2 se muestra una síntesis de los estudios presentados hasta el momento y se
evidencia las características de cada metodología ágil.
Síntesis metodologías agiles de desarrollo con sus características
Metodología Características
Programación Metodología basada en prueba y error.
extrema Cliente bien definido.
(extreme Los requisitos pueden y van a cambiar.
programming, Grupo pequeño y muy integrado (máximo 12 personas.
XP) Equipo con formación elevada y capacidad de aprender.
Fundamentada en Valores.
Expresada en 12 Prácticas.
Implementa compatibilidad y usabilidad con otras metodologías.
Está orientada hacia quien produce y uso del software.
Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema.
Combina las que han demostrado ser las mejores prácticas para desarrollar software y las
lleva al extremo.
Programación organizada.
Reduce la taza de errores.
Satisfacción del programador.
Crystal Entregas frecuentes, en base a un ciclo de vida iterativo e incremental.
Methodologies Cuantas más personas estén implicadas, más grande debe ser la metodología.
Entorno técnico con pruebas automatizadas, gestión de la configuración e integración
continua.
Si el proyecto tiene mucha densidad, un error no detectado puede ser crítico.
El aumento de tamaño o densidad añade un coste considerable al proyecto.
La forma más eficaz de comunicación es la interactiva (cara a cara).
Tamaño de un equipo (número de componentes)

Equipo
Clear es para equipos de hasta 8 personas o menos.
Amarillo para equipos entre 10 a 20 personas.
Naranja para equipos entre 20 a 50 persona.
Roja para equipos entre 50 a 100 personas.
Azul para equipos entre 100 a 200 personas.

Comunicación entre los componentes.

Distintas políticas a seguir.
Mejora reflexiva.
Scrum Permite la gestión de diferentes equipos industriales
Aplicación de las metodologías ágiles en los procesos de calidad, entregando
resultados óptimos.
Su adopción en prácticas orientadas a planes como CMMI o PSP/TSP
La productividad y competitividad de las empresas de software al implementar este
tipo de metodología.
El aporte a la industria a través de las buenas prácticas.
El aporte a la gestión de proyectos a través del proceso.
Aporte efectivo dentro de la gerencia de proyectos de software.
La competitividad en el desarrollo de productos y proyectos industriales a través de
la implementación de esta metodología ágil.
Kamban La industria promete un mayor crecimiento y fortalecimiento de sus procesos.

460 | P á g i n a
 Metodología Características
Con la fusión entre Kanban y el Just in Time, se evidencia la reducción de valores
stock.
Nuevas estrategias para optimizar el nivel de utilidad productivo.
La satisfacción del cliente en cuanto a la ejecución de un servicio más efectivo.
(Mejora, planificación y gestión del inventario de la empresa)
La puesta en marcha de trabajadores multifuncionales con capacidades de proponer
estrategias que ayuden con el crecimiento empresarial.
Control de la producción y mejora de los procesos.
Mejoramiento de la productividad y eficiencia en la producción a través de la
eficacia y eficiencia de la implementación de esta metodología
Tabla 2: Síntesis estudios presentados. [Fuente propia]Por otro lado, se evidenciaron las
siguientes diferencias entre la metodología Scrum y Kamban como se observa en la tabla 3.
Diferencias entre estas metodologías Scrum y Kanban

Scrum
El tiempo definido para las iteraciones es
fijo.
En cada sprint el equipo asume un
compromiso de trabajo.
La velocidad se toma como factor de
medición para la planificación y la mejora
del proceso.
Se establecen equipos multifuncionales.
Las funcionalidades deben dividirse en
partes que puedan completarse en un
sprint.
Deben emplearse gráficos Burndown.
Se emplea una limitación WIP indirecta
(por sprint).
Deben realizarse estimaciones.
En medio de una iteración no se pueden
añadir tareas
La pila del sprint pertenece a un equipo
determinado.
Se esteblecen tres roles (PP/SM/Equipo).
En cada sprint se limpia el tablero de
seguimiento.
La pila del producto debe estar
priorizada.
Tabla 3. Diferencias entre Scrum y Kanban [Fuente propia]
Kanban
No se encuentra definido un tiempo fijo para las iteraciones.
La cadencia puede ser variable frente al plan del proyecto y
la mejora del proceso. Pueden estar marcadas por la previsión
de los eventos en lugar de tener un tiempo pre-fijado.
Adquirir compromisos es opcional.
Se define el Lead Time que es el tiempo de entrega o tiempo
medio que tarda una petición en salir del ciclo, como factor
para medición por defecto de la planificación y la mejora del
proceso.
Se establecen equipos multifuncionales o especializados.
Las divisiones no tienen prescripción para el tamaño de las
mismas.
No se establecen diagramas de seguimiento.
Se emplea una limitación WIP directa (marcada por el estado
del trabajo).
La realización de estimaciones son opcionales.
Siempre que haya capacidad disponible se pueden añadir
tareas
Puede compartirse la misma pizarra Kanban para varios
equipos o personas.
No hay roles establecidos.
El tablero Kanban es persistente.
Es opcional la priorización.

Kniberg & Skarin definieron las siguientes similitudes entre las metodologías agiles
Scrum y Kanban (Kniberg & Skarin, 2010) :
1. Scrum y Kanban son herramientas de proceso que te ayudan a trabajar más
eficazmente, en cierta medida, diciéndote qué hacer.
2. Ambas metodologías proporcionan restricciones y directrices.
3. Scrum y Kanban son adaptables.

461 | P á g i n a
 4. Srcrum y Kanban son empíricos en el sentido de que se espera que
experimentes con el proceso y lo adaptes a tu entorno.
5. Ambos Scrum y Kanban se basan en el desarrollo incremental.
6. Las dos metodologías permiten trabajar en múltiples productos
simultáneamente.
7. Ambos son Lean y Agiles.
8. Se utiliza la técnica de reuniones para compartir información de lo que ha
pasado en las dos metodologías.
9. Ambos emplean sistemas de planificación "pull".
10. Ambos establecen límites WIP.
11. En ambos la visibilidad del proceso es la base de su mejora.
12. Ambos tienen como objetivo la entrega temprana y frecuente de software.
13. Ambos necesitan la división del trabajo en partes.
14. Ambos revisan y mejoran de forma continua el plan del producto en base a
datos empíricos (velocidad / tiempo de entrega).

Teniendo en cuenta las diferencias y similitudes de estas metodologías se evidencia que

Scrumban toma lo mejor de ellas para funcionar. A continuación se presenta la tabla 4
resumen de metodologías Scrum y Kanban, tomando como punto de comparación los
siguientes ítems (Sáez Martinez, 2013):

Items KANBAN SCRUM

Tiempo para cada Flujo constante. Se liberan
iteración recomendado entregables con base a eventos o
necesidades
Tamaño del equipo Sin prescripción
Comunicación en el Informal
equipo Cara a cara
A través de tablero Kanban
Cada equipo define sus procesos
Tamaño del proyecto Proyecto de corta-media duración
Involucración del Sería conveniente
cliente participación activa del cliente
Documentación en el Evita la documentación
proyecto Cada equipo define sus procesos
Habilidades especiales Tablero Kanban
Ventajas Facilita el que todo el mundo
sepa hacer, quien hace qué y
cómo va el proyecto
Limita el número de tareas a
hacer el mismo tiempo. Control
del flujo de trabajo
Fácil de aplicar
Flexible ante cambios
Desventajas Se deben definir las fases del
ciclo de trabajo
2 a 4 semanas
Todos los tamaños (Scrum de Scrums)
Informal
Reuniones diarias de pie.
Reuniones de retrospective
Todo tipo de proyectos
una Cliente fuertemente involucrado a través
del rol de ProductOwner
Solo documentación básica
Sprint, product y sprint backlog, scrum
board, scrum master, planning poker
Equipo autoorganizado
El equipo sabe que tiene que hacer
todo el día
El cliente sabe lo que se le entrega en
cada sprint
Flexible a cambios
Desarrolladores tienen autonomia
Minimiza el trabajo de gestión
Minimiza el syndrome del estudiante
Puede producir stress al sentirse el
equipo en contnuo sprint

462 | P á g i n a
 Items KANBAN
No define rles, ni fases, ni
tampoco profundiza en el tablero
Kanban
Algunos lo ven más como una
técnica que como metodologia
SCRUM
Requiere un equipo formado, motivado
y con cierta experiencia
Necesidad de involucración del cliente
Problemas en equipos distribuidos
geográficamente

Tabla 4. Resumen (Sáez Martinez, 2013) [Fuente propia]

Recordando el interés puntual de esta investigación consiste en presentar un análisis

comparativo de las metodologías agiles en el desarrollo de software, se parte de los hallazgos
para obtener las siguientes conclusiones:
La Ingeniería de software tiene a su disposición una serie de metodologías agiles para su
desarrollo, en donde cada una presenta unas características determinadas y que a pesar que,
en algunos casos son similares o heredadas por híbridos hechos como lo es el caso de
Scrumban estas tienen claras diferencias teniendo en cuenta sus características y diferentes
formas de aplicarse, lo que permite que a la hora de hacer la selección de una metodología
ágil sea la más idónea para el desarrollo del software.
Al realizar el análisis comparativo es importante destacar que las metodologías agiles
propuestas en esta investigación tiene un común denominador y es el trabajo en equipo en
donde este establece funciones para cada integrante del equipo indistintamente de la forma o
fases como se trabaje. Así mismo, estos resultados permiten contar con un punto de partida
para los interesados en el desarrollo de software con metodologías agiles como un análisis
general de las ventajas y desventajas de las metodologías analizadas en esta investigación.
Finalmente, este tipo de estudios son importantes porque le permite al desarrollador de
software ubicarse en un contexto actual de las metodologías agiles promoviendo con ello el
uso de estas y a su vez motivarlo a una estandarización de metodologías.

Anderson, D. J. (2010). Kanban: successful evolutionary change for your technology

business. Blue Hole Press.
Balaguera, Y. D. A. (2015). Metodologías ágiles en el desarrollo de aplicaciones para
dispositivos móviles. Estado actual. Revista de Tecnología, 12(2).
Beck, K. (2000). Extreme programming explained: embrace change. Addison-Wesley
Professional.
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,
(2001). Manifiesto por el Desarrollo Ágil de Software. Obtenido de Agile
Manifesto: Http://www. Agilemanifesto. Org/iso/es/manifesto. Html.
Canós, J. H., Letelier, P., & Penadés, M. C. (2003). Metodologías ágiles en el desarrollo
de software. Universidad Politécnica de Valencia, Valencia.
Cockburn, A., Highsmith, J., Johansen, K., & Jones, M. (2001). Crystal methodologies.
Echeverry Tobón, L. M., & Delgado Carmona, L. E. (2007). Caso práctico de la
metodología ágil XP al desarrollo de software.

463 | P á g i n a
View publication stats

Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development, 9(8),
28 35.
Gimson Saravia, L. E. (2012). Metodologias ágiles y desarrollo basado en conocimiento.
Facultad de Informática.
Huijbers, R., Lemmens, F., Senders, B., Simons, S., Spaan, B., van Tilburg, P., & Vossen,
K. (2004). Software project management: methodologies & techniques. Department
ofMathematics & Computer Science, Page p20.
Kniberg, H., & Skarin, M. (2010). Kanban and Scrum-making the most of both. Lulu.
com.
Kniberg, H., Skarin, M., de Mary Poppendieck, P., & Anderson, D. (2010). Kanban y
Scrum--obteniendo lo mejor de ambos. Prólogo de Mary Poppendieck & David Anderson.
ESTADOS UNIDOS DE AMÉRICA: C4Media Inc.
Letelier, P. (2006). Metodologías ágiles para el desarrollo de software: eXtreme
Programming (XP).
Roczniki Kolegium
, (33), 421 435.
Pérez, E. T. V. (2016). Herramientas tecnológicas aplicables al Kanban para la
optimización de los procesos en la empresa. Visión Gerencial, (1), 82 104.
Rodriguez Gonzalez, P. (2008). Estudio de la Aplicación de Metodologias Ágiles para la
Evolución de Productos Software. Informatica.
Sáez Martinez, P. J. (2013). Identificación y valoración de técnicas ágiles de gestión de
proyectos software.
Schwaber, K., & Beedle, M. (2002). Agilè Software Development with Scrum.
Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard
Business Review, 64(1), 137 146.

464 | P á g i n a