Hola, mi nombre es Maksim Plavchenok, trabajo para Bercut, hago pruebas de integración. En septiembre, mi equipo y yo pasamos un hito importante: recibimos cero errores como resultado de las pruebas de integración para el lanzamiento de una nueva versión de facturación para un operador de telefonía móvil. Fuimos a esto durante dos años; Hoy quiero contarles cómo logramos nuestro objetivo.
Cero errores basados en los resultados de las pruebas de integración: aquí estamos hablando de probar nuevas funcionalidades en una aceptación comercial por parte del operador. Algunas palabras sobre cómo funciona esta prueba.
Lanzamos nuevas versiones de nuestro software de facturación a tiempo, 6 veces al año. Las fechas de envío de lanzamiento se conocen de antemano. En el momento de escribir este artículo, ya hemos programado fechas de lanzamiento para todo el próximo año.
Esta especificidad está asociada con la carrera de los operadores celulares por el time-to-market. El principio fundamental: el suscriptor debe recibir periódicamente nuevas funciones de facturación. Pagos a través de un teléfono inteligente, guardar un número al cambiar de operador, la capacidad de vender tráfico no utilizado: las actualizaciones pueden ser diferentes.
"Puede que no sepamos qué lanzaremos exactamente en un año, pero sabemos la fecha exacta en la que se lanzará la actualización". Debido a esto, es posible mantener el ritmo deseado de actualizaciones.
Por el lado del desarrollo de la facturación, alrededor de 70 personas están involucradas en el lanzamiento. Se trata de 5-6 equipos, cada uno con su propia especialización: análisis, desarrollo (varios equipos), pruebas funcionales, pruebas de integración.
Sí, tenemos una cascada en proyectos de facturación. Pero la historia actual no se trata de cómo cambiamos radicalmente el paradigma de desarrollo de cascada a Agile o viceversa. Cada enfoque de desarrollo tiene sus propias ventajas y es bueno en las condiciones adecuadas; Me gustaría dejar esta discusión fuera del alcance de este artículo. Hoy quiero hablar sobre el desarrollo evolutivo: cómo nos movimos hacia cero errores durante la aceptación del lanzamiento dentro del marco del enfoque de desarrollo existente.
Zona de malestar
En el momento del inicio de la historia descrita, hace dos años, teníamos la siguiente imagen:
- los equipos al final de la cadena de desarrollo estaban abrumados; “Es hora de dar al siguiente equipo, y el anterior acaba de empezar su parte de trabajo”;
- el cliente podría encontrar alrededor de 70 errores después de nuestros ciclos de prueba.
Los errores que se pueden encontrar según los resultados de las pruebas de integración pueden ser menores (“parte del mensaje se muestra como guiones”) o incluso críticos (“no hay transición a otra tarifa”).
Decidimos cambiar esta alineación: establecimos una meta: cero errores en la aceptación comercial de la nueva funcionalidad.
Después de un año, pudimos reducir la cantidad de errores a 10-15 y, a mediados de 2020, a 2-3. Y en septiembre logramos alcanzar el objetivo de cero.
Tuvimos éxito gracias a las mejoras en varias áreas: herramientas, experiencia, documentación, trabajo con un cliente, un equipo. Las mejoras variaron en importancia: conocer los detalles y los procesos del cliente es importante, moverse a una nueva escala para evaluar la complejidad de las tareas es opcional y trabajar con la motivación del equipo es de vital importancia. Pero lo primero es lo primero.
Puntos de crecimiento
La principal herramienta de prueba de integración es el banco de pruebas. Allí se emula la actividad del suscriptor.
Stands compartidos
Los volcados de producción se colocan en bancos de prueba para que pueda probar en condiciones lo más cercanas posible al combate.
El problema es que los vertederos de nuestros stands y los de los clientes podrían ser diferentes. El operador hace un volcado, nos lo pasa, probamos nuevas funcionalidades, detectamos y arreglamos errores. Le damos la funcionalidad completa al cliente, los colegas del otro lado comienzan a probar. El nuestro y sus vertederos podrían diferir en relevancia: probamos en julio, el operador, en agosto, por ejemplo.
Las diferencias no son críticas, pero aún así las hubo. Esto llevó al hecho de que cuando probamos por parte del cliente, podían aparecer errores que no teníamos.
Qué hicimos: Acordamos que los esquemas de datos utilizados para las pruebas serán los mismos y, en general, tendremos una posición común.
El retraso de volcado permanece, pero hemos configurado la infraestructura en la que este retraso es mínimo. Debido a esto, pudimos reducir la cantidad de errores causados por las diferencias entre los entornos de prueba y producción.
Comprobación de la configuración antes de realizar la prueba
Cuando le damos una nueva versión del software al operador, para que lo pruebe por parte del cliente, necesitamos realizar la configuración. Configure una nueva funcionalidad, posiblemente personalice aún más la anterior.
Escribimos la documentación para informarle sobre la configuración requerida. Solo aquí los manuales pueden transmitir información con distorsiones. La documentación fue escrita por personas, leída por personas, y en la comunicación de las personas hay un malentendido.
Esta es la especificidad de nuestro software: se imponen altas exigencias a la configuración en términos de flexibilidad y disponibilidad. La configuración es compleja y, sin comunicación adicional, no siempre fue posible transmitir toda la información necesaria solo mediante documentación.
Como resultado, es posible que la configuración no siempre se realice correctamente, lo que llevó a la detección de errores durante las pruebas por parte del operador. Al analizar, descubrimos que estos no eran errores de software, sino configuraciones. Tales errores hacen perder un tiempo valioso.
Lo que hicimos: introdujimos un procedimiento para verificar la configuración por parte del cliente antes de realizar la prueba en los puestos del operador.
El procedimiento es el siguiente: el cliente elige los casos que mostramos en el stand configurado. Realizamos pruebas. Si hay errores, los corregiremos de inmediato; si no, se pasa la prueba.
Este enfoque nos permitió reducir la cantidad de errores asociados con configuraciones incorrectas durante las pruebas de integración.
Comunicaciones adicionales sobre documentación
Verificar la configuración antes de realizar la prueba, además de describir esta configuración en los manuales, es un ejemplo de comunicación adicional en torno a la documentación. Hubo otros.
Por ejemplo, lo hicimos para que en todo momento siempre hubiera un especialista de nuestro lado, a quien el cliente pudiera acudir con preguntas sobre la documentación y el sistema en su conjunto. Algo así como una línea de soporte técnico dedicada con nuestros especialistas altamente calificados.
Nuestros redactores técnicos han organizado talleres para educar a los empleados del cliente sobre la nueva funcionalidad.
El proceso de transferencia de documentación se volvió menos discreto, más continuo: nueva información, aclaraciones, recomendaciones ahora podrían enviarse en partes después del “envío” de los manuales principales; tal como aparece o bajo demanda.
Todo esto permitió informar mejor al cliente sobre la nueva funcionalidad y así reducir el número de errores en las pruebas de integración.
Experiencia en trabajar con sistemas de terceros
Para desarrollar la facturación, necesitamos poder realizar un seguimiento del tráfico. Hay sistemas PCRF separados para esto. Las llamadas se cuentan en una base de datos, los SMS en el mismo lugar y el tráfico en otra base de datos; y hay un software especial que sincroniza todo esto.
Al mismo tiempo, los sistemas PCRF son software de propiedad de terceros. Es decir, una caja negra: enviamos datos allí, recibimos algo a cambio, pero no podemos controlar lo que sucede dentro. Además, no podemos cambiar nada allí.
Esta alineación limitó nuestra capacidad para localizar y corregir errores relacionados con el tráfico.
Lo que hicimos: Creamos una base de conocimiento interna separada de PCRF. Cada incidente, cada opción de personalización, cada información: todo fue registrado y compartido por el equipo.
Como resultado, nos convertimos en buenos usuarios del sistema PCRF, podemos personalizarlo y entender qué debe hacer. Esto ahorra tiempo en incidentes simples. En casos complejos, por supuesto, todavía recurrimos a los desarrolladores del sistema en busca de ayuda.
Más stands
Otra característica al probar la facturación de los operadores móviles es que los scripts personalizados se pueden estirar con el tiempo. El guión completo que queremos probar puede tardar días o incluso semanas.
Es difícil esperar días o semanas durante la fase de prueba. En realidad, para verificar tales escenarios, la mayoría de las veces es simplemente el momento de relajarse en la base de datos.
Para rebobinar el tiempo, debe cerrar todas las sesiones excepto la suya. Tenemos una situación en la que, condicionalmente, 20 probadores pueden postularse para dos bancos de prueba, y todos quieren rebobinar el tiempo. Esta es la cola. Y la cola es la probabilidad de que para la fecha acordada de envío del software no tengamos tiempo de verificar todo correctamente.
Lo que hicimos: montamos un stand separado para cada tester.
Esto nos permitió eliminar los errores que ocurrieron debido a que “mi turno llegó tarde al estrado, no tuve tiempo”.
Virtualización
La preparación del stand no es un proceso rápido. Necesita conectarse a la red del operador, solicitar acceso, y eso no es todo. El procedimiento completo puede llevar varias semanas. La lucha por reducir el tiempo de preparación de la tribuna fue una dirección importante para avanzar hacia la meta de cero errores.
Qué hicimos: virtualización habilitada.
Copiar máquinas virtuales con todas las configuraciones necesarias, software preinstalado y automatizar este proceso ayudó a reducir el tiempo de preparación del stand a “dentro de un día”.
Planificación
Los errores de las pruebas de integración también son el resultado de errores de cálculo en la planificación del lanzamiento. Hicimos mucho swing, en el momento de la fecha de lanzamiento fija, no todo fue a tiempo.
Lo que hicimos: Introducir fechas límite provisionales para cada etapa de desarrollo. "Si conoce la fecha de finalización, entonces conoce todos los intermedios": este principio nos ayudó a controlar mejor la velocidad de movimiento hacia el objetivo de lanzamiento.
Soporte y lanzamiento en paralelo
Al comienzo de nuestro viaje, hubo una situación en la que las "deudas" del último lanzamiento entraron en conflicto con el próximo lanzamiento. Después de la aceptación, los errores llegaron por parte del cliente y todos fueron a solucionarlos.
Al mismo tiempo, el calendario de lanzamientos no se modificó. Como resultado, en el momento en que llegó el momento de abordar la próxima versión, aún podíamos seguir trabajando en la anterior.
Fue posible cambiar la situación debido a la separación de dos grupos del equipo: quién arreglará los errores de la aceptación y quién se encargará del nuevo lanzamiento a tiempo.
La división era condicional: no necesariamente la mitad allí, sino la mitad aquí. Podríamos transferir personas entre grupos según sea necesario. Desde fuera, puede parecer que nada ha cambiado: aquí hay una persona del equipo, durante el sprint resolvió errores y nuevas funciones. Pero, de hecho, la selección de grupos individuales fue una mejora de la categoría de "ahora podemos exhalar". El enfoque de cada grupo y la paralelización del trabajo entre grupos nos ayudó mucho.
Cronológicamente, este fue uno de los primeros puntos de crecimiento que formulamos en la autopsia. Y aquí llega mi historia a la parte sobre el instrumento principal.
Herramienta principal
La mejora que más nos ayudó son las autopsias honestas.
Alguien lo llama retrospectiva, alguien: un análisis de los resultados; la palabra "post-mortem" se ha quedado en nuestro equipo. Todas las mejoras descritas en este artículo se inventaron en autopsias.
El principio es simple: hubo un lanzamiento, deben reunirse y discutir honestamente cómo fue todo. Suena simple, pero existen dificultades en la implementación. Después de un lanzamiento "fallido", la gente del equipo tiene el estado de ánimo "no hay tiempo para rascar con los idiomas, necesitas hacer algo". Alguien puede llegar a las autopsias y permanecer en silencio (y por lo tanto no entregar parte de la información potencialmente útil).
Durante dos años de avanzar hacia la meta de cero errores, hemos desarrollado una serie de principios sobre cómo llevamos a cabo las autopsias.
- Reúna la imagen completa
Invitamos a una lista ampliada de participantes. Desarrolladores, probadores, analistas, gerentes, ejecutivos: todos los que deseen hablar. Desde el punto de vista organizativo, no siempre es posible reunir a todos, a todos. Está bien, también funciona así. No se trata de negar la participación de compañeros con la frase “aquí en nuestro equipo estamos resumiendo los resultados, tú los sumas en el tuyo”. Trabajamos con stands, código, procesos, interacción: nos esforzamos por no perder de vista ningún aspecto.
- No te agarres a todo a la vez
Bien, como resultado de la autopsia, obtuvimos 30 puntos de crecimiento. ¿Cuánto llevar al trabajo? ¿Quizás podamos resolverlo hasta la próxima? El formato de “elegir 2-3” funcionó mejor para nosotros. En esta situación, hay un enfoque y los esfuerzos de las personas del equipo no se difunden. Es mejor hacer menos, pero completamente, que mucho, pero no recordar.
- No seas inteligente con el formato
Hay muchos enfoques para realizar autopsias. Prácticas de facilitación, técnicas desde el pensamiento de diseño y el pensamiento lateral, la técnica de Goldratt y otros expertos respetados. En nuestra experiencia, el sentido común es suficiente para empezar. Anotamos los problemas, los agrupamos, elegimos varios clusters, dejamos de lado el resto (ver el punto anterior), discutimos, arreglamos el plan. Cuando hay un objetivo común, no es tan difícil encontrar un idioma común.
- Llevar al trabajo
Quizás el principio principal de esta lista. No importa cuán prometedora y convincente sea la lista de mejoras basada en los resultados de la autopsia, si no funciona, entonces todo es en vano. Estuvimos de acuerdo, entonces lo haremos. Sí, hay otros asuntos urgentes. Pero también tenemos un objetivo y queremos acercarnos a él.
La autopsia puede ser bastante dolorosa. Hablar del fracaso, incluso de forma constructiva, no es fácil. Pero vale la pena luchar contra el malestar. Estoy seguro de que sin la autopsia no hubiéramos podido idear e implementar todas esas cosas que ayudaron a lograr el objetivo de cero errores en la publicación.
La herramienta mas importante
La autopsia le permite encontrar medios para lograr el objetivo, pero si lo mira, también se puede llamar una consecuencia de un principio de nivel superior.
La herramienta más importante es la participación del equipo.
Hay un lado instrumental en la participación. Por ejemplo:
- si trabajamos horas extras, el jefe está al lado del equipo, ayudando con las manos;
- si anima a su equipo haciendo un seguimiento del progreso, entonces puede encontrar métricas visuales (no es difícil por la cantidad de errores).
Y además con el mismo espíritu.
La participación también tiene un lado difícil de formalizar: la capacidad de compartir su creencia en el éxito con el equipo. Después de todo, mi equipo y yo no solo miramos el folleto con los valores de la compañía, vimos que había "juntos más fuertes" y decidimos que, bingo, se había encontrado una solución. Hemos visto ejemplos de cómo se pueden lograr metas desafiantes uniendo fuerzas. Teníamos personas en nuestro equipo que creían en el éxito y trataban de transmitir esta creencia a sus colegas. El resto es cuestión de tecnología.
Las personas son lo más importante.
Hubo mucho más en el lanzamiento hacia el objetivo de cero errores. Trabajar para mejorar la documentación, aumentar la velocidad y la calidad de respuesta a las preguntas de los clientes son diferentes. Esta vez intenté compartir solo algunos ejemplos y hablar sobre los principios básicos.
El equipo y yo todavía tenemos mucho que hacer en la lucha por la calidad del lanzamiento y la optimización del tiempo de comercialización. Haga que el resultado sea reproducible regularmente sin errores en las pruebas de integración, automatice la regresión.
Queda por ver cómo lograr estos objetivos. Pero lo que sabemos con certeza en este momento: definitivamente haremos autopsias e implementaremos puntos de crecimiento basados en motivos. E intentaremos aprovechar las oportunidades que tiene el equipo involucrado.
Espero que algo de esto también te sea útil.