De Agilidad y otras hierbas

Me estaba preparando un café ☕ (de esos tan cargados que si los dejas en la mesa disuelven la cuchara solos) cuando me puse a pensar en DevOps y la memoria organizacional . Porque claro, todos hablan de pipelines, CI/CD y despliegues automatizados, pero ¿qué pasa con la sabiduría acumulada de la empresa? Esa que no está en Confluence ni en un GitLab Wiki, sino en la cabeza de la señora que lleva 20 años diciendo: “ese servidor no lo toques que explota” . Se han fijado que en DevOps siempre queremos movernos rápido 🔥, como si fuéramos un Fórmula 1, pero la memoria organizacional es más como una abuelita que dice: “tranquilo mijito, que yo ya pasé por ahí” . Y si no le haces caso, te comes el mismo error con distinto sabor. ➜ DevOps sin memoria organizacional = reinventar la rueda cada sprint. ➜ Memoria organizacional sin DevOps = un archivo polvoriento que nadie lee. El truco está en mezclarlos: que el conocimiento acumulado fluya con la misma naturalidad que el pipeline. Por ej...

Me estaba tomando un cafecito doble (porque uno ya no alcanza después de los 40 😅) y me puse a pensar en esas reuniones de trabajo donde alguien suelta con cara de iluminado: “¡Tenemos que ser más ágiles!” . Y claro, de inmediato todos empiezan a correr como si les hubieran soltado un enjambre de abejas encima 🐝. Pero la verdad es que agilidad no significa rapidez. Se han fijado que confundimos agilidad con andar a la rápida . Y no po, la agilidad no es sprintar como Usain Bolt para entregar un informe que nadie va a leer. Agilidad es más como bailar cueca en un espacio chico: moverse bien, adaptarse al compañero, esquivar la silla en la esquina y aún así verse elegante 💃. La rapidez te puede hacer chocar contra la pared ➜ la agilidad te ayuda a girar antes de pegarte el porrazo. La rapidez es apurarse a terminar la pega, la agilidad es saber cuándo parar, cuándo ajustar, y cómo hacerlo sin quedar como estúpido frente al jefe. Les cuento una cosa: en un proyecto una vez, el geren...

Me estaba calentando una empanada en el microondas, cuando explotó con tanta fuerza que por un momento creí que era una señal divina: así se siente un deploy sin QA . 🥟💥 Les cuento: no tener QA en un equipo DevOps es como manejar un auto sin frenos, sin espejos y con el copiloto dormido. Y peor si todos dicen “pero igual testeamos en local, tranqui”. ¡Mentira! Lo que hacen es cruzar los dedos y esperar que staging aguante. Entonces, cuando no existe un rol QA formal , empiezan los dolores clásicos: 🔁 Bugs eternos que nadie detecta hasta que el cliente grita. 🧪 Tests unitarios que están “en el backlog” desde 2019. 🧼 Código sucio porque “ya funciona, no lo toques más”. ⛔ Deploys revertidos porque algo falló … pero nadie sabe qué. 💊 Pero calma, que no todo está perdido. Aquí van unos remedios caseros para sobrevivir sin QA (por ahora): 👨‍🔧 1. Cultura de calidad compartida Deja claro que la calidad es responsabilidad de todos , no de “alguien QA que algún día llegará”. C...

Han visto que siempre cuando uno se sube a una micro vieja, de esas que crujen en cada curva, uno igual se sienta y mira por la ventana como si fuera un tren europeo? A veces hasta se disfruta el traqueteo, como si el camino mismo contara una historia. En la vida profesional —y sobre todo en la tecnología— pasa algo parecido. Partí hace más de 25 años metiéndole mano a un computador prestado, con más ganas que talento. No era el mejor programador, de hecho, era re malo. Pero preguntaba. Probaba. Me caía y me paraba. Y sin darme cuenta, ese mismo viaje me fue formando. Hoy, ya metido en arquitectura, DevOps y en los enredos de la innovación, me doy cuenta de que el "destino" (el cargo, el título, el proyecto entregado) es solo una postal. El verdadero valor está en lo que aprendiste al recorrer el camino: las madrugadas depurando logs, los compañeros que te enseñaron una línea de código, los errores que te dejaron una lección tatuada. Así que si estás partiendo, o si siente...

Estaba viendo cómo mi gato intentaba entrar en una caja más chica que su dignidad, y pensé: esto es igual que intentar formar un equipo DevOps con roles dispersos en toda el área de TI . 😹📦 Les cuento: uno en infraestructura, otro en desarrollo, otro perdido en soporte, QA en el limbo… ¡y todos diciendo que “hacen DevOps”! Pero a la hora del caos, cada uno corre pa’l otro lado como pollos sin cabeza. ¿Les suena? Entonces, ¿cómo diablos empezar a unir los puntos y formar un equipo DevOps de verdad, sin tener que amenazar con cortar el WiFi? Aquí va mi receta personal: 🧭 1. Identificar los roles y talentos ocultos Primero, caza talentos. Revisa quién en el equipo ya está haciendo cosas DevOps , aunque no lo diga en LinkedIn. Hay un backend que automatiza deploys, un operador que ama scripts… esos son tus fichas claves. 🕵️‍♂️ 🗺️ 2. Mapear responsabilidades y dolores actuales Haz una radiografía real: ¿quién mantiene qué? ¿Dónde están los cuellos de botella? ¿Por qué el deploy...

La catarsis emocional es un proceso psicológico que consiste en liberar emociones intensas acumuladas, generalmente después de situaciones de gran tensión o conflicto. Este desahogo consciente no solo alivia, sino que también permite integrar lo vivido, darle un sentido y continuar con mayor claridad. En contextos laborales, especialmente en entornos de alta exigencia como el tecnológico, hacer catarsis después de resolver un gran problema no es solo saludable: es necesario. ○ Pensemos en ese equipo de desarrollo que trabajó contra reloj durante días para restablecer una plataforma caída. Cuando por fin logran resolverlo, la reacción inmediata suele ser el silencio o el siguiente reto. Pero el cuerpo, la mente y las emociones quedan activas, cargadas. Hacer una pausa grupal para verbalizar lo vivido —con humor, reflexión o incluso con enojo contenido— puede ser profundamente reparador. ▸ La catarsis compartida tiene además un valor simbólico: refuerza el sentido de comunidad. Decir ...

Me estaba haciendo un sandwich con más mayonesa que pan (decisiones de adulto, ¿no?), cuando me dije: ya po, basta de tanto concepto volador, ¿quiénes tienen que estar sí o sí en un equipo DevOps real, de esos que enfrentan el lunes con dignidad? 🥪💻 Así que aquí va, sin humo ni jingles de consultora: los roles esenciales para un equipo DevOps funcional y con menos incendios que una parrilla en Año Nuevo 🔥: 🔧 1. Ingeniero/a DevOps (o Platform Engineer) El alma del asunto. Encargado de pipelines, infraestructura como código, CI/CD, contenedores y orquestación. Sabe hablar YAML sin llorar y tiene tatuado kubectl en el corazón. 🔍 2. SRE (Site Reliability Engineer) El guardián de la producción. Se enfoca en disponibilidad, performance, monitoreo y escalabilidad. Su lema: “que funcione siempre , no solo en staging”. 📦 3. Developer con mentalidad DevOps (idealmente Backend) No cualquier developer, sino alguien que entiende que el deploy no es magia y que su código debe vivir ...

Estaba divagando mientras buscaba en la cocina ese destapador misteriosamente desaparecido (sospecho que se fugó con la cuchara favorita), cuando me pregunté: ¿y si el equipo DevOps fuera una banda de rock? 🎸🥁 Porque seamos honestos, el equipo DevOps no es un monolito de clones con hoodie y café en la mano. Es más bien una combinación explosiva de personajes únicos, cada uno con su estilo, su toque y su nivel de sarcasmo frente a los bugs. Les presento a los sospechosos habituales: 🧠 El DevOps Engineer El baterista que marca el ritmo: sabe de infra, de pipelines, de contenedores, y además tiene el superpoder de explicar por qué el build falló sin insultar (mucho). Es el pegamento del equipo. 🔧 El SRE (Site Reliability Engineer) Ese que vive en producción. Su pasión es el uptime, las alertas que no lo despierten, y la resiliencia del sistema. Medita con logs y predica el evangelio de los SLAs y SLIs 📈. 💻 El Backend Developer con alma de DevOps Sabe que su código no vive...

Me estaba preparando unos fideos instantáneos con la precisión quirúrgica de un microservicio enlatado, cuando de pronto, entre el sonido burbujeante del agua y el olor a glutamato monosódico, me vino la gran epifanía: ¿y si el siguiente paso del Ingeniero DevOps no es ser más multitasking, sino dejar de serlo? 😲🍜 Les cuento una cosa: el Ingeniero DevOps multitasking es como ese pulpo de circo que responde tickets, actualiza el cluster, automatiza deploys, borra ramas zombie y además explica por qué Jenkins está rojo. Y sí, es admirable… pero también es suicida. Porque multitasking no es sinónimo de eficiencia. Es sinónimo de “ya no sé si estoy en staging o soñando con YAML” 🧠⚠️. Ahí es donde aparece el siguiente paso evolutivo : el equipo DevOp (sí, lo escribo así a propósito, como Pokémon legendario único). Este equipo no es una persona disfrazada de equipo, es un grupo funcional real , donde cada quien tiene foco, pero todos comparten un mindset. ✔️ Uno se especializa en CI/...

La “escalera del comportamiento” es una representación visual y mental del proceso interno por el cual interpretamos el comportamiento de los demás antes de actuar. Esta escalera, propuesta por el psicólogo organizacional Chris Argyris, es una metáfora poderosa para entender cómo pasamos de hechos observables a conclusiones y juicios. Cada peldaño representa un paso: desde observar hechos, seleccionar datos, interpretarlos, hacer supuestos, sacar conclusiones, hasta finalmente actuar en base a lo que creemos que es verdad. ▸ Esta herramienta es especialmente útil en contextos laborales donde la rapidez de los juicios puede generar malentendidos. Por ejemplo, si un colega en una startup tecnológica responde un mensaje de forma escueta, alguien podría interpretar que está molesto o desinteresado, cuando en realidad simplemente está saturado de tareas. La escalera del comportamiento nos invita a detenernos antes de reaccionar, preguntarnos: ¿qué datos estoy usando? ¿Estoy interpretando o...

Estaba intentando preparar un café por cuarta vez esta mañana, pero la cafetera decidió hacer deploy sin pasar por staging... otra vez. Mientras el café invadía el mesón con espíritu rebelde, me puse a pensar en esa quimera moderna llamada DevOps 🦄💻. Se han fijado que todos hablan de DevOps como si fuera una secta secreta de sabiduría infinita. Que si “automatización”, que si “pipeline perfecto”, que si “infraestructura como código”... suena más a receta de Hogwarts que a oficina común y corriente. Y claro, en teoría, DevOps es esa promesa dorada donde los desarrolladores y los de operaciones trabajan juntos en armonía, como pandas abrazándose 🐼. Pero en la práctica... ➡️ Unos hacen commit directo a producción un viernes a las 6 p.m. ➡️ Otros creen que Docker es un Pokémon de agua. ➡️ Y mientras tanto, los pipelines fallan porque “el YAML no estaba indentado con espíritu suficiente”. La utopía DevOps supone que todo está documentado (🤣), los ambientes son iguales (😅), y nadi...

Estaba tirado en el sillón, comiéndome una empanada fría que encontré en el refrigerador (sin juzgar, por favor), cuando me cayó la iluminación: ¡es feriado entre semana! 🎉 Y no sé ustedes, pero yo declaro este día como patrimonio espiritual de la procrastinación consciente . Se han fijado que un feriado así, al medio de la semana, es como ese commit raro que nadie esperaba pero que soluciona todo sin conflicto. De repente, la semana ya no es una muralla de tareas, sino una lomita suave que uno puede bajar rodando en pijama. Hoy el mundo anda más lento, los mails llegan sin fuerza, y los grupos de trabajo están en estado zombi 🧟‍♂️ con mensajes tipo: "¿lo vemos mañana?" —la frase más hermosa del idioma laboral. Hoy no quiero productividad. Hoy quiero levantarme tarde, peinarme con la mano (una sola) y mirar el techo mientras pienso en nada. Porque sí, descansar también es un deploy importante. De hecho, uno vuelve con menos bugs emocionales y con mejor performance ment...

Me estaba preparando un café cuando de repente me acordé: ¡mañana es feriado! 😱 Y créanme que ese instante fue como si el sistema operativo de mi alma hiciera un GC.collect() emocional. Literalmente me sentí más liviano que el backlog de un proyecto recién creado. Estaba pensando… ¿no les pasa que un feriado entremedio de la semana es como ese try-catch que uno no sabía que necesitaba, pero que evita un crash total del sistema humano? Porque claro, cuando el feriado cae día jueves, uno entra en modo: “¿y si el viernes lo trabajamos simbólicamente no más?” 😅 Seamos honestos: la productividad esa semana se va al tacho. Pero con dignidad . Porque el cerebro entra en estado de relax_mode = true , y los commits se vuelven más livianos que excusa de viernes en la tarde. A mí me pasa que empiezo a pensar: "este es el momento perfecto para avanzar en mis proyectos personales" , y termino durmiendo con el gato y viendo documentales sobre patos ninja o algo igual de inútil pero ...

Estaba divagando mientras trataba de abrir una bolsa de pan con una sola mano (la otra sostenía el celular viendo memes, prioridad es prioridad 😅), cuando me acordé de ese viejo dicho: el que mucho abarca, poco aprieta . Y ¡chan! me cayó encima la realidad del DevOps todólogo. Ese pobre mortal que termina siendo el pulpo de la oficina , con más tentáculos que permisos en el sudoers 🐙🔥. Les cuento una cosa: en muchos equipos, al DevOps se le pide que sea medio ingeniero de redes, medio psicólogo, medio arquitecto cloud, medio bombero… y medio mago. Resultado: termina siendo un entero desastre . Porque sí, puede abarcar mucho, pero cada área la aprieta como quien intenta atornillar con una cuchara de plástico. ¿Y qué pasa? Que el sistema crashea, el equipo se frustra y el DevOps termina en posición fetal abrazando un plushie de Tux 🐧. Por eso, segmentar la labor no es solo sano, ¡es vital! Cada especialidad requiere foco: automatización, seguridad, infraestructura, monitoreo… n...

Hoy en la mañana, mientras me preparaba un café que parecía tener la densidad del petróleo crudo 🛢️, me puse a pensar en cómo sería la vida si los días de la semana fueran procesos automatizados. Y claro, llegué a la conclusión más obvia: el lunes sería un pipeline... y uno que falla más que semáforo en hora punta 🧨. Se han fijado que el lunes tiene todas las etapas de un mal pipeline: Trigger involuntario ➜ suena la alarma, y uno jura que recién se acostó. Stage de validación ➜ ¿me lavo los dientes o me tiro otros 5 minutos? Spoiler: los 5 minutos se vuelven 30. Build emocional ➜ intento convencerme de que la semana será diferente. Spoiler 2: no lo será. Deploy ➜ salgo de la casa sin llaves, sin ánimo y con la camiseta al revés. Post-mortem mental ➜ "el próximo domingo me acuesto temprano", mentira que me digo desde 1997. Y así, con cada paso, siento que el pipeline de mi motivación devuelve un hermoso status: failed 😵 . Mientras más lo intento d...

Hoy un tema difernte a lo comun pero... me estaba arreglando la corbata para una videollamada (spoiler: era sin cámara), cuando me acordé de esa pregunta que a uno lo deja mirando al horizonte como si sonara el himno: ¿cómo contribuyes a la democracia desde TI en @ sence-chile ? Y no es chiste, porque entre tanto bug y ticket, a veces se nos olvida que lo que hacemos es bien jodidamente importante. Se han fijado que nadie ve a los de TI hasta que todo colapsa. Pero ahí estamos: sosteniendo los sistemas que permiten que miles de personas accedan a formación, empleo y oportunidades reales. ¿Y saben qué? Eso es democracia con mayúsculas. La que se vive, no la que se recita. Cada botón que funciona bien, cada dato protegido, cada sistema que aguanta la avalancha de usuarios… es una declaración de principios: aquí todos tienen derecho a una oportunidad digna, sin importar su apellido, su comuna o su conexión a internet . Y aquí va mi frase épica, para que la graben en piedra (o en GitHu...

Estaba mirando el techo (actividad altamente productiva, según yo), cuando me dije: “¿Y si todas estas ideas que tengo las anotara, aunque suenen a ciencia ficción barata?”... y ahí caí en cuenta de que toda buena implementación empieza como una idea media ridícula . 😅 Les cuento: pensar en convertir criterios de aceptación en pruebas automáticas, que una tarjeta de Kanban se transforme en rama, versión y despliegue, o que el conocimiento se vuelva pipeline... suena a ambicioso. Pero no es tan lejano como parece. Se han fijado que en la mayoría de los equipos hay talento, pero lo que falta es tiempo, foco y un empujoncito de voluntad . Estas ideas son como esos muebles con 500 piezas de Ikea: al principio abruman, pero con instrucciones claras y un poco de torpeza organizada, se puede. 💪📦 🔥 ¿Qué se puede hacer con esas ideas? ✏️ Anotar y priorizar : que no se queden solo en “sería bacán si...”. Hay que bajarlas a tierra. 🧪 Probar a chico : una historia con criterios + pru...

Estaba intentando explicarle a mi gato por qué no puede sentarse encima del notebook mientras hago pruebas... cuando me di cuenta que él también sigue criterios de aceptación: si calienta, me siento. 🐈🔥 Les cuento: convertir criterios de aceptación de una historia de usuario (HU) en pruebas automáticas no solo es posible, es lo más cercano a magia que tenemos los que vivimos entre bugs y teclas pegadas. Se han fijado que muchas veces esos criterios se quedan pegados en el post-it, bonitos pero mudos… ¡y ahí es donde entra el truco! 🎩 🎯 Paso a paso del encantamiento: Redactar criterios claros : nada de “debería funcionar bien” o “más rápido que antes”. Tiene que ser algo como: “Al hacer clic en ‘guardar’, el sistema debe mostrar un mensaje ‘Datos guardados correctamente’”. ✔️ Identificar acciones y resultados esperados : dividir cada criterio como si fuera un guion: Acción: el usuario hace clic. Resultado: el sistema muestra el mensaje. Mapear a pruebas automática...

Estaba en el baño leyendo la etiqueta del shampoo —porque uno es curioso incluso ahí— y me di cuenta que ya no puedo hacer nada sin pensar en etapas, triggers y deploys. Hasta lavarme el pelo lo pienso en pasos: build (enjabonado), test (masajeo), release (enjuague). 😅 Les cuento: llega un momento en que todo el conocimiento que acumulamos —las lecciones, los errores, los rituales de despliegue, los scripts que escribimos con cariño y cafeína— empieza a formar una especie de flujo automático. Y ahí, sin darnos cuenta... ¡tenemos un pipeline mental! 🧬 Se han fijado que al principio uno lo hace todo a manito, como el artesano digital que copia y pega comandos. Pero con el tiempo, uno se cansa de repetir, de olvidar pasos, de romper cosas porque alguien saltó un script. Y entonces surge el pensamiento mágico: “¿Y si automatizamos esto?”. Y ahí va todo: ➜ Lo que sabías lo convertís en scripts. ➜ Lo que hacías con intuición, lo convertís en validaciones automáticas. ➜ Lo que dependí...

Estaba mirando una mancha en el techo mientras pensaba si era humedad o arte moderno, y me cayó la inspiración como baldazo: ¡una idea de sistema pasa por más transformaciones que Gokú en toda la saga! 😆 Les cuento cómo va esta travesía que tú mismo estás describiendo, y que, honestamente, debería estar pintada en un mural: 💡 La chispa divina : una idea. Nace en una reunión, en la ducha, o en medio de una crisis de producción. Algo como: "¿Y si los usuarios pudieran autogestionar sus notificaciones?". 📄 Requerimiento : alguien la aterriza y la convierte en algo serio. Ya no es solo “tengo una idea”, ahora es: “el sistema debe permitir que...”. 👤 Historia de usuario : la bajamos a tierra con cariño: “Como usuario quiero X para lograr Y”. Le ponemos aceptación, casos límite, y un toque de realismo. 🗂️ Tarjeta Kanban : la metemos al tablero como si fuera una misión especial. Ya tiene número, prioridad, colorcito, y a veces hasta una estampita. 🌿 Rama GitFlo...

Me estaba sirviendo una cerveza —artesanal, por supuesto, con nombre impronunciable— cuando vi una tarjeta en el tablero de Kanban con tanto historial que parecía haber pasado por una guerra. Y ahí me dije: “¿Y si esta tarjetita fuera una rama de Git? ¿Y si su destino estuviera atado a una versión y un despliegue?”… ¡epifanía de viernes! 🍻💡 Les cuento: esto que propones no solo es posible, es hermosamente lógico . Se han fijado que muchas veces trabajamos como si Kanban fuera una cosa y Git otra, como si vivieran en dimensiones paralelas que apenas se saludan. Pero si logramos que cada tarjeta se convierta en una rama —por ejemplo, feature/TKT-123-agregar-login — estamos armando una sinfonía entre gestión y código. 🎼🔧 ✨ Así sería la danza: Tarea en Kanban : alguien crea una historia o ticket ( TKT-123 ). Rama GitFlow : nace una rama hija con ese nombre ( feature/TKT-123-nombre ) Commits traqueados : cada cambio se asocia con la historia, todo bien documentado. Merge a...

Estaba tratando de arreglar una silla coja con un destornillador y un tenedor, cuando pensé: “esto es exactamente lo que pasa cuando se diseña software sin pensar en DevOps… ¡puro parchazo!” 😅 Les cuento: la arquitectura de software y DevOps no son mundos separados como nos hicieron creer. No es como el gato y el perro. Son más bien como el gato y el láser: si los juntai bien, hacen maravillas 🐱🔴 Se han fijado que cuando diseñamos un sistema sin pensar en su ciclo de vida, el resultado es un Frankenstein funcional pero imposible de mantener. Entonces aparece DevOps, con su mantra de automatización, integración continua y entrega continua (CI/CD), y empieza a sufrir. “¿Cómo despliego esto?”, “¿por qué tengo que reiniciar el servidor a mano?”, “¿quién pensó que 12 servicios comunicándose por FTP era buena idea?”. 😵‍💫 Pero si desde el principio la arquitectura considera los principios de DevOps, ¡pum! Todo fluye: 🛠️ Modularidad ➜ facilita despliegues independientes. 🎭 Observab...