archivo

Archivo de la etiqueta: enfoque predictivo

Aunque resulte paradójico, la agenda es una de las principales causantes de la pérdida de control del proyecto porque en el momento en que se rompen sus premisas: estabilidad de las especificaciones, del contexto y acierto en las predicciones de coste y plazos y no se trata esta situación de manera natural ajustando la misma a la nueva realidad, estaremos trabajando en una condiciones fundamentadas en unas hipótesis erróneas y de esa situación no se puede esperar nada bueno.

La crisis del software se asoció al no cumplimiento de las agendas porque efectivamente los proyectos no cumplían objetivos de costes, plazos, alcance y calidad y a partir de ahí se constituyó la gestión predictiva de proyectos generando con las experiencias pasadas y con el paso del tiempo todo un cuerpo de conocimiento.

Precisamente este problema es el que sufren los desarrollos que siguen el enfoque clásico pero perfectamente son extrapolables a enfoques pretendidamente ágiles si los mismos están condicionados por agendas rígidas (digo pretendidamente porque agenda rígida y agilidad son conceptos contrapuestos).

Como es lógico, se mejoraron los resultados del pasado porque hay que tener en cuenta que se pasó del caos a un cierto orden, pero seguían sin ser satisfactorios a lo que había que sumar el desgaste que tiene este tipo de gestión entre todas las partes implicadas en el proyecto.

El culto a la agenda no es la solución porque pretende estabilidad y predicción en un contexto de incertidumbre que es inherente al desarrollo de software. Por eso, el centro no debe ser el triángulo de hierro sino el valor del producto de manera que costes, plazos y alcances supongan referencias y no límites.

Una de las claves para sacar adelante cualquier trabajo (y un proyecto no es más que un tipo de trabajo más), con su complejidad y sus características inherentes, es dividirlo en una serie de tareas que sean manejables: divide y vencerás.

El enfoque clásico o predictivo supuso el primer avance en ese sentido, si bien lo que hizo fue darle formalidad a lo que carecía de ella porque la división en tareas más simples en el desarrollo de software existe desde sus mismos inicios.

Esa división en procesos, actividades y tareas la podemos ver en Métrica v3, en versiones anteriores, en cualquier otra metodología basada en enfoques clásicos o en las propias definiciones genéricas de esa estrategia.

El inconveniente que se plantea es que divide en partes las actividades pero no el producto. Sobre esa aproximación inicial surgieron nuevas estrategias que tenían como objetivo descomponer el producto en partes y sobre cada una de ellas realizar una división de las actividades. Esto dio lugar a enfoques de tipo teórico como los desarrollos en espiral o más tangibles como los desarrollos iterativos incrementales.

Con este tipo de estrategias se puso en primer plano los conceptos de feedback y retrospectiva: conocimiento adquirido como consecuencia de la experiencia sobre versiones reales del producto (ya sea en producción o no) y la mejora continua de las prácticas y enfoque del proyecto.

El siguiente paso fue hacer que la descomposición del producto fuera en trozos más pequeños definiéndose para ello sprints de duración fija o variable pero que en cualquier caso iban a ser de corta duración. En este contexto el feedback y la retrospectiva ganan en intensidad, se realizan cada poco tiempo y el producto está preparado para adaptarse al cambio.

En esta evolución se ha pasado de la especificación del producto a su visión: se tiene una colección de tareas a realizar que se va modificando conforme avanza el proyecto y solo se estudian en detalle cuando se está preparando la siguiente iteración.

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.

El segundo escenario suele ser el más habitual y es la base para el fracaso de muchos proyectos de desarrollo de software, independientemente del enfoque a utilizar, si bien los enfoques evolutivos ofrecen la posibilidad de desarrollar el software por incrementos y si el área usuaria se muestra flexible (y la agenda da alguna oportunidad) es posible conseguir una solución razonable con el presupuesto y plazos definidos.

¿Qué agenda se puede gestionar si las condiciones iniciales son imaginarias? Solo es posible hacer algo en el caso de que el cliente entienda esta situación y no se cierre en banda al llave en mano. Si lo hace perderá el proveedor, pero también el cliente, porque pocos proyectos alcanzan un éxito real en esas condiciones.

También podría ser, porque también pasa, que las condiciones iniciales estén muy por encima de lo que requiera el proyecto, este escenario es más favorable que el anterior (por no decir que un chollo para el proveedor si te toca trabajar en estas condiciones), pero no arregla el problema de fondo, tal vez el proyecto sea muy rentable y el cliente quede satisfecho, pero el desarrollo de software es algo lo suficientemente serio como para esperar a ver si la moneda cae cara o cruz.

Recuerdo de artículos míos recomendando que el presupuesto fuera holgado, teniendo en cuenta esta situación de incertidumbre inicial, sin embargo, la solución no pasa por ahí, sino que pasa por la definición de presupuestos objetivos y por la predisposición a modificarlos si las circunstancias del proyecto lo aconsejan.

Cuando hablo de presupuesto objetivo lo hago desde la perspectiva de que se base al menos en una visión sólida del producto, para lo cual no es necesario hacer un análisis completo y en detalle del sistema de información, teniendo en cuenta que ese presupuesto objetivo obedece a una visión inicial (aunque sólida) del producto y que después habrá cambios que afectarán a las condiciones de la agenda.

Cuando el usuario quiera cambiar cosas deberá negociar y en esa negociación suelen quedar tocados tanto desarrolladores como usuarios, los primeros porque el esfuerzo a realizar tras el cambio será mayor, ya que el cumplimiento de la agenda recaerá sobre sus espaldas y los segundos porque no podrán llevar al producto todos los cambios que entienden que son necesarios (el valor del producto está fuertemente limitado por el valor teórico del producto en su especificación) y tendrán, probablemente, un producto de mayor deuda técnica (se descuidará la calidad del desarrollo como consecuencia de incrementar el ritmo de trabajo y del más que probable overtime que tengan dedicar) y con una peor ejecución funcional porque se habrá dedicado menos tiempo (si es que se ha dedicado alguno) a la detección y corrección de incidencias y deficiencias funcionales.

Pero, ¿dónde comienza la gestión de agenda?, ¿antes o después de tener el catálogo de requisitos?. La respuesta natural a la pregunta es que poca agenda puedes gestionar si no sabes lo que vas a hacer y en base a ellos se ha definido un presupuesto y unos plazos equilibrados.

Sin embargo, nos encontramos con dos escenarios:

1) Definición de agenda, una vez definido el alcance inicial del proyecto.

2) Definición de agenda, sin tener una versión inicial del catálogo de requisitos y por tanto, con una estimación del presupuesto y plazos un tanto irreal.

El primer escenario es en el que realmente tendría sentido la gestión de la agenda ya que se da por conocido el sistema que hay que desarrollar y para ello se ha dedicado un presupuesto y previsto unos plazos. Sin embargo, al final, el problema sigue siendo el mismo, porque cuándo surjan modificaciones en los requisitos tocará negociar para mantener la agenda y en caso de desacuerdo el perjudicado en primera instancia será el producto final, en segunda instancia todo el resto de implicados.

En el artículo de mañana analizaremos el segundo escenario que, por desgracia, suele ser el más habitual.

Es cierto que llegado el momento puedes abrir la mano y permitir cambios en las especificaciones, pudiendo negociar el intercambio de requisitos, pero la verdad es que no suele dar buenos resultados por diversas razones: el intercambio no es real (generalmente las tareas que entran suponen más esfuerzo que las que salen, si es que sale alguna), se cambian requisitos sobre visiones abstractas del producto por lo que se siguen realizando a ciegas independientemente de que la visión tenga menos niebla que al principio y además, cambiar de enfoque en determinadas funcionalidades, con el producto avanzado tiene un coste alto.

Esto último también se puede producir en un desarrollo iterativo incremental, lo que lo diferencia es que en muchos casos, la detección del problema se habrá realizado en etapas más tempranas (en el caso de que no sea un cambio de enfoque por cambios en el proceso) ya que los usuarios estarán interactuando con el producto mucho antes.

La gestión de proyectos basados en enfoques clásicos o predictivos es en realidad una gestión del desgaste porque el cumplimiento de la agenda implicará falta de flexibilidad una vez que el análisis inicial se ha completado.

En ese triángulo que forman: alcance, coste y plazos, la modificación de uno de los vértices impacta sobre el resto salvo que exista un margen suficiente que por otra parte casi nunca existe o casi nunca es suficiente. Si no existiendo ese margen se modifica el alcance (o el esfuerzo para conseguir los objetivos, ya que lo mismo el alcance es similar pero la modificación de requisitos sobre componentes construidos hace que sea necesario un esfuerzo mayor ya que el ya invertido hay que contarlo) y se quieren mantener costes y plazos, el primer afectado será la calidad final del producto.

El enfoque clásico o en cascada del desarrollo de software es un modelo de carácter predictivo. Se realiza un análisis del sistema a desarrollar o de los módulos a evolucionar (alcance), se estiman costes y plazos y se trata de gestionar esta agenda (lo que se denomina triángulo de hierro) durante el resto del proceso de desarrollo.

Resulta razonable que pueda funcionar, sin embargo, es un modelo basado en la estabilidad del contexto y en la rigidez de los requisitos y ahí es dónde empieza a tener problemas porque una vez sentadas las bases, lo que cobra prioridad es el cumplimiento de la agenda ya que se entiende que el producto está definido.

La realidad es que los requisitos van a cambiar, conforme vaya avanzando el desarrollo del producto el usuario se dará cuenta de que determinadas especificaciones no son buenas o son mejorables, que se le ha olvidado tal o cual gestión o que las prioridades indicadas tienen que modificarse.

No se trata de que el desarrollador (analista o el componente del equipo que haya hecho ese trabajo) o el usuario lo hayan hecho mejor o peor (por supuesto que un buen trabajo permite trabajar en unas condiciones mucho más favorables) sino de algo que es natural en un proyecto de desarrollo de software y es que haya una evolución ya sea del negocio y/o de la percepción que tienen los usuarios con respecto al sistema de información o algo tan simple y tan frecuente (y humano) como que nos hayamos equivocado.

Esto no es algo que yo me esté inventando, ¿en cuántos proyectos has trabajado en los que no se hayan tenido que cambiar algunos de los requisitos iniciales o se hayan tenido que añadir otros nuevos?.

Como la realidad es esta, tenemos que gestionarla: hay un catálogo de requisitos que permanece vivo a lo largo del proceso de desarrollo.

Como esa es la realidad, los enfoques iterativos incrementales son, a mi juicio, la mejor estrategia para afrontarla, teniendo en cuenta pueden existir proyectos, ¿por qué no?, donde el enfoque clásico sea el más apropiado.