Síguenos:
Cloud
27 de Junio de 2017

El gobierno de proyectos DevOps: nuevas reglas y en revisión. ¿Héroe o forajido?

El gobierno de proyectos DevOps: nuevas reglas y en revisión. ¿Héroe o forajido?

El gobierno de proyectos DevOps: nuevas reglas y en revisión. ¿Héroe o forajido?

Escrito por , 27/06/2017

Allá por el mes de febrero os proponía las claves para escoger el primer proyecto DevOps. Parece mentira cómo pasa el tiempo pero, poco a poco, hemos ido desgranando tres de las cuatro claves que, como mencionaba entonces, es necesario tener en cuenta para garantizar el éxito temprano con DevOps: la cultura de equipo, las herramientas, la infraestructura y la operativa, que abordaré en este artículo para tratar de cerrar el mini serial.

A continuación explicaré cómo se deben plantear los primeros pasos en el mundo de la gestión y gobierno de los equipos y proyectos DevOps.

“El tren de las 3:10” (“3:10 to Yuma”) es uno de esos curiosos casos en la historia del cine, western o no, en que al estrenarse el remake de un clásico no sabes con cuál de los dos quedarte. La versión de 2007, dirigida por James Mangold y protagonizada por Russell Crowe y Christian Bale, es ágil y con interpretaciones estupendas. Pero la de 1957, dirigida por Delmer Daves y protagonizada por Glenn Ford y Van Heflin, transmite mejor el drama de los protagonistas y tiene un mejor final. El argumento es el mismo: un sanguinario forajido es apresado en un pequeño pueblo y un granjero empobrecido se une a la partida que lo lleva a prisión. El plan para evitar que los compinches del maleante rescaten a su jefe es bueno, pero si todo saliera bien, no sería una película épica, claro…

Empecemos a modo de aviso con tres claves de prudencia que es preciso tener en cuenta antes de aplicar el modelo de trabajo DevOps a un proyecto concreto:

  • Si dicho proyecto es muy dependiente de un despliegue de infraestructura hay que tratar de separar la parte software en un proyecto independiente e iniciarlo cuando la infraestructura ya no suponga un riesgo de bloqueo.
  • Si el presupuesto o la esponsorización no están garantizados, o si no están claros los objetivos principales del proyecto, hay que tomarse el tiempo necesario para conseguirlos.
  • Si el proyecto ya está rodando y los equipos están establecidos es preferible no introducir tensiones con cambios en el modelo de trabajo sobre la marcha. Quizá convenga dejar la transformación operativa para una segunda fase del proyecto.

El número de cambios que se manejan en una operativa DevOps es mucho mayor que en un planteamiento convencional. ¿Cuánto mayor? Pues si en una gran organización convencional se considera que realizar decenas de miles de cambios al año supone un nivel de agilidad elevado, en una gran organización DevOps hablaremos de decenas de millones de cambios. Es decir, no hablamos de una transformación cosmética sino de cambios desde la raíz.

¿Cómo puede el comité asesor de cambios (CAB, Change Advisory Board) manejar tantas modificaciones? Necesariamente hay que filtrar cuáles se someten a su decisión y cuáles tan solo se informan, sin someterlos a decisión formal por el CAB. Dado que los equipos DevOps incluyen a los especialistas en el desarrollo, la arquitectura y la explotación, para cualquier cambio que no afecte a un elemento compartido con otros sistemas bastará con realizar una notificación al CAB, y será ejecutado en el momento y bajo las condiciones que acuerde el equipo. ¿Significa esto que los cambios se pueden aplicar en la jornada laboral? Evidentemente sí, ya que el equipo DevOps es soberano en su toma de decisiones.

Un momento… Si el equipo DevOps es soberano, ¿quiere decir que no hay un jefe? Como explicaba en un artículo anterior, dentro del equipo no hay liderazgos, sino que todos los miembros rinden cuentas de todas las actividades del equipo.

¿Y a quién rinden cuentas? Por una parte, el equipo debe tener un seguimiento de resultados que permita garantizar que el foco de su trabajo está en la eficacia y obtener mejoras para el negocio. Pero también es necesario realizar un seguimiento técnico, en el que cada miembro del equipo se reúne periódicamente con los componentes de otros equipos de su misma especialidad para compartir experiencias, recibir instrucciones operativas y realizar propuestas a las arquitecturas estándar tanto técnicas como de procesos.

El seguimiento de resultados se realizará semanal o quincenalmente y su objetivo es mostrar los resultados conseguidos en el periodo. Este seguimiento no debe condicionar los despliegues, que se realizarán por iteraciones. Cada iteración incluye la definición de los objetivos y métricas que se deben cumplir, y se definen los plazos y costes. Un objetivo común del despliegue de cada iteración es la verificación de los objetivos y prioridades generales del proyecto, así como la mejora continua (Plan-Do-Check-Act). El despliegue de cada iteración debe incluir las pruebas regresivas que comprueben el cumplimiento de los objetivos y métricas alcanzados en los despliegues de iteraciones anteriores. Como estaréis pensando, en DevOps el despliegue, los cambios y el seguimiento de actividades se desacoplan entre sí mucho más que en un proyecto convencional.

El seguimiento técnico, por su parte, debe tener una periodicidad mayor y reunir a los especialistas de los diferentes equipos para que compartan y unifiquen criterios sobre nuevas tecnologías, buenas prácticas, etc. y evitar, así, una excesiva heterogeneidad tecnológica, pero también debe ofrecer libertad a los equipos para adoptar nuevas tecnologías.

Esta libertad de movimientos no debe estar reñida con el rigor en los objetivos y las métricas. Al fin y al cabo, detrás de todo proyecto TI hay un cliente al que servir. Se trata de ser más ágiles, no menos rigurosos. La implicación del cliente es fundamental, ya que el prototipado será continuo en todas las fases y los requisitos tendrán que ir ajustando sus prioridades con la misma agilidad con la que se ofrecen los resultados.

El forajido Ben Wade y el granjero Dan Evans descubren la necesidad de reinventarse para trabajar en un proyecto nuevo con nuevas reglas. A lo largo de su aventura deberán ir adaptando sus objetivos frente a los requisitos cambiantes y unificarán sus prioridades, mediante la cooperación para… ¿conseguir subirse a “El tren de las 3:10”? ¿O acaso no lo lograrán? Eso deberéis averiguarlo por vosotros mismos en cualquiera de las dos versiones de esta magnífica película.

Imagen: Portada DVD “3:10 to Yuma” (1957)

Sobre el autor

Eduardo Méndez Polo

Eduardo Méndez Polo

Llevo 26 años en este mundo de las TI, con lo que me ha dado tiempo a conocer una gran variedad de tecnologías, metodologías operativas y buenas prácticas. Por suerte (y por ganas) he podido también realizar casi todo tipo de funciones: desarrollo software, gestión de la calidad, despliegues, operaciones, infraestructura, planes técnicos y estratégicos… Los temas más recientes en los que me he visto envuelto han sido cloud computing y DevOps. En mi tiempo libre formo parte del Coro Gospel de Boadilla del Monte, y he dado unos primeros pasos en el complejo mundo del modelismo espacial…
Ver todos sus artículos »