archivo

Archivo de la etiqueta: enfoque evolutivo

El producto resultante de un proyecto de desarrollo de software requiere de un período de maduración que comienza con el inicio del mismo a través de los ajustes que se realizan en las diferentes iteraciones y a través del conocimiento adquirido dentro y al final de las mismas (no solo se trata de aprender del feedback, se puede aprender también mientras se analiza una historia de usuario y nos apoyamos en estrategias tales como prototipado, pantallazos, etc…).

La solución no se tiene clara desde el principio, nadie la tiene ni usuarios ni desarrolladores (cada uno dentro de su ámbito de actuación) y lo más probable es que la visión que ambas partes tengan del producto en ese momento difieran sensiblemente.

El conocimiento inicial es limitado y esto eleva la probabilidad de que cometamos errores.

Es cierto que por algo tendremos que empezar y eso ya supone una apuesta pero eso es diferente a jugar todas tus cartas a una solución y tirar con ella hasta el final que es lo que sucede en los ciclos de vida clásicos. En estos casos también se madura la solución pero más a nivel técnico que funcional lo que da lugar a los problemas habituales en la aceptación del producto o tras su puesta en producción y es el desajuste entre lo que el usuario recibe y las expectativas que tenía puestas en el mismo.

En el proceso de maduración tendremos probablemente que desechar decisiones que tomamos en etapas anteriores precisamente por el hecho de no haber acertado o por existir otras soluciones más efectivas y válidas. Tirar y volver a hacer tiene un coste pero más caro resulta ir hasta el final con una solución no satisfactoria.

Lo importante es hacer un producto cada vez mejor aunque no consigamos un avance lineal en el proyecto.

Bertrand Meyer realizó la siguiente cita: “Las malas ideas y las más complicadas (que a menudo son las mismas) a menudo aparecen las primeras, se necesita tiempo para que aparezcan las simples y elegantes”.

Comenta Roy Miller (consultor y autor experto en metodologías ágiles) que: “Todo lo que necesitamos saber es el primer paso que tenemos que dar para dirigirnos hacia donde pensamos que queremos dirigirnos en ese momento”.

Este tipo de reflexiones se realizan principalmente para llamar la atención sobre un aspecto concreto y en este caso lo que trata probablemente de hacer Roy Miller es que dediquemos unos minutos a pensar por un lado en la incertidumbre característica de todo proyecto de desarrollo de software y por otro en su enfoque evolutivo en el cual vamos construyendo poco a poco el producto objetivo que lo mismo difiere de manera sensible de la idea que del mismo tenían inicialmente los usuarios y el propio equipo de desarrollo.

Siguiendo un enfoque evolutivo sí que resulta relevante cuál es el siguiente paso que tenemos que dar ya que nos permitirá llegar a la siguiente etapa y allí ya veremos pero no por ello, y estoy seguro que Roy Miller piensa de manera parecida, debemos obviar otro tipo de información que puede resultar de utilidad como por ejemplo los riesgos del proyecto y su situación (que llevamos hecho, qué tareas estarían pendientes de realizar, cuál es el presupuesto restante, qué problemas nos estamos encontrando en el proyecto, cuáles están originando resistencia al desarrollo, etc…).

No se trata de control sino de ser consciente de cómo estamos algo importante para evolucionar porque el siguiente paso importa pero también desde dónde se da.

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.

En los enfoques clásicos los cambios tardíos en los requisitos suponen un golpe muy duro al proyecto porque suelen llegar cuando se están mostrando los avances en la construcción del proyecto, en las pruebas de aceptación o con el sistema en producción.

Ese feedback dará lugar a nuevas peticiones de cambio por parte del usuario ya advertirán aspectos que no han tenido en cuenta, otros que son mejorables y otros que son incorrectos (ya sea por una mala especificación del usuario, por una mala interpretación de la misma por parte del desarrollador o por una mala ejecución de los trabajos). Como el desarrollo del producto está tan avanzado el coste de estos ajustes será importante en muchos casos, sobre todo si se plantean cambios severos en el núcleo de la aplicación (teniendo en cuenta que la deuda técnica va creciendo conforme crece el tamaño del producto).

En otras palabras, que te cambien los requisitos tarde es un marrón y lo peor de todo es cuando esto sucede en un enfoque predictivo como el clásico en el que teóricamente se espera que esto no suceda (aunque hasta el mayor defensor a ultranza de los enfoques clásicos sepa que esto va a pasar) y en donde resultará complicado hacer ajustes en el presupuesto (algo que habría que hacer cuando los cambios no sean motivados por fallos o negligencia del desarrollador).

¿Es un marrón en un enfoque de carácter evolutivo? No puedo decir que este enfoque sea a prueba de cambios porque no lo es. Si pese a que se ha seguido un desarrollo iterativo incremental en donde el usuario ha aportado su feedback desde etapas tempranas resulta que en fases muy tardías hay cambios severos en el proceso o procesos que se implementan o se descubre que el usuario ha sido negligente te revienta el proyecto, quieras o no, y darle la vuelta al calcetín resulta complicado cuando no imposible si no se ajusta el presupuesto y se resuelven determinados problemas que han dado lugar a esta situación (por ejemplo si el usuario ha sido negligente será necesaria su sustitución).

Partamos de la base de que los cambios son ajustes, unos más grandes que otros pero moderados, y que el objetivo es, como no podría ser de otra manera, desarrollar un producto de calidad que satisfaga las expectativas del usuario, si el usuario detecta que es necesario hacer cambios sobre un producto maduro (incluso con varias iteraciones en producción) se hacen, recordemos que no desarrollamos para nosotros sino que desarrollamos para el usuario y él sabe mejor que nadie qué es lo que necesita y más en estas etapas donde ya están trabajando sobre algo real y en producción.

Lo complicado de esto es que el usuario entienda que todo ajuste tiene un coste, ahí es donde se sustancia el problema, en querer que con un presupuesto inicial realizado desde la más absoluta incertidumbre y con gran desconocimiento del resultado final del producto se cubra todo el trabajo. Si se supera esa resistencia, bienvenidos sean los cambios siempre que los mismos den lugar a una mejor versión de la aplicación.

Comenta Jim Highsmith en el libro “Agile Software Development Ecosystems”: “Los planes son hipótesis a contrastar en lugar de predicciones a realizar”.

Resume la diferencia básica entre un enfoque evolutivo y un enfoque clásico.

El enfoque evolutivo está basado en iterar nuevas versiones del producto y mediante el feedback del usuario determinar en qué se ha fallado y en qué se ha acertado (por el momento) de manera que la siguiente versión sea mejor y más completa (con las nuevas tareas incluidas en el sprint), sin embargo en el enfoque clásico se espera que el proyecto transcurra linealmente porque todos los planteamientos iniciales serán igualmente válidos al final del proyecto.

Sé que la descripción que he realizado del enfoque clásico es demasiado ortodoxa y que todos los que desarrollan según este tipo de metodologías saben que no es así y que hay cambios prácticamente en todas las fases del proyecto o lo que es lo mismo, la predicción es imperfecta. Sin embargo aunque esto suceda el planteamiento en el proyecto seguirá siendo rígido (con determinadas concesiones al usuario) y alejado de un feedback sobre un producto real.

Nuestro trabajo no es conseguir imposibles.

Trabajamos con un presupuesto y tiempo limitado, es decir, trabajamos con unas restricciones. Se pueden y se deben ajustar si es necesario pero teniendo en cuenta que el chicle no se puede estirar indefinidamente.

También es frecuente que en el desarrollo normal de un proyecto nos encontremos en un momento dado con más tareas que las que podemos llevar a cabo ya sea a título individual o a nivel de equipo de proyecto.

Esto nos lleva tanto a nivel general del proyecto como a nivel de un momento determinado del mismo a una priorización de las tareas. Para ello es necesario que el área usuaria decida con criterio qué es lo más importante (teniendo en cuenta que todo tiene un coste) hasta que la dinámica de trabajo esté consolidada considerarán que todo es importante, crítico y urgente y aunque así sea (que no lo es) no tendrán más remedio que hacerlo (a veces cuesta que lo entiendan pero mejor así que darles unas expectativas que no vamos a poder cumplir). Una buena estrategia para la asignación de prioridades es la asignación por parte del usuario de un grado de importancia a la tarea del cero en adelante (la menor importancia es el cero) y sin tener la posibilidad de repetir un valor.

Hay que tener en cuenta que si aplicamos un enfoque evolutivo en el desarrollo de software el usuario irá poco a poco dándole forma a la idea general que tenía en la cabeza, la importancia de empezar por lo más prioritario permite que no se invierta el tiempo en realizar tareas secundarias dependientes de otras primarias y que podrían ser desechadas o modificadas si cambia la principal.

En eso consiste desarrollar con intención.

La visión de este problema por parte de Ken Beck y Martin Fowler la reflejan en el libro “Planning Extreme Programming” y es la siguiente (traducción libre): “Cuando estás saturado, no lo veas como que no tienes suficiente tiempo sino como si tuvieras demasiadas cosas que hacer. No podemos conseguir más tiempo pero sí tenemos la posibilidad de hacer menos, al menos por el momento”.

El enfoque evolutivo del desarrollo de software desde una perspectiva ágil consiste en ir descubriendo el camino hacia el cumplimiento de las expectativas de usuario a través de la oscuridad de la incertidumbre que rodea a los proyectos, de la resistencia que encontremos y de los cambios de dirección y sentido que provocan los cambios de contexto.

La brújula es el feedback sobre iteraciones del producto teniendo como base nuestro background como desarrolladores de software y la intención con que se afronta cada evolución del sistema (una cosa es tener que descubrir el camino y otra no tener muy claro realmente a dónde se quiere ir) y nuestro motor el funcionamiento real como un equipo de trabajo.

Los enfoques clásicos, predictivos por naturaleza, entienden que desde el principio se sabe cómo llegar al producto que se desea y que en cualquier caso a lo largo del proceso de desarrollo se podrían realizar ligeros ajustes.

La realidad que nos encontramos en los proyectos de desarrollo de software nos indica que en la mayoría de los casos no se sabe qué es lo que se quiere realmente (o por lo menos con la suficiente precisión como para poder plantear un enfoque clásico) y que el camino para llegar a ese objetivo tiene muchas curvas, subidas y bajadas, asfalto de distinta naturaleza y diferentes condiciones climáticas.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.217 seguidores