archivo

Archivo de la etiqueta: metodología ágil

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 se trata tanto de creer en los enfoques ágiles en el desarrollo de software como de entender y aceptar su ley natural que no es otra que la incertidumbre.

Si se acepta que todo plan puede venirse abajo una o más veces en el proceso de desarrollo y que las causas que lo pueden provocar están en muchos casos fuera de nuestro alcance (en cualquier caso debemos intentar prever los riesgos y evitar su materialización en lo posible) estaremos entendiendo que el proceso de desarrollo de software se realiza en un contexto de incertidumbre en el que necesariamente tendremos que estar preparados para adaptarnos al cambio cuanto antes y con el menor coste posible.

Hay circunstancias que terminan por reventar un proyecto sobre todo si no se quiere asumir presupuestariamente el coste del cambio. Precisamente este hecho es una causas que incide más negativamente en la calidad del producto final ya que por regla general los responsables funcionales entienden de manera muy alegre que el presupuesto inicial soporta todo, algo que no es cierto, ya que si bien pueden intercambiarse los cambios por determinados desarrollos que se tuvieran previstos, llegará un momento donde ese intercambio ya no sea factible. También es posible tener un cierto fondo económico de maniobra en el contrato para estas circunstancias, sin embargo, no suelen ser muchos los contratos que se firman teniendo en cuenta esto y tampoco existe la garantía de que la cantidad provisionada sea suficiente.

Sabemos que hay incertidumbre, que el impacto de la materialización de determinados riesgos afecta al proceso de desarrollo y que es necesario dar una respuesta al cambio. A partir de ahí que cada cual adopte el camino que entienda que es el más adecuado para afrontar esto, ya sea en términos generales como en las circunstancias particulares de un proyecto.

Mi camino lo marca el manifiesto ágil.

Producto, siempre el producto, por encima de los procesos, sin que estos deban obviarse o dejarse de lado.

Se ha enfocado y asociado de manera errónea la calidad del producto a la calidad del proceso, lo que ha provocado que los esfuerzos se hayan centrado en el proceso, de tal forma que en muchos casos se considera un fin y no un medio para conseguir el verdadero objetivo que es desarrollar software de calidad.

Y todavía peor que eso, se asocia en muchos casos la calidad del proceso a la cantidad del papel generado y por tanto, de manera transitiva, el producto software era tan bueno como kilos de papel se hubieran generado en el desarrollo.

Por ese motivo, la realización de análisis o conclusiones finales sobre proyectos que se centren exclusivamente o principalmente en aspectos procedimentales me parece un error, entre otras cosas porque incluso en aquellas circunstancias en las cuales el proyecto haya ido bien y haya sido a nivel de proceso ejemplar nos podemos encontrar con que el producto final es muy costoso de mantener por tener una deuda técnica alta o por tener una arquitectura no escalable.

El proceso debe estar al servicio del producto y a las necesidades que se tengan en su proceso de desarrollo, las cuales estarán muy condicionadas por las circunstancias y contexto en que se realiza.

Es cierto que está haciendo daño a la extensión de los enfoques, prácticas y metodologías ágiles el hecho de que se considere la aplicación de estas estrategias como el martillo de oro que resuelve todos los problemas relacionados con el desarrollo de software y que permite conseguir que todos los proyectos terminen con éxito.

Nada asegura de antemano el éxito, la agilidad tampoco. Todos hemos tenido éxitos y fracasos con enfoques clásicos en el desarrollo de software y también los tendremos con enfoques ágiles.

Entonces, ¿qué aporta la agilidad? una aproximación más natural a las características inherentes al proceso de desarrollo de software y por tanto, proporcionarán unas soluciones más acordes a la problemática que nos encontraremos en los proyectos. Siempre será más fácil alcanzar una meta remando a favor de corriente, siguiendo un recorrido natural que aplicando enfoques o metodologías que no se adaptan a la naturaleza del desarrollo de software.

Es importante, desde mi punto de vista, que en las tareas de difusión de los enfoques ágiles de desarrollo de software se incida precisamente en lo que aporta al proceso de desarrollo como consecuencia de asumir que éste se realiza bajo un contexto de incertidumbre y dejando claro que la misma puede acabar con el proyecto y el producto incluso habiendo aplicando principios o metodologías ágiles de manera adecuada y que la propia aplicación de los mismos no significa nada si el contexto no acompaña o si la ejecución de sus prácticas o del propio producto no se realiza de manera adecuada. Son muchos puntos donde se puede romper la cuerda.

Agilidad, sí, realidad, también.

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.

El enfoque de planifico todo el proyecto, realizo todo el análisis y después diseño, construyo e implanto está todavía presente en una gran cantidad de personas de nuestra industria.

Muchos desarrolladores recién llegados ven el proceso de desarrollo con ese enfoque, sin embargo el problema no son ellos, tienen todavía mucho tiempo para cambiar, sino personas que se dedican a esto desde hace mucho tiempo y que, como suele pasar en las organizaciones, con el paso de los años han alcanzado responsabilidades directivas.

Quien se ha criado en metodologías clásicas, quien ha trabajado durante muchos años con ellas le resulta muy complicado cambiar sobre todo si se está alejado ya del día a día de los proyectos de desarrollo de software. Con el paso del tiempo todo se idealiza, algo que además si no tiene mucho espíritu crítico te puede llevar a pensar que realmente no fueron tan mal todos esos proyectos en los que trabajaste y que utilizaron enfoques clásicos.

Por otro lado, en el área usuaria o funcional, el enfoque de los proyectos en los que trabajan que serán en su mayoría no software también será, por regla general, de tipo totalista, es decir, contrato un trabajo, lo ejecutas de una vez y adiós.

La aplicación de enfoques ágiles se encuentra con esta resistencia, personas que no terminan de entender por qué aplicas esa estrategia, personas que se sienten más cómodas trabajando sobre una planificación general, independientemente de que la misma nunca se cumpla o que el producto final se parezca bien poco a las expectativas que se tenían sobre el mismo.

Para que proyectos con este enfoque puedan llevarse a cabo es fundamental que todas las partes implicadas en él entiendan, comprendan y compartan que esta forma de entender el desarrollo de software es la que mejor se adapta a su incertidumbre inherente y por tanto, es la que de forma más probable te llevará al cumplimiento de los objetivos.

En general, apliques la metodología que apliques es fundamental que todas las partes remen en la misma dirección, de lo contrario a las resistencias que te vas a encontrar en el propio proceso de desarrollo tendrás que sumarle que estaréis solos tu equipo y tú para poder vencerlas y que las otras partes, por regla general, lo que harán será sumar más resistencia.

Kent Beck, describe todo esto de la siguiente manera: “El software es inherentemente poco fiable y los clientes están condicionados a aceptarlo. Los desarrolladores están condicionados a aceptarlo. Los testers están condicionados a aceptarlo”.

Muchos críticos de los enfoques y/o metodologías ágiles lo son porque no terminan de entender como “algo serio” unas actividades de desarrollo de software que no están sustentadas sobre unos procesos sólidos, resultados de años y años de experiencia e investigación en este campo.

Las metodologías ágiles sistematizan determinadas actividades (lo que de por sí podría encajar en el concepto de proceso) pero los que las aplican tratan de ajustar su práctica y sus actividades al contexto organizativo en el que se trabaja y a la naturaleza de los proyectos, en un enfoque orientado a la mejora continua de las mismas porque a través de ellas se conseguirán mejores resultados.

No se trata, por tanto, de normas o procedimientos absolutamente ortodoxos que siguiéndolos a modo de receta de cocina nos llevan hacia el éxito del proyecto. El desarrollo de software sabemos que no es así.

Me gusta mucho la siguiente cita del desarrollador Marc Hamann ya que resume en pocas palabras este punto de vista: “La agilidad no es una ley ineludible de pureza, pero sí un principio práctico de efectividad”.