Entrevista a Víctor Esteban, ingeniero técnico de sistemas.

Introducción y presentación

La gestión de proyectos es un conjunto de actividades específicas realizadas para administrar el proyecto.

Actualmente la gestión de proyectos, desde un punto de vista clásico, está poniéndose en duda, ya que hay nuevos enfoques y planteamientos que intentan evitar los errores más habituales que se cometen en la gestión de proyectos, por ejemplo, las llamadas metodologías ágiles.

Cabe recordar que los productos multimedia, en general, son proyectos complejos. Aplicado al desarrollo de productos multimedia, podemos decir que un proyecto es complejo cuando tanto la tecnología que se utilizará para resolver un problema como los requisitos del proyecto no se conocen claramente al principio del proceso.

Los requisitos tienden a ser complejos con mucha facilidad. De hecho, podemos hablar de requisitos simples si:

• El cliente sabe cuáles son todos los requisitos necesarios y puede transmitirlos al desarrollador, y este es capaz de entenderlos completamente.
• No hay varias partes interesadas en el proyecto con intereses divergentes.
• El cliente sabe exactamente lo que necesita.

Como se puede suponer, esto difícilmente es alcanzable. Aparte, debemos tener en cuenta que los productos multimedia los desarrollan personas que trabajan en equipo. Si las personas ya somos complejas desde el punto de vista individual, esta complejidad se incrementa cuando trabajamos en equipo.

En las metodologías tradicionales, también llamadas predictivas, se intentó luchar contra esta complejidad de forma que tanto los requisitos como la tecnología —ambos aspectos inherentes al desarrollo de productos multimedia— desaparecieran de la ecuación, lo cual dio como resultado fases muy grandes de toma de requisitos, análisis largos de estos requisitos y contratos demasiado cerrados y restrictivos.

A pesar de los esfuerzos efectuados, es difícil luchar contra la complejidad de los productos multimedia y estas aproximaciones no han llevado a la realización de proyectos mejores, sino a tener proyectos con problemas.

Con esto en mente, en 2001 diecisiete ingenieros de alto nivel en el campo del desarrollo de software se reunieron en Utah para explorar y compartir cuál consideraban que debía ser el futuro del desarrollo de un producto multimedia. Dentro del grupo había muchos de los proponentes de metodologías emergentes en aquel momento, como Scrum, Extreme Programming, Crystal, Feature Driven Development y otros. Juntos coincidieron en el nombre para su movimiento: agile (‘ágil’).

En esa reunión los integrantes constituyeron la Agile Alliance (Alianza Ágil) y escribieron el Manifesto for Agile Software Development (popularmente conocido como «Manifiesto ágil»), un conjunto de postulados que ha servido como declaración de valores y principios que deben seguir las metodologías ágiles:

• Personas e interacciones por encima de procesos y herramientas.
• Software que funciona por encima de documentación exhaustiva.
• Colaboración con el cliente por encima de negociación de contratos.
• Respuesta al cambio por encima del seguimiento de una planificación.

Los valores ágiles parecen simples y obvios la primera vez que se leen, y siguen sin modificarse desde el día en que los fundadores de la Alianza Ágil los publicaron como parte del Manifiesto ágil.

Entrevista

Para tratar sobre la dificultad en la gestión de los proyectos multimedia y sobre las diferentes metodologías ágiles entrevistamos a Víctor Esteban (Barcelona, 1971), ingeniero técnico informático de sistemas.

El desarrollo de productos multimedia se basa en proyectos complejos. Teniendo en cuenta tu experiencia, ¿qué fase del desarrollo de un proyecto crees que es más compleja?

Además de las dificultades intrínsecas de un proyecto multimedia, yo creo que hay dos partes importantes dentro de la complejidad de cualquier proyecto.

La primera consiste en identificar bien los objetivos que desea conseguir el cliente y asegurarse de que el diseño de la aplicación permite que el usuario final del producto entienda el uso y el aprovechamiento que puede hacer de él. Escoger las tecnologías en función del estado de la técnica actual y de los recursos y necesidades del cliente, tanto para producir el proyecto como para realizar un mantenimiento eficaz y que permita una buena viabilidad económica.

La otra parte de la complejidad consiste en las tecnologías escogidas. Decidir cómo integrar los diferentes sistemas, los tipos de datos, algoritmos, bases de datos, software propio, software usado como servicio y establecer los recursos necesarios para realizar su producción.

Es necesario saber abstraer las características esenciales para poder tomar las primeras decisiones para dimensionar adecuadamente el proyecto. También la tecnología evoluciona a una velocidad cada vez más rápida y aparecen nuevas herramientas y nuevas formas y procedimientos, por lo que es necesario documentarse siempre para poder adecuar los proyectos al estado de la técnica actual.

¿Nos puedes poner como ejemplo algún caso práctico, algún caso real en el que hayas vivido esa complejidad? ¿Cómo lo resolviste?

Puede servir como ejemplo el caso de un centro formativo que deseaba trasladar su negocio de formación tradicional a un modelo en línea. Es decir, se necesitaba disponer de una plataforma para la realización de los cursos, para desarrollar contenidos digitales e incorporarlos a la plataforma, para captar nuevos alumnos, para generar acciones comerciales, de seguimiento de tendencias para identificar nuevas necesidades y para gestionar administrativamente toda la actividad, tanto formativa como económica. Se trataba de un proyecto no exento de complejidad.

El primer paso consistió en identificar los objetivos de negocio, establecer el flujo de funcionamiento actual del centro y establecer los procesos de funcionamiento para la parte en línea. Con esto se determinaron, junto con los recursos de los que dispone el cliente, los productos de software que se usarían, tanto los existentes en el mercado como los que se debían desarrollar a medida para terminar de completar la funcionalidad que necesitaba el proyecto.

En este caso opté por usar la aplicación Moodle para el entorno docente. Se trata de una aplicación que permite extender la funcionalidad, con lo que es posible configurar, ajustar y extender todo aquello que sea necesario mediante conectores. La aplicación está desarrollada en PHP, por lo que para el desarrollo y mantenimiento se buscó un equipo que conociera este lenguaje.

Para la parte de acceso público se escogió Drupal, un gestor de contenido multipropósito que permite integrarse con Moodle de forma que tanto estudiantes como profesores dispongan de un entorno único integrado. También está desarrollado en PHP, de modo que los mismos profesionales que gestionaban la parte docente podían gestionar también el gestor de contenido (SGC). Las extensiones de Drupal permitieron incorporar la funcionalidad de comercio electrónico para la compra de cursos y material didáctico.

Es decir, para seleccionar las tecnologías y herramientas fue necesario basarse en la relación de objetivos y requisitos que necesita el proyecto, en este caso, trasladar la actividad formativa y un estudio de las herramientas que ya existan en el mercado que se puedan incorporar para el desarrollo de la funcionalidad.

Para la gestión administrativa principal seleccioné un desarrollo a medida con PHP+ Symfony y con un constructor de gestiones de back office llamado Sonata. Con ello se construye la parte del negocio personalizada. También existen otras opciones disponibles, pero el volumen de funcionalidad que ofrecen excede en mucho el necesario, por lo que el aprovechamiento y la adaptación no compensa lo suficiente como para basarnos en un software existente.

«Con las metodologías ágiles la complejidad del proyecto se reduce y hacemos participar al cliente en el proceso de desarrollo»

Y ante otros posibles problemas, ¿por qué soluciones optas como responsable del proyecto?

En función de estos requisitos de negocio, se opta por escoger productos existentes en el mercado, que habrá que adaptar, configurar y extender la funcionalidad que no cubran. La incorporación de software existente permite incorporar las mejoras que con el tiempo se vayan introduciendo en las herramientas. Mientras que, si decidiéramos usar un desarrollo propio, solo tendríamos los recursos propios para mejorar y extender la aplicación. Es decir, podemos aprovechar las actualizaciones y las mejoras en funcionalidad y seguridad de estas aplicaciones y no hemos de desarrollarlas completamente. Si no existiera la posibilidad de incorporar software existente, entonces sería necesario desarrollarlo íntegramente.

¿Cuál fue la reacción del equipo?

Al escoger varios productos desarrollados en el mismo lenguaje podemos aprovechar a los mismos profesionales que incorporemos al equipo.

El equipo de la empresa consta de tres ámbitos: el ámbito docente, el administrativo y el dedicado a la gestión de la herramienta. Todos deben tener un conocimiento básico del flujo de funcionamiento y un conocimiento profundo del uso para aquella parte que forme parte de su responsabilidad. En el mundo en el que nos movemos, el trabajo diferido está cada vez más introducido en nuestra sociedad y en este caso las herramientas deben tener en cuenta esta circunstancia. Tanto para los alumnos como para los profesores y el equipo destinado al mantenimiento de la plataforma.

¿Y la del cliente?

Al cliente le transmitimos la decisión escogida, y el proceso que me llevó a tomar esas decisiones, para hacerlo partícipe de ella y que sea consciente de las ventajas y los posibles inconvenientes. Es decir, más genéricamente, se le describen los elementos principales sobre los que se toman estas decisiones.

¿Has puesto en práctica en alguno de tus proyectos las metodologías ágiles? ¿Qué metodología ágil sueles usar?

La necesidad principal para usar una metodología ágil es mejorar el coste, el tiempo, facilitar la entrega de un proyecto de forma escalonada y no esperar a tener un producto completo antes de que el cliente lo pueda ver. También es más difícil, según mi opinión, caer en la tentación de reducir las partidas vinculadas a test y pruebas.

En mi caso, como no trabajo con equipos fijos, es difícil adaptarse a un tipo concreto de metodología como Scrum, Extreme Programming u otro tipo de metodologías ágiles, pero me baso en ellas con variaciones en función de la configuración del equipo o de las necesidades del proyecto.

También adaptar una metodología a una organización que no la tenga ya implantada es un trabajo complicado. Hay que tener la sensibilidad de captar las características y las habilidades de cada miembro del equipo, para ajustar las reglas y los procesos para que no supongan un esfuerzo adicional y sí se puedan aprovechar las ventajas de una programación ágil.

¿Puedes aportarnos como ejemplo algún caso práctico?

En proyectos de menos de tres meses de duración es difícil poder aplicar metodologías ágiles. Pero en aquellos de duración superior en los que puedan separarse los objetivos del proyecto en productos más pequeños entregables, es posible organizar el proceso de desarrollo en grupos más pequeños. Una de las ventajas más importantes que representa para mí es que la complejidad del proyecto se reduce y hacemos participar al cliente en el proceso de desarrollo, con lo que entiende mucho mejor la funcionalidad conseguida.

Por ejemplo, el desarrollo de una máquina para farmacias en la que se ofrecía el servicio de identificar ciertas características de la piel y ofrecer una recomendación en función de la lectura realizada. La duración del desarrollo de la parte del software tenía una previsión de ocho meses. Se dividió en grupos de dos meses separándose la parte del lado del cliente, manipulación de datos, acceso a dispositivos de hardware e integración. Cada parte separada se construyó como un producto funcional independiente, de forma que el cliente pudo probarlo y validarlo. Aunque no pueda integrarse como un producto final vendible, cada parte tiene una identidad manipulable por el cliente y cada parte dispone de unos objetivos de cliente que se han definido previamente con él.

¿Crees que el proyecto fluye mejor utilizando estas metodologías? ¿El resultado es mejor?

Se obtienen las ventajas que estas metodologías prometen en función de su grado de uso. Aunque —como indico—, en mi caso, una implementación completa de una metodología según su especificación estricta no la he llegado a implementar, porque la duración de los proyectos en los que participo suele ir de los tres a los seis meses de duración y con equipos de trabajo diferentes que, en muchos casos, no tienen la cultura de las metodologías ágiles en mente. Pero eso no impide aprovechar ciertas características de estas metodologías.

¿En qué aspectos de las metodologías ágiles te encuentras más cómodo?

El ciclo de análisis, desarrollo, pruebas e implantación está más unido y es más difícil omitir pasos por parte del equipo o caer en la tentación de reducir el tiempo de pruebas y test. Ya que todos estos pasos se encuentran incluidos en una interacción, por ejemplo, en el caso de Scrum se encontrarían dentro de un sprint.

¿En qué proyectos seguirías trabajando con metodologías predictivas o tradicionales y no apostarías por las ágiles?

Fundamentalmente en función de la naturaleza, los requisitos del proyecto y la duración estimada. Es posible que haya casos en los que sea necesario un ciclo de desarrollo más tradicional. Por ejemplo, en casos en los que haya que hacer una definición precisa y completa de los requisitos del proyecto antes de empezar el desarrollo y que estos requisitos no puedan variarse durante toda la ejecución de los trabajos, o que los cambios que se puedan hacer durante el desarrollo introduzcan un coste importante o la necesidad de disponer de una precisión importante en la fiabilidad del funcionamiento una vez desarrollado el software según los requisitos iniciales.

Cita recomendada: SEDÓ, Ramon G. Entrevista a Víctor Esteban, ingeniero técnico de sistemas. Mosaic [en línea], enero 2019, no. 167. ISSN: 1696-3296. DOI: https://doi.org/10.7238/m.n167.1903.