Lean Thinking para desarrolladores ocupados: la versión definitiva, ahora también en papel

La versión 3.0 de "Lean Thinking per sviluppatori software impegnati" reescribe los capítulos 1 a 6 con el feedback de los lectores y lleva la IA agéntica por todo el texto, no solo al capítulo que le está dedicado. Y ahora existe la edición en papel, 6x9 pulgadas (15,24 x 22,86 cm), 316 páginas. El libro está escrito en italiano; la edición en inglés llegará este año.

El Lean nace en una fábrica. El software no es una fábrica. El libro parte de esa frase, y es la razón por la que la mayoría de los libros Lean para desarrolladores acaba en un cajón: aplican recetas de la industria a un oficio cuya materia prima son requisitos ambiguos, no tornillos estandarizados.

Hoy sale la versión que considero definitiva, y con ella la edición impresa. El papel estaba previsto desde siempre, pero un libro se manda a imprenta cuando está terminado, no mientras lo sigues escribiendo. Ahora está terminado, así que aquí está en Amazon también en papel.

Lo que he visto en los equipos a los que he enseñado Lean

El libro nace de ahí, no de una lectura. Hago consultoría y formación sobre estos principios dentro de empresas reales, y la velocidad con la que un equipo renace cuando deja de pelearse con su propio proceso me sigue sorprendiendo. Gente que en la primera reunión no abría la boca, dos meses después te para en el pasillo para decirte cómo habría que cambiar el tablero.

Luego llega la parte incómoda. Cuando el flujo de trabajo queda a la vista de todos, casi siempre resulta que el cuello de botella no era el equipo. Eran las prioridades reescritas cada lunes, las aprobaciones paradas durante días en la mesa de alguien, el trabajo empezado tres veces y nunca terminado. Muy a menudo ha sido la dirección la que se ha dado cuenta primero, y ha admitido que el problema que había que arreglar era el suyo. Ahí es cuando las cosas empiezan a moverse de verdad.

Software House de pesadilla

Una de las analogías que más uso me la regaló la televisión. Si nunca has visto “Pesadilla en la cocina”, el mecanismo es siempre el mismo: un restaurante está a punto de cerrar, el chef pasa allí unos días, mira cómo trabajan de verdad durante el servicio, da la vuelta al local y se marcha dejando una cocina que funciona. Nadie habla nunca de producción ni de procesos, y sin embargo casi todo lo que el chef impone es Lean: recorta una carta de ochenta platos y la deja en diez bien hechos, vacía cámaras llenas de género comprado hace meses, ordena la cocina porque los movimientos inútiles se ven a simple vista, observa el servicio en directo en lugar de escuchar las versiones de quienes trabajan allí, y antes de irse le devuelve la dignidad a una brigada que se había rendido. Reducción de la variedad, inventario, desperdicio de movimiento, ir a ver al sitio, respeto por las personas. Son los mismos capítulos.

Se podría rodar “Software House de pesadilla” sin cambiar una coma del método. Cambia el artefacto: el plato se convierte en una release, la cámara frigorífica en un backlog de cuatrocientos tickets que nadie abrirá jamás, el servicio del sábado noche en el despliegue del viernes. Los principios se quedan donde están.

Pasa porque son principios y no reglas, y es una diferencia que en nuestro oficio se nos escapa continuamente. El principio aguanta el cambio de contexto: “haz visible el trabajo parado” vale en una cocina, en una planta y en un repositorio. La regla no. La regla hay que reescribirla cada vez que cambia el contexto, porque estaba calibrada sobre el anterior. Y en software somos buenísimos escribiendo reglas, con sus números y todo: sprints de dos semanas, 80% de cobertura, límite de WIP en cinco, cuatro ceremonias por semana. Luego cambia el equipo, cambia el producto, y la regla sigue aplicándose por inercia mientras del principio que la generó ya no se acuerda nadie.

Por eso el libro explica cada principio en su contexto original, el de Toyota, y luego lo re-inventa para el software en lugar de trasvasarlo. Si has entendido el principio, cuando cambia el contexto la regla te la reescribes tú, que es lo único que hace falta de verdad.

“Pesadilla en la cocina” es la adaptación española del formato “Ramsay’s Kitchen Nightmares”, creado y producido por Optomen Television para Channel 4 y distribuido internacionalmente por All3Media International; Gordon Ramsay presenta las ediciones británica y estadounidense, Alberto Chicote la española. Títulos, formatos y marcas pertenecen a sus respectivos titulares: los cito aquí solo como analogía, sin ninguna relación con el programa ni con sus productores.

Qué hay dentro del libro

Los capítulos 1 a 6 están reescritos con el feedback de los lectores: razonamientos más conversacionales y escenarios sacados del día real de quien desarrolla, no de una cadena de montaje.

Los números están ahí para rehacerlos. La ley de Little en la forma que sirve de verdad, Lead Time = WIP / Throughput, y una tabla de work in progress construida sobre supuestos declarados, un equipo de cinco personas y tareas de ocho días-persona, para que puedas comprobar línea a línea qué pasa cuando pasas de tres trabajos en paralelo a uno. Todas las citas se remontan a la fuente primaria, y alguna reserva sorpresas: la palabra “Lean” no la acuñaron Womack y Jones en 1990, es de John Krafcik, en un artículo de 1988 nacido de su investigación en el MIT.

Luego están las páginas que yo mismo uso primero: el cheat sheet final, la tabla de los 7+1 muda con la columna de ejemplos concretos, la checklist de la code review Lean.

Los veinticuatro diagramas están para eso, para enseñar en una figura lo que en prosa ocupa dos páginas. Por ejemplo los tres pilares sobre los que se sostiene todo lo demás.

La IA agéntica no se queda en un solo capítulo

Cuando empecé a escribir, los asistentes de IA completaban líneas de código. Hoy abren pull requests.

Hay un capítulo dedicado, pero encerrar ahí la IA habría sido cómodo y falso. Los agentes mueven los equilibrios en todas partes, así que el tema vuelve donde toca: en el flujo, en las estimaciones, en los límites de WIP, en la code review, en cómo se mira la calidad. Donde la IA no cambia nada no hablo de ella, y donde cambia algo lo digo en el punto en el que el lector ya se lo está preguntando.

Hay una objeción que oigo a menudo: si la IA escribe el código por mí, el Lean sirve menos. Es exactamente al revés. Cuando el coste de producir código se desploma, todo lo demás sigue donde estaba: las esperas por las aprobaciones, los ciclos de feedback de semanas, el tiempo que el trabajo pasa parado en una cola. Si antes escribías una funcionalidad en tres días y esperabas siete para el despliegue, el desequilibrio era tolerable. Ahora que la escribes en dos horas, esos siete días se vuelven intolerables y clamorosos.

Este es el diagrama que en el libro acompaña al capítulo sobre el flujo. Cuenta los días: casi todos son espera, y ninguna de esas casillas se acorta porque un agente escriba el código por ti.

En el libro encontrarás tres desperdicios que en el Toyota Production System no podían existir.

El vibe coding: generar código sin comprenderlo, aceptándolo mientras parezca funcionar. Es el cargo cult técnico en versión moderna, se adoptan las formas externas (el código compila, las funciones se llaman) sin la sustancia. Cada línea aceptada sin entenderla es deuda técnica que no ves en el momento en que la firmas y pagas en cada mantenimiento.

Luego está la sobrecapacidad generativa. La sobreproducción clásica nace de un desarrollador que decide construir algo “ya que estamos”; aquí es el agente el que construye mientras piensa: variantes que nadie ha pedido, casos límite inventados, gestión de errores para escenarios que el sistema no contempla. Cosas que alguien tendrá que mantener igualmente.

El último es el verification overhead, es decir el coste de releer críticamente lo que produce el agente. No es cero y no aparece en ninguna estimación. El agente no conoce tus convenciones arquitectónicas, ni las reglas de negocio implícitas que el equipo ha ido acumulando durante años. Si ese tiempo no lo cuentas, la velocidad de generación parece productividad y no lo es.

Por qué el papel

Porque me lo habéis pedido muchos. Hay quien lee a gusto en digital y quien, con un texto que se consulta, prefiere el papel: se queda abierto al lado del teclado, se anota al margen, se encuentra la página que hace falta sin abrir nada. Son gustos, y la 3.0 ahora cubre los dos.

La edición impresa es de 6x9 pulgadas, es decir 15,24 x 22,86 cm, 316 páginas, papel crema. Los veinticuatro diagramas los rehice expresamente para la impresión, así en la página se leen como se leen en pantalla.

Para quién es, y para quién no

Si tu equipo escribe código más deprisa de lo que consigue llevarlo a producción, el cuello de botella no es el teclado. Este libro sirve para encontrarlo y quitarlo, con lo que ya tienes en casa: el tablero que miráis cada mañana, los números de vuestro flujo, la code review del viernes por la tarde. Está escrito para desarrolladores senior, tech leads, arquitectos y CTO de pymes técnicas, o sea para quien escribe código de verdad y no tiene tiempo que perder con la teoría. Los ejemplos son en Python por legibilidad, pero los principios valen en cualquier lenguaje.

El libro no es para managers que buscan diapositivas motivacionales, ni para consultores que buscan un framework que revender. Y no es un libro sobre el Toyota Production System: Toyota es la premisa histórica, no el tema.

Dónde se encuentra

Las ediciones Kindle y en papel están en Amazon: 9,99 euros el Kindle, 19,90 el papel. En Leanpub sigue estando la versión digital, con las actualizaciones incluidas como siempre para quien ya lo compró.

Una aclaración importante: el libro está escrito en italiano. La edición en inglés está prevista dentro de este año. El español, el portugués de Brasil y el alemán dependen de cuánta gente los pida, así que si quieres uno de esos idiomas escríbeme a d.teti@bittime.it diciéndome cuál. Con suficientes peticiones, lo mando traducir.

Si el libro te ha servido, lo más útil que puedes hacer es dejar una reseña honesta. Para un libro técnico autopublicado esas pocas líneas pesan más que cualquier campaña.