archivo

Archivo de la etiqueta: ciclo de vida

Parece políticamente incorrecto en el mundo ágil la utilización de la palabra requisito. También, aunque algo menos, la palabra especificación. El motivo principal es su asociación a los desarrollos en cascada y a un modelo de desarrollo basado, yéndonos a un extremo, al dicto, interpreto/apunto, construyo.

Parece que el concepto de historia de usuario se asocia más a la colaboración que es la base en la que se sustenta la agilidad y el enfoque de desarrollo iterativo incremental (os recuerdo que un enfoque o ciclo de vida concreto de desarrollo no es en esencia ágil ya que depende de la actitud con que se aborde).

Estoy de acuerdo en que en determinados momentos usar la palabra adecuada puede ser importante pero tampoco se pierde valor si el fondo realmente dice lo que queremos transmitir. Lo realmente importante, independientemente del nombre que le demos, es que en los ciclos de vida clásicos se piensa en el producto, por encima de analizar y trabajar sobre los problemas reales que se quieren resolver y esto es así, entre otras cosas, porque los desarrollos en cascada piensan en los productos en términos finalistas y en los enfoques evolutivos en términos de valor ganado en aproximaciones sucesivas hacia una determinada solución.

¿Cuándo queda para que el proyecto termine?.

Interesante visión la que plantea la Ley de Hartree: “El tiempo desde ahora hasta la finalización del proyecto tiende a ser constante”.

Sería más exacto si en lugar de hablar de proyecto hablásemos de ciclo de vida del producto software, ya que se entiende al proyecto como un conjunto de actividades que se realizan en el tiempo para conseguir unos resultados (mucho más cortoplacista y concreta de lo que sería el ciclo de vida).

Si bien, nos encontramos pese a todo, con proyectos que prácticamente no parecen tener fin, ya sea porque los objetivos (para los cuales se realizan esas actividades) son demasiado abiertos o ambiguos y/o porque la ejecución de las trabajos por parte del equipo de desarrollo es deficiente, teniéndose que volver a realizar de nuevo o parcialmente determinadas funcionalidades, por una deuda técnica elevada, lo que hace que la mantenibilidad o evolución del sistema requiera más tiempo y esfuerzo, etc…

Ya sea tomando como referencia los proyectos o el ciclo de vida, lo que sí resulta interesante de esta ley son los mensajes que podemos interpretar a partir de ella:

– Los proyectos de desarrollo de software suelen tener objetivos demasiado abiertos o ambiguos.
– Las estimaciones son menos precisas cuanto más cerca nos encontremos del inicio del proyecto.
– La deuda técnica de manera paulatina hace más complejo el proceso de desarrollo de software.
– Un producto software de manera inherente tiende a ser evolucionado (ver leyes de Lehman).

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.

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

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

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.

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.

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

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.

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.