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.