archivo

Archivo de la etiqueta: metodología

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.

Anuncios

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.

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.

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á.

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?.

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.

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.