Desarrollo de software. El valor fluctúa durante el ciclo de vida del producto

El valor de un producto se mide realmente cuando entra en producción aunque se ponga en funcionamiento una parte pequeña del mismo. Todo valor anterior son perspectivas, hipótesis y expectativas.

Sobre esa base, toda suposición inicial sobre el valor final del producto no deja de ser una idea abstracta, teniendo en cuenta que todavía lo que se tienen son ideas, con más o menos detalles, definidas con mayor o menor formalidad.

El valor del producto no crece linealmente, es más, puede reducirse y todo ello sin que se tenga que tocar una sola línea de código.

Mantener y/o incrementar ese valor es el objetivo del desarrollo de software mientras exista una rentabilidad entre la inversión necesaria y los resultados obtenios.

Desarrollo de software. Milt Bryce. Especificaciones y comprensión del problema

Uno de los problemas de empezar a programar demasiado pronto es que en muchos casos no se ha llegado a comprender el problema de fondo que pretende resolver una determinada funcionalidad o módulo, en otros no se ha llegado a entender el proceso que se quiere informatizar y en otros, además de lo anterior, no se termina siquiera de asimilar qué es lo que quiere el usuario.

Es cierto que si planteamos un desarrollo iterativo incremental siempre tendremos la oportunidad de ir aprendiendo y de a partir del feedback del usuario ir acercándonos cada vez más a una solución que satisfaga sus expectativas, sin embargo si queremos optimizar los costes y tiempos de desarrollo, así como la deuda técnica, tenemos que intentar que el porcentaje de acierto en cada iteración sea adecuado a las características del sistema que se va a desarrollar.

En la línea de la cita de Cem Kaner que publiqué hace unos días, Milt Bryce comenta lo siguiente: “Ninguna cantidad de programación o tecnología elegante resolverá un problema que no esté adecuadamente especificado o no sea suficientemente comprendido”.

Desarrollo de software. Milt Bryce. Productividad y simplicidad

Uno de las principales ventajas de aplicar un enfoque iterativo incremental, además de permitir una mejor adaptación al cambio y de obtener el feedback del usuario desde etapas muy tempranas del desarrollo del producto, es que si está bien orientado, el desarrollo se basará en una priorización de las funcionalidades del sistema.

No se trata tanto de tener claro desde un principio todo lo que debe hacer el sistema como de tener claro qué es lo que resulta esencial para el mismo, ya que es por ahí por donde se debe empezar, evitando de esta forma distraer esfuerzos en módulos o funcionalidades accesorias.

Ahora bien, con la priorización no resolvemos del todo el problema ya que las actuaciones deben regirse por un principio de simplicidad: “la mejor solución es aquella que satisfaciendo las expectativas del usuario sea la más simple”.

Una ejecución compleja de un módulo o de una funcionalidad además de aportar un valor más que dudoso al usuario implica la realización de un esfuerzo adicional (a la par de una mayor deuda técnica) que perfectamente podría haber sido aplicado en un testing de más calidad del desarrollo, en un desarrollo de más calidad o en remanente para el desarrollo de módulos o funcionalidades menos prioritarias.

Sobre la productividad y simplicidad en el desarrollo, Milt Bryce realizó la siguiente cita: “No hay nada más improductivo que construir algo de manera eficiente que no debería haber sido construido”.

Desarrollo de software. Usuario, producto, evolución

Cuando un producto software empieza a evolucionar de verdad hacia una solución que satisfaga las necesidades y expectativas del usuario es cuando éste empieza a verlo y a usarlo.

Por muy buena capacidad de abstracción que tenga el usuario, por muy bien que se le cuente cómo va a funcionar el sistema, por mucho que él crea que lo tenga claro, la realidad es que cuando se encuentra ante un desarrollo va a ser distinto a lo que se había imaginado y descubrirá que no está de acuerdo tanto con decisiones que ha tomado como con algunas lagunas de la definición del producto que ha cubierto el equipo de desarrollo, sin contar con que probablemente la experiencia de uso de la aplicación diferirá de sus expectativas.

Por tanto, no solo la incertidumbre y la capacidad de adaptación al cambio hacen recomendable un enfoque iterativo incremental, también resulta esencial para la adaptación del producto lo antes posible a lo que el usuario espera.

Desarrollo de software. Productividad y experiencia de usuario

Nos podemos encontrar con sistemas de información que funcionalmente cumplan los requisitos marcados por el área usuaria y que incluso tengan una deuda técnica aceptable pero que sin embargo no satisfaga a los usuarios.

¿Por qué? Pues por el hecho de que el sistema se ha centrado en la funcionalidad sin tener en cuenta lo costoso, complicado o improductivo que pueda ser para el usuario. El sistema se ha desarrollado de espaldas a la experiencia del usuario.

Y en este caso, el usuario lleva toda la razón. El sistema de información debe solucionar problemas, no crearlos, el sistema debe en conjunto mejorar la actividad que se informatiza no empeorarla.

Esto es muy frecuente encontrarlo en sistemas desarrollados siguiendo enfoques clásicos o en cascada en donde en la mayoría de los casos, el usuario no se enfrenta al producto hasta que se les entrega.

Los enfoques ágiles o iterativos e incrementales permiten obtener el feedback del usuario desde etapas muy tempranas, de manera que no solo es sistema puede adaptarse mejor al cambio o es capaz de tener los requisitos más prioritarios más trabajados, sino que además ofrece la posibilidad de que en cada iteración la productividad del trabajo que se realiza a través de la misma y la experiencia de usuario vaya mejorando.

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. 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. Agilidad y la evolución en la incertidumbre en el proyecto

Hablar de un proyecto de desarrollo de software es hablar de incertidumbre. Cuanto más grande y complejo sea el producto a desarrollar, más tiempo se requerirá para tener una versión que se pueda considerar definitiva del producto, independientemente de que si se sigue un enfoque iterativo incremental se puedan tener versiones operativas (aunque no completas) en producción y utilizándose en un contexto real.

La incertidumbre existe en todos los proyectos pero a priori no es la misma en todos ellos ya que además del factor tiempo, existen otros muy significativos: el momento en que se decide iniciar el proyecto (no es lo mismo empezar en un entorno de procesos estable que en un entorno donde se sabe que existe una gran posibilidad de el mismo cambie, no es lo mismo empezar cuando los usuarios expertos pueden dedicar tiempo al proyecto que cuando se sabe que tienen que dedicar gran parte de su tiempo, cuando no todo, a realizar otras tareas, etc…), las características del cliente y de las personas designadas por el mismo, la adecuación del presupuesto a la naturaleza del proyecto, la complejidad del mismo, etc…

Es cierto que conforme se va avanzando en el proyecto se va acotando la incertidumbre pero esto realmente es significativo en desarrollos iterativos incrementales donde realmente en cada iteración, en cada feedback nos vamos acercando más y más a la solución.

Con un desarrollo en cascada con su orientación a entrega única, la incertidumbre no se reduce de manera tan sensible, ya que aunque determinados riesgos tecnológicos, de arquitectura, de cambios en los procesos se hayan superado, siempre quedará la incertidumbre de saber si en esa bola de cristal cuya visión ha quedado plasmada en el análisis de este tipo de desarrollos se ha acertado o no en el pronóstico.

En cualquier caso, sea cual sea el proyecto y sea cual sea la metodología, siempre puede pasar algo, incluso en el último momento que dé al traste con el trabajo: cambio absoluto del proceso que se estaba informatizando, desencuentros entre diferentes departamentos del cliente, etc… Y sucede mucho más de lo que se piensa.

Independientemente de que la incertidumbre siempre estará presente, es un hecho, como comentaba antes, que la misma disminuye conforme se avanza en el proyecto y esto es una ventaja muy grande para los enfoques iterativos e incrementales, ya que las estimaciones de esfuerzo tendrán cada vez una mayor precisión (ya que además, técnica y funcionalmente se tendrá más controlado el sistema) y de esto pueden sacar un mayor provecho tanto clientes como proveedores, siempre y cuando exista un marco contractual (contratación ágil) que sea flexible y coherente con esto.

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.