archivo

Archivo de la etiqueta: ciclo de vida clásico

Podemos discutir el porcentaje pero no el fondo de la siguiente reflexión de Larry Bernstein: “Sólo entre el 40 y 60% de los requisitos de un sistema se conoce al comienzo del proyecto. El resto emerge con el uso. Barry Boehm acuñó el término requisitos emergentes para describirlos”.

Y no se trata de requisitos que aparecen por arte de magia sino que son consecuencia de la evolución que existe entre lo que el usuario cree que quiere y lo que realmente necesita y de la separación que existe entre la visión abstracta de un producto y su implementación real.

De ese porcentaje inicial de requisitos previsibles, una parte importante de los mismos tiene a su vez que ser perfilada también con la utilización del sistema.

Esto al final nos hace ver que los desarrollos llave en mano y/o los ciclos de vida en cascada no se adaptan a esta realidad y por ese motivo no suelen ofrecer buenos resultados y si lo consiguen es porque todas las partes en alguna parte del proceso de desarrollo se dan cuenta de que es necesario llegar a un acuerdo para que el producto se dirija hacia lo que realmente se necesita y no hacia lo que inicialmente era previsible.

Te puedes esforzar en un proyecto para cumplir una planificación y ceñirte a unos costes y sin embargo no conseguir nada, incluso desarrollando todas y cada de las funcionalidades tal y cual se especificaron en un principio.

¿Por qué? La idea inicial no tiene por qué funcionar, de hecho todos sabemos que es muy difícil acertar a la primera y todavía más conforme se incrementa el tamaño y/o complejidad de la solución. Esto es extensible tanto para el desarrollo de un producto propio como para el desarrollo de software para terceros.

Por tanto, afirmar que un producto que va acorde a unos plazos, unos costes y unas determinadas funcionalidades va bien, es mucho suponer si no se mide realmente el valor que se está obteniendo, de ahí el riesgo que supone, por ejemplo, un desarrollo en cascada cuando los desarrolladores y usuarios viven separados desde la finalización del análisis hasta etapas próximas a la entrega.

En los desarrollos iterativos incrementales, con entregas más frecuentes y con versiones en producción desde etapas tempranas el feedback permite evaluar el valor real que se está obteniendo y adoptar decisiones encaminadas a incrementarlo.

Otra cosa, es que pese a trabajar de esta forma se quiera seguir con el guión inicial prácticamente sin variaciones, en ese caso, poco importará la metodología porque predominará el seguimiento de un plan y esto es consecuencia muchas veces no de confiar ciegamente en él, sino por el afan de cumplir, de cubrir el expediente: “si al final se fracasa, la culpa no es nuestra, sino del plan”.

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.

Asumir que no se sabe o se conoce todo es una de las bases para el desarrollo iterativo incremental.

Has podido realizar un análisis que te ha llevado meses, en el que se ha trabajado concienzudamente con los responsables funcionales pero cuando se esté en la fase de desarrollo del producto se materializarán de forma muy probable ciertos riesgos que rompan con esa concepción lineal del desarrollo: analizo, diseño, construyo; bien porque los responsables funcionales descubran que su especificación inicial tiene errores y/o es perfeccionable o bien porque cambie el propio contexto del proyecto (se recorte el presupuesto, cambie determinada normativa que condicionaba las especificaciones, etc…).

Suponer que las condiciones iniciales no van a cambiar es mucho suponer, si has desarrollado en cascada lo habrás sufrido y yo he trabajado en muchos proyectos de este tipo y lo he vivido en primera persona.

Que sí, que todo es negociable, que se pueden cambiar unas tareas por otras y que con voluntad se pueden alcanzar acuerdos que den lugar a soluciones satisfactorias, pero el margen de conseguir esos acuerdos será menor conforme menos presupuesto quede en el proyecto y conforme el coste de realizar los cambios sea mayor o lo que es lo mismo, cuanto más tarde se detecte la necesidad del cambio o los problemas y un desarrollo en cascada es muy dado a que se produzcan esas circunstancias.

Buena parte de la contratación del software está basada en acuerdo llave en mano en la que se pacta un precio cerrado para desarrollar un producto en base a unas especificaciones, por regla general, no muy detalladas de lo que se pretende hacer.

En muchos casos, el proyecto parte de una situación de Death March Project que dará lugar, si es que se consigue llegar, al menos, a ese punto, a un producto que no satisfará las necesidades y expectativas del usuario y en medio de todo eso se habrá producido un desgaste importante entre los diferentes implicados en el proyecto.

Los defensores de esta estrategia de contratación se centran en que el riesgo se traspasa al proveedor que es quien asume unas condiciones y como tal, debe cumplir lo pactado. Sin embargo es algo que termina volviéndose en contra también del cliente, que se debería conformar, con las especificaciones que dé en la fase de captura de requisitos, sin posibilidad de modificarlas posteriormente (la llave en mano y el desarrollo en cascada son compañeros de viaje).

¿Qué pasa? Pues que acertar a la primera es muy complicado y conforme vaya avanzando el desarrollo y los responsables funcionales vayan viendo partes del producto funcionando, surgirá la necesidad de realizar cambios sobre las especificaciones o incluso la necesidad de incrementar el alcance inicialmente previsto.

En ese momento entran en juego las negociaciones y dependerá de la voluntad de las partes que las mismas lleguen a un punto donde sea posible todavía entregar un producto que cumpla unas condiciones mínimas.

Desde mi punto de vista creo que, a pesar de ser legítima, una situación de partida en la que una de las partes trata de echar sobre la otra todo el riesgo no es positiva para un proyecto por sus propias características inherentes: incertidumbre, carácter evolutivo del desarrollo y las diferentes contingencias, casuísticas y problemas que suele haber en los mismos.

Lao-Tsé refleja en un par de citas, un aspecto esencial que tenemos que tener en cuenta a la hora de abordar un proyecto de desarrollo de software y en general para cualquier tarea de un cierto tamaño que queramos afrontar:

“Proyecta lo difícil partiendo de donde aún es fácil”.

“Realiza lo grande partiendo de donde aún es pequeño”.

Precisamente uno de los grandes problemas del ciclo de vida en clásico o en cascada es ese, construir un producto demasiado grande que después resulta complicado de reajustar.

Cuanto más grande sea, más dinero nos habremos gastado, por lo que menos disponibilidad presupuestaria tendremos para hacer modificaciones (a la par de la presión por amortizar la inversión) y la deuda técnica hará más costosas las modificaciones, y eso casi en el mejor de los casos, porque si hay que cambiar arquitectura o estrategias de diseño, los costes se disparan.

Si encima el producto cubre un proceso de negocio estratégico el impacto será aún más fuerte.

Precisamente quienes conocen este problema tratan de dividir el sistema en diferentes versiones, siguiendo un enfoque incremental. Eso es un primer paso para hacerlo también iterativo, en el sentido de que en cada versión se subsanen deficiencias de las anteriores, que no solo llegan a nivel correctivo, sino también perfectivo y evolutivo.

Se mejora de esta forma, pero si la duración de las iteraciones es demasiado prolongada, seguiremos teniendo en esencia el problema inicial, atenuado, pero seguirá ahí.

Por ese motivo, el siguiente paso es la realización de ciclos más cortos. Si son fijos o variables en tiempo, es otro tema de debate.

Hace un tiempo me expusieron un caso de un proyecto que se desarrolló siguiendo un enfoque iterativo incremental con ciclos cortos de menos de un mes de duración, en el que se obtuvo un producto cuyo resultado final dejaba mucho que desear.

¿Pero no es así como recomiendas que se desarrolle? Lo que sí digo siempre es que es la estrategia que mejor se adapta a la realidad de los proyectos de desarrollo de software pero que después cada proyecto es un mundo y sus necesidades o contexto pueden recomendar otras estrategias.

Sin embargo el proyecto no salió bien porque aplicar un desarrollo iterativo incremental sino porque se cayeron en algunos errores que se arrastraron hasta el final:

– Mala elección de la arquitectura del sistema.

– Se desarrollaban historias de usuario que no estaban lo suficientemente consolidadas, lo que hacía que su desarrollo tuviera menos intención y se requirieran más iteraciones de la cuenta en cerrarlas.

– En lugar de rehacer completamente módulos o funcionalidades cuyo funcionamiento se descartó, se trató de solucionar parcheándolas, lo que no daba la suficiente libertad para desarrollar la solución que pudiera satisfacer de manera efectiva las expectativas de los usuarios y por otro lado incrementaba la deuda técnica porque los desarrollos no eran limpios.

– En lugar de dedicar el esfuerzo en resolver los problemas principales del sistema se repartía desarrollando nuevas funcionalidades, lo que implicaba que muchos de ellos no terminaban de corregirse nunca (porque además en los nuevos desarrollos aparecían nuevas contingencias).

La mayoría (o todos) de estos problemas se hubieran dado igualmente en un enfoque clásico, es más, pienso que el resultado final hubiera sido peor porque en este caso, por lo menos, gracias al feedback se pudo ir desarrollando un producto que se aproximase a las expectativas del usuario.

Lo que vengo a exponer en este artículo es que realmente una estrategia o metodología de desarrollo no te ofrece una solución, solo te indica una manera de hacer las cosas, después las decisiones que se adopten, la actitud y la aptitud de las diferentes personas que participan y el contexto del propio proyecto son las que permiten obtener unos resultados mejores o peores.