archivo

Archivo de la etiqueta: ciclo de vida

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.

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.

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

Sinceramente, creo que lo más interesante de mi blog, por encima de determinados artículos o series de artículos concretas se encuentra en que queda reflejada mi evolución desde un enfoque clásico en el proceso de desarrollo de software a otro orientado hacia principios ágiles.

Releyendo artículos de años anteriores me doy cuenta perfectamente de mi evolución. No me arrepiento de haber escrito ninguno de esos artículos porque donde me encuentro actualmente es consecuencia, no solo del cambio de enfoque, sino de un proceso de adaptación desde mis ideas originales concebidas en una formación y en una experiencia y contexto laboral enfocado orientado al desarrollo en cascada.

De hecho considero importante saber de dónde vengo porque puedo apreciar basado en una experiencia previa lo que aporta un enfoque de desarrollo respecto al otro y tengo más criterio a la hora de aplicar principios ágiles en proyectos orientados a metodologías clásicas, además de poder aprovechar conceptos y técnicas válidas de los desarrollos en cascada en otros iterativos e incrementales.

Otro enfoque que se puede aplicar es una variante del anterior y que podría suponer un modelo híbrido entre el modelo con presupuesto y plazos cerrados y el modelo con presupuestos y plazos abiertos (pago por iteración), para ello:

1) Se contrataría la realización del catálogo de objetivos y requisitos, pero centrándose en la obtención de aquellos que sean esenciales para obtener una versión mínima del sistema que sea operativa en producción, es decir, que sea utilizada por usuarios en circunstancias reales.

2) Se contrataría el desarrollo de esa versión y se aplicarían los criterios indicados en el artículo anterior sobre los aspectos que deben quedar fijados en el contrato.

Este desarrollo podría comprender más de una iteración.

3) Con la aplicación usándose en un contexto real el feedback cobra más relevancia. En este caso se podría abordar la contratación de incrementos del producto, ya sea mediante pago por iteración o con un enfoque más amplio, mediante un contrato de mantenimiento evolutivo que se podría articular de diferentes formas:

– Volver a aplicar la estrategia de contrato de catálogo de objetivos y requisitos + contrato de desarrollo.

– Directamente realizar la contratación del mantenimiento evolutivo y mediante órdenes de trabajo se encargarían las diferentes iteraciones a realizar sobre el producto.