La Gerencia de proyectos trabajando con DevOps

A veces, en la gerencia de proyectos técnicos (GPT) tendemos a enfocarnos únicamente en algunos de estos roles:

• Personas que escriben el código.
• Personas que proveen y soportan la infraestructura.
• Personas que hacen testing y realizan el control de calidad (QA).

Entre otro más...

La cultura DevOps cambió fundamentalmente la forma en que los equipos de TI abordan los proyectos, alejándose de las iniciativas monolíticas tradicionales, de varios meses (o de varios años) en busca de una mayor velocidad y agilidad en el ciclo de vida del desarrollo de software.

Es difícil hoy en día para un GPT tener la posibilidad (o darse el lujo de) tomarse el tiempo para planificar todo desde el arranque como dice el librito.

Muchas veces toca entrar en un campo de batalla que ya arrancó y con un alfiler para defendernos.

En TI se dan muchas variables que conspiran al mismo tiempo para que en un proyecto orientado a los DevOps se de bajo la típicas etapas que hay en un proyecto.

Al abordar proyectos de estas características se requiere una sólida práctica de gestión de proyectos para que estos avancen según lo programado con un enfoque claro en las dependencias.

Los GPT no pueden centrarse solo en el diagrama de Gantt y convocar reuniones. Los típicos diagramas de barras quedaron desfasados en el tiempo (al menos para los DevOps) y muchas veces nadie les presta atención, que al menos antes (o en otros rubros) se les da/daba.

Es por eso que existe la necesidad imperiosa de aplicar "agilidad" a la gestión de proyectos de este tipo.

Agilidad/Agile no es solo una metodología o un concepto de desarrollo de software; es una forma de gestionar la necesidad actual de los proyectos a largo plazo en concierto con los enfoques de integración continua / entrega continua (CI / CD) de la era DevOps.

Hay que verlo de esa manera no hay otra. Lo he visto y no funcionan los esquemas tradicionales de GPT en el nicho de los DevOps.

Divide y vencerás y los "microservicios"

Así como la arquitectura de microservicios divide la aplicación empresarial monolítica en servicios más granulares, los proyectos también se pueden dividir en piezas de trabajo mucho más pequeñas e interdependientes. Suena conocido esto lo sé.

Esto nos da lógicamente más margen de maniobra y mayor control sobre los resultados esperados.

La función del GPT ante la cultura DevOps debe estar orientada en un enfoque de "microservicios" al mejor estilo de "features" (característica de un producto que podríamos lograr de forma incremental a través de una serie de Sprints aplicando Scrum y bla bla bla) que permita manejar una velocidad mucho mayor debido al manejo correcto de subproyectos más pequeños.

Suena lindo escrito el párrafo anterior, pero se da en el mundo real, no es ficción. Si hacemos las cosas (o nos dejan hacerlas) podemos lograr buenos resultados trabajando ordenadamente.

Aplicando conceptos ágiles podemos corregir el rumbo con cada release que tengamos en el horizonte.

La mejor práctica siempre es tomar ese gran release y automáticamente negociar la "división" en porciones "manejables" con el fin último de poder mostrar fácilmente resultados y de esta manera obtener comentarios en cada iteración sin complicarnos mucho la existencia y así aprender algo de las retrospectivas.

Esto siempre será un comodín debajo de la manga para el GPT, ya que si llegáramos a estar fuera de curso y algo desfasados en el tiempo, podemos hacer contención de daños y que todos queden más o menos contento al final del cuento.

Por que hay que volverse un experto en las "dependencias" con los DevOps

Saber cómo “hacer algo y hacerlo bien” es fundamental. Comprender cómo todas esas piezas funcionan entre sí y le dan sentido a un todo es más importante todavía.

Hay algo que siempre sube la adrenalina en los proyectos y es la fecha de entrega.

Cuando aumenta la velocidad de entrega (algo típico de la cultura DevOps y se debe a la demanda de resultados), aumenta la importancia de las dependencias.

Y esto por que?

Por que cuando estamos apurados cometemos errores sino hay un marco claro de trabajo y si tocamos X y este hace que deje de funcionar Y ahí es donde el saber sobre dependencias te pone a valer como GPT.

Vivimos en la cultura de la inmediatez y los DevOps no escapan de eso y es así como esperamos que se comporten siempre. Cuando están lentos en las respuesta algo esta pasando y esto puede ser por que el pool de recursos es bajo, hay muchos incendios en la vuelta y eso baja la velocidad de respuesta y pueden desatenderse las tareas planificadas.

Para evitar la entropía dentro de proyectos de este tipo hay que estar pendiente de estas variables:

• La velocidad entre las integraciones.
• La velocidad comunicación entre el equipo de proyecto y los stakeholders.
• Los deadline > fecha actual.
• Hablar el mismo lenguaje de los DevOps. Hay que ser técnico y entender lo que hablan en las reuniones. Eso evitará errores futuros o teléfonos descompuestos.

Scrum, Kanban, que usamos?

Acá no hay receta y a pesar de que hay mucho escrito a nivel de literatura el campo de batalla que se da en las organizaciones a la hora de implementar un proyecto de esta naturaleza dista de lo que dicen los manuales.

Todos saben que es fundamental utilizar un framework como Scrum para dividir el trabajo en iteraciones donde sus dependencias pueden ser bien conocidas y manejadas por el equipo de proyecto. Con eso logramos ese concepto de "agilidad" tan deseado y que suena tan bien cuando se arranca el proyecto.

Usar herramientas como los tableros Kanban también nos ayudan y nos permiten vistas inmediatas de dependencias entre tareas, ver el trabajado bloqueado, issues, bugs **y lo mejor de todo para mi es que hace visible el trabajo del equipo de proyecto. **

Esto es importante por que a veces en el mundo de los DevOps no tenemos claros cuales son los recursos que acometen X o Y tarea y para cuando esta será realizada.

Puede sonar ilógico, pero pasa más de lo normal. Tenemos que contar con un marco de trabajo que nos permita"gerenciar" ágilmente el proyecto y saber "quien" esta con "que" y el "cómo" lo logrará para "cuando".

Un Gantt que se desactualiza rápidamente muchas veces no nos sirve porque en la cultura DevOps los recursos y los requerimientos cambian muy rápido y no nos permite el correcto seguimiento (y evitarnos así ir a un canal de Slack y estar preguntando tímidamente quien está a cargo de X cosa y para cuando queda lista).

Por eso los planes del proyecto deben evolucionar y adaptarlos a esta especie de automatismo típico de la cultura DevOps.

Es un "must" reducir el cronograma de un ciclo de entrega para proyectos de este tipo. Es obvio pero hay que decirlo y repetirlo por que a veces somos muy ambiciosos y se nos olvida.

Esto significa que ya no se puede permitir el hecho de actualizar un plan de proyecto una vez a la semana, esto no tiene sentido ya que en un ambiente de integración/distribución continuas (CI/CD) como es el mundo DevOps es algo del día a día esta actividad.

Los gerentes de proyecto deben estar al tanto de todo al momento, la automatización no es solo para los DevOps, impacta también al que la conduce (o intenta).

Cuidado a la hora de ajustar el tiempo...

A la hora de hacer ajustes sobre los proyectos casi por default nos vamos a atacar el tiempo.

Es quizás la variable fundamental que rige nuestras vidas y por ende nuestros proyectos y que nos condiciona irremediablemente a darle la mayor importancia en muchas queramos o no.

Algo típico es ajustar solo esa dimensión en nuestros Sprints y pasamos por alto lo esencial que puede ser la misma velocidad de respuesta y la calidad del trabajo de los DevOps.

Calidad asegura mejores resultados a futuro. Hacer las cosas "apagando fuegos" pocas veces trae "lecciones aprendidas"y sirve para algo en un futuro inmediato.

Algunos tips finales para trabajar en GPT con DevOps

• Crear planes integrados que tengan en cuenta el trabajo no planificado. Esto a veces "pasa por debajo de mesa" y es trabajo que no se ve. Y menos si no hay métricas que lo respalden. A la hora de asignar recursos este tiempo no es tomado en cuenta y puede moverse la aguja en situaciones que estemos escasos de tiempo.
• Buscar siempre el feedback de las pruebas y que las implementaciones a producción se estén utilizando para volver a planificar correctamente. Algo como la retrospectiva del Sprint pero mas bajado a tierra.
• Buscar siempre la "incrementabilidad" palabra que no existe pero que si existiera estaría definida en hacer lo que dicta Scrum a traves de los Sprints.
• En un entorno de DevOps deberíamos poder responder siempre la mágica pregunta (y que tanto molesta a algunos): "¿Ya está hecho?" - o su pariente cercano, "¿Cuándo se hará?" - con cero interacción humana. Si esto no es así hay que revisarnos.
• Nuestros mejores amigos siempre: El sprint burn-down, velocidad de Sprint y métricas. Estos como el simple motivo de poder ver si las tareas individuales avanzan a tiempo. A veces no tenemos nada de eso, es triste y me ha pasado.
• Hay gente que odia Jira pero si usa bien desde el principio ayuda a la gestión de proyectos. El chiste y lo difícil es hacer que los DevOps proporcionen info actualizada sobre cómo está progresando el release y los issues asociados. Reuniones al estilo Daily Standup (remotely) bien llevadas son claves para seguirle el curso a lo que queremos gestionar.
• No ser fanático de tener un producto terminado a como dé lugar en base a un deadline, hay que buscar adoptar el enfoque MVP (producto mínimo viable). En el mundo DevOps el trabajo nunca está realmente terminado con CI/CD funcionando a tope.
• La medición continua (métricas de algún tipo - si tenemos) para el proyecto son clave, al igual que la estrecha colaboración entre todos los integrantes del proyecto (fundamental si no hay métricas, sino estamos fritos).
• La automatización del mundo DevOps eclipsa a veces las "buenas y viejas prácticas" sugeridas por PMBOK y hay que estar claros con eso. Llegar con pretensiones de "gerenciar" al mejor estilo clásico a un proyecto en donde la cultura DevOps está arraigada en el día a día nos puede frustrar si no lo sabemos manejar.