Hay 3 padecimientos que la mayoría de las personas de la industria de software experimentan a diario en la cadena de valor (esto es todas las etapas y personas necesarias desde la idea hasta la materialización de la misma), pero que pasan desapercibidos por estar intrínsecamente arraigadas en la cultura o formas de trabajo, lo que hace que sea difícil su eliminación; estos son:
1. Fricción
2. Impedancia
3. Deuda técnica.
Me centraré en los primeros dos.
Recuerdo cuando era joven y me enseñaban física, me indicaban inicialmente como calcular la velocidad de un objeto que bajaba por una pendiente. Era un escenario ideal y 
sin fricción. Luego, a medida que avancé en mis estudios, me mostraron como adicionar la resistencia del viento y la fricción con otros elementos.
Las ideas eran complementarias, pero la fórmula se hacía más compleja a medida que se adicionaban nuevos factores.
Lo que ocurre con la física también pasa con el software, pero a diferencia, al estudiar en la universidad se aprende mucho sobre lenguajes y tecnologías pero poco sobre la existencia y repercusión de la fricción, impedancia y deuda técnica en las empresas de desarrollo. Debido a ello, los profesionales desconocen mayoritariamente como lidiar con estas últimas, aunque experimenten sus consecuencias en su día a día.
La fricción, impedancia y deuda técnica son factores que frenan la velocidad del desarrollo de software y que muchas veces no son tenidos en cuenta en los proyectos, o al menos, en su totalidad.
Todos ellos pueden ser considerados desperdicio desde el punto de vista del pensamiento Agile o Lean, esto es, tareas que raramente agregan valor al cliente pero que le cuestan dinero.
He llegado entonces a clasificarlas bajo estos 3 conceptos, lo que creo facilitará que lo entiendas:
Fricción – Todo aquello eliminable que está relacionado con las tareas técnicas y específicas del desarrollo de software y que disminuye su velocidad.
Impedancia – Aquellos factores humanos tangibles que impactan en un proyecto de software y repercuten en el tiempo de entrega.
Deuda técnica – Todas aquellas decisiones de implementación tomadas para acelerar la entrega en el corto y mediano plazo pero que aumentarán los tiempos de programación en el futuro cercano.
Esta agrupación hace fácil entender a cada factor como consecuencia de un efecto diferente, lo que permite un tratamiento mas claro.
Es importante tener en cuenta que ellas pueden verse agravadas cuando por ejemplo existe estrés o presión de la compañía en entregar un producto. El ejemplo típico es una fecha fija de entrega.
«Fricción, impedancia y deuda técnica son una oportunidad para mejorar el proceso»
Fricción
Cuando tratas de estimar una tarea, a no ser que hayas realizado algo similar en el pasado o tengas conocimiento específico del área en cuestión, entonces se obtendrá una versión simplificada del problema, que ignorará la fricción y resistencia.
Por ejemplo, cuando se comienza un nuevo proyecto en un área de conocimiento no indagada anteriormente, se tendrá forzosamente que realizar un primer análisis. Ello implica invertir un número más elevado de tiempo para hacer funcionar los primeros engranajes y conocer las herramientas en cuestión.
Podemos considerar esto como fricción de arranque, de la misma forma que cuando pones un motor en marcha éste comienza de menores a mayores revoluciones.
Las cosas simples llevarán más tiempo ya que desarrollar es una tarea de descubrimiento más que una fórmula matemática y las primeras conclusiones siempre se extenderán. Aparecerán escenarios típicos del aprendizaje, donde luego de conocer como efectivamente resolver la tarea e implementarla, se observarán atajos, lo que llevará a una re-evaluación de lo ya hecho de forma muchas veces retrospectiva. Veamos entonces 3 tipos de fricción:
1. Tareas repetitivas
Aquellas tareas manuales que se hacen una y otra vez. Normalmente las personas lo hacen sin realmente evaluar su impacto global en tiempo. Pueden ser desde tareas minúsculas dentro del editor de código hasta las más macro, que involucren por ejemplo una tarea técnica dentro de una historia de usuario que se repita una y otra vez a lo largo de los ciclos Sprint. Al descubrirlas se deberá siempre evaluar una posible automatización del proceso para así ahorrar tiempo. Tenemos aquí 3 áreas a considerar:
- Monetaria (cuanto cuesta)
- Que tiempo va a ahorrar
- Que fuerza de trabajo está motivada para implementar la automatización y entiende el problema.
La aproximación que muchas personas inicialmente efectúan es «me llevará 5 minutos hacerlo pero 60 horas automatizarlo». Habrá entonces que tener en cuenta cuantas veces al día/semana/mes se realiza la acción para ver si tiene sentido implementarla de tal forma que sea rentable y libere al equipo de desarrollo para que puedan hacer otras tareas.
A mayor liberación, mas cosas se podrán hacer en los futuros ciclos Sprint.
Mi recomendación es que siempre tomen los equipos una tarea en cada Sprint, que acelere la velocidad de estos a perpetuidad.
2. Infraestructura (lentitud)
Cualquier tarea que consuma tiempo considerable, bajando la eficiencia del equipo debido a la lentitud de factores tecnológicos «externos». Por ejemplo, un desarrollador puede querer fusionar las fuentes locales (check-in) con sus cambios en el repositorio maestro. La consecuencia podría ser dada debido a que los miembros del equipo no realizan actualizaciones regulares, lo que da como resultado que al intentar fusionar las fuentes se requiera de mucho tiempo para resolver sus inconsistencias.
A su vez, un recurso remoto (de red), una compilación inefectiva o la complejidad para poner en producción podría ser otro factor de fricción. Éste último es un punto común en organizaciones que comienzan su camino hacia la agilidad.
3. Problemas con el código o donde se requiera re-aprendizaje
Emplear muchas herramientas de software diferentes, trabajar con código donde no se han seguido estándares claros/dispares o código difícil de entender por haber sido escrito por otra persona o por uno mismo en el pasado o no se hacha hecho refactoring como tarea habitual es un problema. En estos casos será necesario un proceso de re-aprendizaje, esto es, tener que somatizar nuevamente algo que en su momento del tiempo era claro.
La industria del software sufre de este síntoma en mayor medida, ya que la inconsistencia y la no utilización de estándares claros, hace que haya que aprender nuevamente algo que en su momento parecía una tarea sencilla.
«La fricción, impedancia y deuda técnica impactan en el desarrollo de software de forma negativa»
La fricción que vimos puede frenar en mayor medida mientras que otros tipos de fricción pueden ser más benignos. Esperar por ejemplo por una base de datos a ser construida podría bloquearte por semanas a diferencia de unos minutos que llevaría la fricción de aguardar por un compañero de equipo a realizar una revisión de tu código.
Afortunadamente, el marco de trabajo de Scrum ayuda constantemente a eliminar la fricción, esto es, mediante la forma sistemática de centrarse en un objetivo común. También contribuye al final de cada iteración cuando se inspecciona las interacciones en la retrospectiva.
Ello permite detectar los desperdicios de los procesos o relaciones personales que han impactado sobre la velocidad o velocity para adaptar o mejorar.
Finalización de un proyecto y automatización
A mi criterio, todo proyecto que se dé por finalizado requerirá algún tipo de mantenimiento, incluso aunque esto no se crea en una primera instancia. Es por ello que aquí hay que considerar que cuanto mayor tiempo pase desde la finalización hasta que se solicite el cambio, mayor será el coste económico de realizar el mismo.
De acuerdo a un estudio de Microsoft, un defecto que se repare dos semanas después de haberlo introducido en el código llevará una media de 35 veces más de tiempo que si se hace enseguida.
t? Coste = Cambio
Siendo (t) el tiempo que eleva el cambio a la potencia. Esto es así ya que pese a no existir futuras capas de software que adicionen complejidad, los tiempos de re-aprendizaje serán mayores a medida que se distancie la modificación del momento de la finalización del proyecto.
De forma similar a los defectos, un cambio o acción a ser realizada tan pronto se terminó el proyecto será infinitamente más barato que llevarlo adelante unos meses más tarde.
A su vez, las personas que trabajaron en un proyecto podrían haber sido re-asignadas a otros, lo que complica aún más el panorama.
Es así que para bajar los futuros costes de mantenimiento de un producto, se debe siempre pensar en automatizar tanto como sea posible en ciclos tempranos del proyecto.
En la segunda parte escribiré sobre impedancia, esto es, los factores humanos tangibles que impactan en un producto digital y repercuten en los tiempos de entrega. Veremos también algunas técnicas pioneras para visualizar y cuantificar la impedancia en tu empresa.
(puedes encontrar la segunda parte aquí)
Te invito también a conocer más sobre mi libro, que ahora también se encuentra en español:
Gracias por escucharme,
Erich,
