Bertrand Meyer. Madurar las soluciones

El producto resultante de un proyecto de desarrollo de software requiere de un período de maduración que comienza con el inicio del mismo a través de los ajustes que se realizan en las diferentes iteraciones y a través del conocimiento adquirido dentro y al final de las mismas (no solo se trata de aprender del feedback, se puede aprender también mientras se analiza una historia de usuario y nos apoyamos en estrategias tales como prototipado, pantallazos, etc…).

La solución no se tiene clara desde el principio, nadie la tiene ni usuarios ni desarrolladores (cada uno dentro de su ámbito de actuación) y lo más probable es que la visión que ambas partes tengan del producto en ese momento difieran sensiblemente.

El conocimiento inicial es limitado y esto eleva la probabilidad de que cometamos errores.

Es cierto que por algo tendremos que empezar y eso ya supone una apuesta pero eso es diferente a jugar todas tus cartas a una solución y tirar con ella hasta el final que es lo que sucede en los ciclos de vida clásicos. En estos casos también se madura la solución pero más a nivel técnico que funcional lo que da lugar a los problemas habituales en la aceptación del producto o tras su puesta en producción y es el desajuste entre lo que el usuario recibe y las expectativas que tenía puestas en el mismo.

En el proceso de maduración tendremos probablemente que desechar decisiones que tomamos en etapas anteriores precisamente por el hecho de no haber acertado o por existir otras soluciones más efectivas y válidas. Tirar y volver a hacer tiene un coste pero más caro resulta ir hasta el final con una solución no satisfactoria.

Lo importante es hacer un producto cada vez mejor aunque no consigamos un avance lineal en el proyecto.

Bertrand Meyer realizó la siguiente cita: “Las malas ideas y las más complicadas (que a menudo son las mismas) a menudo aparecen las primeras, se necesita tiempo para que aparezcan las simples y elegantes”.

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. ¿Por qué es mejor tener esa visión más global del negocio?

Sin esa visión global estás construyendo el sistema a base de retales de manera que funcionalidades que podrían tener una solución general, la tienen de manera particular y eso de lugar a más pantallas, más tablas, más código. Si el sistema es grande y se produce muchas veces este problema estamos haciendo un sistema más complejo, con un mayor coste, más difícil de mantener y más complicado de administrar (a nivel de aplicación).

Como decía en el artículo de ayer, no se trata de hacer un análisis completo del sistema, no me refiero a eso, sino a tener una visión global de qué es lo que se quiere hacer, no se requiere por tanto la formalidad de un análisis de un ciclo de vida clásico y tampoco seguir sus etapas.

Se puede analizar y empezar a construir, así vamos obteniendo feedback del usuario que nos será de mucha utilidad porque esa visión global que nos la da el usuario y el estudio de sistemas de información que viniera utilizando antes para ese mismo proceso (u otro similar existente en otra organización) sigue estando basada en un concepción abstracta del sistema y hasta que el usuario no empieza a ver cosas tangibles no saldrán a la luz comportamientos y funcionalidades que formaban parte de sus expectativas pero que todavía no habían salido a la superficie.

Desarrollo de software. Evitar la complejidad. Tratamiento a diferentes escalas.

Un amigo me comentó que efectivamente estaba de acuerdo que las aplicaciones tenían más complejidad funcional de la realmente necesaria y que en muchos casos hasta las funcionalidades más importantes no tenían la solución más simple lo que las hacía más pesadas al usuario (y provocaba que fueran más complejas de mantener) y afectaban a su productividad.

La complejidad se debe tratar a diferentes escalas:

Escala general: Sobre el conjunto del sistema. Reducir la complejidad implica dedicar tiempo a conocer el negocio y a entenderlo en la extensión que afecta al sistema de información. Tratar una parte concreta obviando el resto puede dar lugar (es lo más probable) a una solución más compleja. Pero, ¿cómo casa esto con un enfoque iterativo e incremental?, ¿cómo casa esto en un enfoque que se aleje del ciclo de vida clásico?.

Es perfectamente compatible solo que en los primeros ciclos el peso de tareas que ayuden a comprender el negocio será mayor que el de las dedicadas a programación. Dependiendo de la complejidad del negocio, del conocimiento que se tenga del mismo y de la actitud del área usuaria será mayor el número de ciclos en el que el peso de entender el negocio será mayor que el de la construcción.

Escala de detalle: Podemos haber trabajado en una solución simple a nivel general y después haber realizado una ejecución de la misma que la llene de complejidad. En este caso se trata de buscar la solución más simple para una funcionalidad concreta o (a un poco de más alto nivel), un módulo o un subsistema.

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 V

Lo importante realmente en la predisposición a modificar la agenda, ahí es donde está la clave de todo esto. Esa predisposición supone haber entendido la incertidumbre del desarrollo de software y la necesidad de adaptarse al cambio y a los nuevos contextos que surjan durante su ejecución.

Sin embargo, son muchos años aplicando la filosofía de la llave en mano, de la gestión de agendas, de ciclo de vida clásico, de pensar que un proyecto de desarrollo de software es solo proceso y que no tiene por qué verse afectado por su contexto. Respeto ese cuerpo de conocimiento ya que supuso el primer intento de crear un orden dentro del caos y tuvieron un cierto éxito en comparación con el estado del arte anterior en el que sencillamente los proyectos, por regla general, no se gestionaban.

Pero tampoco supusieron la solución definitiva, solo un primer avance, sin embargo muchas organizaciones, muchos profesionales de reconocido prestigio creyeron ver ahí la solución a la ejecución de los proyectos software. El tiempo vino a demostrar que no, como tal vez el tiempo venga a demostrar que los enfoques ágiles tampoco lo son, sino una siguiente aproximación a otro modelo que permita obtener mejores resultados.

En cualquier caso y sea cual sea el enfoque a aplicar, lo realmente importante es el valor del producto y considerar la agenda como algo inamovible es atentar precisamente contra ese principio.

Recomiendo la lectura, si no lo habéis hecho ya a esta serie de artículos que si bien están orientados a los enfoques iterativos incrementales tratan, en esencia, de este mismo problema:

La (difícil) convivencia entre el enfoque iterativo incremental y el cumplimiento de agendas: Parte I, Parte II y Parte III.

La gestión de una agenda con falta de flexibilidad en sus parámetros supone no la gestión del proyecto en sí, sino la gestión del desgaste en las relaciones entre los diversos participantes, las cuales se irán deteriorando conforme vaya avanzando el proyecto porque no se terminarán de llegar a acuerdos que sean satisfactorios para ambas partes. La gestión del desgaste tratará de buscar puntos de equilibrio en ese caos en el que se habrá convertido la situación, con el objetivo de intentar exprimir al máximo un fruto al que prácticamente no le queda jugo.