Un asunto arriesgado

Al lanzar una actualización o una nueva función, siempre existe el riesgo de que algo salga mal. Las personas cometemos errores, y en Easy LMS no somos una excepción. La forma en que gestionamos esos riesgos marca la diferencia.

Publicado el
Mar 27, 2023
Tiempo de lectura
8 Minutos
Escrito por
Koen- Ingeniero de back-end

«¿Está preparado?»

«Tan preparado como puedo estarlo», pienso mientras repaso mentalmente mi lista de comprobación por última vez.

Piloto: cordones de las botas, correas de las piernas, correa pectoral, guantes, radio, correa de la barbilla, comprobado.

Cordas: todas libres y sin obstrucciones, la izquierda por encima de la derecha para poder girar hacia mi lado preferido, comprobado.

Ala: el borde de ataque está abierto y bien extendido en forma de herradura, comprobado.

Viento: Empieza a soplar una ligera brisa, un poco demasiado débil para un despegue inverso. Decido esperar unos minutos.

«Elija el momento adecuado».

Asiento con la cabeza al instructor mientras observo la veleta. Tras otro minuto, noto que el viento gana un poco de fuerza. La veleta tiene buen aspecto. Espero unos segundos para ver si se mantiene. Así es.

Viento: comprobado.

Espacio aéreo: no hay otros parapentes volando cerca del punto de despegue ni otros preparados para despegar, comprobado.

Respiro hondo... «¡YA!», tiro de las bandas A hacia mí. El ala se infla a medida que se eleva. Suelto las bandas y acciono los frenos para detenerla sobre mi cabeza. La forma del ala me resulta familiar, bien. No se aprecian nudos, excelente. Una ráfaga de viento gira ligeramente el ala. Ya no está centrada sobre mí. ¿Debería abortar el despegue? Aplico un poco de freno para orientar el ala hacia delante y doy dos pasos para situarme de nuevo debajo del ala. El ala se estabiliza. Mantengo la vela en esta posición durante un segundo o dos para comprobar que tengo el control. Con la vela estabilizada, todas las señales son ahora positivas. Mientras mantengo una presión constante sobre los frenos, giro 180 grados. Tras una breve carrera, noto cómo se tensan las correas de las piernas a medida que la vela me eleva del suelo.

Estoy volando.

Ya lo ha adivinado: tengo una afición arriesgada. Eso significa que soy una persona a la que le gusta correr riesgos, ¿verdad? Bueno, sí, más o menos. ¡Pero también no! Como parapentista, dedico una cantidad significativa de energía a mitigar los riesgos. Con una preparación sólida y manteniendo márgenes de seguridad adecuados, reduzco el riesgo a un nivel aceptable. Por lo tanto, un término más adecuado sería «gestor de riesgos».

Consulte nuestras ofertas de empleo

Sin riesgo, no hay negocio

Esto me lleva al tema que nos ocupa: la gestión de riesgos en el desarrollo de software. Más concretamente, ¿cómo gestionamos nuestros riesgos para poder implementar mejoras con confianza y sin estrés? Al fin y al cabo, implementar software es algo parecido al despegue en parapente. En ambos casos, es probable que los riesgos se materialicen en problemas reales.

Lamentablemente, la única forma de eliminar todos los riesgos es evitarlos por completo. Dejar de practicar parapente o, de forma equivalente, dejar de implementar mejoras de software. La primera es, de hecho, una opción válida. La segunda… bueno, habrá algunos riesgos con los que simplemente tendremos que convivir. Pero aún así podemos reducir el riesgo, así que, ¿cómo lo hacemos en Easy LMS?

Lamentablemente, la única forma de eliminar todos los riesgos es evitarlos por completo

¿Qué es, en realidad, un riesgo?

Un riesgo es un suceso con una probabilidad de producirse y un impacto concreto (negativo). La combinación de probabilidad e impacto determina el nivel de riesgo. Así pues, un suceso que tiene muchas probabilidades de ocurrir y que tiene un gran impacto (negativo) supone un riesgo elevado. Un suceso que es poco probable que ocurra y que tiene un impacto muy limitado supone un riesgo bajo. Si la probabilidad y/o el impacto aumentan, el riesgo también lo hace, y viceversa.

Gestión del riesgo

Dado que el riesgo es una combinación de probabilidad e impacto, se deduce que, para reducir un riesgo, puede:

  • Reducir su probabilidad de que se produzca (asegurarse de que ocurra con menos frecuencia).

  • Reducir el impacto (asegurarse de que, si ocurre, no tenga graves consecuencias).

  • Hacer ambas cosas.

Por ejemplo, como parapentista, consideremos el riesgo de que sufra un accidente porque despego con un nudo peligroso en mis cuerdas. Entre otras medidas, reduzco este riesgo:

  • Seguir siempre el mismo procedimiento de despegue (reduciendo la probabilidad).

  • Llevar casco (lo que reduce el impacto).

La combinación de todas estas medidas me proporciona la confianza suficiente para correr alegremente hacia el borde de la montaña. Confío en mi preparación, mis habilidades, mi equipo y mi capacidad de toma de decisiones. El riesgo sigue existiendo, pero lo he reducido a un nivel que estoy dispuesto a aceptar. Al practicar parapente, el despegue siempre será un momento de tensión para mí. Me exige estar alerta. Pero no estoy estresado.

Del mismo modo, en Easy LMS contamos con medidas para gestionar los riesgos y mantener la calma. Consideremos el riesgo de introducir errores en el sistema al lanzar una nueva funcionalidad. Dos formas en las que minimizamos este riesgo son:

  • Practicar el desarrollo basado en pruebas (TDD)

  • Trabajar en pequeñas iteraciones

En Easy LMS contamos con medidas para gestionar los riesgos y mantener la calma

¿De qué manera nos ayudan estas medidas en Easy LMS?

Desarrollo basado en pruebas (TDD)

El desarrollo basado en pruebas, o TDD, consiste en escribir una prueba automatizada que verifique el comportamiento deseado de una nueva funcionalidad antes de escribir el código de dicha funcionalidad. El TDD contribuye a reducir el riesgo de introducir errores de las siguientes maneras:

  • Al comprobar el comportamiento mediante pruebas automáticas, es más probable que se detecten los errores durante el desarrollo.

  • Los errores se detectan en una fase más temprana del proceso de desarrollo al escribir las pruebas antes que el código.

  • Escribir pruebas antes de escribir el código obliga al desarrollador a reflexionar sobre cómo probar el comportamiento deseado, independientemente del código final.

  • Escribir código que se pueda probar es un poco como escribir un libro legible. Obliga al desarrollador a aplicar una estructura al código. Como resultado, el código que se puede probar suele ser código fácil de mantener.

  • Al seguir el TDD de forma rigurosa, vamos creando con el tiempo un conjunto de pruebas que incluye todas las pruebas escritas anteriormente. Antes de la implementación, ejecutamos todas estas pruebas. Si nuestra nueva funcionalidad causa algún problema con la funcionalidad existente, lo sabremos.

De este modo, el TDD contribuye a reducir en gran medida la probabilidad de introducir errores en el sistema.

Pequeñas iteraciones

En Easy LMS, trabajamos en pequeñas iteraciones, lanzando pequeños cambios con frecuencia. A menudo realizamos una o dos implementaciones al día. Lo hacemos por pequeños pasos, incluso cuando introducimos una funcionalidad de gran envergadura. Esto nos ayuda de la siguiente manera:

  • Recibimos comentarios de los clientes mucho antes de lo que lo haríamos si esperáramos a implementar la función hasta que estuviera completamente «terminada». A partir de esos comentarios tempranos, podemos cambiar fácilmente de rumbo si es necesario.

  • Es mucho más fácil recuperarse de un error si la diferencia con respecto a la última versión estable es pequeña.

  • Las iteraciones cortas son más fáciles de planificar y gestionar. Un equipo simplemente no puede retrasarse en el calendario durante un periodo de tiempo significativo. Esto reduce el estrés y evita que los equipos sientan la necesidad de tomar atajos.

  • Las implementaciones diarias suponen un fuerte impulso hacia un proceso de implementación más ágil y fiable. De lo contrario, lo pagaríamos caro cada día.

De este modo, las iteraciones cortas ayudan a reducir la probabilidad y el impacto de que se introduzcan errores en el sistema.

El TDD y el trabajo en pequeñas iteraciones nos dan confianza. Nos reafirma en nuestra convicción de que lo que estamos a punto de implementar funciona. Si surgiera algún problema, este sería de poca importancia.

Las iteraciones cortas son más fáciles de planificar y gestionar

Las pruebas unitarias están en verde, comprobado.

Muevo el ticket a «En revisión de control de calidad», lo que activa automáticamente una implementación en nuestro entorno de prueba.
Unos días antes, implementamos un pequeño cambio en los estados que se muestran en el resumen de participantes en varios lugares de la aplicación. Se suponía que el cambio haría que los estados reflejaran con mayor precisión la situación de un participante.

Puede que fuera más preciso, pero también resultaba confuso. Los clientes que observaban la nueva situación con la perspectiva anterior tenían la impresión de que no se habían enviado las invitaciones.

Ahora me encontraba aquí, listo para implementar la solución. Basándonos en los comentarios que recibimos en los días posteriores al lanzamiento, hemos mejorado nuestro cambio original. Observo el progreso de la implementación automatizada en nuestro entorno de prueba, donde realizamos nuestras pruebas finales antes de la implementación.

Las pruebas de aceptación dan resultado positivo, comprobado.

Abro el navegador y accedo al entorno de prueba para comprobar el cambio por última vez. El entorno de prueba está configurado de la misma manera que nuestra aplicación en producción.

Funciona tal y como esperaba: comprobado.

El cambio es pequeño, lo que facilita las pruebas. Las pruebas unitarias y de aceptación refuerzan aún más mi confianza en que la funcionalidad existente funciona igual que antes. Todo está en verde. Inicio la implementación.
Doy un sorbo a mi café y reviso mis mensajes mientras se ejecuta la implementación. Reflexiono sobre cómo este cambio debería beneficiar a nuestros clientes. Nos pondremos en contacto con el servicio de asistencia dentro de un día. Esperamos que los clientes ya no se pongan en contacto con el servicio de asistencia respecto a este estado. Si recibimos más comentarios, estoy seguro de que tendremos otra implementación lista esta misma semana para mejorar aún más nuestra aplicación y adaptarla a las necesidades de nuestros clientes.

Al cabo de unos minutos, el paso final de la implementación pasa a verde.

Vamos viento en popa.

Consulte nuestras ofertas de empleo

Check out more of our blogs

Caroline

Caroline

Apr 22, 2025

Su primer mes

Cuando tienes un trabajo nuevo, estás deseando empezar. Al mismo tiempo, siempre hay una buena dosis de nervios. ¿Qué le espera? ¿Cómo serán tus primeras semanas? ¿Y con qué rapidez puedes aportar realmente valor añadido? En esto último nos centramos. Nuestro claro programa de incorporación para ingenieros de software le ayudará a conocer nuestra empresa, a sus compañeros y sus tareas en un abrir y cerrar de ojos. Experimente cómo le damos el pistoletazo de salida.

Read more: Su primer mes
Caroline

Caroline

Apr 8, 2025

¡Trabajar y progresar!

¡Trabajar para Easy LMS es gratificante! Por supuesto que proporcionamos un salario competitivo, viajes y permisos para trabajar desde casa y ¡25 días de vacaciones pagas por año! Pero también estamos orgullosos de ofrecerte beneficios que te ayudan a sentirte y a hacer lo mejor. Tu bienestar, físico y mental, ¡es una máxima prioridad! Porque nuestros empleados son la columna vertebral de nuestra organización.

Read more: ¡Trabajar y progresar!
Caroline

Caroline

Mar 28, 2025