Asimilar la agilidad I

La verdad es que resulta muy cool en algunos ambientes empezar a hablar de Scrum, Kanban, XP, Lean, WIP, sprints, pila de producto, kaizen, agile, deuda técnica, etc… porque se da la sensación de que se está al día en un mundo tan cambiante como el del desarrollo de software, aunque otra cosa es que realmente se sepa lo que hay detrás de esas palabras y eso le pasa a muchos porque leer un libro o recibir un curso aunque puede ser importante, no termina de ser suficiente.

Agile hay quien lo considera una moda y no sé si quien piensa eso está equivocado o no, porque si bien es una tendencia sobre la cual hay cada vez más gente interesada en seguirla, no debemos olvidar que el manifiesto ágil es del año 2001 y que sus valores y principios eran ya aplicados por desarrolladores desde mucho antes.

Subirse a la ola del agilismo puede ser algo relativamente sencillo, sin embargo se requiere un tiempo (y experiencias) para poder asimilar sus fundamentos, y de esta manera que realmente llegar a comprender por qué hay cada vez más personas y organizaciones que tratan de utilizarlo en base a los beneficios que proporciona.

La agilidad no es algo a lo que se accede por la aplicación de determinadas prácticas que se puedan considerar ágiles, sino que necesita de algo más, porque realmente se trata de otra forma de entender el desarrollo de software y eso no se consigue de la noche a la mañana.

De esta forma se puede ser ágil en cualquier contexto, incluso en aquellos casos en los que en un proyecto concreto te impongan la aplicación de un enfoque clásico, ya que existirán circunstancias y momentos en los que ante un determinado problema o una determinada decisión se les pueda dar un enfoque ágil y pese a los obstáculos que te puedas encontrar o que te puedan separar con otras personas, nada impide que te crees tu propia visión de las mismas y de cómo debería ser tu relación con ellas.

Con la aplicación de metodologías ágiles se puede empezar a descubrir todo lo que puede aportar a un proyecto y también, por qué no decirlo, a nosotros mismos, porque varía la forma en que interactúan y se comunican las personas dentro y fuera del equipo de desarrollo y se sitúa al producto en el lugar que le corresponde.

El procedimiento o la metodología queda en un segundo plano, como un instrumento, con mayor o menor importancia en cada caso, pero al fin y al cabo como un instrumento.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: