Aplicar prácticas ágiles no convierte a tu proyecto en ágil

“Estoy desarrollando el proyecto aplicando metodologías ágiles“. Tanto si es cierto o no, no implica que el proyecto sea ágil porque la agilidad, vuelvo a insistir una vez más, no se encierra entre las paredes de una metodología.

Trasciende a la metodología, por eso siempre tenemos la oportunidad de aplicar una visión ágil a los problemas, independientemente de las restricciones que tengamos para poder poner en práctica la solución que nos parezca más apropiada. No olvidemos el contexto, no olvidemos tampoco que existen unas reglas.

Seguir una metodología o determinadas prácticas ágiles es cierto que pueden crear un clima que favorezca la realización de un proyecto siguiendo los valores y principios ágiles pero nada más, el resto del camino no se hace solo.

De hecho muchos de esos proyectos autoproclamados ágiles no se diferenciarán mucho de los enfoques clásicos o de una visión clásica del desarrollo de software, más allá de que se siga un enfoque iterativo incremental.

Muchos fracasos que se achacan a proyectos realizados siguiendo supuestamente un enfoque ágil no deberían sumarse a sus estadísticas, ya que como decía en el párrafo anterior, son enfoques clásicos tuneados o híbridos de difícil clasificación (por muy ortodoxa que sea la aplicación de una determinada metodología).

Por eso, no paro de repetir que es fundamental entender las bases del agilismo porque de esta forma la aplicación de cualquier práctica o metodología ágil es más efectiva y te proporciona un mayor número de recursos a la hora de tomar cualquier tipo de decisión, sea cual sea la situación o proyecto en el que te toque trabajar ya que no siempre se van a dar las circunstancias más idóneas para aplicar tu esquema o método de trabajo favorito.

Ley de Gall II

La Ley de Gall se adapta perfectamente a los enfoques de desarrollo iterativo incrementales, si bien, y como os he comentado otras veces, la estrategia o metodología no sirve para nada si en la práctica no se toman decisiones efectivas.

Es decir, si el planteamiento del desarrollo no está basado en el intento de buscar las alternativas más simples que solucionen el problema y satisfagan las expectativas el usuario, nos encontraremos finalmente con un sistema más complejo del necesario, lo mismo si tratamos de construir la aplicación por el tejado sin haber trabajado previamente con funcionalidades que pueden ser igual o más prioritarias y en donde malas decisiones y/o implementaciones pueden condicionar sensiblemente el resto del sistema.

Es cierto que al ser un desarrollo de tipo evolutivo la complejidad se añade por incrementos y se tiene la oportunidad de rectificar a tiempo (el coste siempre será mucho menor que con el producto desarrollado de manera completa o con una buena parte de sus subsistemas ya desarrollados).

En un desarrollo en cascada el riesgo de caer en soluciones complejas que no han pasado previamente por un período de maduración basado en versiones más simples crece de manera exponencial, ya que este tipo de desarrollos tiene una vocación finalista que no es otra que la entrega del sistema completo (concepto llave en mano).

Los usuarios son el eslabón débil de los enfoques clásico y ágil

Ambos enfoques tienen en común las personas y en ambos juega un papel esencial el responsable funcional, product owner, área usuaria o como lo queramos llamar, en función de como esté organizado el proyecto y la metodología o estrategia utilizada.

Da igual cómo trates de enfocarlo, da igual que tengas grandes técnicos ya que si el usuario no colabora lo más probable es que la partida esté perdida. Es cierto que queda algún as en la manga, como que haya en el equipo personas con un gran conocimiento del negocio y de la organización y/o que haya algún sistema previo o en otra organización que pueda servir de referencia y se acierte.

No obstante la realidad es que resulta muy complicado acertar de esa manera porque se está trabajando a ciegas, sin recibir un feedback adecuado que permita ir perfilando los resultados.

Generalmente se suele tirar hacia adelante y con las especificaciones que se han podido obtener tratar de conseguir unos resultados: el proveedor quiere facturar y el cliente justificar la inversión realizada (sobre todo cuando ya se ha invertido un porcentaje más o menos significativo del presupuesto).

En este contexto suelen perder los dos y si gana uno es en detrimento claro del otro.

Si gana el cliente es porque al final hay un producto que puede satisfacer sus expectativas y si se llega a eso, tras un inicio nefasto y si no se ha invertido más dinero es porque el proveedor ha terminado tragándose todo el problema, convirtiéndose el proyecto en un agujero sin fondo, que nunca acaba y que solo ocasiona pérdida tras pérdida.

Si gana el proveedor es porque todos asumen que lo importante es conseguir un producto final, quedando en un aspecto secundario que realmente satisfaga las expectativas. No digo que no se quieran obtener buenos resultados, solo quiero decir que llegado el momento, muchos implicados querrán salvar los muebles y verán como única salida llegar a entregar algo.

En estas situaciones, la mejor salida, si no se consigue revertir el problema de la falta de implicación del usuario y no se asume el coste (ya sea inyectando más presupuesto o reduciendo el alcance), es asumir lo que hay y cerrar el proyecto.

Poco importa el enfoque si el destinatario de la aplicación no pone el interés o la dedicación necesaria al servicio del proyecto.

Desarrollo de software. El daño de los tiempos de espera

En esa situación ideal de tener al personal que trabaja en un proyecto repartido entre varios y poder balancearlos en función de la carga de trabajo existente, los tiempos de espera no presentan mucho problema. Sin embargo, todos sabemos que es muy complicado (que no imposible), llegar a encontrarnos con algo así.

En los ciclo de vida clásicos, tal vez sea más sencillo encontrar ese equilibrio, porque por mucha agenda que haya, todos sabemos lo que suele pasar: El análisis, la construcción o ambos tienden a durar más de lo que se esperaba.

En los enfoques ágiles los tiempos de espera atacan directamente a la línea de flotación del propio planteamiento del proyecto porque rompe el ritmo y afecta al cumplimiento de los compromisos. Por otro lado, sabemos que no es productivo tener a personas compartidas entre proyectos que no tienen nada que ver entre sí y que lo mismo no es tan fácil o rápido recuperarlas cuando el proyecto vuelva a arrancar.

Por otro lado, resulta esencial que al comienzo de una iteración se tenga todo lo necesario para realizarla, soy muy pesado con este tema, porque he vivido en primera persona lo perjudicial que resulta no empezar con todo lo necesario porque resta flexibilidad a la hora de afrontar los trabajos y porque llegado un punto no se podrán cumplir con los compromisos adquiridos y os aseguro que nos lo demandarán y exigirán de igual forma que si hubiéramos recibido todo lo necesario al principio.

Por el bien del proyecto a veces será necesario romper esa regla pero esas excepciones debemos tratar que se conviertan en norma, porque no solo es responsabilidad de los desarrolladores que se cumplan los compromisos.

El analista y los proyectos ágiles

La versatilidad y la polivalencia son características muy apreciadas en los integrantes de equipos de trabajo ágiles. Si además, se promueve la rotación de tareas, se entiende que cualquiera está preparado para cualquier actividad que se presente en el proyecto, dotando al equipo de una mayor eficiencia y de una gran flexibilidad que resulta muy útil a la hora de afrontar las diferentes contingencias que, seguro, vamos a encontrar.

Sin embargo, no se debe menospreciar la especialización. No es ágil prescindir a priori de la idea de tener determinados especialistas en el proyecto (en general no es ágil crear restricciones sin analizar la situación).

Un analista es un especialista. Su misión es interpretar las expectativas del usuario, trasladarlas al equipo de proyecto, recoger el feedback y vuelta a empezar. No es un intermediario, sino un facilitador tanto para usuarios como para desarrolladores, no es alguien que está en el medio, sino alguien que está con ellos. Esa es la visión de este perfil en un proyecto ágil.

En un enfoque clásico, la división en procesos hace que los analistas sí que tengan una mayor separación con respecto a los programadores, aunque dependerá mucho de cómo se haya organizado el proyecto, ya que es frecuente también que presten soporte en el proceso de construcción.

Pero incluso en estos casos, la diferencia con un proyecto ágil se encuentra en la intensidad. En el enfoque clásico los analistas dedican un mayor esfuerzo en la fase de captura de requisitos y análisis, en los enfoques ágiles su esfuerzo se mantiene constante, ya que mientras se ejecuta una iteración, preparan la materia prima para la siguiente (interviniendo en ambas tareas con la dedicación que se precise en ese momento en el proyecto).

Desarrollo de software. Limitar el valor no debe ser el objetivo

No digo nada nuevo si os comento que las mejores especificaciones de los usuarios van surgiendo conforme se va avanzando en el proyecto y se les empieza a despejar la niebla que se extiende por su visión de lo que debe ser el sistema de información.

En un enfoque clásico, pretender acertar desde una fase de análisis que se encuentra muy lejos del momento en que se va a poner el producto en producción es casi una quimera por mucho que se haya trabajado con prototipos y los desarrolladores conozcan bien al negocio y a los usuarios.

¿Cómo mantener una agenda de plazos y presupuesto si me cambian los requisitos? No se puede salvo que termines reventando al equipo y/o recortando el alcance (y calidad) del sistema de información y aún así probablemente te termines desviando en ambos.

Si nos quedamos con las especificaciones iniciales no se puede esperar un producto con un mayor valor que el que nos ofrecen las mismas porque estamos limitando el valor al no permitir cambios propiciados por el feedback usuario.

Por tanto, no solo nos estamos encontrando con una estrategia de desarrollo de software que se aleja de la realidad de los proyectos sino que, además, su orientación a la agenda, ofrece menos flexibilidad para incorporar valor al producto a lo largo del proceso de desarrollo.

Desarrollo de software. ¿Es el enfoque iterativo incremental una sucesión de cascadas?

Se puede ver de esa manera pero es tan diferente el enfoque que ambos términos chirrían. Es cierto que cuando te planteas una iteración haces todas las actividades que sean necesarias sobre cada historia de usuario, no obstante la principal diferencia la tenemos en que al plantearse un desarrollo por incrementos, existe la posibilidad de realizar evaluaciones, sobre versiones en funcionamiento, desde el punto de vista del resultado (feedback) y de cómo se hacen las cosas (retrospectiva), las cuales permiten ir incrementando el valor del producto y adaptarse a los cambios que puedan producirse tanto desde el punto de vista del producto como de los métodos y organización del trabajo.

En un enfoque clásico o en cascada pueden existir revisiones intermedias del producto (más comunes) y también se puede obtener feedbacks y realizar retrospectivas (menos comunes), aplicar esas estrategias que podríamos considerar ágiles tienen sus ventajas, sin olvidar que siguen sin solucionar los principales inconveniente del desarrollo en cascada:

- El tiempo de puesta en marcha de versiones efectivas del producto.
- Su orientación al cumplimiento de una agenda: costes y plazos, lo que resta flexibilidad a la hora de realizar cambios sobre las especificaciones iniciales.

Desarrollo de software. Maleabilidad

Siempre es posible desarrollar un software aplicando las mismas técnicas de gestión que para construir un puente, sin embargo estaríamos prescindiendo de una de sus principales características, su maleabilidad, lo que le permite adaptarse al cambio y modificar criterios con un coste asumible (siempre y cuando se tenga la deuda técnica bajo control).

Cuando tienes un puente a medio construir, tomar la decisión de poner un carril más en cada dirección puede ser prácticamente imposible o requerir una inversión muy superior a la que hubiera sido necesaria si se hubiera tenido en cuenta desde el principio.

En el desarrollo de software no es así. Es cierto que el cambio tiene un coste pero no es equiparable al de las construcciones físicas.

Renunciamos a la maleabilidad del software cuando lo importante es el cumplimiento de una agenda, es decir, se prioriza mantener previsiones de costes y plazos sobre la posibilidad de entregar un producto con mayor valor. Hay que analizar cada circunstancia y es posible que no haya otra alternativa que cumplir con la agenda: no es posible dedicar mayor presupuesto al proyecto y/o modificar los plazos, siempre y cuando se entienda que no es posible la cuadratura del círculo: cumplir agendas y tener al producto sometido a continuos cambios de criterio.

Mi apuesta es incrementar el valor del producto que se pone en producción y eso requiere un enfoque iterativo incremental para aprovechar el feedback del usuario. Esto tiene implicaciones presupuestarias que se solucionarían bien teniendo abierto el presupuesto del proyecto o si está cerrado centrarse en que las funcionalidades prioritarias vayan bien (esto último siempre y cuando no nos encontremos en una situación de Death March Project en la cual todo será mucho más complicado).

Desarrollo de software. Sprints e implicación

No es lo mismo hacer sprints sobre productos consolidados o basado en modificaciones leves o moderadas sobre funcionalidades ya implementadas, que los primeros sprints relacionados con el desarrollo del sistema, con el desarrollo de una nuevo subsistema o con modificaciones sensibles de su funcionalidad.

La diferencia es el esfuerzo que hay que dedicar para preparar el siguiente sprint, para tener esa materia prima necesaria para que la maquinaria no pare.

Ese esfuerzo se realiza en paralelo con el sprint en curso por lo que es necesario tener en cuenta ese aspecto a la hora de estimar la velocidad de desarrollo si hay personas del equipo que participan en la obtención de la materia prima, ya que no se debería contabilizar una dedicación del 100% de las mismas al sprint.

De lo contrario estas personas tendrán una dedicación superior al 100% en la iteración y la consecuencia de esto es el overtime y la imposibilidad material en determinadas circunstancias de atender a demandar ya sea del propio desarrollo o de la preparación del siguiente sprint.

Trabajar con sprints requiere una gran implicación porque se trata de una maquinaria que no para: termina un sprint y empieza el siguiente, se trabaja en un sprint mientras se prepara el siguiente. Estas condiciones no la aguantan todos los responsables funcionales (el equipo de proyecto, como comentaba antes, sí que puede si modula bien los esfuerzos) y es una de las circunstancias que hacen complicada la puesta en marcha de este tipo de enfoques.

Si el responsable funcional, product owner o como lo queramos llamar no se implica, no entiende esta dinámica de trabajo o sencillamente no puede dedicar el tiempo necesario a esto se rompen las reglas del juego y obligará a enfocar el proyecto de otra manera.

¿Por qué? No tendremos la materia prima necesaria para el siguiente sprint, ¿alternativas? parar el desarrollo por sprints o reducirlo a lo que se pueda abordar con la materia prima disponible y pactar con el responsable funcional un tiempo para seguir definiendo funcionalidades del sistema, ¿es esto volver a lo de antes?, ¿es esto volver al enfoque clásico?, no es así exactamente ya que el enfoque sigue siendo iterativo incremental, lo que sucede es que se pierde el ritmo de desarrollo que tienen los sprints y como consecuencia se disminuye la velocidad con que se agrega valor al producto y la capacidad de adaptación al cambio.

Desarrollo de software. Modelos predictivos o cómo gestionar el desgaste II

Es cierto que llegado el momento puedes abrir la mano y permitir cambios en las especificaciones, pudiendo negociar el intercambio de requisitos, pero la verdad es que no suele dar buenos resultados por diversas razones: el intercambio no es real (generalmente las tareas que entran suponen más esfuerzo que las que salen, si es que sale alguna), se cambian requisitos sobre visiones abstractas del producto por lo que se siguen realizando a ciegas independientemente de que la visión tenga menos niebla que al principio y además, cambiar de enfoque en determinadas funcionalidades, con el producto avanzado tiene un coste alto.

Esto último también se puede producir en un desarrollo iterativo incremental, lo que lo diferencia es que en muchos casos, la detección del problema se habrá realizado en etapas más tempranas (en el caso de que no sea un cambio de enfoque por cambios en el proceso) ya que los usuarios estarán interactuando con el producto mucho antes.

La gestión de proyectos basados en enfoques clásicos o predictivos es en realidad una gestión del desgaste porque el cumplimiento de la agenda implicará falta de flexibilidad una vez que el análisis inicial se ha completado.

En ese triángulo que forman: alcance, coste y plazos, la modificación de uno de los vértices impacta sobre el resto salvo que exista un margen suficiente que por otra parte casi nunca existe o casi nunca es suficiente. Si no existiendo ese margen se modifica el alcance (o el esfuerzo para conseguir los objetivos, ya que lo mismo el alcance es similar pero la modificación de requisitos sobre componentes construidos hace que sea necesario un esfuerzo mayor ya que el ya invertido hay que contarlo) y se quieren mantener costes y plazos, el primer afectado será la calidad final del producto.