Dave Thomas. Todo es mantenimiento

El desarrollo de software es un continuo adelante y detrás no solo fruto del feedback o del cambios en las especificaciones sino también como parte del proceso de construcción. ¿Quién no tiene que corregir errores?, ¿quién no mejora una sección del código que no termina de convencerle?, ¿quién no tiene que realizar ajustes como consecuencia de evolución solicitada por el área usuaria?.

Este tema lo traté en artículo: «¿Qué es el mantenimiento?» y lo vuelvo a hacer ahora porque realmente el hecho de que en el desarrollo de software la frontera entre la construcción y el mantenimiento sea tan débil (por no decir inexistente) me parece muy interesante ya que refleja un aspecto inherente al desarrollo de software como es su naturaleza evolutiva, es decir, el sistema se desarrolla poco a poco y con el paso del tiempo va adquiriendo forma, en todo ese proceso hay evolución y no solo por los aspectos funcionales (o no funcionales) que se van añadiendo, modificando o eliminando sino porque en ese proceso el software también cambia y no necesariamente para cambiar una funcionalidad (refactorización, corrección de incidencias, etc…).

Esta naturaleza evolutiva junto a otra característica inherente al proceso de desarrollo como es la incertidumbre ponen de manifiesto que el software estará sometido a cambios a lo largo del proyecto (por muy diversas causas) y que será necesario habilitar los mecanismos necesarios para que la adaptación a los mismos se realice lo antes posible.

Me gusta el enfoque que Dave Thomas da sobre este tema (traducción libre): «Si nos fijamos en el tiempo que pasamos programando, escribimos un poco y luego volvemos atrás y hacemos un cambio. O volvemos atrás y corregimos una incidencia. O lo tiras todo o lo reemplazas por otra cosa».

La dificultad de la aplicación de prácticas ágiles IV

Hablo de equipo pero no es suficiente en muchos casos sobre todo si se quiere entrar de lleno en determinadas prácticas que buscan predecibilidad acotada a la iteración, un ritmo en el desarrollo y productividad, sin dejar atrás el feedback que permite aumentar el valor del producto en cada incremento.

Se requiere que el área usuaria crea en ellas, participe, colabore y se comprometa y en otros proyectos, donde las ramificaciones llegan afectan a más grupos de trabajo, hace que prácticamente esos compromisos se extiendan al nivel de la organización.

Es evidente que esto no se puede hacer de la noche a la mañana, por lo menos en organizaciones de un cierto tamaño.

Si las prácticas producen resultados llevarán a la aplicación de otras más para mejorar los mismos y a su extensión a un mayor número de proyectos y equipos de trabajo, es decir, los buenos resultados y un esquema de trabajo donde el desarrollador se siente más realizado producirán un efecto llamada, si bien el impacto de la misma dependerá en gran medida de la organización: si falta comunicación, si no hay formación y si sigue existiendo resistencia al cambio probablemente se tendrán equipos aislados (pocos o muchos) que apliquen este enfoque hasta que se cansen de hacerlo o se hayan marchado buena parte de sus integrantes porque si ya de por sí es complicado desarrollar software más difícil resulta si en lugar de allanar el camino nos colocan resistencias.

Llegado el momento tendrás que tomar la decisión de adoptar estas prácticas desde las trincheras y cuando lo hagas recordarás lo bonito e ideal que venía explicado todo en los libros aún cuando estuviera basado en experiencias reales.

Se tratan de experiencias de otras personas, en contextos distintos, probablemente fruto de una iteración y mejora continua. Tu estás en otra realidad, con otros problemas, no se trata de que tus circunstancias sean más difíciles, es posible que lo sean o no, esencialmente lo que sucede es que son diferentes y tendrás que analizar qué es lo que resultad más conveniente para el proyecto. Dentro de ese análisis pudiera resultar incluso que lo más adecuado sea aplicar un enfoque clásico, ¿por qué no? De entrada ser ágil implica adaptarte al cambio y al contexto para conseguir los mejores resultados posibles.

Es posible que te equivoques y el enfoque aplicado no sea el correcto. Esas personas a las que lees y que imparten conferencias por todo el mundo, también se han equivocado y se equivocan, quien toma decisiones es quien acierta o falla, lo importante es aprender de los errores, teniendo en cuenta que nada es gratis, los errores tampoco.

No hay que tener prisa, soy partidario de ir adoptando prácticas poco a poco e ir perfeccionando paulatinamente su aplicación en nuestro contexto. Conforme las vayamos consolidando tendremos la oportunidad de ir un poco más lejos y así sucesivamente, siempre pensando en lo mejor para el proyecto y el producto que estamos desarrollando.

Conforme vayamos dominando más estas técnicas y veamos que aplicadas de manera adecuada producen buenos resultados, nos sentiremos tentados de un mismo patrón en todos los proyectos. Esto sería caer en el error de la implantación tradicional de procesos en el desarrollo de software.