archivo

Archivo de la etiqueta: agilidad

Si entiendes que la simple aplicación de una metodología te hace ágil es que no has entendido realmente lo que es ser ágil. El simple hecho de esconderte tras una metodología, de seguirla como si fuera un dogma te deja desarmado ante la adaptación al cambio porque más allá de la misma te encontrarás el vacío.

Precisamente la explosión de las metodologías ágiles ha sido un arma de doble filo, por un lado ha servido para extender el mensaje y por otro ha podido dar lugar a una mala interpretación del mismo por parte de quienes las practican.

La agilidad no tiene ataduras, puedes usar una metodología pero la misma estará a disposición del proyecto y del contexto y no al revés, ¿que hay que cambiar? si hay causa justificada se cambia y no pasa nada.

No siempre vas a poder aplicar metodologías ágiles porque para ello se tienen que dar una serie de circunstancias en el proyecto que no siempre se producen, eso lo sabemos, ¿tenemos que renunciar entonces a ser ágiles? En absoluto. Nuestro background es ágil y si las circunstancias lo permiten tendremos la oportunidad de aplicar sus fundamentos y principios, tal vez no todos, tal vez en parte, tal vez en alguna ocasión.

La agilidad tampoco es ausencia de metodología porque tener unas reglas del juego proporcionan dinamismo al equipo (que se romperá cuando se quiere mantener una reglas que no sirven para el juego que está ahora mismo sobre el tapete).

La agilidad también consiste en entender que puede haber otros puntos de vista, otra forma de hacer las cosas y en la libertad de cada uno de aplicar las prácticas, estrategias y herramientas que consideren más adecuada al contexto del proyecto.

Siempre hay un desencadenante, un artículo, un libro, una conferencia, unas prácticas que observas en terceros (en mi caso fue la lectura del Manifiesto Ágil) que lo único que hace es poner frente a ti una realidad que sentías, que llevabas dentro pero que la formación que recibiste, la forma en que se enfocaban los proyectos en los que trabajabas, lo tenían a un lado.

Ya estabas cansado de proyectos con desgaste, de proyectos con éxito exiguo, de fracasos pese a que te dejaste la piel en ello. Necesitabas algo que te hiciera creer de nuevo en el desarrollo de software, algo que fuera natural a él y eso lo encontraste en la agilidad.

La agilidad es ciertamente un proceso. Lleva su tiempo. La agilidad no es aplicar una metodología concreta, la agilidad es una forma de entender el desarrollo de software en la que lo importante son las personas y el producto y en donde todo lo demás aún siendo importante son instrumentos a nuestra disposición para ser utilizados o no de una u otra forma en función del contexto en el que trabajemos.

Si tu formación no ha sido clásica, si has tenido siempre la suerte de trabajar de esta forma lo verás como lo más natural del mundo, quienes venimos del otro lado la agilidad nos ha devuelto la ilusión.

La ilusión por una forma de entender este trabajo aún sabiendo que cada proyecto es un mundo y que nada asegura que pueda resultar un fracaso.

La agilidad no viene de la noche a la mañana, ya venías aplicando técnicas ágiles como ya se venían haciendo desde muchos años antes del Manifiesto Ágil y tiempo después de ese momento en el que descubriste este mundo seguirás teniendo actitudes lejos de la agilidad. Es un proceso con el que hay que tener cuidado porque puede parecer que es la piedra filosofal que convierte cada proyecto en oro y sin embargo no es así, se sientan unas bases que después tienes que aplicar dentro de un contexto que puede ser variable y con unas restricciones de fondo y en ese mar puedes naufragar, de hecho naufragarás tarde o temprano y más de una vez, no lo dudes.

Muchas veces cuando se cuestiona la visión ágil en el desarrollo de software parece que se viene a decir que los agilistas desean el cambio y que si no lo hay, ellos mismos se encargan de que lo haya.

Mi opinión es que no es así. A todos el mundo le encantaría tener una receta que siguiéndola de principio a fin diera lugar a un proyecto con éxito. Si tuviéramos esa receta la aplicaríamos porque ¿para qué complicarnos la vida?. El cambio da lugar a quebraderos de cabeza, la línea recta es mucho más sencilla, el cambio por regla general no gusta, no es cómodo, salvo en aquellos casos donde el camino iniciado sea incorrecto o estemos en una situación en la que no lleva a ningún sitio. Es decir, el cambio (provocado) solo cobra sentido si es para mejorar un determinado estado o situación

El cambio es el resultado de que todo está en “movimiento” bajo un contexto de incertidumbre (no sabemos qué va a pasar, podemos tener sospechas o predicciones, tener los riesgos bajo supervisión e incluso con contramedidas, pero no es posible tener todo bajo control): el proyecto, el cliente, el negocio, nuestra propia organización, los usuarios, nosotros mismos, etc… Si estos cambios afectan al proyecto hay que reaccionar y cuanto antes mejor y para que la adaptación sea rápida se requiere flexibilidad, actitud y orientación al producto, además de unas condiciones de partida que faciliten (permitan) el cambio: procesos que permitan realizar los ajustes rápidamente, equipos de proyecto que tengan conciencia de la realidad del desarrollo de software, una arquitectura y un software mantenible, etc…

La agilidad vista como una orientación al producto exacerbada donde nada ni nadie importa por conseguir un resultado favorable no es agilidad, llamadlo como queráis, pero no agilidad.

Claro que importa obtener un producto que satisfaga las expectativas del usuario además de otras condiciones (mantenibilidad, robustez, etc…) pero no hay un solo camino para conseguirlo aunque generalmente se opte la mayoría de las veces por el más corto y es no tener en cuenta prácticamente nada más que el sistema que se está desarrollando como si fuera un elemento aislado dentro de la organización.

¿Cuál es el resultado de esto? La fragmentación de los sistemas de información y de los datos que gestionan. En el primer caso es una deuda técnica que generalmente nunca se tiene en cuenta pero que es real en el momento en que te pones a pensar en la diversidad de tecnologías que se terminan utilizando, de la compatibilidad con navegadores, servidores de aplicaciones, servidores de bases de datos, etc… En el segundo caso dificulta la realización de consultas integradas de información y os aseguro que los Datamart pueden ayudar a eso pero no hacen milagros.

¿Por qué el camino más corto? Pues porque es el más fácil, no dependo de nada así que quito resistencia al desarrollo del proyecto que bastante tiene ya de manera inherente, además siempre habrá una excusa (porque seguro que hay motivos para ella) para alegar que es la mejor solución porque no es fácil integrarse con terceros sistemas cuando estos están gestionados por otras personas con otros intereses y la existencia de situaciones de bloqueo, de falta de entendimiento y dificultades a nivel técnico o de datos para integrar son riesgos que de alguna u otra manera suelen materializarse cuando tenemos en cuenta estos factores.

¿Cuándo se actúa de manera adecuada? Cuando de la manera más objetiva posible se entiende que lo mejor (haciendo balance entre beneficios e inconvenientes) para el proyecto y para el producto teniendo en cuenta la organización y dentro del contexto actual.

El enfoque evolutivo del desarrollo de software desde una perspectiva ágil consiste en ir descubriendo el camino hacia el cumplimiento de las expectativas de usuario a través de la oscuridad de la incertidumbre que rodea a los proyectos, de la resistencia que encontremos y de los cambios de dirección y sentido que provocan los cambios de contexto.

La brújula es el feedback sobre iteraciones del producto teniendo como base nuestro background como desarrolladores de software y la intención con que se afronta cada evolución del sistema (una cosa es tener que descubrir el camino y otra no tener muy claro realmente a dónde se quiere ir) y nuestro motor el funcionamiento real como un equipo de trabajo.

Los enfoques clásicos, predictivos por naturaleza, entienden que desde el principio se sabe cómo llegar al producto que se desea y que en cualquier caso a lo largo del proceso de desarrollo se podrían realizar ligeros ajustes.

La realidad que nos encontramos en los proyectos de desarrollo de software nos indica que en la mayoría de los casos no se sabe qué es lo que se quiere realmente (o por lo menos con la suficiente precisión como para poder plantear un enfoque clásico) y que el camino para llegar a ese objetivo tiene muchas curvas, subidas y bajadas, asfalto de distinta naturaleza y diferentes condiciones climáticas.

Muchas personas contrarias a las metodologías o enfoques ágiles utilizan como argumento que la agilidad es una puerta abierta a la entrega de versiones de productos deficientes bajo el amparo de un enfoque evolutivo del desarrollo de software basado en la aproximación sucesiva a la versión final de producto y el feedback o dicho de otro modo: como vendrán nuevas oportunidades de seguir evolucionando el software no me esfuerzo por entregar un buen producto (ya se arreglará o ya se mejorará).

Pues no, no es así. Quien hace eso yo no lo considero agilista (opinión personal), es más puede que no lo considere incluso un buen profesional.

La agilidad requiere desarrollos con intención. La intención es la aproximación a un objetivo tirando a dar, minimizando la especulación. Un desarrollo con intención no se puede sustentar en entregas de calidad deficiente porque de lo contrario la evolución del producto será muy lenta y la capacidad de adaptación al cambio, por tanto, disminuye.

No lo es, aunque muchas veces te lo llegas a plantear.

Cuando piensas de una manera y después la mayoría no lo piensa o lo siente así se te pasa por la cabeza que tal vez estés haciendo algo equivocado.

Vengo de una formación con una visión clásica del desarrollo de software, mi trayectoria profesional ha estado centrada desde sus inicios en ese tipo de enfoque, he visto las consecuencias de ese tipo de estrategias en primera persona, no desde las trincheras sino hundido dentro de ellas.

Tal vez veo las cosas desde el extremismo del converso pero la agilidad me ha traído aire fresco, una nueva forma de entender el desarrollo de software. Es posible que muchos que se han criado ya en entornos ágiles no lo puedan apreciar pero desde mi punto de vista el enfoque ágil es el enfoque natural para los que entendemos que el desarrollo de software es algo más que ejecutar un trabajo, es posible que unos tardemos más que otros en darnos cuenta, pero al final terminamos descubriendo como si de una visión se tratase que ese es el camino adecuado (claro que habrá proyectos donde sean más válidos otros enfoques, no discuto eso) por ese motivo los enfoques ágiles ya existían mucho antes del manifiesto ágil.