La corrección de errores es una parte tediosa pero obligatoria de cualquier desarrollo, y no todos quieren hacerlo. ¿Cómo convertir la corrección de errores en algo emocionante? Organizar una competencia! En esta publicación, hablaremos en detalle sobre nuestro "maratón de corrección de errores" de 24 horas, desde la preparación preliminar hasta la clasificación de los últimos compromisos después de otorgar a los ganadores.
Infectado con la idea
La escala de desarrollo de nuestra aplicación Sberbank Online ha aumentado significativamente durante el año pasado. Junto con esto, comenzaron a acumularse pequeños errores, que no se reflejaron de ninguna manera en las métricas clave. Pero entendimos que esta es una bomba de tiempo y que hay que hacer algo con ella.
Nos inspiramos en cómo nuestros colegas de
Avito resuelven tales problemas, y decidimos organizar un ataque masivo contra errores en el formato bagaton, teniendo en cuenta nuestra estructura de desarrollo, cultura y características específicas del flujo.
Era necesario organizar todo para que los muchachos quisieran participar en un bagaton y demostrar su frialdad sin las directivas de arriba. Para hacer esto, la competencia debe tener un ambiente genial. Decidimos crear un estilo especial, algo reconocible sobre los errores. Los bichos son bichos. ¿Quién destruye los errores en la vida ordinaria? Desinsectores: chicos con trajes amarillos de protección química. ¿Dónde se han encendido en los últimos años? En una serie popular sobre un profesor de química. Hay una base, terminamos con actividades. Organizaron un torneo de videojuegos, un concurso con premios, nominaciones individuales geniales ... y, por supuesto, mucha comida deliciosa. Pero lo principal, sea lo que sea que se diga, es la competencia para eliminar errores. Esto recordó un tablero con una interfaz web, que muestra el progreso de los equipos, sus posiciones actuales, número de puntos, etc. Discutimos todo con los líderes del equipo; ellos aprobaron nuestros planes.
Android vs iOS - tan deshonesto
Primero, queríamos empujar a los desarrolladores de Android Sberbank Online con sus colegas de iOS a jugar en la rivalidad de las plataformas. Pero en el proceso, las organizaciones se dieron cuenta de que esta no es la mejor solución, porque técnicamente las plataformas funcionan en condiciones desiguales. Dio la casualidad de que en iOS, las compilaciones son más rápidas y se ejecutan las pruebas automáticas.
Luego cambiamos el formato e hicimos equipos mixtos: cinco desarrolladores de Android e iOS cada uno. Anteriormente, los capitanes fueron elegidos entre los desarrolladores proactivos para ayudar a formar equipos. Resultó nueve equipos. Y a pesar del hecho de que descubrimos el problema del hierro desde el punto de vista del juego limpio, todavía teníamos que asegurarnos de que otras restricciones no se interpusieran en nuestro ejército de correctores de errores.
La siguiente búsqueda fue la elección de la fecha bagaton. Las fechas de lanzamiento para cada plataforma son diferentes: se seleccionaron para que todos se sintieran cómodos. Intentamos que la fecha sea lo más cercana posible a la fecha en que se asigna el candidato de liberación.
Además, bagaton carga fuertemente las infraestructuras de la plataforma. Cuando hay una competencia, que corrige los errores más rápido, el número de solicitudes de extracción despega. Otro mes y medio antes de Bagaton, existía el riesgo de que nuestro equipo no pudiera hacer frente a los picos previstos. Pero en ese momento esperábamos hierro nuevo, y llegó justo a tiempo. Logramos conectar, configurar y fortalecer la infraestructura de ancho de banda de ambas plataformas varias veces.
Tubería: cómo no bajar todo en una tubería
Todo se hizo aquí de la siguiente manera: inmediatamente antes del inicio del bagaton desde nuestro desarrollo, tomamos la rama en la que los equipos tenían que trabajar. Se vertieron muchas solicitudes de extracción con errores corregidos durante bagaton. Se ejecutaron pruebas automáticas en cada una de ellas, los desarrolladores revisaron las solicitudes de extracción y los evaluadores verificaron nuevas compilaciones para corregir el error. Y así, las 24 horas de la competencia.
También fue necesario distribuir la carga de los probadores. Hicimos un gráfico por hora del número previsto de solicitudes de extracción en el intervalo de bagaton de 24 horas, dependiendo del número de participantes, la carga del servidor, las actividades de terceros, etc. En comparación con el rendimiento promedio de los evaluadores y el número de horas efectivas de cada bagaton que lo acompaña. Distribuimos el "deber" para que el sábado por la mañana las colas fueran lo menos posible. En general, se confundieron.
Al mismo tiempo, tomamos en cuenta que después de bagaton era necesario comenzar de inmediato las pruebas de regresión para evaluar la calidad de la rama lo antes posible y decidir su infusión en la rama de desarrollo. Esta es una carga adicional para los probadores.
Revisión de características
Fue muy importante para nosotros no solo corregir errores, sino hacerlo de forma cualitativa. Tres procedimientos proporcionan la verificación del código enviado por los desarrolladores en las solicitudes de extracción. Para que el código se ajuste, deben pasar con éxito:
- Tres desarrolladores experimentados revisaron y aprobaron el código.
- el código normalmente fallaba y no fallaba las pruebas automáticas;
- Después de la compilación y la infusión, el error en el ensamblaje en las condiciones descritas no se reanuda.
Temíamos que en modo competitivo nadie se revisara entre sí. Y dentro del equipo no puedes dejar una reseña. Por lo tanto, decidieron no inventar nada y actuar según el flujo estándar, como en el modo de trabajo: una revisión cruzada arbitraria: quien sea libre, él se encarga del proceso.
También fue necesario realizar un seguimiento para que las revisiones no fueran a la cola. Para ir a lo seguro, atrajimos a los firmantes a la revisión (incluso aquellos que no participaron en el bagaton en sí) y recordamos activamente a los participantes la orientación sobre la calidad. Un desarrollador senior de iOS, en paralelo con la corrección de errores para su equipo, en un día recibió 80 solicitudes de extracción: lo leyó y lo entendió. ¡Esto es realmente mucho!
Seleccionamos y evaluamos errores
Tomamos errores de baja prioridad, eliminamos basura obvia por etiquetas y fechas. En total, resultaron 490 errores, en su mayoría pequeños y medianos, que las manos no alcanzaron debido a tareas más importantes. Estos son todos triviales y menores sanos:
- errores que se han movido repetidamente de una versión a otra
- errores terminaron en las solicitudes de los usuarios
- choque más fresco
- errores de regresión
- errores que afectan a UX
Todos los errores se dividieron en tres oleadas según la prioridad de cierre:
- La primera ola: unos 230 errores
- La segunda ola: alrededor de 150 errores
- La tercera ola (reserva) - alrededor de 110 errores
Los defectos se evaluaron no por la complejidad, sino por la criticidad para el negocio. Los más críticos son "artificialmente" y se colocan temporalmente en prioridad "bloqueador" y "crítico". Cuanto mayor sea la prioridad del error, más puntos se le otorgaron. La complejidad no se tuvo en cuenta: sucedió que el bloqueador de errores se cerró en 20 minutos y el trivial, en 4 horas. Por un error, puede ganar de 1 a 7 puntos.
Mantuvimos la puntuación de cada equipo para errores cerrados de acuerdo con su valor en las reglas de bagaton. Si los equipos tuvieron tiempo, se pusieron a trabajar el siguiente defecto. La motivación a través del valor hizo posible en primer lugar cerrar errores más críticos.
Cómo cerrar errores
Dividimos la primera ola de errores en 11 grupos (con un margen), iguales en número de puntos y en la proporción de Android e iOS. La primera ola son los errores "caros", los prioritarios con un mayor costo. Para una búsqueda conveniente en Jira, les asignamos las etiquetas apropiadas. Se lanzaron alrededor de 20 errores en cada grupo.
Al comienzo del bagaton, reunimos capitanes de equipo y jugamos etiquetas. Además, los capitanes en su filtro designaron la etiqueta deseada y distribuyeron los errores correspondientes dentro del equipo. Así que logramos eliminar la corrección de errores caótica, donde los chicos simplemente tomarían lo que es más comprensible para ellos.
Las primeras cuatro horas, los equipos recibieron puntos solo por errores con las etiquetas del grupo que les había caído para establecer un ritmo específico. Cuando se acabó el tiempo, los insectos aún abiertos pasaron a la segunda ola, añadiendo a los otros que tenían sentido cerrar dentro del bagaton.
A las 19:00, todos los errores no cerrados entraron en la tercera ola, además de los errores que ya estaban planeados allí. Como resultado, durante la noche tuvimos errores "rápidos" que se cerrarían en el flujo habitual: cachés y errores actuales, descargados literalmente un día antes del bagaton, así como errores con la prioridad más baja. Las tres olas se pusieron a trabajar. Como resultado, 286 de 493 errores seleccionados fueron cerrados por bagaton.
Bagaton une
La sede de Bagaton estaba ubicada en nuestra sala de conferencias, también había pruebas y un torneo de videojuegos. Los equipos no fueron limitados, dispersados donde sea conveniente para ellos. Como resultado, todo el banco aprendió sobre bagaton. Un oonista de productos del cuarto piso dijo: “Me reuniré en el piso 14, buscando la sala de reuniones adecuada. De repente, entiendo que acabo de ver caras familiares, estoy volviendo: mis desarrolladores están sentados con poder y protagonismo, y sin ninguna atención hacia mí. Ja, creo, no se esconderán de su dueño del producto y en más de 10 pisos, está bien, siéntate, la corrección de errores es lo correcto ".
Hubo un equipo en el que solo un Android llegó al bagaton y al mismo tiempo seis fuertes desarrolladores de iOS. Excepcional eliminamos a este equipo de otro paquete con errores de iOS.
Además, siete desarrolladores de las regiones vinieron a Bagaton. Algunos se reunieron con sus equipos por primera vez, lo que habían visto anteriormente solo por videoconferencia. Fue genial ver cómo estos chicos se unieron activamente al proceso.
¿Cómo se evaluaron los resultados?
Para casi un centenar de desarrolladores, solo teníamos 15 probadores. Y por la noche hay cuatro en absoluto. Todos ellos no fueron suficientes, por lo que las pruebas continuaron al día siguiente. Fueron los evaluadores quienes otorgaron puntos a los equipos, por lo que los eliminamos del equipo para eliminar el sesgo. En un flujo de trabajo normal, el probador puede llamar al desarrollador y averiguar: "Escucha, amigo, hay un problema ...". En bagaton fue estricto: los evaluadores deben envolver todo lo que no pase claramente.
Entonces pudimos ver que algunos desarrolladores no están trabajando en el flujo aceptado. Hackathon se ha convertido en un tipo de catalizador para todas las desviaciones. Aquellos que trabajan claramente en flujo lograron pasar las pruebas en la primera ola y obtener puntos. Todos los que no correspondían realmente entraron en la cola, que ya habían rastrillado después de Bagaton. Tiene 60 errores.
Incidentes
En general, todo salió como de costumbre, los incidentes fueron típicos y se resolvieron en condiciones de funcionamiento. Cuando algo se rompió, algunos de los Signors cambiaron inmediatamente de la corrección de errores a la eliminación del incidente.
Hubo un incidente gracioso. Al preparar el panel, describimos los posibles riesgos: acceso a Jira, actualizaciones continuas, etc. Notificaron a todos los administradores que durante el tiempo del bagaton era necesario suspender todo el trabajo de mantenimiento, las actualizaciones de Jira y los servidores. Se crearon cuentas de respaldo para acceder a Jira. Y de repente alrededor de las 18:00 nos damos cuenta de que el tablero ha dejado de recopilar datos. Los supuestos eran diferentes. ¿Quizás no tomaron en cuenta algún tipo de protocolo de seguridad? El motivo fue inesperado. Nuestra organización es muy grande, no siempre es posible obtener información completa sobre todos los procesos planificados. Nuestro tablero se implementó en una máquina virtual en uno de los servidores secundarios. Resultó que fue en este día, viernes por la noche, que este servidor, según un plan desconocido, se desconectó físicamente de la toma de corriente, se cargó en el automóvil y se envió a la residencia permanente en nuestro nuevo centro de datos. Como resultado, para el sábado por la mañana tuvimos que recopilar todos los datos y calcular puntos en modo manual.
Fusionar sucursales y otros resultados
En el modo de funcionamiento normal, toda la rama es manejada manualmente por más de 800 casos de prueba. Un equipo completo de evaluadores realiza nuestras pruebas de regresión a tiempo completo en dos semanas. No podíamos permitirnos seguir desarrollando sin cambios durante tanto tiempo. Para reducir el tiempo de prueba, seleccionamos los principales casos de prueba del estado de la aplicación, alrededor de 107. Hasta el final del lunes, manejaban el 80% de iOS, el 50% de Android y no revelaron un solo error crítico. Decidimos que las ramas se pueden fusionar.
De los 286 errores cerrados en el bagaton, se arreglaron 182 errores. El resto son redjacks que no son relevantes por varias razones, errores (en algún lugar el diseño o la funcionalidad ya ha cambiado). Estos errores no son críticos, pero ahora ya no necesitarán distraerse y puede concentrarse tranquilamente en tareas importantes.
Además, muchos, siguiendo los resultados de bagaton, tenían una pregunta: ¿cuántos errores cometimos? Solo ocho errores en iOS y siete errores en Android.
Es importante para nosotros que los desarrolladores se sientan responsables del código del producto en igualdad de condiciones con otros miembros del equipo. Esto es importante en cualquier desarrollo, pero en el desarrollo distribuido se convierte en un requisito previo para un trabajo exitoso. Y en nuestra opinión, logramos aumentar el nivel de esa misma propiedad y espíritu de equipo. El resultado fue una historia con un montón de ganancias: en poco tiempo arreglamos un montón de errores, descargamos trabajos atrasados, bombeamos habilidades de equipo y obtuvimos muchos admiradores.
Material preparado por el equipo de Sberbank Digital Business Platform