Metodología ágiles. Catalizando el cambio en sector informático

Índice de contenidos.

• Introducción
• Análisis de la problemática actual
• Metodologías ágiles como solución
• Conclusiones

Introducción

Llevo semanas pidiendo que me hagan muchos dibujos. Me han pedido que explique el porqué de ellos que parecen desconectados: ni mucho menos .. los uso para cursos y charlas que estoy dando de agilismo/emprendimiento. Los dibujos son buenos para explicar y propiciar el cambio.

Serendipia está definida en Wikipedia como “descubrimiento o hallazgo afortunado e inesperado que se produce cuando se está buscando otra cosa distinta”. Eso es lo que creo que ha pasado con la metodología ágiles: buscando un mejor modelo de gestión, se está consiguiendo restaurar el valor del personal cualificado y una inversión del modelo de servicios (de algo degradado a algo mejor). Puede ser un espejismo porque se nos acerca solo la gente que busca ésto pero creo que es sintomático de un cambio mucho más grande.

Vamos por partes viendo un análisis de la situación actual, a tratar de modelar realidades evidentes pero mal entendidas y cómo las metodología ágiles están propiciando cambios.

Análisis de la problemática actual

Analizando el sector del desarrollo de software, en la mayoría de los casos se puede decir que es algo caótico. Como no es algo nuevo, os dejo este dibujo que creo que lo representa muy bien. Resumiendo, los ingenieros “que nos creemos muy inteligentes” no estamos siendo suficientemente “listos” para crear un buen sector y darle el valor que se merece.

[Haga click en la imagen para verla a tamaño completo]

Uno de los primeros fallos que cometemos es que no entendemos que un producto de Software es algo que no se ha construido nunca antes. Además, cuando el usuario de negocio (que lo pide), lo empieza a ver funcionando, es cuando se da cuenta de si es lo que quería o no. Por lo tanto, hace una pre-concepción completa de lo que desea es imposible. En el libro The Leader’s Guide to Radical Management http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=radical_management habla de que hacer software es resolver un misterio… y no un puzzle. Ese matiz vale su peso en oro.

Esto tiene que invitar a la reflexión a quien contrata. Parece razonable, por tanto, que no es el camino seguir con la dinámica tradicional de sacar pliegos cerrados indefinidos, a las empresas más grandes “homologadas por compras”, de productos que nos entregarán en meses (con presión asimétrica durante el tiempo para el equipo), sin supervisar la ejecución (ni su calidad) y sin preocuparnos de obtener feedback temprano de los clientes. Parece evidente que cuando estos clientes/usuarios empiecen a ver la solución y probarla de verdad, se empezarán a ver desajustes en los momentos de mayor presión, es decir, al final del proyecto.

Adicionalmente, todos los defectos emergerán al mismo tiempo cercanos a la fecha de entrega. Mezclar cambios de funcionalidad (realmente redefinición), prisas y corrección de errores suele ser un coctel explosivo. Sobre todo provocan una frustración de todas las partes. No hay más que ver los datos sobre matriculaciones en carreras técnicas para ver la derivada (cayendo en un sector creciente).

Con una alta presión, en un entorno poco disciplinado, la calidad se abandonará. Si encima ya no era buena de partida, peor.

También parece indiscutible que alguien tendrá que pagar ese sobre-coste. O el cliente, o el proveedor o aparentemente “nadie”. Como en cualquier cadena, el eslabón más débil es el que antes se rompe. Ese eslabón suele ser el trabajador poco cualificado, que tiene miedo por perder su trabajo si no da todo su “compromiso”, traducido en largas horas de trabajo no remuneradas. Aparte de inmoral es ilegal y me gustaría saber por qué no hay inspecciones de trabajo a las 19:30 en la mayoría de las oficinas de este país. ¿Cómo se puede explicar esos horarios en empresas con convenios de oficinas y despachos o consultoría?.

En este sector estamos todo el día hablando de modelos de gestión, como si el software se construyera sólo y no requiriera grandes expertos para diseñarlo. Como si se aprendiera en unos meses a programar cuando llevaría vidas enteras dominar todo en conocimiento que hace falta para construir software empresarial en un momento del tiempo. Son muchas personas con distintos conocimientos los que lo hacen posible.
Nosotros no paramos de estudiar y el conocimiento nos supera (aprendizaje lineal sobre evolución exponencial). La pila base de tecnologías no para de crecer.

Periódicamente tratamos de hacer un mapa de referencia: ¿a cuántas personas conocéis que dominen un mapa similar? Obviamente no hace falta todo en una Start-Up pero os aseguro que cualquier organización grande lo tiene aún más variado. Y es solo para tecnología Java. Si le sumas los nuevos lenguajes que surgen (como Swift de Apple, u otros que van creciendo en adeptos como Scala o Groovy, etc.), nuevos paradigmas que vienen para quedarse (como BigData), etc. es agobiante.

[Haga click en la imagen para verla a tamaño completo]

Parece absurdo que restemos valor a los profesionales y tratemos de convencer a los clientes de que programar es un técnica auxiliar y que cualquiera puede hacerlo. Estúpido ya es decir que una profesión de conocimiento, que cambia imparablemente, es una commodity y que se puede llevar a un país en vía de desarrollo. SOLO UN TONTO RESTA VALOR AL CONOCIMIENTO EN UNA PROFESION DE CONOCIMIENTO.

Metodologías ágiles como solución

Pero desde hace poco, cuando se empieza a hablan cotidiánamente de las metodología ágiles, se intensifica unos conceptos de Lean: definir un producto mínimo viable, evitar el desperdicio, reducir el trabajo en curso e integrar la calidad en el desarrollo. Por tanto subyacen unos principios también de sentido común:

• Desperdicio es construir software que, aunque se ciña a un contrato, no hace lo que el usuario necesita.
• Desperdicio es construir mucho software sin que lo valide el usuario y ayude a redefinirlo en base a su necesidadad.
• Desperdicio es desarrollar grandes piezas de software que luego nadie puede mantener por su complejidad.
• Desperdicio es construir software que no se prueba automáticamente, por lo menos parcialmente.
• Desperdicio es construir software con una calidad ínfima, sabiendo que el 80% del coste de un proyecto es su mantenimiento en años.
• Desperdicio es dedicar miles de horas de personal poco motivado a mantener software del que se avergüenzan y que se sienten forzados a parchear constantemente por la presión de tiempo.

Entonces se empieza a hablar de medidas de aseguramiento de la calidad asociadas a construcción de software (ya no solo control de la calidad final): BDD, TDD, XP, patrones de diseño, patrones de refactorización, herramientas de medida cuantitativa comparable de calidad (como SONAR), integración continua, gestión de repositorios distribuidos, gestión de dependencias, etc.
Estos son cimientos. Por mucha “gestión de proyectos” que hagamos.. con malos cimientos la casa se hunde o está llena de grietas. Parece mentira que muchos profesionales lleven años trabajando y estos conceptos sigan siendo “los conocidos no cercanos”.

Si hay que proporcionar software rápidamente, de calidad y enseñar resultados a corto plazo, con esta complejidad tecnológica, difícilmente asumibles por una sola persona, ya no vale cualquiera para construirlo. ¡Es que no cualquiera es capaz de construir software de calidad en ciclos cortos!
Si además todo es transparente y cuantificable como proponen las metodologías ágiles, como SCRUM, ya cualquiera no puede hacerlo.

Ya no es un negocio de rotación (horas baratas deslocalizadas) sino que se convierte en un negocio de profesionalidad y cercanía con el cliente.

Sabremos que, con métodos ágiles, aunque no lleguemos a todos los objetivos inicialmente definidos (misteriosos y posiblemente mal prioridades y con un desconocimiento tecnológico asociado) los que estamos presentando son los que el usuario necesita y han sido probados múltiples veces. La entrega de valor es más evidente. El riesgo es más bajo. Los problemas se ven antes.

[Haga click en la imagen para verla a tamaño completo]

Conclusiones

Las metodología ágiles tampoco son para todo, ni un milagro. Mucha gente no entiende que trabajar en ciclos cortos, sin más, no es trabajar con metodología ágiles. El equipo ágil se basa en el desarrollo continuo de las habilidades e interacciones entre el equipo. En la integración de la calidad en el proceso. En la entrega de valor continua. En la disciplina colectiva. No es trabajar como siempre en hitos más pequeños.
Como todas las cosas, también tiene su curva de aprendizaje y sus problemas de implantación y adaptación en las organizaciones pero, por lo menos, permiten que tengamos una transparencia constante de la situación del proyecto. Pronto se podrá comprobar la capacidad del equipo de aportar valor, también pronto veremos si el cliente obtiene lo que busca y le ayudará a redefinirlo. Pronto se dará cuanta el cliente/usuario de su responsabilidad en el proyecto.

Creo que las metodología ágiles han constituido el principal catalizador en mucho tiempo para ayudar a mejorar el sector tecnológico en España. Hacen que se marquen tremendas diferencia entre las empresas que se dedican a vender horas de gente poco cualificada y las empresas que son capaces de generar resultados de calidad a corto plazo.
Además de que hacen que luzca el valor de los profesionales competentes se ha producido otro efecto importante, que la programadores salgan de su cueva y empiecen a participar en eventos públicos. Para que un sector se desarrollo hace falta que se creen en mayor número de conexiones, como las neuronas, entre sus participantes. Cuando critiques tu empresa o tu sector piensa que si estás trabajando en un entorno desfavorable y no sales al mundo, adquieres nuevos contactos y nuevos conocimientos (por tanto inquietudes) no vas a poder establecer ninguna presión sobre ese entorno para que cambie.

Por tanto, esto no es simplemente una moda o llamar a lo que “hemos hecho toda la vida” de otro modo. Es un cambio mucho más profundo, que ya venía haciendo falta. Nosotros vemos los cambios todos los días en grandes corporaciones y administraciones públicas donde muchas veces las barreras son más mentales que físicas.