“Hemos conseguido construir sistemas que requieren mucho menos mantenimiento. La consecuencia es un ritmo de entrega mayor y, sobre todo, mucho más constante.”
Menos software,
más impacto
Cómo evitar que tu equipo colapse bajo el peso de su propio código
Una guía práctica de Lean Software Development escrita desde la experiencia de construir (y a veces destruir) equipos de alto rendimiento.
- 25+ Años construyendo equipos
- 20+ Charlas y podcasts
- 11 Lectores beta del libro
- 8 Voces entrevistadas
La tesis
El mayor problema de los equipos no es que escriban código malo. Es que escriben código de más.
El software existente consume recursos continuamente, lo uses o no, como el metabolismo basal de un organismo. Si no se gestiona activamente, ese coste basal crece hasta colapsar la capacidad del equipo.
Tres disciplinas
Tres disciplinas para evitar el colapso
Simplicidad activa
Diseñar para lo que sabes hoy, no para lo que imaginas mañana. La mejor arquitectura es la más simple que resuelve el problema conocido y puede evolucionar cuando el problema cambie.
Maximizar el trabajo no hecho
Cada decisión de no construir algo es una decisión de proteger la capacidad futura del equipo. Tu contribución más valiosa puede ser el código que no escribiste.
Eliminación continua
Podar es parte natural del cultivo. Si una funcionalidad cuesta más mantenerla que lo que aporta, eliminarla no es destruir. Es liberar capacidad para lo que importa.
Qué te llevas
Tres decisiones que puedes aplicar en 30 días
El libro no promete recetas. Pero sí te da el lenguaje y los criterios para tomar decisiones distintas desde la primera semana.
01
Semana 1
Identificar el coste basal oculto
Listar las funcionalidades que mantenéis y casi nadie usa. Poner número al coste de tenerlas vivas. Empezar la conversación de podar.
02
Semanas 2-3
Maximizar el trabajo no hecho
Cuestionar la próxima feature antes de planificarla. Aprender a decir "todavía no" con criterio en vez de "sí" por defecto.
03
Semana 4
Reducir el WIP del equipo
Bajar el trabajo en curso a un número que de verdad podáis sostener. Medir cycle time como señal antes de tocar procesos.
Equipos reales
Cómo se ha aplicado esto en equipos donde he trabajado
Voces directas de personas con las que he construido. Sin promesas genéricas: detalles concretos en sus propias palabras.
“Más de 13 años evolucionando sin necesidad de grandes reescrituras.”
“Recuerdo tu técnica de borrar tickets del backlog con más de 6 meses sin decir nada a producto. Ni se dieron cuenta: no eran tareas tan necesarias.”
Para quién es este libro
Es para ti si…
- Eres Engineering Manager y respondes por la capacidad técnica del equipo.
- Eres Tech Lead o Staff Engineer y ves la degradación antes que nadie.
- Eres Product Manager dispuesto a aceptar que la separación entre producto e ingeniería es parte del problema.
- Tu equipo funciona pero sientes que algo no va bien, y no sabes nombrarlo.
No es para ti si…
- Buscas una introducción amable al mundo Agile.
- Quieres confirmación de lo que ya haces.
- Buscas recetas en vez de decisiones.
Las prácticas hablan por sí mismas cuando dejas de evangelizar y empiezas a encarnarlas.— Georgina Giannoukou, Software Engineer
Del prólogo del libro.
Más voces
Lo que dicen quienes ya lo han leído
En un sector que premia el hacer, Edu lleva años practicando y enseñando el arte igualmente difícil de no hacer: no construir lo que no aporta, no acumular lo que no se necesita. Este libro es, entre otras cosas, un manual de esa renuncia inteligente.— Andoni Eguíluz Morán, Decano de la Facultad de Ingeniería, Universidad de Deusto
Había leído muchos libros y artículos sobre Lean y Agile, pero no había visto una aplicación tan radical y profunda de sus principios.— Borja Cadenato, Director de producto
Un libro escrito desde la sabiduría del conocimiento y de la experiencia que ayuda a tener más conciencia del coste basal del software, un concepto acuñado por el propio autor del libro. Se dice que lo que no tiene nombre, no existe. Si no existe, no se hará nada para gestionarlo.— Raquel M. Carmena, Software Engineer
Este libro recoge algo que llevo años viendo en lo que Edu escribe: una búsqueda constante por simplificar sin caer en simplismos. El resultado es una guía muy sólida, basada en experiencia real sobre Lean, XP y el original concepto de coste basal, para cualquiera que quiera construir software con más impacto y menos ruido.— Julio César Pérez Arqués, Engineering Manager
Un libro imprescindible para desarrolladores y equipos que quieran replantearse su manera de relacionarse con el código. Edu ha escrito un libro demostrando con casos reales que aplicar Lean, XP y el coste basal es un win-win.— Javier Vela, Software and Platform Engineer
Estructura del libro
Qué vas a encontrar dentro
Dieciséis capítulos organizados en cuatro partes, un epílogo sobre por qué no hablo de IA, y anexos con casos y voces reales de equipos que han pasado por estas transformaciones.
Ver índice completo 01 Parte I
Fundamentos
Qué es Lean Software Development, por qué importa, y qué es el coste basal del software.
02 Parte II
Los principios Lean en práctica
Cinco principios traducidos a decisiones concretas: eliminar desperdicios, amplificar el aprendizaje, decidir en el último momento responsable, entregar lo antes posible, empoderar al equipo.
03 Parte III
Calidad sostenible
Por qué la calidad no es enemiga de la velocidad sino su única base. Detectar errores pronto, sostener calidad en el tiempo, superar resistencias.
04 Parte IV
Pensamiento sistémico
Optimizar el todo en vez del individuo. Integrar Lean, XP y mentalidad de producto.
Recursos complementarios
Todo lo que no cabe en el libro
Los capítulos del libro son autocontenidos. Pero hay vídeos, artículos y libros que han influido cada capítulo y que merece la pena explorar. Los encontrarás aquí, organizados por capítulo.
Explorar recursos Dónde conseguir el libro
Disponible en Amazon
English
Coming soon
The English edition will be available in paperback and Kindle shortly after the Spanish release.
Coming soon