"¿Estás listo?"
Todo lo preparada que puedo estar, pienso mientras repaso mi lista mental por última vez.
Piloto: Cordones de los zapatos, correas de las piernas, correa del pecho, guantes, radio, correa de la barbilla, comprobado.
Líneas: Todas libres y sin obstáculos, izquierda sobre derecha para que pueda girar hacia mi lado preferido, comprobado.
Ala: El borde de ataque es abierto y se extiende muy bien en forma de herradura, comprobado.
Viento: Se levanta una ligera brisa, un poco débil para despegar marcha atrás. Decido esperar unos minutos.
"Elige tu momento".
Asiento al instructor mientras miro la veleta. Después de otro minuto, siento que el viento se levanta un poco. La veleta tiene buen aspecto. Espero unos segundos para ver si dura. Y dura.
Viento: comprobar.
Espacio aéreo: No hay otros planeadores volando cerca del despegue y no hay otros planeadores listos para despegar, comprobado.
Respiro hondo... "¡Arranca!", tiro de los elevadores A hacia mí. El ala se infla mientras se eleva. Suelto los elevadores y tiro de los frenos para detenerla sobre mí. La forma del ala me resulta familiar, bien. No hay nudos visibles, excelente. Una ráfaga de viento hace girar ligeramente el ala. Ya no está centrada sobre mí. ¿Aborto? Freno un poco para orientar el ala hacia delante y doy dos pasos para colocarme de nuevo bajo el ala. El ala se estabiliza. Mantengo el ala en esta posición durante uno o dos segundos para verificar que tengo el control. Con el ala asentada, todas las señales están en verde. Manteniendo una presión constante sobre los frenos, giro 180 grados. Tras un breve sprint, siento que las correas de las piernas se tensan cuando el ala me despega del suelo.
Estoy volando.
Lo has adivinado: tengo una afición arriesgada. Eso significa que soy una persona arriesgada, ¿verdad? Bueno, sí, más o menos. También, ¡no! Como parapentista, dedico una gran cantidad de energía a mitigar los riesgos. Con una preparación sólida y manteniendo unos márgenes saludables, reduzco el riesgo a un nivel aceptable. Por lo tanto, un término mejor es gestor de riesgos.
Vea nuestras vacantes
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 desplegar mejoras con confianza y sin estrés? Al fin y al cabo, el despliegue de software es algo parecido a un lanzamiento en parapente. Ambos son momentos propicios para que los riesgos se materialicen en problemas reales.
Por desgracia, la única forma de eliminar todos los riesgos es evitándolos por completo. Dejar de volar en parapente o, lo que es lo mismo, detener el despliegue de mejoras de software. La primera es realmente una opción válida. La segunda, bueno, con algunos riesgos tendremos que vivir. Pero aún podemos reducir los riesgos, así que ¿cómo lo hacemos en Easy LMS?
Por desgracia, la única forma de eliminar todos los riesgos es evitándolos por completo.
¿Qué es el riesgo?
Un riesgo es un suceso con una probabilidad de ocurrir y un impacto concreto (negativo). La combinación de probabilidad e impacto determina el nivel de riesgo. Así, un acontecimiento muy probable y de gran impacto (negativo) es un riesgo elevado. Un acontecimiento que es poco probable que ocurra y tiene un impacto muy limitado es un riesgo bajo. Si la probabilidad y/o el impacto son mayores, el riesgo aumenta, y viceversa.
Gestión de riesgos
Dado que el riesgo es una combinación de probabilidad e impacto, se deduce que para reducir un riesgo, se puede:
Por ejemplo, como parapentista, consideremos el riesgo de estrellarme porque despego con un nudo feo en las líneas. Entre otras medidas, reduzco este riesgo:
La combinación de todas las 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 toma de decisiones. El riesgo sigue ahí, pero lo he reducido a un nivel que estoy dispuesto a aceptar. En parapente, el despegue siempre será un momento tenso 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. Pensemos en el riesgo de introducir errores en el sistema al lanzar una nueva función. Dos formas de minimizar este riesgo son:
En Easy LMS contamos con medidas para gestionar los riesgos y mantener la calma
¿Cómo nos ayudan estas medidas a Easy LMS?
Desarrollo basado en pruebas (TDD)
Test Driven Development, o TDD, es la práctica de escribir una prueba automatizada para el comportamiento deseado de una nueva funcionalidad antes de escribir el código para la funcionalidad en sí. TDD ayuda a reducir el riesgo de introducir errores de las siguientes maneras:
Al probar el comportamiento en pruebas automáticas es más probable que se detecten errores durante el desarrollo.
Los errores se detectan antes en el proceso de desarrollo escribiendo pruebas antes de escribir el código.
Escribir pruebas antes de escribir el código obliga al desarrollador a pensar en cómo probar el comportamiento deseado independientemente del código final.
Escribir código comprobable es un poco como escribir un libro legible. Obliga al desarrollador a aplicar una estructura al código. Como resultado, el código comprobable tiende a ser código mantenible.
Siguiendo religiosamente TDD, construimos un conjunto de pruebas con el tiempo, que comprende todas las pruebas escritas en el pasado. Antes del despliegue, ejecutamos todas estas pruebas. Si nuestra nueva funcionalidad causa un problema con la funcionalidad existente, lo sabremos.
De este modo, TDD ayuda a reducir en gran medida la probabilidad de introducir errores en el sistema.
Pequeñas iteraciones
En Easy LMS, trabajamos en pequeñas iteraciones, liberando pequeños cambios a menudo. A menudo realizamos uno o dos despliegues al día. Lo hacemos en pequeños pasos, incluso cuando introducimos una gran funcionalidad. Esto nos ayuda de la siguiente manera:
Recibimos comentarios de los clientes mucho antes que si esperásemos con el despliegue hasta que una característica está completamente "terminada". Basándonos en los primeros comentarios, podemos cambiar de dirección fácilmente si es necesario.
Es mucho más fácil recuperarse de un error si la diferencia con 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 una cantidad significativa de tiempo. Esto conduce a menos estrés y evita que los equipos sientan la necesidad de recortar gastos.
La implementación diaria crea un fuerte impulso hacia un proceso de implementación más ágil y fiable. Si no fuera así, sentiríamos el dolor a diario.
Los equipos que trabajan en un equipo de TI se sienten menos estresados.
De este modo, las iteraciones cortas ayudan a reducir la probabilidad y el impacto de que se introduzcan errores en el sistema.
TDD y el trabajo en pequeñas iteraciones nos dan confianza. Estamos convencidos de que lo que vamos a desplegar funciona. Si hay algún problema, será pequeño.
Las iteraciones cortas son más fáciles de planificar y gestionar
Las pruebas unitarias están en verde, compruébalo.
Muevo el ticket a "En revisión de control de calidad", lo que desencadena automáticamente un despliegue en nuestro entorno de preparación.Unos días antes, desplegamos un pequeño cambio en los estados mostrados en la descripción general de los participantes en varios lugares de la aplicación. El cambio debía hacer que los estados reflejaran con mayor precisión el estado de un participante.
Podría haber sido más preciso, pero también confuso. Los clientes que veían la nueva situación a través de las antiguas lentes tenían la impresión de que no se enviaban invitaciones.
Aquí estaba yo, listo para desplegar el remedio. Basándonos en los comentarios que recibimos en los días posteriores al lanzamiento, ahora hemos mejorado nuestro cambio original. Observo el progreso del despliegue automatizado en nuestro entorno de ensayo, donde realizamos las pruebas finales antes del despliegue.
Las pruebas de aceptación se ponen en verde, compruébalo.
Abro el navegador y navego hasta el entorno de ensayo para probar el cambio por última vez. El entorno de ensayo está configurado de la misma manera que nuestra aplicación en vivo.
Funciona como espero, compruébalo.
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 como antes. Todas las luces están en verde. Activo el despliegue.
Le doy un sorbo a mi café y compruebo mis mensajes mientras se ejecuta el despliegue. Pienso en cómo debería ayudar el cambio a nuestros clientes. Dentro de un día nos pondremos en contacto con el servicio de asistencia. Esperamos que los clientes ya no se pongan en contacto con el servicio de asistencia en relación con este estado. Si recibimos más comentarios, estoy seguro de que tendremos otro despliegue listo esta semana para seguir mejorando nuestra aplicación y satisfacer las necesidades de nuestros clientes.
Tras unos minutos, el último paso del despliegue se vuelve verde.
Estamos volando.
Vea nuestras vacantes
