Ron Jeffries, Ann Anderson y Chet Hendrickson en el libro “Extreme Programming Installed” hacen la siguiente reflexión: “Si tu cliente sabe ahora exactamente lo que quiere, y si en el momento en que haya terminado todavía va a querer lo mismo, puede ser la primera vez en la historia del software que esto ha sucedido. Probablemente habrá un premio para ti en algún sitio”.

Está bien que estos autores lo pongan en su libro pero probablemente tu propia experiencia te hará llegar a la misma conclusión.

La aparición de la agilidad y métodos de trabajo potencialmente ágiles (siempre os digo que realmente lo que la hacen ágil o no es la actitud de las personas en el proyecto) no fue un capricho, sino una respuesta a unos métodos de trabajo que no respondían a una realidad que se repetía de manera insistente en los proyectos de desarrollo de software y que se basaba generalmente en el ciclo de vida tradicional.

Pero las metodologías, marcos o estrategias de desarrollo son solo herramientas, es necesario entender el fundamento del enfoque iterativo incremental y se puede resumir perfectamente en la cita en la que se basa este artículo.

Los usuarios pueden tener claro lo que tienen (cosa que está por ver) e incluso que el contexto del proyecto se pueda mantener de forma más o menos estable y no influya excesivamente en la línea de desarrollo del producto pero lo más probable es que los usuarios vayan haciendo ajustes en su visión del producto conforme se trabaja con más detalle en el mismo y conforme van viendo versiones del producto mientras se está desarrollando o mientras se entregan sprints y eso es debido a que es muy difícil abstraer lo que se cree que se quiere, a algo concreto.

Si pese a que sois desarrolladores habéis sido usuarios (incluso vuestros propios usuarios) os habréis encontrado muy probablemente con situaciones en la que vuestra idea inicial del desarrollo ha sufrido cambios sensibles.

Los proyectos se pueden llevar más de lejos o más de cerca. Personalmente prefiero realizar un seguimiento más directo del proyecto y tener un mayor contacto con el área usuaria, con el equipo de proyecto y otras áreas implicadas en el proyecto.

Es posible que tengas que realizar una gestión del proyecto desde más distancia debido a que tal vez la carga de trabajo que tengas asignada sea excesiva, ante ese tipo de circunstancias lo más que se puede hacer es tratar de estar lo más implicado posible y saber muy bien dónde y cómo priorizar el esfuerzo, ya que prácticamente lo que te tocará es ir apagando fuegos.

Tener a un jefe de proyectos sobrecargado presenta sus inconvenientes porque los separa de lo que se cuece en los proyectos. A veces los informes que te envían o los números del proyecto te pueden dar una idea, pero la verdad no está ahí, sino en lo que pasa en el día a día.

Esa mayor implicación traerá consigo ir más lejos porque te permite de primera mano atender a las necesidades del proyecto, sentir más empatía con tu equipo y el resto de stakeholders, tomando decisiones y realizando acciones que no harías si no te sintieses parte del proyecto.

Un problema que se suele producir bastante a menudo es que se desarrolle un determinado producto software sin tener en cuenta determinadas restricciones o problemáticas a nivel de base de datos, servidores o incluso determinadas políticas en cuanto a cómo debe realizarse la entrega.

Muchas veces esas restricciones, problemáticas y normativas están escritas incluso con detalle y también se cuenta en numerosas ocasiones con la experiencia de trabajar en esos entornos pero si se tienen dudas, por ejemplo, porque se trate de un desarrollo que presenta diferencias significativas con respecto a lo que es común instalar o que tenga unas necesidades de proceso de datos, almacenamiento o infraestructura que puedan resultar necesarias analizar, es fundamental reunirse con las partes implicadas.

Tal vez pueda ser complicado llegar a determinados acuerdos o consensos pero mucho mejor resolver los problemas en este momento que encontrarlos cuando ya se ha invertido una parte importante en el producto o cuando esté en producción y esas necesidades no funcionales no puedan ser cubiertas de manera satisfactoria con la infraestructura existente.

Además, servirá para hacer equipo porque las personas de los departamentos de base de datos, de sistemas, etc… valoran que se les tenga en cuenta en ese proceso de toma de decisiones, ya que cuando existen problemas en el sistema también les afecta a ellos.

Un esquema tradicional de la implantación del software podría ser el siguiente: 1) instalación en el entorno de integración, 2) Pruebas del sistema en el entorno de integración, 3) Instalación en un entorno de pruebas/preproducción, 4) Validación de el entorno pruebas/preproducción, 5) Instalación en producción.

Que sea tradicional no quiere decir que todos estén de acuerdo con él (y el esquema sea absolutamente distinto) o que sobre el mismo no haya modificaciones.

No entro a valorar si las instalaciones se realizan de forma automatizada o no, no es el objeto del artículo sino de las pruebas o validaciones. Tampoco entro en si se deben realizar pruebas unitarias o automatizadas de mayor nivel, ya que me quiero centrar más en las pruebas de carácter manual que realiza el equipo de testing (si existe) y/o los usuarios.

¿Se debe probar antes de entregar? Por supuesto que los desarrolladores deben hacerlo porque pese a se prueben secciones del sistema durante el desarrollo, es necesario hacer un testing final que afecte al conjunto de funcionalidades entregadas y hacer pruebas de regresión.

¿Debe probar el usuario? Es cierto que se requiere que los usuarios tengan tiempo para realizar esta tarea y en muchos casos, cuando los cambios son significativos y la aplicación compleja, el esfuerzo necesario es importante. Yo soy partidario de que los usuarios prueben en el entorno de integración sobre todo si el impacto funcional del desarrollo es importante (y/o la criticidad del cambio lo aconseja) y si los desarrolladores no tienen un control funcional lo suficientemente sólido.

Otro factor a tener en cuenta es el tiempo medio que se suele tardar desde que se entrega hasta que el producto llega a producción, teniendo en cuenta los posibles rechazos que puede haber en ese proceso.

En cualquier caso, como suelo decir, no se trata de aplicar necesariamente una política general a todos los proyectos sino de realmente analizar las características del sistema (es muy importante tener en cuenta su criticidad), de los cambios realizados, de los usuarios, etc… lo que pasa es que a veces por buscar una armonización de las tareas de testing se suelen establecer una normativa común (que puede admitir o no excepciones motivadas).

También es importante recordar que normalmente el coste de corrección de una incidencia suele ser proporcional al tiempo que ha pasado desde que se ha incorporado al código.

Lo que a corto plazo puede ser una buena decisión, es posible que no lo sea a nivel estratégico, a más largo plazo. También puede ser al revés, es decir, que olvidar el corto plazo sea un error, sobre todo si hay aspectos que es necesario abordar en breve y que puedan tener impacto en el proyecto o en la organización.

Por ese motivo hay que valorar el corto y el largo plazo y no centrarnos exclusivamente en un aspecto. Es cierto que tiene sentido que tengamos una perspectiva más estratégica pero también lo es que el momento actual también puede tener necesidades que deberían ser cubiertas.

En los proyectos de desarrollo de software a veces resulta importante elegir un determinado camino y para ello hay que valorar muchas cosas. Cuando existe impacto económico y éste es significativo, la decisión es complicada porque tiene más trascendencia y eso hace necesario que las diferentes opciones sean vistas no solo para resolver problemáticas puntuales sino para alcanzar objetivos concretos que lo mismo pueden ser diferentes o aconsejar una alternativa distinta.

Es cierto que el momento actual es acuciante porque las presiones que recibimos en el proyecto son consecuencia del mismo pero eso no debe condicionar la decisión salvo que la no atención de esa problemática pueda impactar sensiblemente en el proyecto.

Si empiezas a tomar decisiones sin escuchar a nadie llegará un momento donde los componentes de tu equipo dejarán de expresarte su opinión y se perderá con ello todo ese valor que pueden aportar al proyecto, porque muchas veces no se trata exclusivamente de que las personas realicen sus tareas habituales, sino de que puedan aportar su visión sobre otros aspectos o circunstancias (técnicas o no) que pueden ocurrir en el proyecto.

No sabes de todo, no entiendes todo, no lo ves todo. Más personas tienen más capacidad de interpretar un problema desde distintas perspectivas. No creas que tienes siempre la respuesta para todo y que no hay mejor solución que la que tienes en mente, puede que sea buena, pero con las aportaciones de tu equipo es muy probable que sea mejor.

Todas las personas del equipo de proyecto son importantes, demuéstralo, escúchales, de esta forma no solo consigues aprovechar mejor su potencial sino que también estarán más implicados en el proyecto.

Soy muy partidario de escuchar diferentes opiniones y si al final mi solución no es válida o es mejorable, no pasa nada, se rectifica. No se trata de tener siempre la solución sino de hacer que la mejor solución posible llegue al proyecto venga o no de ti.

Hay una cosa cierta, de cada proyecto en el que trabajamos, si tenemos la intención, aprendemos más y por tanto, tenemos la posibilidad de adaptar mejor nuestra forma de trabajar a las circunstancias que se presenten y de poder hacer uso de esa experiencia para tratar de acertar más en nuestras decisiones.

Por ese motivo me parece muy interesante la reflexión de Lowell Lindstrom que si bien está centrada en la programación extrema es perfectamente extensible a cualquier otro esquema de trabajo (traducción libre): “XP no es el final del viaje, es sólo el pozo de agua corriente que es especialmente sabroso para muchos. Vamos a aprender más con cada proyecto que hacemos”.

Cada proyecto es diferente e incluso dentro de cada uno hay circunstancias que implican cambios más o menos sensibles en el enfoque, por ese motivo si nos limitamos exclusivamente a aplicar las mismas ideas, prácticas y métodos de trabajo probablemente estamos restringiendo nuestra capacidad de poder aplicar determinadas soluciones que pueden resultar más aconsejables al contexto del proyecto.

Ojalá todo fuera tan fácil en el desarrollo de software como seguir unas guías, de hecho si así fuera la mayoría de los proyectos tendrían éxito y el concepto de crisis del software estaría erradicado.

¿Tienen éxito la mayoría de los proyectos? Lo mismo tu respuesta es que precisamente no tienen éxito por no aplicar en ellos marcos de trabajo o metodologías. No quiero decir que no se hagan uso de ellas, sino de que sea excesivamente rígido con la forma en que se aplican y de que no se tenga en cuenta de que nuestro conocimiento y las técnicas que tenemos a nuestra disposición son herramientas que tenemos la posibilidad de aplicar o no en función de las necesidades del proyecto.