Sobre devops

Developer operations es lo que significa “devops”. Es lo que lleva a trabajar de un modo amateur a trabajar de forma profesional. Y trabajar de foma profesional hace que uno se sienta productivo y esa satisfacción de sentirse productivo para mí vale más que los evidentes beneficios empresariales, que los hay y están documentados; hay muchos que han escrito mucho mejor que yo sobre el tema.

Y yo, ¿cómo trabajaba antes? Pues imagino que como todos: sin orden. Cuando se es estudiante sí que hay orden: uno va a clase, le cuentan una cosa y necesita aprenderla (normalmente estudiando) para finalmente aprobar un examen. Tú te organizas tu tiempocomo quieres y hay gente que lo hace mejor que otra pero se sabe perfectamente lo que hay que hacer:

Esas dos cosas hacen que recuerde con cariño la carrera, me gustaba lo que estudiaba y me gustaba estudiar; después de cada tarde de estudio veía avance.

Luego llega la vida profesional y lo primero que descubre uno es la cantidad de tiempo que se pierde. Y también que, a diferencia de la época universitaria, los proyectos salen adelante con el trabajo de más de una persona porque hay cosas que no se pueden hacer solo. Descubres esas cosas que a uno le cuentan en la carrera pero sólo desde un punto de vista teórico: los diagramas de Gantt, la planificación de proyectos, la gestión de dependencias, esas cosas. Todo eso es una gestión del tiempo en cascada (en inglés waterfall).

Y los proyectos en cascada se retrasan. Siempre. Y se retrasan mucho. El manifiesto agile, en 2001, fue una respuesta a todo eso y, como venía del mundo del software, está tardando en adoptarse en el resto de disciplinas. Es un error porque claramente waterfall no funciona.

No funciona, según la literatura, porque es imposible tener un plan maestro a largo plazo con el detalle suficiente. Es imposible anticipar todo lo que puede salir mal, las dependencias entre unas tareas y otras. Además de que da igual la experiencia que se tenga: estimar cuánto tiempo lleva hacer una cosa es algo que hacemos mal.

Pero hay otro aspecto que se menciona poco y que a mí me parece muy importante. Da igual el marco de trabajo que se tenga, ágil o en cascada, un proyecto va bien si las personas que trabajan en él son productivas. Y ser productivo significa trabajar mejor en el día a día. Es algo que en otros sectores sí se hace bien.

En la hostelería, por ejemplo. Vayan ustedes a un Starbucks, ¿a que funciona bien? Todo el mundo sabe lo que tiene que hacer y nadie está perdiendo el tiempo. Los procesos que existen están optimizados.

Un hospital también funciona bien. Utilizaré analogías con hospitales con frecuencia, al fin y al cabo en mi familia hay mucho médico. Decía, un hospital también funciona bien. El tiempo del médico en consulta o en un acto médico está bien aprovechado, existe toda una coreografía alrededor del paciente que hace que las cosas salgan bien. Muchas de las labores del personal médico están protocolizadas, eso reduce errores.

Y pese a todo esto, en las empresas tradicionalmente siempre se ha trabajado por proyectos en modo waterfall. Y cuando no se trabaja por proyecto, cuando se trabaja a demanda como hace un médico o un camarero, toda la optimización de procesos que existe en esos trabajos se olvida y sus enseñanzas no calan en el mundo de los proyectos.

Entro ya en el mundo del software, que no es diferente a los otros; todo es trasladable.

Llevo algo más de dos años trabajando en agile. Y más de diez desarrollando software. Nos gusta en mi mundo decir que lo que yo hago no es software, que son modelos analíticos. Con esa excusa, trabajamos mal. Trabajamos mal porque no tenemos procesos y trabajamos mal porque escribimos software sin calidad. Eso se acabó.

Desde un punto de vista de gestión de proyecto, agile es muy superior a todo lo que sea waterfall. Agile tiene varios marcos de ejecución (frameworks), los más conocidos son scrum y kanban. Son diferentes pero tienen sus puntos en común.

Esta transparencia hace que para los miembros de un equipo sea más fácil trabajar en equipo y que para la gente de fuera sea muy fácil hacer un seguimiento del proyecto. Responder a la típica pregunta de ¿vamos bien?