Estado de DevOps: Una historia de mejora continua

Hola a todos. Estamos muy emocionados de estar aquí en DevOps JS. Gracias por unirse a nosotros para escuchar una historia de mejora continua.

Nuestra historia de hoy será interpretada por Amanda Lewis, una ingeniera de software en un equipo que es responsable de la aplicación Kanban que su equipo utiliza para realizar un seguimiento del trabajo. Y tenemos a Nathan Harvey, quien interpretará a sí mismo, un defensor de DORA y un animador de mejora continua.

Entonces Nathan, eres un defensor de DORA. ¿Qué es DORA? Oh, cierto. Me alegra que hayas preguntado, Amanda. DORA es un programa de investigación que ha estado en funcionamiento durante aproximadamente una década. Este programa de investigación analiza cómo los equipos mejoran en la entrega y operación de software. Increíble. Estoy muy emocionada de poder hablar contigo hoy porque mi equipo y yo tenemos esta meta y creo que podrás ayudarnos a alcanzarla.

¡Guau, eso es increíble! Amanda, si voy a ayudarte a alcanzar tu objetivo, la primera pregunta que tengo es, ¿cuál es tu objetivo? ¿Qué estás tratando de lograr? Queremos obtener el trofeo DORA. Queremos ganar el trofeo DORA. Oh, genial. Eso parece importante, pero tal vez no sea la mejor meta. ¿Por qué? ¿Por qué quieres un trofeo DORA? ¿Qué estás tratando de demostrar con eso?

Sabes qué, Amanda, tal vez podríamos realizar la evaluación rápida junto con tu equipo, la evaluación rápida de DORA, y entender cómo están haciendo las cosas hoy. Y eso incluso podría ayudarnos a aclarar cuáles deberían ser tus metas. Debo decir, Nathan, que queremos el trofeo, pero reconocemos que para obtenerlo, debes demostrar que estás mejorando continuamente con el tiempo. Y eso es absolutamente lo que queremos hacer. Y el equipo realmente se ha reunido y ha realizado la evaluación rápida. Así que hemos respondido estas cinco preguntas que estás mostrando. Y también hemos pasado por el ejercicio de priorización, que fue realmente interesante, hablando sobre nuestra integración continua, en la que estamos haciendo muy bien. Cuando se trata de architecture, sabes, ¿tenemos control allí? En realidad, no lo tenemos. Realmente dependemos de otros equipos cuando realizamos cambios. Pero también hemos respondido las preguntas sobre la cultura. Y quería preguntarte, aquí están nuestros hallazgos del ejercicio de priorización. Y sabes, fue genial. Estamos haciendo bien en la integración continua. Hay margen para mejorar allí. La cultura está bastante bien. Pero esa arquitectura poco acoplada, eso parece, oh, deberíamos comenzar allí. Pero el equipo, no creemos que podamos, ni siquiera sabemos cómo empezar. Realmente no tenemos influencia sobre las decisiones arquitectónicas.

Ah, sí, puedo entender eso. Y definitivamente recomiendo que comiencen con algo en lo que su equipo pueda mejorar. Pueden comenzar con una evaluación rápida. Esto les ayudará a establecer una línea de base de cómo está haciendo su equipo hoy en día en cuanto al rendimiento en la entrega de software. Y les permitirá hacer un seguimiento de su puntuación a medida que realicen mejoras. Muy bien. Así que solo para asegurarme de entender, porque usamos la evaluación rápida, quiero asegurarme de entender qué estamos midiendo.

Entonces, con el tiempo de entrega de cambios, estamos pensando en cuándo comprometemos código, ya sabes, en el repositorio y luego cuando llega a manos de nuestros usuarios.

Sí, eso es exactamente correcto. Una vez que se implementa en producción, ahí es cuando se detiene el temporizador. De acuerdo. Y luego, en cuanto a la frecuencia de implementación, se trata de con qué frecuencia lo estamos llevando a producción.

Así es. Queremos pensar en qué tan frecuentemente puedes actualizar tus sistemas de producción. De acuerdo. Y la tasa de fallos en los cambios es cuando algo no sale bien y tenemos que solucionarlo rápidamente o tal vez revertirlo.

Sí. Me gusta llamar a esto la tasa de O-Expletive. Es lo que sucede cuando alguien envía un cambio a producción y escuchas un expletivo. No podemos esperar hasta la próxima versión para solucionarlo. Tenemos que revertir este cambio o implementar una solución rápida. Afortunadamente, hoy en día no escuchamos eso con frecuencia, así que eso es bueno. Y luego, el tiempo de restauración es cuánto tiempo nos lleva recuperarnos y volver a la normalidad para nuestros usuarios después de escuchar ese expletivo. Así que. Muy bien. Muy bien. Me alegra que entendamos eso. Sí. Sabes, mientras revisábamos esto o mientras tu equipo revisaba esto, vimos que una arquitectura poco acoplada era una de esas cosas en las que podrían profundizar. Tal vez no tengan mucho control sobre eso. Pero, ¿qué hay de las revisiones de código?

¿Cómo van las revisiones de código en tu equipo? Bueno, creo que van bien, pero como equipo, definitivamente vimos en el informe de este año cuánto impacto podría tener tener revisiones de código más rápidas en nuestra entrega de software. Es un área en la que queremos investigar más y ver si hay fricción y si podemos mejorarla. Este año no fue la primera vez que profundizamos en esto. De hecho, en la investigación de 2014, vimos que los equipos abordaban esto de manera diferente. Se les permitía a los equipos responsabilizarse de la calidad de su código a través de revisiones entre pares y funcionaba. Las revisiones de código han existido durante mucho tiempo. De hecho, en 2017, también vimos que los equipos de mejor rendimiento realizaban mucho menos trabajo manual, incluida la automatización de algunas de sus revisiones de código y procesos de aprobación de cambios. Es posible. De hecho, vemos que los procesos de aprobación de cambios pesados tienden a ralentizarnos.

No solo nos ralentizan, sino que también hacen que nuestros cambios sean menos propensos a tener éxito. Así que aquí tenemos una doble negativa. Hay que tener cuidado con la duración del proceso de aprobación de cambios y esto comienza con las revisiones de código. Definitivamente, este es un área en la que podríamos mejorar.

Como estabas diciendo, mientras pensaba en ello, tenemos un proceso pesado, especialmente cuando implica la necesidad de aprobaciones externas a nuestro equipo. Así que este podría ser un buen lugar para mejorar. ¿Y qué hay de la inteligencia artificial? Tal vez podrías explorar cómo la IA podría ayudar a mejorar tus revisiones de código. Sabes, Nathan, eso es una buena idea. Me pregunto si estamos jugando al bingo porque mencionaste la palabra IA. Sabes, nos encanta hablar de IA en nuestro equipo, ya sabes, hemos empezado a experimentar con ella. La mayoría de nosotros la estamos utilizando en el IDE y viendo cómo nos ayuda, ya sabes, a programar más rápido. Y así, no había pensado en cómo podría afectar a las revisiones de código, pero definitivamente es algo que el equipo debería discutir. Sí, absolutamente. Sabes, en nuestra encuesta más reciente, vimos que la IA está empezando a contribuir en varias tareas técnicas. Por supuesto, todavía es muy temprano, pero muy, muy emocionante. Sí, ya sabes, estamos emocionados por explorarlo más a fondo. Solo estamos esperando esas aprobaciones. Y una vez que estas herramientas hayan pasado por el proceso de aprobación de nuestra organización, entonces definitivamente vamos a querer profundizar más. Bueno, espero que ese proceso de aprobación ocurra muy rápidamente porque, ya sabes, hemos visto que llevará un poco de tiempo para que estas herramientas impulsadas por IA se utilicen ampliamente en la industria. Pero somos muy optimistas sobre cómo nos van a ayudar. Así que, mientras esperas a la IA, tal vez Amanda, pueda preguntarte sobre tu documentación. Oh, es tan importante, Nathan. Lo sé.

Absolutamente. Y también me interesa cómo utilizas la nube. Como empresa, definitivamente estamos comenzando a utilizar la nube.

Han establecido un equipo de plataforma que está trabajando para facilitarnos las cosas. Por nuestra parte, lo estamos utilizando un poco, pero aún no completamente. Pero esperamos que a medida que avancemos hacia 2024, podamos hacerlo un poco mejor.

Me alegra escuchar que tu equipo de plataforma está haciendo que sea más fácil. Vemos que una infraestructura flexible conduce a un rendimiento organizacional mucho mejor. Y lo que realmente importa no es que estés utilizando la nube, sino cómo estás utilizando la nube. ¿Eres capaz, como desarrollador, de aprovechar cosas como el autoservicio bajo demanda y la elasticidad rápida? Estas son las cosas que la nube tiene para ofrecer. Y aunque muchos equipos y organizaciones han estado utilizando la nube durante mucho tiempo, vemos que es más importante asegurarse de que la estás utilizando correctamente. No solo que la estás utilizando, sino cómo la estás utilizando. Y nuestra investigación realmente abarca una serie de capacidades como las que hemos discutido aquí hoy, capacidades técnicas, procesos y culturales, y realmente ayuda a los equipos a comprender ¿dónde está mi restricción? ¿Dónde puedo hacer alguna mejora para poder embarcarme en este viaje de mejora continua donde mejoro en el arte de mejorar?

Bueno, Nathan, gracias por esta discusión. Me has dado muchas ideas geniales para llevar de vuelta al equipo y lugares que podemos explorar que realmente están bajo el control de nuestro equipo.

Y realmente disfruté leyendo el informe. Algunas de las conclusiones que vi fue que nuestra cultura es realmente importante. Tener una buena cultura dentro de nuestro equipo y organización es fundamental para tener éxito. Enfocarnos en el usuario cuando estamos realizando estas iniciativas de cambio. Asegurándonos realmente de que estamos pensando en el usuario cuando lo hacemos.

Documentación, te escucho. Veo el valor. Definitivamente vamos a abordar eso. La importancia de, con una infraestructura flexible, es cómo la estamos utilizando. Y diría que nuestro equipo de plataforma ha sido realmente fantástico. Realmente nos están escuchando y ha sido una colaboración real. Así que siento que vienen cosas buenas ahí.

Y luego la sección sobre cómo se distribuye el trabajo fue realmente impactante para nosotros. Y estamos trabajando en mejorar y tener un proceso para cómo distribuimos el trabajo. Porque no queremos que nadie tenga más trabajo excesivo o que esté trabajando en algo que no será recompensado a largo plazo. Porque eso no es justo y no nos hará un equipo feliz y productivo.

Sí, me encanta eso, Amanda. Y gracias por leer el informe. Y estoy realmente emocionado de seguir tu viaje mientras tomas ideas del informe y las pones en acción. Y para aquellos de ustedes que aún no han tenido la oportunidad de descargar el informe, vayan a dora.dev slash dorareport y pueden descargar el informe y leerlo hoy. Encuentren su propia inspiración.

Y luego te animo a unirte a la Comunidad de Práctica de DORA. Hoy, acabamos de comenzar mostrando cómo puedes comenzar en este viaje de mejora continua. Pero en la Comunidad de DORA, hay muchos profesionales compartiendo cómo lo están haciendo, los resultados que están obteniendo. Y es un gran lugar para conectarse, emocionarse y trabajar juntos en mejorar nuestra entrega de software. Así que espero que te unas a nosotros en DORA.Community. Y realmente, Nathan, gracias por unirte hoy. A todos aquí, gracias por unirse a nosotros. Estoy realmente emocionado de estar aquí y espero que disfruten el resto de las charlas.