EL DESARROLLO DE SOFTWARE: ¿UN MARATÓN?

El día 6 de abril del año en curso y después de doce semanas de entrenamiento logré finalizar el Maratón de París. Durante ese tiempo, cada domingo salía a hacer las tiradas largas y fue en una de estas que se me ocurrió que hay bastantes similitudes entre el desarrollo de software y todo lo que conlleva correr un maratón.

Consistencia y Tiempo

A pesar de ser un novato en la mítica distancia, aprendí durante estas doce semanas que mantener un ritmo constante es fundamental para correr una buena carrera. A medida que avanzaba en los entrenamientos lograba hacer más consistente mi ritmo y por tanto mi capacidad de predecir, a través del estudio del histórico de mis splits, en cuanto tiempo lograría terminar la carrera. En el desarrollo de software, las metodologías ágiles se basan en sprints cortos acotados en tiempo (timeboxed) para obtener avances concretos y con los niveles de calidad esperados. Mediante el seguimiento de los progresos realizados en intervalos fijos de tiempo, los equipos de desarrollo logran mejorar su capacidad predecir fechas de entrega.

Muchos equipos tienden a preocuparse sólo por la velocidad y la productividad inicial a expensas de todo lo demás, incurriendo en conceptos como la deuda técnica. Dichos equipos son equivalentes a los velocistas, buenos en distancias cortas (proyectos pequeños y de vida corta) pero que simplemente no podrían mantener un ritmo tan alto durante los 42.195 kilómetros de un maratón, se desplomarían en algún momento y el resultado sería el fracaso.

Los equipos de desarrollo deben encontrar el ritmo adecuado y consistente que les permita realizar las entregas con la calidad necesaria para que el proyecto llegue a la tan ansiada meta.

Go fast enough to get there, but slow enough to see. — Jimmy Buffett

Por otra parte algunos equipos se ven obligados a trabajar largas horas durante largos períodos de tiempo, lo que inevitablemente los vuelve menos productivos. Mantener un ritmo consistente significa resistirse a la tentación de comprometer al equipo a entregar más de lo que ha hecho en el pasado. La consistencia mantiene la mente fresca y creativa, la moral alta y una velocidad de desarrollo coherente.

Overtime is like sprinting: It makes some sense for the last hundred yards of the marathon for those with any energy left, but if you start sprinting in the first mile, you’re just wasting time. — Tom Demarco & Timothy Lister.

Planificación

Visto desde la superficie, correr parece ser una actividad bastante básica. Simplemente necesitas colocarte las zapatillas y salir. Lo cierto es, que aprendí, que para poder tener éxito en una carrera y en especial un maratón, se necesita un plan. Es necesario dividir el recorrido en diferentes partes (entregables), tener un plan de contingencias (análisis de riesgo) y estar preparado para ajustar la estrategia según cómo transcurre la carrera (control de cambios). ¿Qué tan rápido correré los primeros kilómetros? Si el plano altimétrico de la carrera muestra cuestas importantes, ¿cómo guardaré energía para conquistarlas? ¿Cuándo debo comer, beber, y en qué cantidades? ¿Cuál es el pronóstico del tiempo? ¿Cómo me visto para evitar recalentarme?

En el caso de desarrollo de software, ¿cuál es el alcance de la entrega? ¿Qué herramientas utilizaremos para crear todos los artefactos necesarios? ¿Cuántos recursos necesitamos y dónde debemos concentrar a la mayoría? ¿Cuáles son los riesgos? ¿Qué arquitectura se utilizará?

A goal without a plan is just a wish. ? Antoine de Saint-Exupéry

Influencia Social

Durante el entrenamiento descubrí que tal y como ocurre en todas las actividades humanas las dinámicas de grupo tienen una gran importancia. Los días que entrenaba junto a alguien más rápido que yo, tenía la sensación de que iba a mayor velocidad que cuando salía a entrenar solo. Adicionalmente al correr acompañado, independientemente de la velocidad de los compañeros, observaba que mi ritmo era mucho más consistente.

La moral de un equipo puede ser afectada de forma negativa si los jefes de proyecto o gerentes hacen estimaciones o exigen funcionalidades más allá de las estimaciones del grupo y como consecuencia disminuye la velocidad de desarrollo. Por otra parte, cuanto más cerca estén los miembros del equipo más se estabilizará la velocidad de desarrollo. La programación en parejas, con la complicidad y compromiso del cliente, puede transformar un grupo de programadores en un verdadero equipo.

No one can whistle a symphony. It takes a whole orchestra.” — H.E. Luccock

Trampa

Cuando se empuja a un corredor más allá de los límites de su capacidad durante demasiado tiempo, éste inevitablemente considera hacer trampa. El entrenamiento para una maratón requiere de disciplina. Un corredor podría engañarse a sí mismo saltándose los entrenamientos o simplemente realizándolos sin cumplir con la distancia o los tiempos establecidos, una práctica cuyas repercusiones pasarán factura el día de la carrera.

Los jefes de proyecto usualmente se encuentran bajo una presión continua para completar los proyectos a tiempo y dentro del presupuesto establecido, por lo que intentan empujar a los miembros del equipo para que estos aumenten la velocidad de desarrollo, son empujados más allá de su ritmo natural y como consecuencia hacen trampa. Dejan de escribir las pruebas unitarias y dejan a un lado la refactorización y mejoras, prácticas que sin duda tendrán repercusiones en la estabilidad y facilidad de mantenimiento del software una vez liberado.

A journey of a thousand miles begins with a single step. — Lao Tzu

Más información:

Carlos Mendible con más de 14 años de experiencia diseñando e implementado soluciones de software, comenzó su carrera en Venezuela, donde en 1999 obtuvo su primera certificación Microsoft. Actualmente está certificado como CISA, ITILF, MCSD, MCTS y MCP. Trabaja desde 2012 como Arquitecto Senior de Soluciones Microsoft en Sogeti España colaborando también como evangelista tecnológico, formador e ingeniero de pre-venta.

Para más información: carlos-fernando.mendible-porras@sogeti.com