¿Existe una relación entre la deuda técnica y la velocidad?

TL;DR

La velocidad y la deuda técnica no están directamente correlacionadas, y la velocidad no puede medir la deuda técnica directamente. Sin embargo, la velocidad (cuando se implementa correctamente) puede actuar como un control de detección para descubrir deudas ocultas.

La deuda técnica no es necesariamente mala. Al igual que el apalancamiento financiero, existen deudas buenas y deudas malas. Asumir la deuda que el proyecto puede pagar puede ser una opción necesaria para cumplir con los objetivos a corto plazo. ¡Es importante asumir solo la deuda que el proyecto puede pagar y que el equipo puede pagar!

El principal problema de la deuda técnica es cuando es invisible. La Ley de Transparencia℠ de CodeGnome dice: "¡Ningún trabajo invisible, nunca!" La deuda visible no reducirá su velocidad, pero puede reducir la velocidad a la que se pueden entregar nuevas funciones. El trabajo invisible actuará como un lastre en la velocidad, lo que es una advertencia temprana de que puede haber una deuda técnica desconocida o inesperada que todo el Equipo Scrum debería sacar a la superficie y abordar.

Deuda técnica definida

Wikipedia actualmente define la deuda técnica de la siguiente manera (énfasis en negrita mío):

La deuda técnica (también conocida como deuda de diseño 1 o deuda de código) es un concepto en el desarrollo de software que refleja el costo implícito del retrabajo adicional causado por elegir una solución fácil ahora en lugar de usar un mejor enfoque que tomaría más tiempo.

La deuda técnica se puede comparar con la deuda monetaria. Si la deuda técnica no se paga, puede acumular "intereses", lo que dificulta la implementación de cambios más adelante. La deuda técnica no abordada aumenta la entropía del software. La deuda técnica no es necesariamente algo malo ya veces (p. ej., como prueba de concepto) se requiere deuda técnica para hacer avanzar los proyectos. Por otro lado, algunos expertos afirman que la metáfora de la "deuda técnica" tiende a minimizar el impacto, lo que se traduce en una insuficiente priorización del trabajo necesario para corregirlo.

Cuando se inicia un cambio en una base de código, a menudo existe la necesidad de realizar otros cambios coordinados al mismo tiempo en otras partes de la base de código o la documentación. Los cambios requeridos que no se completan se consideran deuda que debe pagarse en algún momento en el futuro. Al igual que la deuda financiera, estos cambios incompletos generan intereses además de los intereses, lo que dificulta la construcción de un proyecto. Aunque el término se usa principalmente en el desarrollo de software, también se puede aplicar a otras profesiones.

En la práctica, la deuda técnica puede ser conocida o desconocida, y puede ser visible o invisible. La deuda conocida y visible puede o no ser rastreada explícitamente dentro de su proyecto, aunque ciertamente debería ser así.

Deuda Técnica y Velocidad

La velocidad es una métrica ágil que mide principalmente la capacidad de trabajo que probablemente se puede completar en una sola iteración. La idea central es que las mediciones históricas se pueden suavizar (a menudo expresando la velocidad como un rango o un promedio móvil) para hacer pronósticos a corto plazo razonablemente precisos (por ejemplo, "suficientemente buenos").

Generalmente hay dos clases de deuda técnica: visible e invisible. Las dos clases se comparan a continuación.

Deuda Técnica Visible y Conocida

Velocity no mide directamente la deuda técnica. Si realiza un seguimiento explícito de su deuda técnica y la hace visible como trabajo en la cartera de productos (como debería hacerlo), los costos principales de la deuda técnica a menudo aparecerán como:

1. Mayor asignación de la capacidad del equipo a "pagos de deuda" en forma de tareas y refactorización explícita a medida que aumenta la deuda, generalmente a expensas de nuevas características.
2. Un aumento general en el tamaño de las estimaciones del equipo, teniendo en cuenta la refactorización implícita y la holgura adicional necesaria para gestionar los efectos colaterales de la deuda.
3. Una reducción aparente (aunque no necesariamente real) en el valor para las partes interesadas de cada iteración siguiente, a medida que se gasta más y más capacidad del equipo en los "pagos de deuda" necesarios para desarrollar las características o evitar que el proyecto se derrumbe bajo el peso de su deuda técnica.

Debido a que la deuda es visible y rastreada, generalmente no afectará en absoluto la velocidad real del equipo. En cambio, puede afectar el valor percibido de esa velocidad, porque reducirá el ritmo de entrega de nuevas funciones. Es posible que 20 puntos de trabajo ya no brinden 20 puntos de valor para las partes interesadas, pero la cantidad de esfuerzo real que el equipo puede gastar en cada iteración en realidad no cambiará mucho.

Deuda Técnica Invisible o Desconocida

El costo de la deuda invisible, o peor aún, la deuda técnica desconocida, a menudo se paga en términos de un lastre inesperado en la productividad. Si el lastre para la productividad crece lo suficiente y permanece invisible durante el tiempo suficiente, esto eventualmente conduce a:

1. Una creciente incapacidad para pronosticar con precisión la capacidad.
2. Una incidencia cada vez mayor de iteraciones que no cumplen los objetivos del equipo o de las partes interesadas.
3. Una pérdida de confianza de las partes interesadas en el equipo.
4. Una pérdida general de confianza en el marco de gestión de proyectos.

En resumen, en lugar de culpar a la implementación del marco, se culpará al propio marco (y muy probablemente al equipo que permite que esta deuda permanezca invisible) por la falta de progreso. Esto se magnificará enormemente en implementaciones ágiles que solo rastrean el valor de las partes interesadas al medir la velocidad. A medida que aumenta el nivel de esfuerzo para cada función, la velocidad aparente disminuye, ya que la capacidad del equipo para funciones visibles para el usuario disminuye drásticamente a medida que la deuda técnica invisible se agrava en cada Sprint.

Consejos generales

La velocidad es solo una métrica entre muchas. No dependa únicamente de la velocidad para medir su proyecto, pero tampoco lo descarte como irrelevante. Aquí está mi lista de las diez mejores sugerencias para usar la velocidad y otras técnicas para medir o descubrir la deuda técnica:

1. Utilice la velocidad para medir el esfuerzo , no el valor de las partes interesadas.
2. Use la velocidad para pronosticar la capacidad del equipo , no el valor potencialmente entregable.
3. Identifique la deuda técnica lo antes posible durante cada iteración, incluso en Sprint Planning, Backlog Refinement y Sprint Review.
4. Mantenga la deuda técnica conocida visible para el equipo de desarrollo, el propietario del producto y las partes interesadas en todo momento.
5. Solo asuma deuda técnica deliberadamente, con el consentimiento informado de todo el Equipo Scrum (e idealmente también con las partes interesadas). ¡ Tendrán que devolverlo todos juntos!
6. Realice un seguimiento de todo el trabajo conocido (incluida la deuda técnica) como elementos en la cartera de productos.
7. Revise su Sprint Backlog al final de cada Sprint para identificar nuevas fuentes de deuda técnica.
8. No diferencie entre tareas, errores, funciones, etc. en sus mediciones de velocidad sin procesar, ya que todos requieren tiempo, esfuerzo y recursos del equipo.
9. Revise los aumentos inesperados de tiempo, esfuerzo y recursos, ya que esto puede ser el resultado de una deuda tecnológica invisible.
10. Busque la deuda técnica invisible cada vez que se pierda un Sprint Goal o cuando la velocidad caiga inesperadamente.

La velocidad por sí misma puede o no revelar la deuda técnica, pero ciertamente puede actuar como un sistema de detección temprana para el trabajo invisible. Mientras se esfuerce por mantener todo el trabajo visible, su proceso transparente y aproveche todos los ciclos de inspección y adaptación de su marco de trabajo de manera efectiva, por lo general evitará ser sorprendido por la deuda técnica . Todavía puede acumularlo, y la deuda impaga aún puede hundir su proyecto, ¡pero al menos el equipo y las partes interesadas no se sorprenderán!

Realice un seguimiento de todo el trabajo que consume la capacidad del equipo (incluido lo que esté clasificando como deuda técnica) como un elemento de primera clase dentro de su Product Backlog. Al igual que con la deuda financiera, es mucho menos probable que "quede en bancarrota" cuando realiza un seguimiento estricto de sus gastos y evita los onerosos pagos de intereses.

Dependiendo de cómo quiera lidiar con la deuda técnica, se determina si afecta su velocidad. Tienes algunas opciones por lo que puedo ver:

1. No asigne puntos de historia a la deuda técnica en un 'problema' separado

Si asume una deuda técnica sin puntos de historia, por ejemplo, en una tarea separada, verá una caída en la velocidad de ese sprint. Eso es de esperar porque la deuda técnica no tiene puntos de historia asociados.

2. Asignar puntos de historia a la deuda técnica en un 'problema' separado

Al hacer esto, la velocidad no se verá afectada porque los puntos de la historia se utilizan en el cálculo de la velocidad. Hacer esto constantemente le mostrará una velocidad y si la deuda técnica se puede estimar correctamente en puntos de historia, debería poder planificar el trabajo.

3. Incluir la fijación de la deuda técnica en el piso que requiere su solución Si tiene un piso que no se puede entregar hasta que se resuelva la deuda técnica, incluya el trabajo en la estimación del piso. Si eso significa que la historia se vuelve demasiado grande para manejarla en un sprint, cree una épica y divida la historia en partes más pequeñas y conéctelas a la épica. Esto tiene mi preferencia porque muestra lo que se debe hacer para implementar una función y puede indicar dependencias en las historias enumeradas debajo de la epopeya.

Existe un fuerte vínculo entre la deuda técnica y la velocidad, tanto a corto como a largo plazo.

Un equipo podría potencialmente aumentar su velocidad a corto plazo acumulando deuda técnica. En efecto, están aplazando las cosas para que puedan dar la apariencia de un progreso más rápido.

A largo plazo, la acumulación de deuda técnica puede comenzar a reducir la velocidad, ya que dificulta el desarrollo.

Un aspecto clave de la deuda técnica es la visibilidad del proceso de toma de decisiones .

Es decir, cuando un equipo asume una nueva deuda técnica o reconoce una deuda técnica existente, debe tomar una decisión clara y visible sobre qué hacer al respecto.

Por ejemplo, un equipo podría decidir aplazar la resolución de una deuda técnica desafiante porque se acerca un lanzamiento. Reconocerían y harían visible el impacto que esto tendrá en el desempeño a largo plazo del equipo y también podrían decidir priorizar la resolución de la deuda después de la liberación.