Sabes lo que es eso. Cram todo lo necesario en una carrera de velocidad, por lo que no es fácil, y de hecho todavía necesita un lugar para encontrar el 10-20% adicional de tiempo para volver a los desarrolladores de la deuda técnica . Si alguna vez has defendido la necesidad de hacer tiempo para esto, entonces sabes que esto es como una cruzada de proporciones épicas.
Pero puede hacer esto, y en esta guía descubriremos exactamente cómo.
He visto demasiadas reuniones donde exactamente esta pregunta ha pasado demasiado tiempo. Los argumentos generalmente no tienen fundamento, y las emociones pueden ser altas, y gana el que tiene la voz más alta en la sala.
El dilema es el siguiente: si la presión del negocio toma ventaja, su empresa corre el riesgo de obtener demasiada deuda técnica, y luego los desarrolladores pierden su motivación, la empresa llega a la bancarrota técnica y sus competidores lo derrotan. Si supera la presión de los desarrolladores , la compañía corre el riesgo de asumir muy poca deuda técnica, y luego sus competidores podrán proporcionar productos y características más rápidamente, capturar el mercado y luego utilizar las ganancias recibidas para devolver su deuda técnica. Se pierde de nuevo.
El sentido común sugiere que los equipos de desarrollo deben desarrollar una comprensión intuitiva de la base del código, donde se esconde la deuda técnica, así como sus consecuencias para la empresa, creando así la confianza dentro de la organización. Si su arquitecto y fundador principal dice que necesita refactorizar en este momento, usted (por lo general) simplemente lo toma y lo hace.
Tiene sentido tratar de retener a sus desarrolladores para crear una cultura de conocimiento, intercambio y confianza. Pero tomará años de arduo trabajo y, terminando la refactorización, todavía no tenemos idea de si hemos perdido nuestro tiempo. ¿Quizás acabamos de ahorrar unos días del tiempo de desarrollo futuro? ¿O podríamos esperar un poco para pagar la deuda técnica más tarde y agregar algunas características nuevas? Nunca estamos seguros y atribuimos nuestra ignorancia al hecho de que el desarrollo de productos es más un arte que una ciencia.
Bueno, es hora de agregar algo de ciencia al proceso.
¿Cuáles son la confiabilidad similar del sitio y el presupuesto para la deuda técnica?
La deuda técnica adecuadamente administrada y planificada a propósito puede ser una herramienta invaluable. Al darnos cuenta de lo que estamos haciendo, podemos usarlo tal como usamos la deuda financiera como un apalancamiento. Pero si, sin sospecharlo, asumimos demasiado, por ejemplo, no entendemos completamente los términos de la transacción (es decir, el impacto que la deuda técnica tiene en nuestra base de códigos, clientes, equipo y negocio), el negocio puede terminar en el colapso de nuestra compañía.
Los mejores equipos de administración de confiabilidad del sitio operan con su presupuesto de confiabilidad del sitio en términos de deuda técnica administrada. La confiabilidad del sitio es un concepto popularizado por Google; ella es responsable de mantener el software en un estado "en funcionamiento", pero, curiosamente, las compañías como Google no tienen como objetivo aumentar el tiempo de actividad al 100%. La razón es que un tiempo de actividad del 99.99% es suficiente para que los productos de Google sean excepcionalmente confiables para usuarios reales. Y este último 0.01% es exponencialmente difícil de lograr, y simplemente no tiene sentido luchar por ello.
Por lo tanto, si esto da un total de 52 minutos de tiempo de inactividad por año, Google intentará acercarse lo más posible a esta cifra; pero a menos de 52 minutos por año, es una oportunidad perdida para asumir más riesgos y más rápidamente proporcionar funciones avanzadas a sus clientes.
Piense en su presupuesto de deuda técnica como un presupuesto para la confiabilidad del sitio. Siempre que incurra en una deuda técnica razonable y permanezca por debajo del monto máximo de deuda que puede pagar antes de que comience a afectar a sus clientes y negocios, debe aumentar el monto de la deuda para asumir más riesgos y ganar sus competidores
Si su deuda técnica está en la zona roja, debe pagarla parcialmente. Si está en la zona verde, puede asumir más riesgos y más deudas. Su objetivo es mantener constantemente el monto de la deuda lo más cerca posible del ideal. En otras palabras, si está en la cima de la parte roja del gráfico, el presupuesto ideal para la deuda técnica es A ⇒ B. Si está en la depresión de la parte verde del gráfico, entonces el presupuesto ideal es C ⇒ B. Recuerde solo que A ⇒ C es un presupuesto demasiado grande para la deuda técnica .
Dado que la deuda técnica se puede medir (escribimos sobre esto en otro artículo ), este no es solo un concepto, sino que satisface plenamente las necesidades prácticas.
Cómo aprovechar al máximo su presupuesto de deuda técnica
Debe esforzarse por obtener un presupuesto de deuda técnica que lo devuelva hacia arriba o hacia abajo, a la cantidad máxima de deuda técnica que puede pagar. Para determinar este presupuesto, describa en las áreas base de su código donde las deudas técnicas deben pagarse de inmediato, es decir, las deudas que evitarán que su empresa alcance sus objetivos actuales. No es aconsejable que pague muy poca deuda o demasiado.
Andreas Klinger , coordinador del equipo remoto en AngelList, lo explica bien en su artículo Refactorización de grandes bases de código heredado :
No todo necesita ser refactorizado. Si esto no es una parte crítica, o si nadie necesita mejorar esta funcionalidad en los próximos meses, o si es demasiado complicado, considere reconocer este lugar como una deuda técnica.
En pocas palabras, su objetivo es encontrar dónde se superponen dos cosas: en qué trabajará en el sprint actual, mes o trimestre, y aquellas partes de su base de código que contienen deuda técnica. Pague la deuda en el área de esta intersección, pero no más allá.
Y es aquí donde la ciencia complementa el arte. Puede utilizar los datos para identificar las áreas en las que necesita para pagar la deuda técnica en un futuro próximo:
- Resalte los archivos con propiedad débil en su base de código, ya que la propiedad del código es un indicador principal del bienestar de su base de código. Más sobre esto en nuestro artículo "Una característica de la cultura corporativa necesaria para el bienestar de la base del código" .
- Medir la cohesión (cohesión) y el compromiso (acoplamiento) para esos archivos y salir de la lista sólo los archivos con la propiedad débil, baja cohesión y alto apalancamiento. Puede obtener más información sobre cada uno de estos indicadores en nuestro artículo "Uso de los estudios de líderes de la industria para medir la deuda técnica" .
- Calcule la actividad recurrente (rotación) para cada uno de estos archivos para determinar un subconjunto de los archivos problemáticos. Según un estudio de Microsoft , los archivos que cambian activamente representan solo el 2–8% del total de archivos en el sistema, pero representan el 20–40% de todos los cambios, y son responsables del 60–90% de todos los errores.
- Relacione la lista de archivos resultante con sus planes trimestrales. ¿Alguna de las características enumeradas en sus planes requerirá que trabaje en un subconjunto de los archivos de problemas que describió? En caso afirmativo, establezca objetivos relacionados con la refactorización de estos archivos, evalúe la cantidad de trabajo necesaria y asigne tareas a desarrolladores específicos, preferiblemente a aquellos que poseen los archivos correspondientes. Incluye este trabajo en tus planes.
Para comenzar, eche un vistazo a nuestra extensión gratuita VSCode : le ayudará a monitorear y pagar constantemente las deudas técnicas más urgentes.
Entrar en una relación a largo plazo con una deuda técnica
Hemos implementado este enfoque basado en datos en Stepsize, así como en muchas compañías de software de clase mundial. Ahora el tema de la deuda técnica no solo se ha vuelto mucho más claro, también sabemos cuánta deuda estamos dispuestos a asumir y cuándo / cómo devolverla. Raramente pensamos si elegimos correctamente un compromiso entre las nuevas características y la deuda técnica. Logramos eliminar una parte importante de las conjeturas, así como muchos temores y ansiedades que acompañaron esta elección.
Aclaremos nuevamente: esta no es una bala de plata que puede usarse una vez al año y luego olvidarse. Necesita conocer mejor su deber técnico. Siga su progreso en todos los indicadores de cada sprint y continúe mejorando todo el proceso para lograr el bienestar técnico .
Escribimos sobre varias formas de hacer esto, así que para crear la motivación correcta, lea sobre cómo cultivar una cultura de desarrollo basada en la propiedad y honrar a los desarrolladores que devuelven la deuda técnica .