de Gene Kim
Por qué lo he leído
Había visto varias referencias al libro por Twitter, blogs y distintos podcasts. Sabía que el libro era muy similar a La meta, de Eliyahu M. Goldratt, un libro que me gustó bastante.
Así que, tras ver que Eduardo Ferro también lo había leído, me decidí a leerlo yo también.
Qué esperaba
No creo que se pudiera esperar tanto como de La meta. Ese libro es un recurso más que recomendable para conocer la Teoría de las restricciones. Pero esperaba algo similar enfocado en el mundo del software.
Esperaba una historia de éxito de una persona o grupo de personas que van superando problemas, uno tras otro, donde el autor los aproveche para explicar su punto de vista y dar forma a las teorías que quiere explorar.
Qué encontre
Más o menos lo que esperaba. A través de una historia llena de problemas a solucionar, el autor expone las teorías que quiere difundir. Estas teorías están relacionadas con el desarrollo de software y más concretamente con el mundillo DevOps.
En realidad, el autor defiende unas prácticas que son la fundación del movimiento DevOps, pero para llegar hasta ahí, el protagonista de la historia comienza con un ascenso que le lleva a ser el director del departamento de TI de una empresa que no destaca por su gestión de servicios tecnológicos, pero que solucionando problema tras problema, y con la ayuda de una figura un poco enigmática (muy al estilo de La meta), va mejorando hasta hacer del departamento y la empresa un lugar mucho mejor.
Conclusiones
Por un lado, el libro me ha gustado. Es un libro sobre el mundo del desarrollo de software, muy al estilo de La meta, que también me gustó. Y describe el proceso que sigue una empresa ficticia de ser un desastre, a ser una empresa envidiable en su sector.
Pero por otro, me ha decepcionado un poco. Esperaba que estuviera más centrado en el desarrollo, pero está más centrado en la gestión y provisión de servicios de TI. No es nada malo, pero estoy más interesado en lo primero.
De todas formas, el libro es interesante, sobre todo si quieres conocer cómo hacer bien las cosas en un departamento de TI. Creo que este libro es una buena aproximación al mundo DevOps. Pero no deja a los desarrolladores en muy buen lugar, así que si eres desarrollador, no te tomes todas las cosas que dicen sobre nosotros muy a pecho.
Qué he aprendido
La única cosa más peligrosa que un desarrollador, es un desarrollador conspirando sobre temas de seguridad
Eliyahu M. Goldratt, quien creó la teoría de las restricciones, nos mostró que cualquier mejora echa en cualquier sitio que no sea el cuello de botella es una ilusión, es inútil
Los tiempos de espera dependen de la utilización del recurso
La necesidad reducir contínuamente los ciclos de tiempo es parte del Primer Camino. La necesidad de la amplificación de los bucles de feedback (o realimentación), idealmente desde el cliente, es parte del Segundo Camino. El Tercer Camino va de asegurarnos de estar introduciendo tensión continuamente en el sistema, de forma que estamos contínuamente reforzando hábitos y mejorando algo
Recursos relacionados
- [The Phoenix project] en Amazon
- Notas sobre el libro
- La meta, de Eliyahu M. Goldratt
- Blog de Eduardo Ferro
- Teoría de las restricciones