Javier Garzás, o de la conjugación de lo teórico con lo práctico

Javier GarzasLo que distingue a un profesional de otro es su talento, su capacidad de innovar a gran velocidad, de relacionarse con su entorno y de transmitir conocimiento y experiencias, más que información, a sus pares. Ese es el caso de Javier Garzás, quien se ha mantenido, sagazmente, entre dos universos de cuya concordancia ha obtenido los mejores beneficios.

Doctor, PhD, (calificado cum laude por unanimidad) e Ingeniero en Informática (premio extraordinario), con un Postdoctorado en la Universidad Carnegie Mellon (Pittsburgh, EE.UU). Y más allá de los títulos, hasta la fecha, ha ayudado ya a más de 80 empresasa que hagan mejor software, en tiempo, en productividad, con calidad y felicidad, como él mismo acostumbra decir.

El Dr. Garzás ha escrito 20 libros, sobre temas de estimación, diseño OO (como el libro “Object-Oriented Design Knowledge”), etc. Dos de esos libros son sobre agilidad: ‘Gestión de proyectos ágil…y las experiencias de más de 12 años de proyectos ágiles’ (que va por la 3ª edición) y ‘Cómo sobrevivir… A la planificación de un proyecto ágil’.

Actualmente es profesor de la Universidad Rey Juan Carlos, fundador de Kybele Consulting y colaborador con la startup www.233gradosDeTI.com. Y en medio de este movimiento de traslación en el que se mantiene, aceptó gustosamente la invitación que la Comunidad amiga Avanet le hizo para venir a #Agiles2014, oportunidad que aprovechamos para que nos contara un poco sobre sus experiencias en la academia y en la industria y sobre las altas y las bajas del movimiento Ágil.


Javier, has recorrido un muy largo camino en la academia, con una parada en un doctorado y otra en un postdoctorado. Y del recorrido en la industria ni hablar: Más de 15 años, más de 80 empresas y proyectos. Sabemos además que en Ingeniería de Software sigue habiendo una separación de intereses entre la academia y la industria. ¿Cómo crees que estos dos ecosistemas se pueden conjugar para lograr resultados aun mejores?

Es un reto al que ambas partes, academia e industria, están obligadas a darle una solución. Más aún en disciplinas como la nuestra, informática y relacionadas, cuya aplicación a la empresa y a la mejora social es directa.

La Universidad debe ayudar a la industria, formando mejores profesionales y ayudando mediante los resultados de sus investigaciones. Y la empresa debe ayudar a la Universidad validando sus aportaciones, probándolas y transfiriendo a la universidad sus necesidades.

Pero, aunque parezca muy obvio y de sentido común… no podemos negar que la transferencia de conocimientos Universidad – empresa es hoy un reto.

Por un lado nos encontramos más preocupación por publicar en revistas importantes, que por realizar investigaciones que ayuden a la empresa. Y el otro, más preocupación por vender cómo sea (en precio y tiempo) que por invertir en mejoras, investigación, formación y en diferenciarse de la competencia por hacer mejor software (en vez de por precio y tiempo).

Claro que, las regiones que han sabido hacer de verdad transferencia Universidad – empresa son hoy líderes tecnológicos.

 

¿Y cómo crees que la academia puede contribuir al mejoramiento del entorno ágil en la industria?

Indudablemente la academia, la universidad, tiene un papel clave, al ser la institución que debe formar a los futuros profesionales del software, los cuales deben estar formados en las mejores técnicas, prácticas, etc., para hacer tecnología, entre ellas, la agilidad.

 

En tu último libro, ‘Gestión de Proyectos Ágil’, comienzas diciendo que construir software no es como construir autos o casas. También aseguras que la práctica más discutida y polémica que hemos traído a nuestra industria, prestada de otros ambientes, es la predictibilidad. Nada más cierto. ¿De qué otras prácticas, enfoques o incluso conocimiento debemos deshacernos quienes practicamos la Ingeniería de Software, en general, y la Agilidad, en particular?

Sin duda, la parte más profunda, impactante y peligrosa es la que comentas: asemejar la creación de software con la fabricación tradicional de productos físicos, con la industrialización, etc.

A ello debemos prácticas aún vivas, como el “ciclo de vida en cascada en proyectos de años” (típico en la construcción de obras), los dañinos “contratos cerrados” (luego entraré un poco más en ellos), “el sólo haré las cosas con calidad si el cliente las paga” (como si la calidad en software fuese un lujo, como sucede en la industria, cuando en software la calidad realmente es algo necesario para lograr mantenimientos económicos), destructivas prácticas como “contar el avance de un proyecto, o la productividad de los desarrolladores, en líneas de código” (al igual que el avance de una obra se puede contar en metros construidos), la sobre documentación, documentar cosas que nunca se implementarán, creer en que “un sistema es mantenible porque está documentado en un pdf” (en vez de serlo por estar bien construido), etc.

La lista es demasiado larga, pero lo lograremos.

 

Y sobre gestión de proyectos ágil, Scrum es precisamente un marco de gestión de proyectos que ni siquiera incluye un rol de Gerencia de Proyectos. Con esto en mente, ¿crees que los gerentes de proyecto de software, como los conocemos hoy, están condenados a desaparecer? ¿Y cómo podemos deshacernos de esos enfoques robustos y fuertes que imponen modelos como los del PMI y similares?

Más que desaparecer creo que la gerencia tradicional, y en general la manera tradicional de estructurar las organizaciones de TI, en el mundo de la tecnología, va a tener que cambiar si quiere competir y estar a la altura de organizaciones más avanzadas que ya han dado el paso del cambio.

Cada vez es más común ver organizaciones más planas, con menos niveles de gerencia, con menos departamentos (en pro de más equipos multifuncionales autosuficientes), con más equipos pequeños en número, frente a equipos gigantes con muchos niveles de jefatura, etc.

¿La mejor manera de deshacernos de enfoques robustos? Pues quizás no tengamos que hacer nada, quizás desaparezcan solos al ver cómo los enfoques ligeros les pasan por el lado y hacen mucho más competitivas a las organizaciones que los usan.

 

Ágil no es perfecto y quizás nunca lo sea ¿Cuáles son hoy los 3 o 5 pecados más grandes del enfoque Ágil?

Bueno, más que pecados, yo los voy a llamar (1) áreas que tenemos que madurar más, (2) áreas que tenemos que hacer que calen en muchos más equipos y organizaciones y (3) maneras de trabajar obsoletas para las que la agilidad da una respuesta pero que aún no hemos logrado que calen lo suficiente. Te dejo una de cada…

1 – La agilidad en grandes empresas, lo que algunos están denominando Scrum en grandes empresas, etc. Creo que en pequeños grupos, empresas, startups, etc., en, mayor o menor medida, el mensaje ha calado, pero en empresas grandes aún hay mucho desconocimiento de cómo escalar la agilidad a nivel corporativo y no sólo en equipos que trabajan de manera aislada.

2 – La incorporación de otros actores, que no son puros de desarrollo software, en los valores ágiles. Lograr realmente lo que llamamos equipos multifuncionales. Destacando dos casos muy claros:

a) El papel que juegan clientes, comerciales, marketing, etc., los llamados “stakeholders”, en una organización que quiere ser ágil. En agilidad lo normal es que esta parte se canalice por medio de lo que todo el mundo hoy ya conoce como “product owner”, pero a la hora de la verdad… cuesta mucho que esto así sea y que además sea de manera correcta.

b) La parte de operaciones, explotación, sistemas, o como cada uno lo llame, muchas veces la velocidad que desarrollo gana con la agilidad se ve frenada por la falta de coordinación e integración con operaciones. Aquí se está trabajando mucho, bajo áreas como DevOps, Continuous Delivery, pero queda mucho.

3 – Lo que en España llamamos contrato cerrado o llave en mano, que es la versión contractual de los grandes proyectos basados en ciclos de vida en cascada, hace un tiempo le dedique incluso un post de mi blog, llamado Contrato cerrado, ¿el peor enemigo del software o mal necesario? (esto te interesa mucho, más que cualquier cosa en la ingeniería software). Este punto para mi es de los que más daño nos lleva haciendo durante más tiempo.

 

Finalmente, Javier, ya has estado antes en Colombia. ¿Hace cuánto? ¿Qué esperas encontrar esta vez en Medellín durante #Agiles2014?

¡Sí! Muchas veces, creo recordar que habré hecho unos 6 o 7 viajes a Colombia.

Tuve una temporada de trabajo allí, sería en 2004. Principalmente residía en Bogotá, con viajes a Cartagena de Indias. La última vez que estuve fue en 2012, para dar una charla en Colombia 3.0

Pero la ciudad de Medellín no la conozco… por ahora J


¡Por ahora! Javier estará en Medellín, con nosotros en #Agiles2014, este 24 de octubre, con su charla ‘Verdades incomodas, y mentiras reconfortantes, que aprendí después de trabajar para 80 empresas software’, donde nos contará sus historias y experiencias, no solo profesionales sino personales, aventuras y desventuras, después de trabajar y colaborar durante su vida profesional con más de 80 empresas – proyectos de desarrollo software.

¡Semejante oportunidad yo no la voy a perder! Ya me registré para la Conferencia más grande sobre Ágil en la región. ¿Y tú? Todavía estás a tiempo, pero apresúrate, los cupos se agotan.