Diferenciando agilidad y metodologías

No vale con asistir a seminarios, cursos, certificarte, leerte varios libros y/o haber participado en algún proyecto donde se haya aplicado un enfoque ágil.

Todo lo anterior te contextualiza, te ofrece información, conocimientos, incluso experiencia, pero la agilidad se construye (o destruye) con el tiempo.

El tiempo te permitirá participar en proyectos distintos con problemas, personas y condiciones de partida diferentes a los que te habrás tenido que enfrentar aplicando diversas soluciones, en algunos casos, incluso contrapuestas.

Ahí es donde te darás cuenta, entre otras muchas cosas, que la agilidad pasa por flexibilizar el uso de determinadas técnicas o metodologías (si tratas de aplicar, por ejemplo, Scrum en el 100% de los casos y situaciones probablemente te estarás equivocando), que algunas veces es necesario afrontar, temporalmente o para tareas concretas, enfoques en los que se mezclen tanto el mundo clásico como el ágil.

Precisamente, y hablo ya en primera persona, el tiempo me ha permitido entender y diferencias la agilidad de las metodologías, algo que resulta fundamental para ser verdaderamente ágil. Si te encierras en la metodología estás acotando tu margen de maniobra, tu agilidad para responder al cambio, para dar respuestas, para poder cambiar o mejorar la relación con las personas de tu equipo o de otros, etc…

La agilidad es la base, las metodologías, técnicas, prácticas o estrategias son solo instrumentos.

Teoría y práctica en el desarrollo de software

Las metodologías y prácticas son modelos teóricos que si bien han podido ser probados con éxito en situaciones particulares, difícilmente resultan exportables, tal cual, a todo el conjunto de proyectos. Por ese motivo, la adaptación al contexto y la adaptación al cambio resulta fundamental a la hora de seleccionar el método de trabajo.

Por este motivo, cuando se trata de imponer ciertas dinámicas de trabajo suelen no conseguir resultados porque muchos proyectos o situaciones dentro de los mismos no terminan por encajar y al final no se consigue ni respetar esa dinámica, pero tampoco esquivarlas completamente afectando directamente al proyecto y con ello, muy probablemente, a sus resultados.

¿Quién está libre de no haber caído en ese error? Yo he sido el primero que ha caído en ello, empezando en la aplicación de metodologías de enfoque clásico e incluso con las metodologías aǵiles (algo que va contra natura de lo que el agilismo pretende y en lo que se cae con demasiada frecuencia).

Como decía Séneca: «Largo es el camino de la enseñanza por medio de teorías; breve y eficaz por medio de ejemplos».

Por este motivo es difícil acertar a la primera porque al principio te basas en fundamentos teóricos: lo que leiste en un libro o lo que escuchaste en aquella conferencia, etc… Al final, la experiencia te pondrá en tu sitio, siempre y cuando decidas aprender algo de la misma.

¿Están los agilistas obsesionados con los procesos?

Una de las mayores críticas que se tiene hacia los agilistas es que se considera que están obsesionados por el proceso, hasta tal punto de contravenir el siguiente principio del Manifiesto Ágil: «Valorar a los individuos y su interacción, por encima de los procesos y las herramientas».

No estoy de acuerdo con esa crítica porque hace una generalización que creo que no se ajusta a muchas realidades. Si bien tiene un trasfondo real y es el hecho de que se considera agilistas a muchas personas por el mero hecho de trabajar con metodologías ágiles y como he comentado ya en diferentes artículos: «la agilidad es cuestión de actitud y no de metodología«.

La aplicación de metodologías ágiles es una aproximación pero depende mucho del enfoque con el que se trabaje con las mismas y de quiénes intervengan en el proceso.

Si no entiendes o conoces el trasfondo de lo que significa ser ágil la respuesta no te la va a dar ninguna metodología y si te encierras en ella, probablemente estés dando pasos en el sentido equivocado.

Desarrollo de software. Ágil no es lo mismo que iterativo incremental

Lo primero, como he repetido en diversas ocasiones, agilidad es actitud y eso es una capa o un filtro por encima de cualquier metodología, lo que permite que tengamos la posibilidad de aplicar principios ágiles o al menos seguir una mentalidad ágil en cualquier proyecto (tener la posibilidad no quiere decir que le demos la vuelta al proyecto como a un calcetín, las reglas del juego son las que son, pero aún así, incluso en los procesos más cerrados siempre habrá una rendija a través de la cual podamos aplicar un enfoque o actitud ágil).

Ahora bien, los principios ágiles se llevan bien con enfoques iterativos e incrementales, por eso su instrumentación en metodologías siguen este tipo de ciclo de vida. Sin embargo, la simple aplicación de la misma no quiere decir que el desarrollo sea ágil ya que lo único que hace es fragmentar el proyecto en diferentes entregas. Si el enfoque no es ágil, la aplicación del ciclo de vida iterativo incremental tampoco lo será.

Desarrollo de software. Hemos hecho lo que el cliente o usuario nos ha pedido

El producto software que se obtiene finalmente es consecuencia de las directrices que ha indicado el área usuaria. Nos habrá dado unos requisitos, a lo largo del proyecto, habrá cambiado el enfoque de algunos de ellos, otros se desecharán y aparecerán algunos nuevos. Esto es independiente de la metodología utilizada.

Sin embargo el equipo de proyecto no debe ser una serie de ovejitas que van detrás de un partorcito (el usuario), ¿dónde está el valor que aporta el equipo al proyecto? Traducir especificaciones a un lenguaje de programación tiene su complejidad, sobre todo si se hace bien, pero, ¿solo somos traductores?, ¿no somos capaces de proponer alternativas al usuario?, ¿no somos capaces de hacerle vez que tal vez determinadas funcionalidades que solicita en términos coste/beneficio no son ventajosas?, ¿no somos capaces de aportar al cliente toda nuestra experiencia?.

Es muy fácil lavarse las manos y echar toda la culpa al cliente o al usuario (que la tendrán y en algunos proyectos mucha o casi toda) pero, ¿seguro que no somos responsables de nada?.

Desarrollo de software. Metodologías ágiles y aplicaciones heredadas

Muchas personas piensan que no es posible aplicar metodologías ágiles en aplicaciones que se han heredado de otras organizaciones o de otros equipos de desarrollo que no han empleado en su desarrollo metodologías ágiles esgrimiendo como principal argumento la posible deuda técnica elevada con la que podemos encontrarnos.

Es cierto que si la deuda técnica es elevada se va a requerir más esfuerzo continuar con el desarrollo o realizar el mantenimiento, es decir, iremos más lentos (los resultados efectivos por iteración serán menores) y probablemente la capacidad de ir refactorizando el software dependerá más de la destreza de los programadores que del tiempo real disponible para realizar estas actividades.

¿Es esto incompatible con la aplicación de metodologías ágiles? Desde mi punto de vista no.

Desarrollo de software. Agilidad en la interlocución

Incluso en aquellos proyectos donde más complicado puede resultar la aplicación de principios ágiles siempre existen oportunidades en donde podremos aplicarlos, si bien su efectividad dependerá mucho del contexto del proyecto, la metodología aplicada y los procesos en torno a los cuales se realiza el desarrollo de un software para una organización.

Independientemente de la metodología que se aplique resulta de gran importancia la participación activa de los interlocutores, sin eso, en el mejor de los casos el proyecto irá a trompicones y en los peores la especificación de requisitos se encontrará llena de huecos que en unos casos tendrán reflejo directo en el producto final y en otros serán cubiertos por el propio equipo de desarrollo, en base a su interpretación del proceso que se informatiza y de la experiencia precia.

El problema en esos últimos casos es que incluso acertando en una solución aceptable, la misma no tiene por qué coincidir realmente con lo que el usuario quiere y además, siempre tendrá la oportunidad de decirte que quién te ha comentado a ti que hayas optado por hacerlo de esa manera.

Sí, lo has hecho de buena fe, lo has hecho pensando en lo mejor para el proyecto y para el usuario, pero después te encontrarás con determinados individuos que cargarán contra ti su propia irresponsabilidad y lo peor de todo, tendrás pocos argumentos de defensa más allá de reprochar su falta de implicación en el proyecto, la cual negará o minimizará, quedando ante personal directivo la palabra de uno contra la de otro y con unas funcionalidades en el desarrollo que no puedes justificar su origen.

Se dice que en contextos donde va a resultar complicado encontrar agilidad en la interlocución no es posible aplicar metodologías ágiles, vale, pero, ¿acaso sirve cualquier otra metodología?, ¿acaso esa otra metodología puede garantizar mejores resultados?, ¿acaso va a conseguir que los interlocutores participen más y mejor?.

Se podría responder que puede ser más sencillo conseguir un compromiso por parte de los interlocutores si se les dice que su participación se reducirá a un espacio concreto de tiempo, es decir, lo que dure el análisis.

Si el usuario no es bueno, hasta lo anterior será complicado de conseguir, pero incluso en el caso de que se logre, estaremos dejando el proyecto a merced de que se haya acertado en los requisitos y a todos los inconvenientes que tras de sí tiene el ciclo de vida en cascada.

Por tanto, independientemente de la metodología o enfoque a utilizar, siempre hay que solicitar y exigir la participación del área usuaria.

Aceptar un contexto en el que no exista agilidad en la interlocución por parte del usuario debe ser la última vía. Incluso si se aprecia que puede existir hostilidad en los mismos, lo mejor para todos es no abordar el proyecto.

En el caso de que se acepte el proyecto tenemos que adaptarnos a las circunstancias y resulta a priori complicado indicar si la mejor solución pasa por un enfoque ágil o clásico, será necesario evaluar el contexto y en base a eso tomar una decisión.

Desarrollo de software. La agilidad es un paraguas en la tormenta

Me comentó un compañero que los enfoques ágiles en el desarrollo de software son buenos en teoría y pueden producir buenos resultados en la práctica pero que al final presentan los mismos riesgos que un enfoque de carácter clásico.

La agilidad es adaptación al cambio en un entorno de incertidumbre mediante la aplicación de una serie de principios y de estrategias y prácticas (cuando se materializan en una metodología) pero no puede impedir precisamente ese cambio al encontrarse el mismo, en la mayoría de los casos, fuera del control de las personas que participan directamente en el proyecto.

Algunos cambios en determinados momentos del proyecto pueden terminar con el mismo, independientemente del enfoque y de la metodología. Lo que diferencia a la agilidad de otras estrategias es que por lo menos en situaciones de tormenta actúa como un paraguas que evitas que te mojes o, al menos, que te caiga menos agua, pero si el viento sopla muy fuerte no podrá evitar lo inevitable y el paraguas se terminará rompiendo.

Un enfoque iterativo incremental permite ir creando campamentos base, que son la versión del producto que se obtiene en cada iteración. En un enfoque en cascada, no tienes nada donde refugiarte.

Desarrollo de software. Contratación ágil IV

¿Es suficiente realizar estos planteamientos al cliente para que acepte el desarrollo de sistema de información aplicando una metodología ágil, teniendo en cuenta que lo mismo está acostumbrado a contratar según un modelo clásico y monolítico y existen otros proveedores que pueden aceptar esas condiciones?.

Si el cliente no conoce los beneficios de la aplicación de los principios ágiles y su instrumentación mediante metodologías podrá ver el enfoque que se plantea alejado de la ortodoxia y ya sabemos todos lo complicado que resulta salir de la zona de seguridad aunque te vaya mal en ella.

Por tanto, si existe la oportunidad de hacer pedagogía con los clientes y mostrarles las ventajas de un enfoque ágil en el desarrollo de software, no solo te estarás ayudando a ti, sino también a toda la profesión y a todo el sector.

No obstante, el desarrollo iterativo incremental ofrece diversas cartas bajo la manga que pueden resultar muy atractivas para el cliente (y también para el proveedor):

– ¿Por qué no incluir en el contrato la posibilidad de que el cliente pueda dar por finalizado el proyecto antes de ejecutar todo el presupuesto?.

Esto se puede plantear de muy diversas formas: Darle la oportunidad a que lo pueda hacer en cualquier momento, a que lo pueda hacer con un mínimo de un % del presupuesto ejecutado, etc… En cualquier caso, el proveedor debería tener como compensación, además de lo ya ejecutado, un % del presupuesto restante (salvo que se haya pactado que un incumplimiento del acuerdo de nivel de servicio pueda suponer que esa compensación se elimine).

En este planteamiento todos ganan:

Si el cliente no está contento puede anular el proyecto, si el proveedor tiene una versión del producto que le parece suficiente no tiene por qué seguir invirtiendo en funcionalidades que lo mismo van a ser innecesarias.

El proveedor en el primer caso, no conseguirá los ingresos inicialmente estimados, pero a cambio se evita el camino a ninguna parte y lleno de desgaste al que iba el proyecto. En el segundo caso, el proveedor obtiene como premio además del beneficio por el trabajo ejecutado, el % extra de la compensación (sería como una prima por hacer las cosas bien).

– ¿Por qué no abordar un modelo relacionado con el esfuerzo necesario para realizar la tarea en el que todos ganen?.

En este caso al esfuerzo planificado se le aplica un buffer de esfuerzo, de manera que si el esfuerzo es t, nos quedemos con un rango válido de [t-buffer,t+buffer]. Si se consigue terminar la tarea con un tiempo entre [t-buffer,t] el beneficio se reparte entre cliente y proveedor y si la tarea termina con un tiempo entre [t,t+buffer], se reparten los gastos.

En el caso de que se superen los límites, habría que estudiar, antes de aplicar cualquier medida el motivo de tal desviación.

Desarrollo de software. Enfoques iterativos incrementales y el concepto de proyecto, ¿conflicto?

En el artículo «¿Qué es un proyecto?» daba una posible definición de los mismos (una de entre otras tantas que se podía aplicar):

«Conjunto de actividades planificadas en el tiempo (su realización, por tanto, es gradual) que tienen como objetivo producir unos resultados (entregables) en base a los objetivos para los cuales se constituyó… Un proyecto, por tanto y por definición, debe ser finito».

Vamos a ver si existe algún conflicto con un desarrollo iterativo incremental.

– Actividades planificadas en el tiempo.

Cada iteración está planificada en el tiempo, incluso podría establecerse una planificación inicial basada en una visión optimista de que nada va a cambiar durante el desarrollo, que no se va a producir ninguna contingencia o que siempre se va a acertar. Ahora bien, dicha planificación general debería adaptarse al feedback que se obtenga del usuario en cada ciclo, no hacerlo es atentar contra el cumplimiento de las expectativas del usuario que no es otra cosa que el fin último del proyecto.

– Producir unos resultados (entregables) en base a los objetivos para los cuales se constituyó.

Esto es lo que puede crear algo más de controversia, si bien la misma controversia que puedes aplicar a un desarrollo iterativo incremental la puedes aplicar a un desarrollo en cascada que muchos consideran el paradigma de lo debe ser un proyecto.

La controversia la podemos tener en el hecho de si realmente los entregables obtenidos entre el inicio y el fin del proyecto cumplen con los objetivos que dieron origen al mismo.

Si entendemos como objetivo la obtención de una aplicación que satisfaga las expectativas del usuario (o del cliente) en base a las especificaciones que se hayan podido implementar entre un inicio y fin pactado de un proyecto (en el siguiente punto, vemos esto de manera más concreta), el conflicto lo podemos encontrar no tanto en el nivel de acabado del producto sino en el cumplimiento de las expectativas, las cuales pueden ser satisfechas o no independientemente de la metodología o ciclo de vida aplicado.

Si no se ajustan dichas expectativas (que evolucionan desde los objetivos iniciales) a un final pactado del proyecto en función de su presupuesto, plazos y contingencias que se produzcan en su desarrollo, es cuando los proyectos parecen eternizarse o no tener fin.

Por tanto al final, la consideración de si los entregables del proyecto satisfacen los objetivos iniciales, es más cuestión de sentido común aplicado al contexto del proyecto que otra cosa (por eso, porque es cuestión de sentido común y de ética, existen tantos problemas a la hora de determinar un cierre de proyecto y esto es aplicable tanto a clientes como proveedores).

– Finito. Lo son. ¿Qué delimita el inicio y el fin? Posibilidades tenemos muchas, unas más objetivas que otras:

Si tomamos como base un presupuesto de partida, el inicio es el momento en que empezamos a consumir el mismo y el final cuando lo hemos agotado. Si hay un incremento sobre el presupuesto de origen, una segunda fase del proyecto (que en realidad es un nuevo proyecto) vendría delimitado de la misma forma por el inicio y fin de ese presupuesto adicional y así sucesivamente.

Otra posibilidad es tomar como referencia la entrega de un producto final que satisfaga las especificaciones del usuario, independientemente de que algunas hubieran cambiado desde la definición del alcance del proyecto (pudiendo haber diversas entregas intermedias que pasen a producción que satisfagan determinadas funcionalidades).

Ambas posibilidades, que son dos ejemplos posibles de delimitar un principio y un fin del proyecto son perfectamente compatibles con un enfoque iterativo incremental.