¿Qué es una Metodología Ágil?

Vivimos en un mundo donde los cambios se respiran todos los días, y últimamente, nunca sabemos
cuando de pronto puede cambiar todo. De esta manera, existen guías tradicionales de gestión de
proyectos que, en vez de ser salvavidas en momentos cambiantes, tratan de adivinar el futuro y son
por lo tanto muy rígidas. Es así como necesitamos modelos que ayuden a responder rápidamente ante
los cambios, por esta razón se crearon las metodologías ágiles.
Las Metodologías Ágiles (AMs) valoran:
● Al individuo y las interacciones en el equipo de desarrollo más que a las actividades y las
herramientas
● Desarrollar software que funciona más que conseguir una buena documentación.
● Minimalismo respecto del modelado y la documentación del sistema
● La colaboración con el cliente más que la negociación de un contrato
El ''Manifiesto ágil'':
1) Al individuo y sus interacciones más que al proceso y las herramientas:
Sin duda, la herramienta fundamental de la ingeniería del software y del desarrollo de aplicaciones es
el cerebro humano. Unas jornadas maratonianas de catorce horas de trabajo van en detrimento de la
calidad del producto final.
2) Desarrollar software que funciona más que obtener una buena documentación:
Uno de los objetivos de una buena documentación es poder ir a consultarla cuando haya que
modificar algo del sistema.
3) La colaboración con el cliente más que la negociación de un contrato:
La consultoría informática de los últimos años se ha convertido en una lucha a muerte entre el
proveedor del servicio y el cliente que lo contrata. Por una parte, el cliente intenta que se hagan el
mayor número de funcionalidades con el mismo dinero, por otra parte, el consultor intenta que por ese
dinero sólo se realicen las funcionalidades contratadas inicialmente.
4) Responder a los cambios más que seguir una planificación.
Una organización cambia constantemente, se adapta a las necesidades del mercado y reorganiza sus
flujos de trabajo para ser más eficiente. Es difícil, pues, que, en el desarrollo de un proyecto, éste no
sufra ningún cambio, ya que es seguro que las necesidades de información de la empresa habrán
cambiado.
Filosofía ágil
En la filosofía ágil, lo primordial es evitar estos fallos, centrar nuestro tiempo en asegurar que el
software funciona y que se ha testeado exhaustivamente, e intentar reducir la creación de documentos
"inútiles", de éstos que acaban no manteniéndose, ni tan siquiera consultándose. La regla no escrita es
no producir documentos superfluos, y sólo producir aquellos que sean necesarios de forma inmediata
para tomar una decisión importante durante el proceso de desarrollo. Estos documentos deben "ir al
grano", ser cortos y centrarse en lo fundamental, olvidándonos de los circunloquios que no aportan
nada a la comprensión del problema.
¿Cuándo puedo aplicar una metodología ágil?
¿Cómo? ¿No es siempre? Pues no. Como casi todo en esta vida, depende. Depende de cada proyecto
en concreto, cada uno necesita de una metodología adecuada a él que le garantice el éxito. Necesita
que se adecue no sólo a sus funcionalidades a desarrollar, sino además al equipo de desarrollo, a los
recursos disponibles, al plazo de entrega, al entorno socio-cultural, etc.
Un buen profesional no debería cerrarse en una sola metodología de desarrollo, debería analizar el
proyecto en concreto y ver cuál de todas las existentes sería la más adecuada a su proyecto. Y si
ninguna le satisface plenamente, debería de ser capaz de adaptarlas. Las metodologías son para
ayudarnos, pero nosotros debemos decidir cuándo y cómo es mejor aplicarlas.
Aun así, existen algunas reglas básicas, de "sentido común", para discernir si debemos aplicar una
metodología tradicional o una metodología ágil. Pero recordad que son simplemente una guía, no un
mandamiento
Primero debéis responder a las siete preguntas siguientes:
1) ¿Cómo es de grande vuestro proyecto?
Si es muy grande y/o involucra a muchas personas en el equipo, lo mejor es que se utilicen
metodologías más estrictas y que se basen en la planificación y control del proyecto. Si se trata de un
proyecto pequeño y/o con un equipo reducido de desarrollo, de tres a ocho personas, tenéis una
oportunidad de experimentar con los métodos ágiles.
2) ¿Vuestros requisitos son dinámicos?
Si os encontráis ante un ámbito de actuación donde los flujos de negocio están cambiando
constantemente y tenéis que adaptarlos, como podría ser una gestión de fuerza de ventas, entonces la
metodología ágil os ayudará a adaptaros. Si estáis en un ámbito en el que el dinamismo es escaso, por
ejemplo, en la creación de un sistema de contabilidad, quizás deberíais utilizar una metodología
orientada al plan que contemple los cambios previsibles y que os asegure minimizar el reworking.
3) ¿Qué pasa si vuestro sistema falla?
Si os encontráis en un sistema crítico en el que cualquier fallo involucra pérdidas humanas o grandes
cantidades de dinero, por favor, no utilizar las metodologías ágiles. Si estáis diseñando un sistema
para controlar un bisturí láser, no hay lugar para muchas pruebas, lo mejor es que funcione a la
primera y las metodologías clásicas garantizan la calidad.
4) ¿Vuestro cliente tiene tiempo para dedicarlo al proyecto?
Si no vamos a conseguir que nuestro cliente se involucre en la creación de un sistema que en el fondo
es para él, nos será imposible aplicar una metodología ágil. En este caso lo mejor es utilizar una
metodología en cascada con un gran análisis inicial.
5) ¿Cuántos júniors tenéis en vuestro equipo de desarrollo?
Las metodologías ágiles requieren de una gran madurez, experiencia y una dosis de talento. Deben ser
equipos con gente seniors o semi-seniors. Si vuestro equipo lo constituyen principalmente júniors, lo
mejor es que no lo intentéis con las metodologías ágiles.
6) ¿Cuál es la cultura empresarial de la empresa en la que se va a desarrollar e proyecto?
Las metodologías ágiles requieren de cierto ambiente "informal", que fomente la comunicación de
igual a igual. Si la organización en la que se quiere desarrollar el proyecto tiene un alto grado de
ceremonia y jerarquías estrictas, no deberíais utilizar las metodologías ágiles.
7) ¿Os apetece?
Hay que saber si realmente se tienen ganas de probar una metodología ágil. Aprender cosas nuevas
supone casi siempre un nuevo sacrificio.
Si vuestro equipo es pequeño y está formado mayoritariamente por gente con talento y experiencia, si
el cliente final está involucrado y no impone barreras de comunicación, si los requisitos son altamente
cambiantes, si no es proyecto crítico y no es demasiado grande, y os apetece probar una metodología
ágil, no lo dudéis, es el momento de experimentar esta forma de diseñar y crear aplicaciones.
Metodologías ágiles:
Scrum: Scrum es un método para solventar problemas complejos, entregando productos que
aporten el mayor valor posible. Es una metodología:
● Ligera: Scrum tiene poca teoría, únicamente define algunas reuniones o ceremonias, los
roles, y unos pocos principios básicos. El contenido teórico se lee en menos de 5 minutos.
● Fácil de entender: Es una metodología abierta, que no propone reglas complicadas ni
demasiado específicas en función del proyecto.
 ● Difícil de dominar: La clave es adaptarse correctamente al entorno y al proyecto
concreto. Por eso está definido el rol de Scrum Master, que es la figura que domina el
método y ayuda a su aplicación y ajuste.
Está basada en procesos empíricos de control, es decir, el conocimiento viene de la experiencia, y se
toman decisiones en función de la información que se tiene. Su enfoque es iterativo e incremental.
XP (Programación Extrema):
XP (del inglés "eXtreme Programming") es una metodología ágil exclusiva para el desarrollo de
software. Al igual que Scrum, considera que los cambios durante el proyecto serán frecuentes, tanto,
que se puede llegar a trabajar en iteraciones de 1 sólo día, con entregas y despliegues de los resultados
a diario, incluso en períodos más breves de tiempo. Contempla prácticas de ingeniería, valores,
actividades y roles.
Valores en XP:
● Simplicidad: Recordemos que el diseño simple es una de las premisas que se deben
seguir.
● Comunicación: El código simple y bien documento comunica a los programadores muy
bien qué funcionalidad persigue.
● Feedback: La retroalimentación por parte del cliente es inmediata, puesto que forma
parte del equipo de trabajo. Esto se refuerza porque las entregas se realizan
continuamente en períodos muy cortos de tiempo.
● Motivación: Motivación y valentía para centrarse sólo en lo necesario para la entrega de
hoy, y no para la de mañana.
● Respeto: Los programadores se respetan mutuamente porque nadie puede escribir código
que haga fallar código o pruebas de otra persona.
Actividades en XP
● Codificar: El código se construye siguiendo las prácticas de ingeniería recomendadas
(programación por parejas, refactorización, estándar de codificación, etc.
● Probar: Es fundamental que el desarrollo sea dirigido por las pruebas, por lo tanto
codificar y probar son actividades que van de la mano.
● Escuchar: Puesto que se trabaja por parejas, y también conjuntamente con el cliente, las
personas del equipo tienen que aprender a escuchar a los demás y a compartir su
información y opinión profesional.
● Diseñar: Se contempla en todo momento el diseño simple, la refactorización, el respeto
al estándar de codificación, la documentación en el código... estas actividades forman
parte del diseño del software.
Kanban
Se utiliza un "Kanban" o "TaskBar para buscar cambios de estado en el trabajo, que reflejen el
progreso y el trabajo en curso. Esta metodología consiste en la organización del trabajo diario en base
a un panel de tareas como el siguiente:
El Método Kanban no te pide que cambies tu proceso. No propone cambios en las prácticas de
ingeniería ni una nueva definición de proceso o estilo de trabajo
Kanban es una traducción libre del japonés de “cartas". Es una parte fundamental del flujo tenso
(pull). Se diseña para evitar la sobreproducción y para asegurarse de que los componentes pasan de un
subproceso al siguiente en el orden adecuado.
El flujo tenso del producto desde aguas arriba se indica mediante un kanban de retirada (withdrawal).
El flujo tenso del cliente retira componentes del “supermercado”; éste se define como un lugar de
capacidad limitada para almacenar el producto proveniente del proceso de suministro. El
supermercado se rellena emitiendo un kanban de producción cuando el inventario es demasiado bajo.
Este kanban de producción da la orden adecuada al proceso de suministro para producir más
componentes. El proceso de suministro emite las unidades necesarias para reponer lo extraído. Este
método evita la sobreproducción, pero permite un inventario rígido que se sitúa entre los procesos de
suministro y del cliente.

Page Break

Bibliografías:
https://tentulogo.com/cuales-son-las-metodologias-agiles-y-por-que-son-beneficiosas-para-
tu-empresa/
http://zeus.inf.ucv.cl/~bcrawford/AULA_ICI_3242/Met_Agiles_Crawford.pdf
https://www.exabyteinformatica.com/uoc/Informatica/
Tecnicas_avanzadas_de_ingenieria_de_software/
Tecnicas_avanzadas_de_ingenieria_de_software_(Modulo_3).pdf