METODOLOGIA AGIL

¿Qué es una metodología?

Una metodología consiste en todos los datos que se recopilan a la hora de
planificar y gestionar un proyecto, con el fin de seleccionar las técnicas o métodos
concretos para realizar un diagnóstico del problema y posteriormente ofrecer
estrategias y procedimientos que permitan solucionar los inconvenientes de manera
apropiada.

Es decir: en una metodología se trata de detallar una serie de pasos para

establecer las prioridades de cada tarea y de esta manera poder lograr el éxito de la
actividad propuesta.

La metodologías como tales tienes cinco fases:

1. Fases: En este punto se determinan las diferentes actividades que hay que
realizar en cada etapa del proyecto. Aquí se agrupan las tareas elementales
que ocupan un largo trayecto de tiempo durante la ejecución del proyecto.
Además, se asignan los recursos correspondientes donde se incluyen los
recursos humanos, financieros y los materiales.
2. Documentación: Se definen los documentos que se van a entregar en cada
etapa, esta documentación se debe realizar de manera exhaustiva y completa.
Algunos ejemplos de documentación son: las actas de reuniones, formatos de
pruebas, los requisitos del proyecto, etc.
3. Métodos: Se debe identificar el modo en que se aplicará la metodología en el
desarrollo del proyecto. Generalmente, se divide en grupos pequeños, con la
intención de conseguir los objetivos planteados en el menor tiempo posible.
4. Técnicas y herramientas: Después de definir los métodos, se aplican las
técnicas y herramientas que indicarán cómo debe resolverse cada tarea.
Existen diferentes tipos de técnicas—
 Para recopilar datos se pueden usar: encuestas, entrevistas,
cuestionarios, etc.
 Para gráficos: diagramas, organigramas, histogramas, etc.
5. Control y evaluación: Consiste en comprobar, aceptar o negar los resultados
que se van obteniendo y así poder replantear las tareas asignadas de ser
necesario.
  Ventajas de una metodología

Cuando una empresa adopta una metodología para cada uno de sus procesos
consigue mejores resultados, ya que es una buena práctica para estimar los recursos,
tiempos y coste del proyecto.

 Desventajas de una metodología

Depende en gran medida del líder del equipo y es indispensable su trabajo y

presencia. Cualquier solución errónea en pleno trabajo puede desviar al equipo de
conseguir los objetivos previamente definidos.

Si un miembro del equipo renuncia es complicado reemplazar ese rol, ya que la

persona se lleva consigo el conocimiento específico que se ha planeado al inicio del
proyecto.

TIPOS DE METODOLOGIAS

1. Metodología tradicional

Este método se realiza de forma lineal, es decir, que cada etapa está ligada a
la anterior.

La más usada es el modelo en cascada o waterfall, se caracteriza porque

todas las fases se realizan en forma secuencial, es decir, que las etapas se llevan a
cabo una detrás de otra, pero eso sí, cada etapa debe estar finalizada antes de
empezar la otra.

En esta metodología se pueden identificar los siguientes roles:

 Gestor de proyecto: este rol tiene la función de controlar si el proyecto sigue

la planificación y si se está cumpliendo los objetivos planteados.

 Desarrolladores: este rol tiene la función de implementar las instrucciones

indicadas por el gestor del proyecto. Participa en las fases de desarrollo,
prueba y mantenimiento.
  Probadores: estos realizan las pruebas necesarias para comprobar que el
proyecto cumple con los requisitos exigidos por el cliente.

2. Metodología Ágil

Más que una metodología, lo que se establece es un marco teórico que permite
acortar los tiempos de desarrollo, eliminar la incertidumbre, mejorar la eficiencia del
equipo y obtener un resultado de calidad, con el propósito de brindar la mayor
satisfacción posible al cliente, a través de la interacción con los avances obtenidos en
cada etapa y la retroalimentación durante la construcción del producto.

 Diferencia entre Metodología Ágil y Tradicional

En la planificación de todo proyecto, siempre se tienen en cuenta tres variables

principales, estas son: alcance, tiempo y costo. Lo anterior, se conoce con el nombre
de “Triángulo de Hierro”.

 El alcance, definirá las tareas necesarias para alcanzar las características que
deseamos obtener de nuestro producto.
 El tiempo, es la duración aproximada en que se entregará el producto.
 El costo, son los recursos que se van a destinar para la ejecución de

En la imagen podemos observar el comportamiento del triángulo de hierro en

ambas metodologías, en el caso de la tradicional el comportamiento del tiempo y el
costo es variable, esto quiere decir que cualquier cambio en el alcance del proyecto
afectará el tiempo y el costo.
 Ahora, para el caso de un proyecto ágil el tiempo y el costo son fijos, mientras
que el alcance es variable.

De forma esquemática se podría decir lo siguiente:

Analizando la imagen, identificamos que la metodología tradicional sigue una

dirección fija, es decir no cambia el sentido durante el desarrollo del proyecto, a
diferencia de la metodología ágil, la cual analiza, ejecuta un plan, diseña, construye,
prueba y luego avanza, esto es conocido como Sprint, este es el corazón del Scrum,
pues es el que determina si el proyecto está “hecho o terminado”.

En un proyecto tradicional se tiene una serie de etapas progresivas las cuales

son: planeamiento, análisis, diseño, programación, pruebas (como se ve en la imagen
anterior). Cuando se inicia el proyecto el cliente se siente muy feliz, pero en el
desarrollo de cada una de las etapas los tiempos planificados no siempre se cumplen,
esto ocurre debido a que en cada etapa se trabaja de manera independiente y no
como un equipo, así también los tiempos de demora en las etapas iniciales
(planeamiento, análisis, diseño) afectan el tiempo de las fases de programación y
pruebas, y esto a la vez ocasiona que se le entregue al cliente un producto incompleto
y con observaciones.

Un proyecto ágil se divide en etapas, estas etapas se llaman Sprints (o

Iteraciones), cada sprint tiene la misma duración de tiempo. En cada uno de estos
sprints se entrega un avance al cliente, este avance es realizado en cada finalización
de sprint, esto mantiene al cliente informado y feliz en cada una de las etapas al poder
visualizar su producto. Esto quiere decir que con scrum (una de las metodologías
agiles) entregan valor en cada etapa de manera constante, haciendo que el usuario
pueda obtener un producto determinado en cada sprint.

METODOLOGIA AGIL

En este documento se tendrá especial enfoque en las metodologías agiles.

Como se vio anteriormente, este tipo de metodología es una metodología iterativa, es
decir, se realizan entregas cíclicas y en cada entrega se realizan todas las fases del
ciclo. Es decir, en el sprint 1 se realiza el planeamiento, análisis, diseño,
programación, pruebas…En el sprint 2, se vuelve a realizar el planeamiento, análisis,
diseño, programación, pruebas…es conclusión, se hace ‘para cada una de las fases
del proyecto’.

Dentro de estas metodologías—ágiles—se encuentra algo llamado ‘Manifiesto

Ágil’, el cual no es más que un documento que se centra en 4 valores y 12
principios para el desarrollo de todo proyecto.

Los 4 valores:

1. Individuos e interacciones sobre procesos y herramientas. Valorar más

a los individuos y sus interacciones que a los procesos y las herramientas. Los
equipos que trabajan con metodología Agile valoran más la
colaboración en equipo y trabajar juntos, que trabajar de manera
independiente y hacer las cosas “al pie de la letra”.

2. Software funcionando sobre documentación extensiva. El software que

desarrollan los equipos ágiles debe funcionar. El trabajo extra, como la
documentación, no es tan importante como desarrollar un buen software.

3. Colaboración con el cliente sobre negociación contractual. Los clientes

son sumamente importantes para la metodología Agile. Los equipos que trabajan con
estas metodologías dejan que los clientes marquen la dirección en la que se debe
orientar el software.
 4. Respuesta ante el cambio sobre seguir un plan. Uno de los
principales beneficios de la metodología Agile de proyectos es que
permiten que los equipos sean flexibles.

Los 12 principios:

1. Satisfacer a los clientes a través de la entrega temprana y

continua. Cuando los clientes reciben actualizaciones con
regularidad, es más probable que vean los cambios que desean dentro
del producto.

2. Se acepta que los requisitos cambien, incluso en etapas

tardías del proyecto.

3. Se hace entregas valiosas con frecuencia. Igual que el

primero, en cada etapa se informa al cliente sobre el avance del
proyecto. Esto hace que el cliente este involucrado y satisfecho con
el avance del producto.

4. Trabajo en equipo. Se rompe el trabajo independiente que se

tiene en las metodologías tradicionales por trabajo en conjunto de
cada uno de los departamentos involucrados.

5. Motivación. Mantener a los miembros del equipo siempre

motivados. Esta metodología ágil hace que los miembros se
mantengan comprometidos con el proyecto haciendo que trabajen
activamente.

6. Comunicación cara a cara. El método más eficiente y efectivo de

comunicar información al equipo de desarrollo y entre sus miembros es la conversión
frente a frente.
 7. El software en funcionamiento es el principal indicador del progreso en
la Metodología Agile. Es decir, una medida de que el proyecto va avanzando es
viendo si el software funciona, sino, el proyecto está estancado.

8. Ritmo de trabajo constante. El objetivo es mantener la constancia

a lo largo del proyecto.

9. La excelencia continua favorece la agilidad. sí el equipo desarrolla

un código excelente en un sprint, podrá basarse en ese mismo código
para el siguiente desarrollo. En pocas palabras, entre mejor se haga
algo, ese algo puede ser ocupado en otra fase del proyecto, para
agilizar el mismo.

10. La simplicidad es esencial. A veces, la solución más simple es la mejor.

Lo bueno no siempre tiene que ser complejo.

11. Los equipos auto organizados generan resultados más

valiosos.

12. Análisis retrospectivo. Con regularidad, el equipo reflexiona

y adapta las formas de trabajo para favorecer la efectividad. Es
tiempo dedicado a que los equipos miren hacia atrás, reflexionen
sobre su desempeño y adapten los comportamientos para el futuro.

METODOLOGIA SCRUM

Scrum es un proceso en el que se aplican de manera regular un

conjunto de buenas prácticas para trabajar colaborativamente, en
equipo, y obtener el mejor resultado posible de un proyecto.

Asimismo, un proceso Scrum se ejecuta durante un sprint que,

generalmente, son sesiones de trabajo de dos semanas con entregas
específicas que deben realizarse al final.

Hay dos eventos adicionales que son también claves para

entender qué es Scrum. Las reuniones diarias de actualización, como
su nombre indica, se dan una vez al día. Estas representan una
oportunidad para que el equipo de Scrum se conecte durante 15
minutos y coordine las actividades diarias. El segundo evento, el
análisis retrospectivo del sprint, tiene lugar al final de cada sprint.
Durante el análisis retrospectivo del sprint, que estará a cargo del
Scrum Master, el equipo de trabajo tiene la oportunidad de reflexionar
con respecto al sprint y hacer ajustes para futuros sprints.

SCRUM: ROLES Y RESPONSABILIDADES

Habitualmente el equipo de desarrollo está conformado por

grupos de trabajos de entre 3 y 8 integrantes sin incluir al Scrum
Master y el Product Owner. Cada uno de estos roles tiene distintas
responsabilidades y deben responder de manera diferente a las
peticiones del encargado del proyecto.

1. Producto Owner (Dueño del Producto). Este personaje es el

responsable de asegurar que el equipo aporte valor al negocio y
representa a las partes interesadas internas y externas a la
organización, es decir, se considera como el representante del cliente
y a la vez hace parte del equipo Scrum. Cabe señalar que el dueño del
producto tiene una gran responsabilidad porque es la persona que
conoce bien el negocio y es el encargado del producto en sí.
Generalmente no está permitido trabajar con requerimientos que no
hayan sido analizados, estudiados y aprobados por el product owner.

2. Scrum Master. El Scrum Master es el responsable de implementar y

verificar que la metodología se está cumpliendo. Esta persona es la conexión o
mediador entre el Product Owner y el equipo de desarrollo, en todas las reuniones
debe estar presente.

3. Development Team (Equipo de Desarrollo). Este equipo está conformado

por los desarrolladores—programadores, ingenieros en sistemas, codificadores—del
proyecto. Según el marco de trabajo Scrum, cada equipo debe tener entre 3 y 8
personas, ya que la comunicación de esta forma fluye y no existen roces constantes
entre grupos.

En conclusión, en la metodología Scrum existen dos personajes principales que

son el dueño del producto (Product Owner) y el facilitador de proyectos (Scrum
Master), que se encargan de gestionar al equipo de desarrollo para satisfacer al cliente
con los requerimientos de su proyecto.

 EVENTOS TÍPICOS DE LA METODOLOGÍA SCRUM

Cuando se desarrolla esta metodología, se deben de identificar

ciertos requerimientos a realizar en cada uno de los proyectos. Es
decir, el desarrollo del Scrum.

1. Organizar el trabajo pendiente. Para comenzar un sprint de

Scrum, el líder del equipo (también conocido como Scrum Master)
identificará qué trabajo extraer de la lista de tareas pendientes, es
decir, el trabajo que debe realizarse.

2. Sprint Planning—planeación. Realiza una sesión de

planificación del sprint. Antes de que se pueda comenzar el sprint de
Scrum, se necesita saber el enfoque.

3. Comienzo del sprint. Normalmente dura 2 semanas (15 días).

Como máximo puede durar hasta un mes—NO MÁS.

4. Daily meeting. Organizar reuniones diarias de unos 15

minutos para informar con respecto al trabajo que se está realizando
e identificar cualquier obstáculo inesperado que haya surgido.

5. Sprint Review: Una vez que se haya terminado el sprint de

Scrum, tu equipo debe reunirse para hacer una revisión del sprint.
Que es lo que se hizo en el sprint.
 6. Sprint Retrospective—Retrospectiva: Al final de cada sprint,
es necesario tomarse un tiempo para analizar cómo se desarrolló el
sprint y qué podría mejorarse en el futuro.

7. Refinamiento: acta se hace la planeación para el siguiente

sprint. Se podría considerar como una pre planeación. Es decir, una
fase previa al Sprint Planning.

 ARTEFACTOS SCRUM

En Scrum, un artefacto es algo que se crea, como una

herramienta para resolver un problema. Existen tres artefactos que
definen qué es Scrum: la pila de producto o product backlog, la pila de
sprint o sprint backlog y el incremento del producto. Básicamente, los
artefactos son elementos diseñados para maximizar la transparencia
de la información y asegurar que la comunicación en el equipo sea
efectiva.

1. Producto backlog (Pila de producto). El encargado del

Product Backlog o pila de producto es el product owner, en este
documento se van a plasmar la lista de necesidades, ideas, requisitos
que darán cumplimiento a las necesidades del cliente. Estas
necesidades serán transmitidas tanto al Scrum Master como al
Development Team. Esto se hace en el Sprint Planning, donde se
planeara como darle solución a una primera fase de ese producto
final.

2. Sprint Backlog. Como resultado del Sprint Planning se obtiene

una lista de funcionalidades llamadas sprint Backlog, las cuales son
tomadas del Product Backlog. Este—el sprint Backlog—consiste en un
conjunto de requisitos que se deben construir en un tiempo de 1 a 4
semanas como máximo, esto es lo que se ha venido llamando Sprint.
 3. Incremento del producto. El incremento del producto es lo
que se entregará al final de cada sprint. Este artefacto Scrum puede
consistir en un nuevo producto o función, una mejora o corrección de
errores, o cualquier otra cosa dependiendo del equipo. Esto no es más
que la suma de los requerimientos completados en un Sprint y que
constituyen un producto entregable

 HISTORIAS DE USUARIO

Probablemente, en algún momento has trabajado en algún

proyecto para un cliente y notarás, que el cliente solicita diversos
componentes en un lenguaje no técnico, por ejemplo, “quiero un
botón en este lado para mostrar publicidad sobre la página”, “quiero
una opción para cambiar la contraseña”, como estos existen otros
requerimientos solicitados por el cliente que se deben tener en
cuenta para satisfacerlo.

Por ello, la metodología Scrum cuenta con las historias de

usuario: estas no son más que descripciones breves y concisas
sobre qué, por qué y para qué el cliente necesita que cierto
requerimiento se incluya en el proyecto.

Las historias de usuario facilitan la interacción del cliente con

el equipo para verificar que el proyecto en el que se está trabajando
cumple sus expectativas.

Estructura de las historias de usuario

 Nombre historia: es necesario colocar un nombre a la HU para
saber de qué se trata. Lo recomendable es siempre comenzar con
verbos.

Como: <rol>, la persona que se desempeñara en esta historia.

Ejemplo: como empleado, como cajero, como automovilista. No
tratarlo “como usuario”, siempre tratar de identificar a ese usuario,
no dejarlo simplemente así.

Quiero: <funcionalidad>, lo que vamos a realizar, la función que

necesitamos.

Para: <Justificación> especifica el valor de la funcionalidad, para

que se necesita dicha función, para qué sirve, que es lo que
resuelve.

*Recomendación: hacer un doble ‘para’, para reflexionar— es

decir, encontrar la finalidad futura de dicha funcionalidad, el valor
como tal de esa función.

Criterios de Aceptación: estos son los criterios de aceptación de

la historia que estamos creando. En esta sección se establecen
literalmente criterios para saber si la funcionalidad que estamos
creando arriba se hizo o no.

Conversación: especificar otros detalles importantes,

especificaciones que el PO crea conveniente especificar al
Development Team, en otras palabras, es una conversacion que
ocurre entre estos dos para acordar o agregar detalles.

Ejemplo:
 Nombre historia: Retiro de efectivo desde la aplicación.

Como: persona que usa la aplicación bancaria.

Quiero: opción para sacar dinero con el teléfono celular.

Para: tener acceso a mi dinero desde cualquier parte sin

necesidad de la tarjeta.

Para: hacer más fácil el acceso a mi dinero desde cualquier parte

en cualquier momento.

Criterios de Aceptación:
1. La app debe proporcionar un código de 8 dígitos o código
QR para ser escaneado en el cajero.
2. El código debe tener una duración de 24 horas.
3. En el cajero, el usuario debe ingresar el código generado
por la app o escanear el código QR con su celular.

Conversación:
 Una vez realizada la transacción enviar un mensaje SMS con
el estado de la operación. Si el retiro fue exitoso o no.
 Si el dinero no es retirado en el tiempo estipulado, enviar una
notificación al usuario para hacerle saber que su dinero ha
sido reincorporado a su cuenta.

 PRODUCT BACKLOG

Como se vio anteriormente, el product backlog es un listado de

todas las tareas que se pretenden hacer durante el desarrollo de un
proyecto, este artefacto es dinámico y no necesariamente estará
completo con todos los requisitos del proyecto al principio. En otras
palabras, conforme se avanza en el proyecto, se pueden ir agregando
nuevos requisitos.

Todas las tareas deben listarse en el product backlog, para que

estén visibles ante todo el equipo y se pueda tener una visión
panorámica de todo lo que se espera realizar.

En la Lista del Producto (Producto Backlog) se incorporan

únicamente los requisitos que están totalmente claros y se van
incorporando los nuevos requisitos conforme se vayan definiendo. La
Lista de Producto tiene la misma vida que el proyecto, mientras éste
no esté finalizado, la Lista de Producto seguirá viva.

A cada uno de los elementos o tareas pendientes que forman el

Product Backlog se les llama PBI(Product Backlog Item). Cada uno de
ellos tiene la siguiente información:

 Número/Nombre: El concepto del número en un PBI identifica

a la tarea a realizar mientras que el nombre es una
descripción en lenguaje natural que permite tener una idea
sobre la tarea en cuestión. Se puede tomar como referencia
el ‘nombre’ de la Historia de usuario.
 Descripción del elemento: La descripción es la especificación
de cuáles son los objetivos de la tarea. Se especifican a
través de las Historias de Usuario escritas en lenguaje
natural en vez de las especificaciones formales utilizadas en
las metodologías tradicionales.
 Prioridad: La prioridad debe ser definida por el Product Owner
y marca por un lado los PBI's que deben ser detallados y que
van a ser candidatos a formar parte del Sprint. Es decir,
conforme a la priorización se tratan aquellos ítems que se van
a trabajar. Tampoco quiere decir que se debe de trabajar al
pie de la letra de esa forma, pero si se pueden considerar.
 Estimación: La estimación es el número de horas o puntos
estimados para completar la tarea.
 Valor: El valor es una forma con la que indicar la importancia
que tiene la tarea para el cliente. Junto con la estimación
ayuda al Product Owner a asignar o cambiar la prioridad.
 Criterios de Validación: Los criterios de validación indican los
aspectos que deben tenerse en cuenta para que la tarea se
considere como terminada.
  SPRINT BACKLOG—cuales de esas tareas que se tienen en el
producto backlog se trabajaran en el sprint, se toman algunas
de ellas y se llevan al sprint backlog.

Profundizando en el producto Backlog.

En la

imagen anterior se ilustra la estructura del Product Backlog o por su traducción al

español “Pila del producto”, como bien lo dice su nombre es una especie de pila que
organiza la información de acuerdo a su prioridad. Claramente, la prioridad va arriba y
lo no prioritario está unos escalones por debajo, el motivo de esto último es que no
vale la pena invertir tiempo y esfuerzo en detallar los requisitos de una historia de
usuario hasta que comience su implementación, ya que cuando obtengan la etiqueta
de “prioritario” probablemente el cliente ha cambiado características que cambian
sustancialmente el rumbo de la historia creada inicialmente.

En la infografía anterior, se observa cada uno de los roles implicados en el

equipo Scrum, en la parte izquierda se encuentra el dueño del producto (Product
Owner) que define la lista de tareas en la pila del producto (Product Backlog), a partir
de aquí empieza el equipo de desarrollo (Development Team) a trabajar en el Sprint,
teniendo en cuenta que cada día el facilitador (Scrum Master) debe realizar una
reunión para facilitar la transparencia de la información y la colaboración entre los
miembros, finalmente se realiza una reunión retrospectiva para analizar los puntos a
mejorar y posteriormente se entrega el incremento del producto.