archivo

Archivo de la etiqueta: metodología ágil

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

Pocas citas reflejan de manera tan contundente la realidad del proceso de desarrollo de software (traducción libre): “De lejos, el motivo principal para no liberar pronto es la resistencia a pasar del sueño del éxito a la realidad del feedback”.

Y esto es así, en los papeles todo puede llegar incluso a encajar y podemos dejarnos seducir por el pensamiento de que ya solo queda traducir a un lenguaje de programación (que no es poco) las especificaciones recogidas al usuario.

La realidad es bien distinta cuando el usuario se enfrente al producto y este no hace lo que esperaba y/o su experiencia de uso es nefasta y la probabilidad de que esto ocurra es mayor cuanto más tiempo pase desde que se realizó el análisis y cuanto más inestable sea la estructura organizativa del cliente y/o sus procesos.

El camino no es otro que asumir que el desarrollo de software es evolutivo, siempre con intención, siempre tirando a dar, admitiendo que a veces será necesario desandar parte del camino con el objetivo de no perdernos y llegar a la meta.

Me parece muy interesante la siguiente cita del que fuera presidente y general américano Dwight David Eisenhower: “En la preparación para la batalla siempre he encontrado que los planes son inútiles, pero la planificación es indispensable”.

¿Por qué? Pues porque el establecimiento de objetivos y metas y la definición de escenarios son elementos puramente teóricos y que se pueden desmoronar cuando determinados detalles inesperados entran en escena.

La planificación es la capacidad de distribuir tus recursos y tu esfuerzo en función del escenario en que te encuentras en ese momento, de lo que has hecho hasta ahora y de lo que pretendes conseguir. No es una visión cortoplacista sino adaptativa.

Si el usuario no tiene en cuenta lo que cuesta cambiar de opinión, equivocarse y en general la adaptación de la solución disponible en cada iteración a una que se aproxime cada vez más a sus expectativas estamos entrando en el juego peligroso de la barra libre ficticia, ya que llegará un punto donde por parte del proveedor no se pueda asumir más gasto y generalmente se avisará al cliente demasiado tarde (siempre será demasiado tarde).

Cuando se llega a esa situación el resultado en la mayoría de los casos será desgaste por ambas partes y un producto final que no dejará contento a nadie.

¿Una posible estrategia? Que el cliente (tanto el responsable técnico como los responsables usuarios) tengan conocimiento y estén de acuerdo con el coste que tiene llevar a cabo las especificaciones realizadas en cada iteración (una por una) y que como se partirá de un presupuesto de partida fijo a cambio de qué se llevan a cabo esos ajustes (ver artículos relacionados con la contratación ágil).

No se trata de poner al cliente o al usuario bajo la presión de tener que acertar siempre, eso no sería ni realista ni ágil, sino de que entiendan que se tienen que tomar muy en serio su rol en el proyecto y que la evolución del producto no se lleva a cabo mediante prueba y error, sino con intención.

La resistencia vista desde distintas perspectivas, como por ejemplo el tiempo de más que tarda en pasarse a producción un producto o todas aquellas dificultades u obstáculos extras en el proceso de desarrollo, que puede ir desde la deuda técnica hasta la falta de colaboración por parte de los usuarios, dificulta el establecimiento de ciclos cortos en un enfoque iterativo e incremental.

Esto al final es como la pescadilla que se muerde la cola, ya que cuanto más largo sea el ciclo, mayor número de funcionalidades se incorporarán o se modificarán y alimentarán, por ejemplo un paso a producción más largo.

No entro a valorar en término cuantitativo qué es un ciclo corto o qué es un ciclo largo porque opiniones hay para todos los gustos, como también las hay para determinar si todas las iteraciones dentro de un proyecto deben tener la misma duración o no.

Si se quieren ciclos cortos y que estos sean efectivos (que sean resolutivos de cara a las expectativas del usuario) hay que disminuir la resistencia y eso no es una cuestión simple, sobre todo si se parte de la base de que se intenta aplicar este enfoque de desarrollo en proyectos que se encuentran en una etapa avanzada o que se encuentran en fase de mantenimiento.

Disminuir la resistencia debe ser siempre un objetivo a tener presente, sobre todo condiciona de manera grave el proceso de desarrollo. Si es importante en todos los casos, lo es todavía más cuando se pretende liberar nuevas versiones del producto cada poco tiempo.

Disminuir la resistencia implicará actuaciones no funcionales (y eso será necesario tenerlo en cuenta y explicarlo muy bien al usuario), como por ejemplo automatizar en lo posible la instalación de la aplicación en los diferentes entornos, la automatización en la ejecución de las pruebas partiendo desde las pruebas unitarias y subiendo cuantos niveles sean precisos, la realización de pruebas manuales en aquellos casos donde no llegue o no sea rentable automatización, la refactorización, etc…

También obligará a realizar diversas tareas de gestión para intentar agilizar los procesos y las actividades de las diferentes personas y roles que participan en el proceso de desarrollo y de implantación y aceptación del sistema.

Hace poco, a modo de crítica sobre el enfoque ágil en el desarrollo de software, me comentaron que la visión ágil está centrada en el corto plazo, dejando de lado lo que es el medio y el largo plazo tanto en la realización de un proyecto como en lo que el sistema de información en sí.

No estoy de acuerdo, ser agilista y cortoplacista no es lo mismo, es más, no tienen nada que ver. Tener la capacidad de adaptarte rápido al cambio y hacerlo cuando es preciso no es ver las cosas a corto plazo sino actuar lo antes posible antes de que el problema vaya a más.

Es más, no se puede ser ágil sin tener una visión a medio o largo plazo, ya que precisamente se trata de actuar con intención, con el enfoque en conseguir los objetivos y para ello hay que saber hacia donde se quiere ir, para ello hay que ir de la mano con un plan, que estará sujeto a las sucesivas adaptaciones que sean necesarias hacer en el mismo, no de manera arbitraria, sino en respuesta a una situación.

Existen reglas en la organización en la que estamos trabajando y tenemos que cumplirlas, otra cosa es que se abra un debate interno sobre la necesidad de relajar ciertos aspectos que se controlan en los procesos y que dificultan un desarrollo ágil de los proyectos sin que exista un beneficio evidente en unos procesos tan rígidos.

Si ese debate interno no existe, se debería iniciar, siempre con un máximo respeto ante las personas que se encargan de supervisar el cumplimiento de los procesos y que también son los encargados de su actualización.

Con respeto se pueden cambiar las cosas, sin respeto tal vez también se consiga pero se abrirán brechas que tardarán mucho en cicatrizar y que afectará la relación entre personas, lo que a su vez impactará en los proyectos.

Dentro de esas reglas, se encuentran las relacionadas con la documentación de los proyectos. Por muy rígidas que sean siempre tendremos nuestro margen de maniobra en la revisión del contenido del documento, en aspectos formales o en el continente tengamos poco que hacer ya que probablemente sea revisado por terceros en base a una serie de reglas definidas. Mi consejo es que valores realmente si el contenido cumple el propósito que se pretende con él y no pierdas el tiempo en revisar aspectos formales adicionales a los definidos en las reglas (yo he hecho eso y es un error, ya que no aporta nada y supone un esfuerzo extra tanto para ti como para el desarrollador).