Metodología agiles de Desarrollo de Software.

¿Cuál se adapta a mi proyecto?

Universidad Simón Bolívar. Metodología de Sistemas de José Acuña
Caracas, Venezuela. Información (PS-8134).Profesora josecarrilloleal@gmail.com
Anna Griman

Resumen
Cuando emprendemos un proyecto a veces nos antes mencionados con sus ventajas y desventajas.
preguntamos ¿Qué metodologías debemos
Y de esta manera formar al lector para la toma de
utilizar? Por eso, he decidido crear este
decisión sobre las herramientas más adecuadas
documento donde comparo brevemente tres
para su proyecto. Una buena elección del modelo
metodologías agiles que seleccione (SCRUM, XP y
(correctamente aplicado) ahorra tiempo y mejora
KANBAN). La elección y aplicación correcta de
la calidad de los sistemas. Para finalizar
un modelo de desarrollo de software permite
mencionare seis principios agiles que me
ahorrar tiempo y mejorar la calidad de los
parecieron muy importantes colocar en este
sistemas que se producen. Sin embargo, la amplia
trabajo de investigación.
variedad de modelos y metodologías en el mundo
del desarrollo de software, hace que no sea
sencillo elegir el modelo más apropiado para un
proyecto específico, sobre todo cuando la
definición de estos modelos y metodologías se
encuentra dispersa en varios libros, artículos y
sitios de internet. Para efectos de este artículo que Palabras claves: Metodologías agiles, SCRUM,
es meramente informativo y se propone estudiar Extreme Programming, KANBAN. Ingeniería del
¿Qué son metodologías ágiles?, los tres modelos software, Proyecto, Sistema de Información.

Introducción

En la Ingeniería de Software existen diversos tipos de metodologías de desarrollo, entre las que se
destacan las tradicionales y las ágiles. Las metodologías tradicionales son aquellas con mayor
énfasis en la planificación y control del proyecto, en especificación precisa de requerimientos y
modelado. Las ágiles se caracterizan por ser iterativas e incrementales, y fácilmente adaptables a los
cambios, involucrando al usuario en el desarrollo. En la actualidad, estas metodologías ágiles tienen
gran aceptación a nivel mundial y están basadas en un manifiesto publicado en 2001 ("Manifiesto
de desarrollo ágil de software"), cuyo objetivo fue esbozar los valores y principios que deberían
permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan
surgir a lo largo del proyecto.

1
 Este documento está estructurado de la siguiente manera un marco teórico donde se detallan, los
conceptos sobre la literatura asociada con la temática. Una sección donde se habla de las
metodologías SCRUM, XP y KANBAN exponiendo sus principales características, ventajas y
desventajas. Y por último se presentan las conclusiones y las fuentes bibliográficas.

Marco Teórico

Ingeniería de Software impredecible y cambiante de los proyectos de

software, surgen como una
La ingeniería de
En la Ingeniería de Software existen alternativa de desarrollo en
software, en diversos tipos de metodologías de relación a los enfoques
términos prácticos es desarrollo, entre las que se destacan las
tradicionales.
la disciplina que tradicionales y las ágiles. Las metodologías
involucra el diseño, tradicionales son aquellas con mayor Proyecto
desarrollo, énfasis en la planificación y control del
proyecto, en especificación precisa de Un proyecto es un esfuerzo
mantenimiento y
requerimientos y modelado. Las ágiles se temporal emprendido para
documentación de caracterizan por ser iterativas e crear un producto o un
sistemas de software incrementales, y fácilmente adaptables a los
servicio único (PMBOK,
mediante la cambios, involucrando al usuario en el
desarrollo. 2004).
aplicación de
técnicas de Sistema de Información
ingeniería.
(Chaudron, y otros, 2002). Es una combinación organizada de personas,
hardware, software, redes de comunicaciones y
Metodología Agiles recursos de datos que reúne, transforma y
disemina información en una organización
Representan un relativo nuevo enfoque para el
(O´Brien, 2001).
desarrollo de software que ofrecen una respuesta
a la necesidad de responder al entorno

Los principios que fundamentan los métodos agiles son:

 Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de
software con valor.
 Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos
Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
 Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia
al periodo de tiempo más corto posible.
 Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante
todo el proyecto.
 Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el
apoyo que necesitan, y confiarles la ejecución del trabajo. Entre otros.

2
Metodología SCRUM

Esta metodología se Por eso debes saber qué

usa para minimizar los requerimientos debe
riesgos durante la tener tu proyecto si
quieres utilizarla con
realización de un
eficacia, entre ellas
proyecto, pero de
podemos mencionar:
manera colaborativa.
Entre las ventajas  Equipos
podemos mencionar pequeños:
las siguientes. cuando en tus
proyectos los
Figura 1 equipos de
La productividad,
calidad y que se realiza trabajo no
un seguimiento diario de los avances del superan las 8 personas. Aunque existen
casos de empresas que la han utilizado con
proyecto, logrando que los integrantes estén
éxito en equipos más grandes, no es
unidos, comunicados y que el cliente vaya viendo
recomendable.
los avances. La profundidad de las tareas que se  Poca necesidad de documentación: si el
asignan en SCRUM tiende a ser incremental, caso cliente te exige que todo el proyecto esté
que coincide exactamente con el devenir normal muy bien documentado desde el principio
de un desarrollo. (fases de consultoría y de tomas de
requerimientos largas) SCRUM no es tu
En el caso del Scrum su mayor fortaleza reside en metodología. Sin embargo, si sus
que la lista de requisitos mínimos facilita el expectativas son las entregas rápidas y
trabajo. Se entregan aquellos que aporten más tener mucho control sobre el proyecto, el
SCRUM te resultará muy útil porque se
valor al cliente. Quizás su principal limitación es
enfoca precisamente en este aspecto.
que mientras se desarrolla una iteración, por lo  Proyectos con riesgos de cambios durante
general no se pueden cambiar sus requisitos. Esta el proceso: como la metodología SCRUM
metodología es recomendada para proyectos ejecuta el proyecto en fases cortas de dos a
grandes. En la figura 1. Podemos observar una cuatro semanas, permite mucha
gráfica donde nos indica cada ciclo. flexibilidad a la hora de acometer cambios
a mitad del proyecto, ya que tras cada fase
se replantean las tareas y los objetivos.
Las herramientas principales de esta metodología  Confianza en la metodología: serás el
son: encargado de velar que se cumpla, por lo
tanto, antes de trabajar en un proyecto con
SCRUM debes aprender bien cuáles son
• La lista de requisitos sus principios y maneras de operar y
• La lista de tareas de la iteración sentirte cómodo con ellos, para poder
• Gráficos de la velocidad del trabajo traspasar esa confianza al resto de los
actores de tu proyecto.
No es necesario, ni siquiera conveniente, utilizar
la metodología SCRUM en todo tipo de proyectos.

3
 Equipo SCRUM sus equipos, mejorar su forma de trabajar y ser
más productivos.
Como podemos comprobar, Scrum y las
Metodologías ágiles apuestan por el trabajo en En conclusión ¿Qué soluciona Scrum?
equipo y de manera colaborativa, para obtener el
mejor resultado posible del proyecto. En Scrum  Tener resultados a corto plazo.
existen una serie de roles definidos por la propia  Cambiar a menudo los requisitos del
metodología. Todos y cada uno de estos roles son proyecto.
imprescindibles para que el proceso funcione. Lo  Ver si se cumplen sus expectativas.
podemos detallar más claramente en la figura 2.
¿Qué se quiere?
Stakeholder: Es el cliente propiamente dicho. Es
el responsable de establecer los requerimientos y  Equipos altamente productivos y
de recibir el producto, proporcionando feedback motivados.
sobre éste al final de cada iteración.  Solucionar los problemas que impiden que
los equipos progresen.
 Product Owner: Es el nexo de comunicación entre  Utilizar un proceso de gestión ligero aún
el stakeholder y el equipo de desarrollo. Es el en proyectos complejos.
responsable de crear el Product Backlog, así como
de priorizarlo según las necesidades del negocio.
Metodología XP
 Scrum Master: El Scrum Master tiene dos papeles
fundamentales para el correcto funcionamiento Se aplica en equipos con muy pocos
del proceso: Actuar de “facilitador” para el programadores quienes llevan muy pocos
equipo de desarrollo, eliminando todos los procesos en paralelo. Consiste entonces en
impedimentos que identifique durante el proceso, diseñar, implementar y programar lo más rápido
y actuar como “árbitro“, encargándose de que el posible, hasta en casos se recomienda saltar la
resto del equipo siga los valores y principios documentación y los procedimientos
ágiles, reglas y procesos de Scrum. tradicionales. Este método trabaja con 10 a 15
iteraciones. Cada iteración o ciclo se divide en
 Equipo de desarrollo o Scrum Team: Es el equipo etapas:
responsable de desarrollar los casos de uso
definidos en el Product Backlog. Se trata de un 1. Análisis y exploración
equipo auto gestionado (no existe el papel de Jefe 2. Planificación
de Equipo), en el que se engloban todas las partes
que intervengan en el proceso de construcción. El
propio equipo se encargará de realizar las
estimaciones, y en base a la velocidad obtenida en
las iteraciones pasadas, construir el Sprint
Backlog, identificando cuántos casos de uso son
capaces de realizar.

Esta metodología la podemos usar para proyectos

complejos, para tener resultados rápidos.

Empresas grandes y pequeñas en las que el

trabajo en equipo es fundamental, que trabajan
por proyectos o desarrollan productos, se apoyan
en Scrum para tener capacidad de reacción ante el Figura 2
mercado, impulsar la innovación y creatividad de
4
 3. Diseño
4. Implementación
5. Pruebas
La fase de análisis y exploración dura dos
semanas y en ella se define el alcance general del
proyecto. El cliente redacta historias de usuarios
que explican lo que se necesita.
Entre sus ventajas tenemos su increíble capacidad
de respuesta ante imprevistos, aunque por diseño
es una metodología que no construye para el
largo plazo y para la cual es difícil documentar.
Por otra parte es importante destacar que los
programadores deben aplicar la técnica de
ingeniería del software llamada refactorización de
manera de reestructurar su código fuente
mejorando la facilidad y comprensión del mismo.
XP es un método estupendo para equipos
extremadamente pequeños que se centran en un
solo cliente.
EQUIPO XP
Aunque en otras fuentes de información aparecen
algunas variaciones y extensiones de roles XP, en
este apartado describiremos los roles de acuerdo
con la propuesta original de Beck.
Programador: El programador escribe las pruebas
unitarias y produce el código del sistema. Debe
existir una comunicación y coordinación
adecuada entre los programadores y otros
miembros del equipo.
Cliente: El cliente escribe las historias de usuario
y las pruebas funcionales para validar su
implementación. Además, asigna la prioridad a
las historias de usuario y decide cuáles se
implementan en cada iteración centrándose en
aportar mayor valor al negocio. El cliente es sólo
uno dentro del proyecto pero puede corresponder
a un interlocutor que está representando a varias
personas que se verán afectadas por el sistema.
Encargado de pruebas (Tester): El encargado de
pruebas ayuda al cliente a escribir las pruebas
funcionales. Ejecuta las pruebas regularmente,
difunde los resultados en el equipo y es
responsable de las herramientas de soporte para
pruebas.
Encargado de seguimiento (Tracker): El
encargado de seguimiento proporciona
realimentación al equipo en el proceso XP. Su
responsabilidad es verificar el grado de acierto
entre las estimaciones realizadas y el tiempo real
dedicado, comunicando los resultados para
mejorar futuras estimaciones. También realiza el
seguimiento del progreso de cada iteración y
evalúa si los objetivos son alcanzables con las
restricciones de tiempo y recursos presentes.
Determina cuándo es necesario realizar algún
cambio para lograr los objetivos de cada iteración.
Entrenador (Coach): Es responsable del proceso
global. Es necesario que conozca a fondo el
proceso XP para proveer guías a los miembros del
equipo de forma que se apliquen las prácticas XP
y se siga el proceso correctamente.
Consultor: Es un miembro externo del equipo con
un conocimiento específico en algún tema
necesario para el proyecto. Guía al equipo para
resolver un problema específico.
5
Gestor (Big boss): Es el vínculo entre clientes y Los principios de la metodología Kanban
programadores, ayuda a que el equipo trabaje
La metodología Kanban se basa en una serie de
efectivamente creando las condiciones adecuadas.
principios que la diferencian del resto de
Su labor esencial es de coordinación.
metodologías conocidas como ágiles:

• Calidad garantizada. Todo lo que se hace

debe salir bien a la primera, no hay margen de
error. De aquí a que en Kanban no se premie la
rapidez, sino la calidad final de las tareas
realizadas. Esto se basa en el hecho que muchas
veces cuesta más arreglarlo después que hacerlo
bien a la primera.

• Reducción del desperdicio. Kanban se

basa en hacer solamente lo justo y necesario, pero
hacerlo bien. Esto supone la reducción de todo
Figura 3 aquello que es superficial o secundario (principio
YAGNI).

• Mejora continua. Kanban no es

Metodología KANBAN simplemente un método de gestión, sino también

un sistema de mejora en el desarrollo de
proyectos, según los objetivos a alcanzar.
Es un proceso tan sencillo como eficaz. De lo que
se trata es de medir tiempos y cantidades en • Flexibilidad. Lo siguiente a realizar se
procesos de fabricación, para optimizar cada una decide del backlog (o tareas pendientes
de las actividades que se llevan a cabo. Kanban es acumuladas), pudiéndose priorizar aquellas
una palabra japonesa que significa “tarjetas tareas entrantes según las necesidades del
visuales” (kan significa visual, y ban tarjeta). Esta momento (capacidad de dar respuesta a tareas
técnica se creó en Toyota, y se utiliza para imprevistas).
controlar el avance del trabajo, en el contexto de
¿Cómo funciona? a continuación se
una línea de producción. Actualmente está siendo
describen las fases de esta metodología.
aplicado en la gestión de proyectos software.
Las principales reglas de Kanban son las tres
Las principales ventajas de esta metodología es
siguientes: (1) Visualizar el trabajo y las fases del
que es muy fácil de utilizar, actualizar y asumir
ciclo de producción o flujo de trabajo, (2)
por parte del equipo. Además, destaca por ser
determinar el límite de “trabajo en curso” (o Work
una técnica de gestión de las tareas muy visual,
In Progress) y (3) medir el tiempo en completar
que permite ver a simple vista el estado de los
una tarea (lo que se conoce como “lead time”).
proyectos, así como también pautar el desarrollo
Veámos que significa cada uno de los anteriores.
del trabajo de manera efectiva.
1. Visualizar el trabajo en Kanban y las fases del ciclo
de producción, o flujo de trabajo.
6
Kanban se basan en el desarrollo incremental,
dividiendo el trabajo en partes. Una de las
principales aportaciones es que utiliza técnicas
visuales para ver la situación de cada tarea, y que
quizás habrás visto representado pizarras llenas
de post-it.
El trabajo se divide en partes, normalmente cada
una de esas partes se escribe en un post-it y se
pega en una pizarra. Los post-it suelen tener
información variada, si bien, aparte de la
descripción, debieran tener la estimación de la
duración de la tarea. La pizarra tiene tantas
columnas como estados por los que puede pasar
la tarea (ejemplo, en espera de ser desarrollada, en
análisis, en diseño, etc.). Abajo dejo una figura 4
con un ejemplo de tablero Kanban.
2. Determinar el límite de “trabajo en curso”.
Quizás una de las principales ideas del Kanban es
que el trabajo en curso (Work In Progress o WIP)
debería estar limitado, es decir, que el número
máximo de tareas que se pueden realizar en cada
fase debe ser algo conocido.
En Kanban se debe definir cuantas tareas como
máximo puede realizarse en cada fase del ciclo de
trabajo (ejemplo, como máximo 4 tareas en
desarrollo, como máximo 1 en pruebas, etc.), a ese
número de tareas se le llama límite del “work in
progress”. A esto se añade otra idea tan razonable
como que para empezar con una nueva tarea
Figura 4
alguna otra tarea previa debe haber finalizado.
3. Medir el tiempo en completar una tarea.
El tiempo que se tarda en terminar cada tarea se
debe medir, a ese tiempo se le llama “lead time”.
El “lead time” cuenta desde que se hace una
petición hasta que se hace la entrega. Aunque la
métrica más conocida del Kanban es el “lead
time”, normalmente se suele utilizar también otra
métrica importante: el “cycle time”. El “cycle
time” mide desde que el trabajo sobre una tarea
comienza hasta que termina. Si con el “lead time”
se mide lo que ven los clientes, lo que esperan, y
con el “cycle time” se mide más el rendimiento
del proceso.Puede haber más métricas, pero las
anteriores son las realmente importantes, y
necesarias para el control y mejora continua.
Conclusión
Apostar por una metodología ágil. Es el punto de
partida para la gestión de cualquier proyecto de
sistemas de información en estos tiempos ya que
los procesos van deprisa, la información fluye
como nunca antes y es necesario estar al día con
las nuevas innovaciones.
Debemos considerar las siguientes variables:
 La plataforma o el lenguaje de programación
a utilizar.
 El tipo de empresa a que va dirigido o la
actividad que desempeña.
 El sistema operativo que utiliza.
 La base de datos.
 La metodología para desarrollar el software
que vamos a elegir si es un proyecto grande o
pequeño.
 La cantidad de personas que van a participar
en el proyecto.
 Soporte técnico confiable y calificado.
Debemos tener en cuenta que la metodología
seleccionada sea de fácil acceso para el equipo de
trabajo. Es decir, asegúrate de que tenga una
7
pauta común y resulte lo suficientemente precisa
y sencilla de usar.

Recordemos que la metodología no puede dar

respuesta a las necesidades del proyecto. Antes de
tomar cualquier decisión al respecto, se debe
considera que exista compatibilidad en ambos
elementos.

Fijémonos en su grado de adaptabilidad de las

herramientas, y su vigencia en el tiempo y si
permite realizar los cambios que exige la
dinámica de la organización y su entorno.

Referencias

Javier Garzas (2011) “¿Qué es el método Kanban

para la gestión de proyectos?

URL(http://www.javiergarzas.com/2011/11/Kanba
n.html.)

Historia de las Metodologías Ágiles en Contexto

(2013)

URL(http://www.caminoagil.com/2013/03/historia
-de-las-metodologias-agiles-en.html).

Blog Unicersitat Barcelona (2016) “Criterios para

elegir tu metodología de desarrollo de software”.

URL( https://www.obs-edu.com/int/blog-project-
management/metodologias-agiles/criterios-para-
elegir-tu-metodologia-de-desarrollo-de-software).

Blog Unicersitat Barcelona (2016) “Los 5 modelos

de desarrollo de software que elegirás”.

URL (https://www.obs-edu.com/int/blog-project-
management/metodologias-agiles/los-5-modelos-
de-desarrollo-de-software-que-elegiras).

Valeria Velasco (2013) ”Principios de las

metodologías agiles”.

URL(https://es.slideshare.net/joselynvaleria93/pri
ncipios-de-las-metodologas-agiles).
8