Esta es una historia ficticia, pero trata problemas muy reales. Así que, se trata de cómo una empresa, a través de su personal directivo principal, intenta salvarse a sí misma. “El Proyecto Fénix” es un producto de esta empresa que ya no puede continuar de la manera habitual. Los competidores lanzan nuevas funciones rápidamente, mientras que el equipo actual tarda mucho tiempo en sacar sus versiones. Después de esos lanzamientos, la funcionalidad del producto suele fallar para muchos usuarios debido a la baja calidad y a las pruebas de integración débiles.
Comprendiendo el problema principal, los gerentes de la empresa intentan de todas las formas posibles arreglar la situación, pero al principio nada funciona y todo empeora. Existe una gran dependencia de algunos ingenieros clave, cuya ausencia dificulta el mantenimiento de los proyectos y la publicación de nuevas versiones. Otro problema importante es la deuda técnica, que sigue creciendo con el tiempo.
Con el tiempo, el equipo empieza a adoptar nuevos enfoques en el desarrollo, especialmente en las pruebas y el despliegue, y esto conduce a resultados positivos. Ahora no tienen deuda técnica, y pueden hacer lanzamientos incluso a diario. Para evitar revelar demasiados spoilers, me quedaré con un resumen muy breve y me concentraré en otros mensajes del libro.
La tecnología de implementar DevOps con soluciones completas de CI/CD es muy buena por sí sola. Sin embargo, simplemente introducir las herramientas a menudo no aporta mucho beneficio al proyecto. Sí, permite desarrollar código, probarlo y entregarlo a los usuarios rápidamente. Pero para que el producto sea demandado y todo el ciclo de desarrollo sea lo más eficiente posible, es necesario cambiar fundamentalmente los enfoques de comunicación y la mejora de procesos entre departamentos. Este problema se menciona siempre de forma sutil (y a veces abierta) a lo largo del libro. Toda la construcción de los procesos DevOps se discute junto con la motivación, la burocracia y otros matices. Algunos de estos matices son extremadamente indeseables y destructivos. A lo largo del libro también se puede observar cómo, junto con la construcción de los procesos de desarrollo y entrega del producto al usuario final, cambian también las relaciones entre equipos.
En general, es un libro interesante y fácil de leer. Será útil para quienes quieran desconectarse un poco del trabajo, pero sin alejarse demasiado de los temas de TI. Además, para muchos gerentes y personal directivo sería útil ver qué problemas pueden surgir con un enfoque equivocado y una mala organización de procesos, y cómo todo esto se puede y debe cambiar.
