archivo

Archivo de la etiqueta: enfoque clásico

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.

A veces los nuevos contextos no son el de por circunstancias externas (o que tienen una alta influencia desde el exterior) sino que son creados por cambios provocados desde dentro, los cuales nos pueden proporcionar una ventaja competitiva con el resto si somos capaces de ser los primeros y de hacerlo bien.

Esta necesidad de dar una respuesta rápida a estos cambios supuso otro argumento más para pasar de un enfoque clásico al ágil en términos generales y en el desarrollo de software ya que cuando hay que evolucionar hay que hacerlo lo antes posible y eso requiere romper con determinados convencionalismos de manera que en lugar de recrearnos en el proceso o en la metodología el camino pasa a ser: “hay un problema, resolvámoslo, tenemos un objetivo, vamos a por él, hay que cambiar, hagamos lo que haya que hacer, ¡pero ya!”, sin que esto tenga que suponer necesariamente una merma en la calidad del producto final (la que se considere necesaria) como tampoco te asegura dicha calidad aplicar fórmulas clásicas.

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.

Es cierto que está haciendo daño a la extensión de los enfoques, prácticas y metodologías ágiles el hecho de que se considere la aplicación de estas estrategias como el martillo de oro que resuelve todos los problemas relacionados con el desarrollo de software y que permite conseguir que todos los proyectos terminen con éxito.

Nada asegura de antemano el éxito, la agilidad tampoco. Todos hemos tenido éxitos y fracasos con enfoques clásicos en el desarrollo de software y también los tendremos con enfoques ágiles.

Entonces, ¿qué aporta la agilidad? una aproximación más natural a las características inherentes al proceso de desarrollo de software y por tanto, proporcionarán unas soluciones más acordes a la problemática que nos encontraremos en los proyectos. Siempre será más fácil alcanzar una meta remando a favor de corriente, siguiendo un recorrido natural que aplicando enfoques o metodologías que no se adaptan a la naturaleza del desarrollo de software.

Es importante, desde mi punto de vista, que en las tareas de difusión de los enfoques ágiles de desarrollo de software se incida precisamente en lo que aporta al proceso de desarrollo como consecuencia de asumir que éste se realiza bajo un contexto de incertidumbre y dejando claro que la misma puede acabar con el proyecto y el producto incluso habiendo aplicando principios o metodologías ágiles de manera adecuada y que la propia aplicación de los mismos no significa nada si el contexto no acompaña o si la ejecución de sus prácticas o del propio producto no se realiza de manera adecuada. Son muchos puntos donde se puede romper la cuerda.

Agilidad, sí, realidad, también.