Tradicionalmente, la creación de nuevos sistemas en el ámbito de las tecnologías de la información ha
involucrado a perfiles con necesidades y objetivos muy diferentes. Por un lado, tenemos a los/las responsables de mantener las infraestructuras operativas (personal de comunicaciones, arquitectura, sistemas o seguridad entre otros) y en buena forma, siempre disponibles de acuerdo con el nivel de servicio necesario y dimensionadas para unas determinadas cargas establecidas. Y, por otro, están los perfiles expertos en el desarrollo de software, que tienen que responder a las necesidades del negocio en plazos ajustados y no siempre con unos alcances y definiciones funcionales claros y ajustados a la necesidad empresarial.
La dependencia mutua es completa, desde el momento en que, para que una nueva aplicación funcione requiere de una infraestructura específica; y para que esa infraestructura esté optimizada y ajustada, necesita conocer cómo se ha desarrollado la aplicación que va a ser ejecutada sobre ella.
Sin embargo, los intereses entran muchas veces en conflicto debido a que, mientras que los equipos de desarrollo necesitan desplegar sus soluciones de forma rápida y, a veces, sin tener en cuenta las limitaciones de infraestructura, los equipos de operaciones tienen la obligación de dimensionar dicha infraestructura de una forma sostenible y controlada; con unos tiempos de aprovisionamiento más lentos e inversiones y costes que controlar desde el punto de vista financiero.
Desafortunadamente la solución a este conflicto de intereses no pasa por juntar ambos roles en un único equipo, no es tan sencillo.
Para entender el porqué de la necesidad de utilizar metodologías DevOps en las empresas actuales, analicemos cómo se han venido gestionando los proyectos de software hasta hace algunos años.
Los equipos de desarrollo han venido trabajando en un modelo de gestión de proyectos llamado “en cascada” o waterfall. Esta metodología consiste en dividir las fases de desarrollo en pequeñas tareas relacionadas entre sí, definiendo hitos parciales y estimando tiempos de desarrollo, en base a la experiencia del propio equipo y la carga de trabajo, entre otros aspectos.
Esta forma de trabajar es altamente ineficiente por varios motivos:
- Si existe un mecanismo de retroalimentación y las necesidades del solicitante cambian, es necesario reajustar todas las tareas para acomodarlas, con el consiguiente impacto en costes y recursos. En estas situaciones, es habitual intentar mantener los plazos de ejecución y los costes iniciales, lo que repercute en una menor calidad en el producto final; es algo inevitable.
- No disponemos de un producto consumible hasta el final del proyecto y nuestro usuario no podrá saber si los requerimientos iniciales están bien implementados. O peor aún, es muy común que esos requerimientos sean muy vagos o poco realistas, lo que genera una sensación de frustración y pérdida de tiempo en todos los involucrados, usuarios y equipo de TI.
La solución a esta realidad vino de la mano de la introducción de dos metodologías nuevas, la primera heredada de la industria automovilística (LEAN) y la segunda creada por un grupo de desarrolladores que idearon el llamado Agile Manifesto (Manifiesto Ágil), que veremos más adelante, pero que introduciremos brevemente en este punto.
El Manifiesto Ágil establece doce principios que promueven la calidad del software, ciclos continuados de mejora, la colaboración más estrecha entre personas con el objetivo común de la entrega continua de valor.
A medida que esta metodología se ha ido imponiendo en los equipos de software, convirtiéndolos en más productivos y permitiendo incorporar una retroalimentación del solicitante de forma continua en el proyecto, el cuello de botella se ha trasladado a los equipos de operaciones, que no son capaces de responder a las necesidades de los desarrolladores a la velocidad necesaria.
Views: 2
