Eliminar las pruebas de su deuda técnica

Bien. Comencemos hablando sobre el estado de la deuda técnica, lo que he presenciado en los equipos y cómo la gente está pensando en la deuda técnica hasta ahora. A menudo veo una hoja de ruta, algo así, que los gerentes de producto y los gerentes de ingeniería se esfuerzan mucho en armar, para determinar exactamente cuáles son las prioridades principales para este equipo. Y luego generalmente hay alrededor del 15% de la capacidad dedicada a la deuda técnica. Y eso es en lo que me voy a enfocar hoy, en ese 15% de capacidad. Hablemos de lo que entra en esa categoría. A menudo veo que la escalabilidad se incluye en ese 15% de capacidad, las pruebas pueden entrar ahí, las actualizaciones y el mantenimiento se clasifican como deuda técnica, los errores se clasifican como deuda técnica. Y comienza a sentirse como el cajón de los trastos de la ingeniería de software, donde cualquier cosa que no se incluya explícitamente en la hoja de ruta del equipo se coloca en este cajón del 15% de capacidad de deuda técnica, y el equipo intenta hacerlo dentro de esos límites.

Sin embargo, la realidad es que no creo que puedas encajar todas esas cosas en solo el 15% de la capacidad de tu equipo. Aquí hay mucho trabajo por hacer. He estado en equipos que han intentado, quiero decir, yo misma he intentado encajar todo eso. Y el resultado que veo es que realmente ralentiza a tu equipo. Tu equipo comienza a sufrir porque la deuda técnica solo crece y nunca se aborda por completo. Por supuesto, esto es malo para tu negocio cuando tu equipo no puede lanzar características rápidamente. También tiene estos efectos secundarios, como la felicidad de los desarrolladores comienza a sufrir porque las personas generalmente no quieren trabajar en equipos que están cargados con una tonelada de deuda técnica. Puedes tener problemas con la moral y la retención, incluso puedes tener problemas para contratar porque las personas a menudo no quieren unirse a equipos con una tonelada de deuda técnica. Obviamente, no es genial estar en ese lugar donde te estás acumulando una tonelada de deuda técnica, pero ¿cómo sales de ahí? Creo que una solución es aplicar más estructura y rigor en la forma en que tu equipo decide qué califica como deuda técnica. Y lo que he visto que funciona bien es esta filosofía que he desarrollado, o que he aprendido de otros, que la deuda técnica son problemas que afectan principalmente al desarrollador en lugar del usuario. Eso significa cosas que van a hacer que el desarrollador sea más productivo, más eficiente, en lugar de mejorar directamente la experiencia del usuario. Y la consecuencia menos obvia de eso es que creo que la preservación de características está dentro del ámbito de la construcción de características y no debe clasificarse como deuda técnica.

Y cuando hablo de preservación de características, me refiero a cosas como las pruebas automatizadas y el monitoreo, cosas que hacen que todo el sistema sea consciente de que existe una característica y evitan que una característica desaparezca o se rompa sin que el equipo de desarrollo lo sepa. La razón por la que clasifico esto como no deuda técnica es porque si estas características se rompen, el impacto real recae en el usuario. Es el usuario quien sufre si una característica se rompe. Por lo tanto, creo que es muy importante que el gerente de producto respalde la inclusión de actividades como las pruebas automatizadas y el monitoreo en el alcance de la característica, porque los usuarios sufrirán si no se tienen en cuenta.

Entonces, permítanme profundizar en esta filosofía. Cuando recibes un ticket o un proyecto de un gerente de producto, generalmente tienes un alcance muy explícito, que es hacer que esa nueva cosa funcione. Y luego hay un alcance implícito oculto debajo, que es no romper las cosas antiguas. Si rompieras las cosas antiguas, la persona que sufriría, nuevamente, sería el usuario en lugar del desarrollador. Por esa razón, creo que es realmente importante que el gerente de producto respalde la inclusión de actividades como las pruebas automatizadas y el monitoreo en el alcance de la característica, porque los usuarios sufrirán si no se tienen en cuenta.

De acuerdo, genial. Ahora que tenemos esa filosofía, intentemos ponerla a prueba en algunas situaciones de la vida real. A medida que avanzamos, quiero enfocarme nuevamente en quién se beneficia al resolver este problema. Comencemos con un ticket para solucionar un error, como arreglar este tooltip roto. Esto lo clasificaría como algo para el usuario, por lo que no es deuda técnica. Probablemente no sea el desarrollador quien sufra por este tooltip roto. Probablemente sea el usuario, por lo que debe tener prioridad sobre todas las demás preocupaciones del usuario. ¿Qué tal un ticket de limpieza de código, donde vamos a refactorizar un archivo de autenticación enorme en múltiples módulos? Esto, diría yo, es un gran ejemplo de deuda técnica. Esto es para el desarrollador. Probablemente sea para ayudar a los desarrolladores a moverse más rápido, comprender las cosas más rápidamente, por lo que es un buen uso de ese 15% de capacidad. Las pruebas, como escribir pruebas para un nuevo modelo. Diría que esto es preservación de características, por lo que no es deuda técnica y realmente debe tenerse en cuenta en la estimación de la creación original de la característica. Y la escalabilidad, como hacer que un servicio de usuario funcione para 10,000 personas. Nuevamente, esto es en realidad para el usuario, por lo que diría que no es deuda técnica. A pesar de que esto parece un proyecto muy técnico, hacer este trabajo no hará que el desarrollador sea más productivo o eficiente. Realmente es para servir mejor a tus usuarios, por lo que diría que esto no es deuda técnica. Esto, nuevamente, debe tener prioridad sobre otras preocupaciones del usuario.

De acuerdo, reconozco que he presentado este escenario como muy blanco y negro, pero no lo será, ¿verdad? Habrá muchas cosas que sean buenas tanto para el usuario como para la productividad del desarrollador. Por lo tanto, se requerirá juicio y sutileza para aplicar esta filosofía, pero al pensar en ello, creo que debemos concentrarnos en los dos extremos de este espectro, como la deuda técnica que se refiere principalmente a la productividad del desarrollador, y no como cualquier cosa que realmente beneficie al usuario. Con suerte, con esta estructura, podrás salir de la deuda técnica de manera más efectiva utilizando ese 15% de capacidad.

De acuerdo. Gracias. Esa es mi charla. Solo una mención rápida de que Galileo está contratando, así que definitivamente contáctame si estás interesado en eso. Puedes encontrarme en Twitter como Carly Jo. Gracias.