ubc_2012_fall_lim_erin2.en.es.pdf

sistema y predecir la probabilidad de que los clientes encuentren efectos de tener
deuda técnica presente en el sistema.
4.3 Causas
Uno de los objetivos de las entrevistas fue comprender las razones por las que los participantes
decidieron incurrir en deuda técnica en sus proyectos. Realidad empresarial, actitudes, inexperiencia.
y el envejecimiento fueron las razones mencionadas con más frecuencia para que los proyectos incurrieran en deuda técnica.
4.3.1 Realidad empresarial
Todos los participantes de la entrevista identificaron la realidad empresarial como la motivación principal.
detrás de su decisión de asumir deuda técnica. Como explicó S18, “…la realidad empresarial
nos obliga a tomar decisiones en momentos determinados para poder llegar a resultados más amplios, usted
ya sabes, ofrecer una solución”. S19 agregó: "No creo que debas intentar evitarlo [técnico
deuda] porque creo que es necesario. Ya sabes, y porque esa es la realidad empresarial”.
Las realidades comerciales de los proyectos de software incluyen limitaciones de cronograma, poco claras
necesidades y prioridades cambiantes.
4.3.1.1 Presiones de tiempo
Muchos participantes de la entrevista reconocieron que estaban motivados a incurrir en deuda técnica.
debido a presiones de tiempo. Por ejemplo, S04 comentó que si su proyecto no asumiera
deuda técnica, corría el riesgo de no poder cumplir nada. Asimismo, S15 reflejó que
“…se toman algunas decisiones… para decir, bueno, podríamos hacerlo mejor o podríamos
hacerlo de manera más corta. Y el camino corto ganó debido a las presiones de tiempo. No
diría que hubo un esfuerzo consciente por sacrificar la integridad o la estructura del software
o la capacidad de mantenimiento del software para llegar al mercado. No creo que haya sido
una decisión realmente consciente... fue más bien del desarrollador.
39
Traducido del inglés al español - www.onlinedoctranslator.com

El equipo dijo: "Está bien, bueno, si quieres cumplir con esas cosas, tendremos que
hacerlo de esta manera y eso es todo porque los plazos no se movían".
Los participantes de la entrevista proporcionaron una serie de ejemplos para ilustrar cómo las presiones del tiempo
influyó en la decisión de su equipo de asumir deuda técnica. El proyecto del S17 asumió aspectos técnicos.
deuda porque se habían comprometido a vender su sistema al cliente antes de su construcción;
en consecuencia, estaban obligados contractualmente a liberarse en un plazo ajustado. S04
El proyecto acumuló deuda técnica porque necesitaba entregar a tiempo para poder integrarse.
con otro producto. El proyecto de S06 decidió incurrir en deuda técnica porque necesitaban
entregar a tiempo para una próxima feria comercial que el marketing consideró que era una "gran
oportunidad” para la empresa. Los equipos de proyecto de S18 y S19 utilizaron deuda técnica para ayudar
entregarán su software en la primera semana de noviembre para coincidir con las dos semanas
período en el que sus clientes estaban en el mercado para comprar nuevo software. S19 dijo que si
su equipo de proyecto perdió esta ventana de dos semanas, es mejor que no lancen el producto
en absoluto porque habrían perdido por completo su mercado objetivo. Por último, técnico
La deuda permitió que el proyecto de S10 desarrollara un prototipo funcional del software para
asegurar la financiación de los inversores.
4.3.1.2 Cambio de prioridades
S19 comentó que su equipo de proyecto a veces incurría en deuda técnica como reacción a un
situación inesperada o a recibir nueva información del mercado. Comentó que incluso
Las decisiones de diseño que se tomaron con la mejor información disponible podrían convertirse rápidamente en
deuda técnica cuando el equipo del proyecto conoció y respondió a nueva información. T06
lo describió como
40

Tienes una especie de escenario en el que, con el tiempo, tus prioridades cambian y
necesitas, por cualquier motivo, obtener nueva información del mercado o lo que
sea, por lo que cierta información nueva ingresa al sistema y decides que necesitas
otros cambios en lo que pensabas. necesitabas o necesitas algo nuevo.
S07 comentó:
Pero también es que tomas una decisión, la haces lo mejor que puedes, ¿no? Usted
contrajo esta deuda y mira cómo va el mercado, ¿verdad? Como si estas cosas
cambiaran en un mes y luego tu deuda no sea tan mala como podría haber sido. Son
estos factores externos.
S08 proporcionó un ejemplo para ilustrar este escenario. En su ejemplo, S08 describió cómo su
El proyecto invirtió en el desarrollo de una aplicación de escritorio para su producto. sin embargo, el
El mercado cambió de dirección, pasando de las aplicaciones de escritorio a las aplicaciones basadas en web.
porque los departamentos de TI no querían que los usuarios instalaran software en sus computadoras para
razones de seguridad. En consecuencia, “…las características diferenciadoras [del escritorio
aplicación]…al principio sonaba como la fórmula ganadora para este producto, pero se convirtió
estar equivocado”. Fowler describió este tipo de deuda técnica como deuda prudente-inadvertida;
McConnell no incluyó este tipo de deuda en su taxonomía.
4.3.1.3 Objetivos poco claros
Varios participantes de la entrevista atribuyeron el hecho de incurrir en deuda técnica a tener ambos
partes interesadas internas y externas que no entendieron completamente los objetivos o
entregables del proyecto. S17 reflexionó que una de las razones por las que incurrió en su proyecto
La deuda técnica se debía a que tenía desarrolladores en su equipo que no entendían cómo
utilizar el software desde el punto de vista del cliente. En consecuencia, le resultó difícil
confiar en los miembros de su equipo para contribuir al proceso de toma de decisiones porque
no pudieron apreciar cómo sus decisiones de diseño podrían afectar a sus clientes. T06
41

hizo una observación similar y señaló que la deuda técnica se acumulaba porque “…tan
muchas cosas fueron lanzadas sin supervisión por personas que realmente no sabían
lo que estaban haciendo”. Parte del problema, como señaló S06 y estuvo de acuerdo S10, era que
algunos desarrolladores no entendieron la historia del proyecto: cómo evolucionó el software,
qué se ha construido y cuáles fueron las presiones en el momento en que se tomaron las decisiones.
Según sus experiencias, S11 creía que la falta de visión del producto contribuía a incurrir en
deuda técnica. Sintió que "es realmente difícil obtener información perfecta sobre lo que la gente
creen que quieren hoy, cierto, incluso si podría estar en la cabeza de alguien, es realmente difícil
traducir eso en un sistema y eso es difícil, pero es imposible saber dónde estás
Voy a querer estar dentro de cinco años”. Como resultado, S11 creyó que las razones de sus proyectos
La deuda técnica incurrida se debió a que el equipo del proyecto no tenía una hoja de ruta clara del producto.
y porque el equipo carecía de una estructura organizativa que designara a alguien para ser
responsable de supervisar el desarrollo del proyecto.
Además, varios participantes de la entrevista dijeron que incurrieron en deuda técnica porque
Los clientes a menudo no sabían qué necesitaban que hiciera el sistema. Por ejemplo, el S17
El equipo del proyecto estaba obligado contractualmente a crear una solución personalizada para un cliente.
Sin embargo, el cliente no estaba "increíblemente confuso" acerca de lo que quería que hiciera el sistema.
y siguieron cambiando de opinión hasta semanas antes del parto. De manera similar, S11 descubrió
que "no sabes cuáles son los requisitos reales hasta que los presentas al público".
cliente." Describió una situación en la que su equipo de proyecto gastó una cantidad significativa de
tiempo tratando de capturar los requisitos de un cliente que no tenía una idea clara de
42

sus expectativas para el sistema terminado. Lamentablemente, cuando se entregó el sistema,
el cliente lo rechazó porque no era lo que quería, a pesar de que el
El sistema cumplió con todos los requisitos. Tanto S10 como S15 descubrieron que los clientes necesitaban
jugar con el producto para saber lo que quieren; Como resultado, el proyecto de S10 y S15 incurrió en
deuda técnica para permitir que sus equipos de proyecto entreguen su producto temprano para solicitar
comentario.
4.3.2 Inexperiencia
Algunos de los participantes de la entrevista atribuyeron haber incurrido en actos no intencionados (inadvertidos-imprudentes)
deuda técnica por tener desarrolladores junior y estudiantes cooperativos en el equipo. S06, S10 y
S15 declaró que los desarrolladores sin experiencia en el equipo probablemente incurrirían en deuda técnica
porque, como comentó S06, "realmente no sabían la diferencia entre el bien
software y software malo…”. Explicaron que los desarrolladores junior requerían más tiempo.
y más supervisión para producir el mismo trabajo de calidad que otros miembros de la
Equipo de desarrollo. Sin embargo, debido a limitaciones de cronograma, el equipo de desarrollo a menudo no
no tener tiempo para ofrecer a los desarrolladores junior el nivel de soporte que necesitaban; como consecuencia,
sus resultados fueron más descuidados, lo que provocó una deuda técnica no intencionada.
S04 identificó que incurrió en una deuda técnica debido a la falta de familiaridad de su equipo de proyecto.
con la tecnología que estaban usando. En su ejemplo, S04 y su equipo fueron
No estoy familiarizado con el desarrollo de software para el sistema operativo Linux. ellos habian asumido
que el uso de Java, un lenguaje de desarrollo multiplataforma, permitiría que su aplicación
trabaje en sistemas operativos Windows y Linux sin esfuerzo adicional.
Además, decidieron priorizar la solución de problemas en el sistema operativo Windows.
43

porque el equipo estaba más familiarizado con el entorno y sería más fácil de apoyar.
Sin embargo, cuando S04 y su equipo comenzaron a probar su software en Linux, se dieron cuenta de que
Había muchas cuestiones fundamentales que habían pasado por alto, lo que hizo que apoyar a sus
software en Linux imposible. Como resultado, S04 y su equipo incurrieron involuntariamente
deuda técnica como resultado de su inexperiencia desarrollando para la plataforma Linux.
4.3.3 Actitudes
Las entrevistas también revelaron que las actitudes de los líderes técnicos y no técnicos de alto nivel
y los gerentes de proyecto tuvieron una fuerte influencia en la decisión del equipo del proyecto de incurrir
deuda técnica. Equipos que tenían liderazgo técnico y gestión que “acababan de obtener
Las actitudes "cosas hechas" tenían más probabilidades de incurrir en deuda técnica en comparación con los equipos que tenían
Líderes que estaban centrados en lo que el software debía hacer. Por ejemplo, S07 describió
una situación en la que la ingeniera de proyecto de su equipo estaba tan concentrada en fabricar el producto
la mejor oferta del mercado, lo que impulsó al equipo a desarrollar funciones de forma rápida pero igual de
Los abandonó rápidamente cuando la respuesta del cliente fue pobre, para pasar a
algo más. Desafortunadamente, esto resultó en una serie de casas abandonadas y a medio terminar.
características que se convirtieron en un problema de mantenimiento para el equipo de desarrollo. S06 tenía similar
experiencias cuando su liderazgo técnico decidió crear tres productos con el mismo
código fuente en tres ramas de código diferentes. Incurrir significativamente en esta deuda técnica
aumentó los gastos generales de mantenimiento de su equipo porque cada vez que solucionaban un problema,
necesario para fusionar los cambios en tres ramas de código, realizar tres revisiones de código y probar
tres bases de código. Por otro lado, S11 consideró que su equipo de proyecto incurrió en deuda técnica.
porque permitieron que sus prioridades fueran impulsadas por su cliente más importante, quien favorecía
desarrollar nuevas funciones en lugar de corregir errores.
44

S12 también observó que tener "programadores deshonestos" en el equipo era una fuente de problemas técnicos.
deuda. Describió a estos desarrolladores como "personas inteligentes que saldrían y harían cosas en
los suyos sin siquiera salir a la superficie para registrarse con el resto del equipo”. Asimismo, S07
explicó cómo el objetivo del equipo directivo de su empresa es retener a los mejores talentos creando
Proyectos paralelos para que los desarrolladores puedan experimentar con nuevas tecnologías y lenguajes.
El resultado final fue una arquitectura "Frankenstein" para el producto estrella de la empresa.
También descubrió que, como resultado de la baja tasa de rotación de la empresa, los equipos del proyecto
incurrió en deuda técnica porque había una menor necesidad de documentar las decisiones de diseño y
hacer cumplir los procesos ya que hubo una mínima transferencia de conocimientos a los nuevos empleados.
4.3.4 Era del software
Algunos de los participantes de la entrevista describieron un tipo de deuda técnica causada por
Envejecimiento y evolución del software. Como comentó S11:
Y encuentro que incluso si su arquitectura es realmente buena, después de 10 años, ya no es
tan buena porque ha tenido tantas características nuevas que simplemente no conocía el día
1 y, por lo tanto, si no hace un esfuerzo continuo en la construcción... después de un tiempo,
comienza, la arquitectura antigua, incluso si es genial, comienza a crujir bajo su propio peso...
Una razón, señaló S11, es que los sistemas generalmente se diseñan basándose en lo que se
posible construir en el momento en que se especificaron los requisitos. Explicó que es
Es difícil para el equipo del proyecto predecir cómo crecerá el sistema y tener en cuenta esto.
crecimiento porque no tienen visión del futuro. Además, S11 señaló que
"Si lo diseñas [el software] para todo lo que puedas imaginar el día 1, tendrías
alguna enorme bestia de arquitectura que estaría 80% equivocada porque el 80% sería
dirigido a funciones que nunca crearás”.
45

Otra razón es que la tecnología utilizada se vuelve obsoleta, como explicó S12:
Y para mí, un ejemplo de deuda técnica es que con el tiempo, las tecnologías
gradualmente se vuelven obsoletas o reemplazadas por otras cosas y, con el tiempo, se
acumula una deuda técnica que implica el uso de cosas que ahora son una especie de
tecnologías heredadas... No veo ninguna manera de evitarlo...
S12 describió un proyecto en el que trabajó y en el que el equipo del proyecto había tomado una decisión.
muchos años antes para utilizar una tecnología de comunicación entre procesos que, actualmente, es antigua.
Reconoció que la deuda técnica estaba en la tecnología misma, porque hay
Ahora hay disponibles tecnologías de comunicación mejores y más nuevas que son más familiares para
todos en el equipo de desarrollo y más fácil de mantener. Sin embargo, S12 explicó
que reemplazar la tecnología era costoso porque requeriría cambios a nivel
nivel de infraestructura del sistema y porque se utiliza en todas partes. Sin embargo, en algunos
En este punto, añadió S13, el equipo del proyecto no tendrá más remedio que actualizar la tecnología.
porque ya no será compatible con las plataformas informáticas disponibles.
4.4 Síntomas
Este estudio también tuvo como objetivo capturar las impresiones de los participantes de la entrevista sobre cómo
La deuda técnica impactó sus proyectos. Sus respuestas revelaron que, en gran medida,
La deuda técnica impactó negativamente los proyectos de software, causando inestabilidad, mantenimiento y
problemas de rendimiento y compromisos. Sin embargo, la deuda técnica también tuvo un importante
impacto positivo en sus proyectos al permitir que sus equipos de desarrollo entreguen sus
producto rápidamente al mercado para alcanzar sus objetivos comerciales.
46

4.4.1 Mala calidad
Todos los participantes de la entrevista afirmaron que el resultado de incurrir en deuda técnica fue
mala calidad, incluyendo mayor complejidad, bajo rendimiento, baja mantenibilidad y
Código frágil. En consecuencia, la mala calidad creó un "dolor" a largo plazo para los desarrolladores.
S08 describió la situación como "lo que terminaste con un código arcano, diría yo,
muy anticuado, difícil de mantener, frágil, fácil de romper y los insectos caerían
a través de ”eso dejó solo un pequeño número de desarrolladores que pudieron mantener el código.
Por lo tanto, como señaló S10, para algunos ingenieros era estresante trabajar con una empresa cargada de deudas.
base de código.
Algunos de los participantes de la entrevista describieron cómo la deuda técnica también infligía “dolor” a
sus clientes. En particular, la deuda técnica a menudo impactaba el rendimiento, la confiabilidad y
estabilidad del producto, creando malas percepciones del cliente y haciéndolos infelices
y enojado. En el caso de S11, el cliente estaba tan molesto con el producto que la empresa de S11
no sólo corría el riesgo de perder a su cliente, sino que también era demandado por el cliente por no cumplir
cumplir lo que se les prometió. Algunos participantes reflexionaron que tener deuda técnica
aumentó la cantidad de esfuerzo y costo requerido para apoyar a sus clientes, especialmente
porque era menos eficiente y más costoso abordar los problemas técnicos de deuda encontrados en un
sitio del cliente.
Cuando los participantes de la entrevista incurrieron en deuda técnica, comprometieron la calidad
de su software de diferentes maneras. Por ejemplo, el equipo del proyecto S18 redujo el alcance de
su solución entregada para admitir solo un subconjunto de funcionalidades. S03 decidió implementar
47

un "truco" para solucionar una limitación en Java Runtime Environment (JRE) para poder
implementar una nueva característica que podría detectar si el usuario estaba fuera de los límites del
solicitud. Sin embargo, el “truco” impidió que el control de calidad (QA) pudiera
verificar la solución de S03 utilizando escenarios de prueba que reflejaran la interacción normal y diaria del usuario (control de calidad).
sólo pudo verificar la solución poniendo el mouse boca abajo sobre la mesa). Ambos S06
y los proyectos de S15 se relajaron en la aplicación de procesos de desarrollo de software, como por adelantado
diseño y revisiones de código y diseño. Como lo explicó S06:
…ellos [ingeniería] terminaron llegando a un punto en el que no se iba a hacer a
tiempo, por lo que básicamente comenzaron a tener que tomar atajos solo para
que las cosas funcionaran. Entonces, ya sea que fuera una buena solución o algo
que fuera escalable o algo que probablemente se ampliara, simplemente se
descartó por completo, el diseño no necesariamente se siguió y luego... tenía esta
cosa que de alguna manera funcionó. Al final del día e hizo muchas de las cosas que
los requisitos no oficiales decían que debía hacer, pero lo hizo de tal manera que
ponerlo en manos de usuarios reales en escenarios reales resultó ser muy
deficiente.
Por lo tanto, el equipo del proyecto S06 terminó lanzando al mercado un producto que no funcionaba de manera confiable.
para los clientes y dio como resultado una base de código que era un híbrido de código antiguo y frágil que el
Los desarrolladores tenían miedo de trabajar con un código nuevo que no funcionaba el 100% del tiempo.
4.4.2 Incertidumbre
Varios participantes de la entrevista describieron cómo la deuda técnica impactó la estabilidad del sistema y
provocó un comportamiento inesperado. S08 proporcionó un ejemplo de una aplicación que su proyecto
Equipo construido cuya arquitectura original no fue diseñada para soportar su estado actual.
Desafortunadamente, la alta dirección no pudo encontrar la justificación para invertir en reescribir el
aplicación, dejándola en un estado donde “la mayoría de las cosas funcionarían pero algún cliente
Pruebe algo extraño en una nueva versión y no funcionará”.
48

La deuda técnica también creó incertidumbre para los desarrolladores que realizaban cambios en el código base.
S06 explicó cómo la deuda técnica de su proyecto creó una serie de dependencias implícitas.
en el código. Con el tiempo, su equipo se puso nervioso acerca de realizar cambios en el código para solucionar
errores porque no estaban seguros de si sus cambios causarían problemas adicionales en el
sistema: "... la cantidad de tiempo que tomó solucionar cualquier problema conocido estaba aumentando, no lo haría
decir exponencial, pero tenía esa sensación de que cada vez... temías que cada vez que
Si hicieras un cambio, causarías que algo más saliera mal”. Además, su
La gerencia comenzó a perder confianza en las correcciones de errores del código, especialmente con el tiempo.
presiones, porque tenían miedo de que las soluciones causaran problemas que no serían
detectado por control de calidad antes de que el software fuera entregado al cliente.
Para S11, tener deuda técnica dificultó que su equipo de proyecto realizara un trabajo preciso.
estimados. Encontró que la deuda técnica distorsionaba las estimaciones de trabajo de dos maneras. En primer lugar, el
La complejidad añadida introducida por la deuda técnica significó que llevara más tiempo desarrollar nuevos
características o corregir errores. En segundo lugar, la mayor responsabilidad del cliente como resultado de tener
La deuda técnica significó que el equipo de desarrollo dedicó más tiempo a atender las llamadas de los clientes y
solucionar problemas de los clientes, especialmente si se les pedía que visitaran el sitio de un cliente. Así, cuando
una característica o corrección de error excedió su estimación de trabajo, S11 nunca podría estar seguro si el trabajo tomó
más tiempo debido a la complejidad imprevista de la característica o debido a la
complejidad de la deuda técnica.
4.4.3 Entrega al mercado rápidamente
Cuando se les preguntó si valía la pena incurrir en deuda técnica, la mayoría de los participantes de la entrevista
Expresó que fue porque permitió a su equipo de proyecto entregar software al mercado.
49

rápidamente. S08 consideró que incurrir en deuda técnica le permitió a su equipo de proyecto ganar una enorme
rincón del mercado. El equipo del proyecto S10 contrajo deuda técnica por razones similares: su
El equipo del proyecto lanzó un producto pionero en el mercado y quería superar a sus competidores.
Además, el equipo del proyecto S10 quería lanzar su software al mercado rápidamente para poder
podría recopilar comentarios de los clientes antes. Esto fue particularmente importante para el proyecto del S10.
equipo porque no estaban muy familiarizados con su dominio; así podrían aprender lo que
sus clientes realmente querían y cómo planeaban usar el software, permitiéndoles
dirigen su atención sobre qué construir a continuación y dónde mejorar primero. Asimismo, S18 afirmó
que asumir deuda técnica para entregar al mercado rápidamente ayudó a su equipo a evitar gastar
demasiado tiempo en áreas del sistema que no aportaban valor empresarial.
Sin embargo, algunos de los participantes de la entrevista sintieron que parte de la deuda técnica que tenían
Los costos incurridos para entregar su software rápidamente al mercado no fueron necesarios. S11 comentó:
…las cosas que estábamos haciendo no van a impulsar las ventas durante un año
más, por lo que pasar otra semana reforzándolo podría haber sido lo correcto, pero
siempre estuvimos tan concentrados en Quiero sacar este lanzamiento esta semana
o este mes... Y también miré las funciones que habíamos desarrollado... y las
teníamos a medio hacer... y estaban bastante bien, pero nadie las usó porque no
eran excelentes y, de hecho, no lo eran. Los necesito mucho de todos modos”.
S06 tuvo las mismas opiniones que S11. Consideró que su proyecto asumía innecesariamente cargas técnicas.
deuda para cumplir con los estrictos plazos de entrega marcados por marketing; sin embargo, “la gente
No estábamos derribando nuestras puertas para este producto, por lo que realmente hubo que presionar a la gente para que
Cómpralo." Además, su equipo de proyecto pasó seis meses después del lanzamiento del producto para
cree un paquete de servicio que rediseñó y corrigió muchas características del producto. Así, como
Como señaló S06, incurrir en deuda técnica no valía la pena para el éxito del proyecto.
producto; en cambio, S06 creía que si el lanzamiento se había retrasado, el equipo de desarrollo
50

podría haber tenido más tiempo para desarrollar el producto y marketing podría haber gastado más
tiempo para generar interés en el mercado.
4.5 Gestión
La mayoría de las respuestas a la pregunta de cómo los participantes de la entrevista gestionan los aspectos técnicos.
deuda en sus proyectos implicaba alguna forma de comunicación, tanto externa como con
clientes, marketing y gestión e internamente, dentro del equipo de desarrollo.
Sin embargo, varios participantes de la entrevista sugirieron que no hacer nada también era una estrategia
a la gestión de la deuda técnica. Sintieron que era mejor esperar pasivamente a que llegara el cliente.
retroalimentación en lugar de ser proactivo en el pago de la deuda técnica. Su razón es porque
el producto no gana ningún valor al pagar la deuda técnica que no causó
problemas para el cliente en primer lugar. Además, también señalaron que
esperar los comentarios de los clientes ayudó al equipo del proyecto a evitar reducir el tipo incorrecto de
deuda o adoptar un enfoque equivocado para reducirla. Sin embargo, las entrevistas también
capturó algunos enfoques más proactivos para gestionar la deuda técnica, incluido el análisis
riesgos, gestión de expectativas y documentación.
4.5.1 Riesgos
Una sugerencia de los participantes de la entrevista para gestionar la deuda técnica fue gestionar
como riesgos del proyecto. El equipo de S10 priorizó su lista de deudas técnicas para pagar antes
comparando la prioridad, valor, costo y riesgo de cada partida de deuda. Partidas de deuda técnica con
alto riesgo y bajo costo fueron rechazados, y las partidas de deuda con alto costo y bajo riesgo fueron
abordado inmediatamente. Otras partidas de deuda intermedias se evaluaron frente a otros factores,
como cuellos de botella, solicitudes de clientes y planes a largo plazo para el producto. S11 dio un
51

ejemplo de un líder de equipo en su equipo de proyecto que vio las solicitudes de funciones también como una
oportunidad de abordar la deuda técnica en la misma área del código. Así, el líder del equipo
incluiría tiempo extra en sus estimaciones de trabajo para el largometraje, porque “…el exterior
El mundo no sabe si esta función debería tardar 20 días o 10 días, así que si tardas 20 días
y refactorizarlo, nadie externo tiene que saberlo…” Por otro lado, S06 y S15 negociaron
con la gerencia para convencerlos de asignar entre el 5% y el 10% del esfuerzo y costo total de cada
liberación para pagar su deuda técnica.
S06 descubrió que monitorear activamente los cambios de código que se registraron en el control de fuente
También ayudó a limitar la cantidad de deuda técnica no intencional o innecesaria introducida en
el código fuente. De manera similar, S15 y S18 hicieron cumplir los procesos y estándares de calidad del software.
en su equipo de desarrollo como una forma de mitigar los riesgos de deuda técnica.
Por último, S17 creía que construir un equipo que compartiera su filosofía y actitud hacia
La deuda técnica le ayudó a gestionar la deuda técnica de su proyecto. Así, hizo algunas claves
contrataciones que trajeron nuevas influencias para cambiar y mejorar la perspectiva del equipo sobre
incurrir estratégicamente en deuda técnica dedicando más tiempo a la planificación y
diseño.
4.5.2 Expectativas
Otro enfoque para gestionar la deuda técnica que siguieron los S15, S16 y S18 fue
Gestionar las expectativas de los clientes haciéndoles conscientes de que existía deuda técnica en sus cuentas.
proyectos. S16 acuñó el enfoque como “promesa insuficiente, entrega excesiva”. Para S15, esto
incluyó exponer todos los problemas técnicos de deuda en el software al cliente porque
52

S15 consideró que "todos somos socios iguales a la hora de crear un desastre, por lo que tenemos que ser socios iguales a la hora de crear un desastre".
limpiándolo”. Tanto S15 como S16 mantuvieron un diálogo abierto con sus clientes al
destacando la existencia de deuda técnica sobre el proyecto y su impacto en el coste futuro del mismo.
implementar nuevas características si no se asigna tiempo para abordarlas. De manera similar, S18 trajo
visibilidad al describir la deuda técnica a las partes interesadas no técnicas como los riesgos que
enfrentarían al tratar de cumplir con sus entregables. Este enfoque se benefició al poner
deuda técnica en un contexto que las partes interesadas no técnicas entendieran y al que
podría relacionarse fácilmente.
4.5.3 Comunicación
El enfoque más común para gestionar la deuda técnica fue comunicar su presencia
a través de documentación. S03 y S18 utilizaron comentarios en línea y TODO para marcar el
lugares donde se incurrió en deuda técnica en el código. El equipo del proyecto S19 realizó un seguimiento de todo
de la deuda técnica de su proyecto en una página Wiki a la que pueden acceder todos los miembros del equipo.
S15 rastreó la deuda técnica de su equipo como elementos de su sistema de seguimiento de errores.
Además, muchos de los participantes de la entrevista documentaron la deuda técnica en sus
proyecto organizando una sesión de lluvia de ideas con todos los desarrolladores al final de cada
liberar. En la sesión de lluvia de ideas, se preguntó a los desarrolladores: "¿Si había cosas que
podrías rehacer en el software, ¿cuál sería?” Cada una de las áreas de código que fueron
identificados durante la sesión de lluvia de ideas se registraron y rastrearon como deuda técnica.
Este enfoque tiene varios beneficios. En primer lugar, destacó rápidamente las áreas clave en
el código donde se debe abordar la deuda técnica en función de la frecuencia con la que esa parte del código
es mencionado por los desarrolladores. En segundo lugar, aprovechó las ideas del
53

desarrolladores, que trabajan con el código diariamente, para identificar deuda técnica en el sistema. Por último,
Este enfoque no sólo recordaba constantemente al equipo de desarrollo que la deuda técnica
existió, pero también hizo que los desarrolladores fueran muy conscientes de la cantidad de deuda técnica en el
sistema.
4.6 Conclusión
Las entrevistas realizadas con diecinueve profesionales de la industria del software revelaron que
La deuda técnica no es un concepto nuevo para ellos, sino algo con lo que están familiarizados y
trabajar a diario. En general, los entrevistados describieron la deuda técnica como
“compensaciones” y “atajos”. La mayoría de los casos de deuda técnica en un proyecto se incurrieron como
un resultado de la realidad empresarial (cumplir con las limitaciones de presupuesto y cronograma) pero otros factores,
como la familiaridad con los objetivos del proyecto, la experiencia y la antigüedad del software también influyeron.
El impacto de la deuda técnica, tal como lo describieron los participantes de la entrevista, fue en gran medida
negativo y doloroso, que afecta el rendimiento, la estabilidad y la calidad general del software.
Sin embargo, los participantes también reconocieron que incurrir en deuda técnica valía la pena.
dolor porque ayudó a sus equipos de proyecto a entregar su software al mercado rápidamente. Finalmente,
Todos los participantes de la entrevista señalaron que la clave para gestionar la deuda técnica en un
proyecto de software es comunicación: dar constantemente visibilidad a la existencia de
deuda técnica y sensibilizar a las partes interesadas, tanto técnicas como no técnicas, sobre la
consecuencias de trasladar la deuda técnica a la siguiente versión.
54

CAPÍTULO 5
ESTUDIO DEL JUEGO – “DECISIONES DIFÍCILES”
El propósito del estudio del juego es validar los hallazgos del estudio de la entrevista mediante
Investigar cómo los profesionales del software caracterizan y gestionan la deuda técnica a través de
Como se Juega. El juego es una técnica de aprendizaje que los entrenadores ágiles suelen emplear para enseñar.
nuevos conceptos. Es una herramienta de enseñanza interactiva y divertida que brinda a los estudiantes la oportunidad
participar activamente en la obtención de conocimientos y experiencia práctica a partir de la aplicación de los conceptos
ser enseñado a situaciones simuladas. A veces, el juego puede ser un medio más eficaz de
entregar ideas en lugar de los métodos tradicionales de dar conferencias y leer libros.
Trabajé con investigadores en Comunicando los beneficios de la arquitectura dentro de Agile.
Proyecto de desarrollo en el Software Engineering Institute (SEI) de Carnegie Mellon
Universidad de Pittsburgh, PA, para desarrollar un juego de mesa en torno a los conceptos técnicos
deuda, denominada “decisiones difíciles” [52]. El objetivo del juego de mesa es ayudar a los jugadores a reconocer,
e identificar estrategias para gestionar la deuda técnica a lo largo del desarrollo de software.
proceso [53]. Este capítulo describe el juego de mesa “Decisiones difíciles”, las metodologías
que se llevaron a cabo para realizar este estudio y los resultados derivados de las discusiones que
se generaron después de jugar el juego con varios grupos de practicantes de software.
5.1 Tablero de juego
En enero de 2010, asistimos a un taller de un día sobre “Creación de juegos de aprendizaje ágiles” impartido por
Chris Sims de Agile Learning Labs [54] para aprender sobre el proceso de creación de juegos y
55

Piense en ideas para juegos. En el taller nos encontramos con el juego de mesa “Short Cut”.
por Quality Tree Software, Inc. [55]. Dado que el juego de mesa “Atajo” contenía muchos de
Los elementos de diseño del juego que queríamos para nuestro juego de mesa de deuda técnica, decidimos
mejorar y ampliar el juego de “Atajos” para crear “Decisiones difíciles”. El diseño del juego.
elementos que utilizamos para comunicar los conceptos sobre la deuda técnica en “Hard
Opciones” se muestran en la Tabla 4:
Concepto de deuda técnica Elemento de diseño del juego
Riesgo, incertidumbre Oportunidad, vueltas
Compensaciones Estrategia, Elección, Desequilibrio, Conocimiento
Impacto Competición, Finalización, Ganar, Puntuación
Tabla 4: Mapeo del concepto de deuda técnica con los elementos de diseño del juego
El tablero de juego (ver Apéndice C) consta de un camino sinuoso desde “INICIO” hasta “FIN”;
el camino es una metáfora del ciclo de lanzamiento del desarrollo de software. Ciertas plazas a lo largo
El camino está marcado con símbolos para representar las decisiones que el equipo de desarrollo debe tomar.
hacer durante el lanzamiento, como se muestra en la Tabla 5:
Símbolo Nombre Acción
Decisiones difíciles Punto de decisión: los jugadores deben decidir si tomar un atajo
(es decir, cruzar el puente) para terminar el juego más rápido, pero
incurrir en una penalización, o continuar y avanzar lentamente a
través del juego.
Puente Atajo: los jugadores que cruzan el puente recogen una carta de
"Puente". El puente representa un atajo o una decisión de
compensación, que permite a los jugadores terminar más rápido.
La carta "Puente" conlleva una penalización: los jugadores deben
restar 1 de cada tirada de dados posterior. Los jugadores pueden
deshacerse de sus cartas "Puente" saltándose un turno en el
futuro.
56

Símbolo Nombre Acción
Herramienta Diseño/Arquitectura: Los jugadores que aterrizan en una herramienta
recogen una tarjeta de "Herramienta". Las herramientas representan una
decisión de dedicar tiempo a implementar un buen diseño/arquitectura. La
tarjeta "Herramienta" tiene una recompensa: los jugadores reciben 1 punto
por cada tarjeta "Herramienta" que recolectan. Los jugadores pueden
intercambiar su carta "Herramienta" por un turno gratis.
Tabla 5: Símbolos de ruta de “decisiones difíciles”
El objetivo del juego es cruzar el cuadrado “FIN”, que equivale al final de una
ciclo de lanzamiento de software, con el mayor número de puntos. Además de ganar puntos por
Al recolectar tarjetas de "Herramientas", los jugadores obtienen puntos extra por cruzar la línea de meta primero (es decir,
siendo el primero en lanzar el software al mercado).
5.2 Reglas
“Hard Choices” está diseñado para dos a cuatro jugadores. Para jugar, el jugador lanza una
dados para determinar el número de casillas que avanza (un jugador puede moverse en cualquier dirección
y/o cambiar de dirección). Con cada tirada de dados, el jugador debe tomar decisiones sobre
si moverse o no en una determinada dirección, cruzar un puente, aterrizar sobre una herramienta, saltarse un giro para
deshazte de una carta de "Puente" o cambia una carta de "Herramienta" por un turno gratis adicional para cruzar
el “FIN” con mayor número de puntos. Cada elección que hace el jugador tiene
beneficios y consecuencias. Por ejemplo, el beneficio de cruzar un puente es que el jugador
puede llegar al cuadro "FIN" más rápido, lo que podría ayudarle a ganar puntos extra.
Sin embargo, la consecuencia de cruzar un puente es que el jugador debe restar 1 a
cada tirada de dados posterior, lo que podría resultar en una desaceleración de su progreso hacia la
Cuadrado “FIN”. Asimismo, desplazarse por el camino con el objetivo de aterrizar sobre una herramienta tiene la
57

beneficio de acumular un punto, pero conlleva la consecuencia de un progreso más lento hacia la
Cuadrado “FIN”. La decisión del jugador en cada tirada de dados depende de su posición actual en
el tablero, la posición de los demás jugadores en el tablero y su estrategia de juego.
Cuando termine la primera ronda de “Decisiones difíciles” (es decir, todos los jugadores hayan alcanzado la meta).
casilla “FIN”), se informa a los jugadores que deberán jugar una segunda ronda. El
El propósito de la segunda ronda, que representa el segundo lanzamiento de un producto de software, es
para ayudar a los jugadores a apreciar el impacto de las decisiones que tomaron en la ronda anterior,
o liberación. En la segunda ronda, los jugadores conservan todas las cartas de “Puente” y “Herramienta” que
recogieron en la primera ronda del juego. Además, las tarjetas "Game Changer" son
introducido en la ronda para imitar los cambios repentinos en los objetivos comerciales o en los clientes.
demandas que pueden ocurrir durante el desarrollo del producto. Las tarjetas “Game Changer” pueden afectar
la valoración de las cartas “Puente” y “Herramienta” e introducir elementos adicionales de
aleatoriedad e incertidumbre en el juego, por ejemplo:
• Por cada carta “Saw”, +1 a la tirada de dados;
• Por cada carta de “Puente”, -2 a la tirada de dados;
• Los jugadores pueden devolver una carta "Puente" por cada carta "Martillo" que hayan
propio.
• Los jugadores pueden cruzar un puente por cada carta "Destornillador" que posean.
sin incurrir en penalización.
Se juegan múltiples rondas de “Decisiones difíciles” hasta que los jugadores sienten que pueden
comprender los conceptos de gestión de riesgos, incertidumbre, opciones y el impacto de llevar
58

deuda técnica durante el desarrollo de software. Generalmente, se realizan dos rondas del juego.
suficiente para que los jugadores comprendan los objetivos de "Decisiones difíciles".
5.3 Metodología
Este estudio de juego se basa en los hallazgos que recopilé en tres sesiones de juego en
a la que asistí, como se enumera en la Tabla 6:
Sesión Ubicación Número de
Participantes
Mi papel
Reunión ágil de Vancouver Vancouver, Columbia Británica,
Canadá
15 Organizador y
Facilitador
Desarrollo ágil y
Arquitectura de software:
Evento de juegos Hard Choices
en la Conferencia SATURN
Minneapolis, Minnesota,
Estados Unidos
dieciséis Taller
Partícipe
Reunión “Dev-Squared” en
Aquatic Informatics, Inc.
Vancouver, Columbia Británica,
Canadá
15 Organizador y
Facilitador
Tabla 6: Información sobre las sesiones de “Decisiones difíciles”
Aunque este estudio sólo se basa en las tres sesiones a las que asistí, las “Decisiones difíciles”
El juego de mesa ha sido jugado por más de cien personas en varias conferencias,
reuniones, talleres y aulas dirigidas por miembros de Comunicando los Beneficios
del equipo de proyecto de Arquitectura dentro de Agile Development.
El estudio del juego brindó la oportunidad de explorar cómo los participantes ven y gestionan
deuda técnica en un entorno uniforme. En este estudio, todos los participantes compartieron la
mismas experiencias de aprendizaje sobre deuda técnica jugando “Decisiones difíciles”,
independientemente de su familiaridad con el tema. Posteriormente, esto proporcionó a todos
el mismo contexto en el que basarse durante las discusiones cuando se les pidió que compartieran sus
lecciones aprendidas. Además, el juego permitió examinar las opiniones de los participantes.
59

proceso de toma de decisiones a lo largo de un ciclo de desarrollo de software en un formato muy comprimido
cantidad de tiempo. Los participantes en el estudio jugaron dos rondas del juego para capturar
cómo las decisiones que tomaron en la ronda anterior afectaron sus decisiones en la actual
situación; cada ronda duró aproximadamente veinte minutos.
5.3.2 Recopilación de datos
Se invitó a los participantes a asistir a las sesiones de juego “Decisiones difíciles” por correo electrónico.
enviado a la lista de correo de la organización y, en el caso de la conferencia SATURN, a través de
boca a boca. Entre los participantes que asistieron a las sesiones se encontraban desarrolladores de software,
analistas de negocios, arquitectos de software, ingenieros de requisitos y gerentes de proyectos.
Antes de que comenzara el juego, los participantes recibieron una breve presentación de cinco minutos que
Definió brevemente el concepto de deuda técnica y explicó las reglas del juego. Entonces el
Los participantes fueron divididos aleatoriamente en grupos de tres o cuatro jugadores y se les entregó el tablero.
Juego, piezas del juego y reglas del juego. Mientras los grupos tocaban “Hard Choices”, yo estaba
disponible como facilitador para responder cualquier pregunta que surgiera. Cuando cada grupo terminó el
primera ronda del juego, pedí a los grupos que esperaran hasta que todos en la sala terminaran
jugando. La Figura 3 es una fotografía de los participantes jugando “Decisiones difíciles”, tomada de uno de los
sesiones de juego:
60

Figura 3: Jugar al juego de mesa “Decisiones difíciles”
Cuando todos los grupos completaron la primera ronda, presenté las tarjetas "Game Changer" y
Les dijo a los grupos que jugaran la segunda ronda. Después de la segunda ronda, dirigí a los participantes en una sesión informativa.
sesión para discutir lo que los jugadores aprendieron al jugar “Decisiones difíciles”, incluyendo
estrategias y cómo los elementos del juego se relacionan con el concepto de deuda técnica.
Además, también pedí a los participantes que me proporcionaran comentarios sobre el juego y
sugerencias sobre cómo se podría mejorar el juego.
Durante la sesión informativa, tomé notas sobre las ideas y comentarios de los participantes.
compartido. Inmediatamente después del final de la sesión, complementé las notas con información adicional.
observaciones y comentarios que había escuchado durante el juego. Estas notas fueron
61

compartido a través de correo electrónico con los miembros del grupo Comunicando los Beneficios de
Arquitectura dentro del equipo del proyecto Agile Development.
5.3.3 Análisis de datos
Los datos de las sesiones de juego "Decisiones difíciles" también se analizaron utilizando contenido
análisis. A diferencia del estudio de entrevistas, el estudio de juegos no tenía códigos preestablecidos. El
Los datos del juego se codificaron utilizando codificación abierta para identificar códigos emergentes. La codificación axial fue
aplicados para desarrollar categorías a partir de los códigos emergentes. Luego, los códigos del juego fueron
comparado con los códigos de la entrevista para encontrar similitudes y diferencias y extraer temas.
La lista de códigos para el estudio del juego se muestra en la Tabla 7:
Códigos Subcódigos
Riesgos calculados Oportunidades
Desventajas
Adaptabilidad
Suerte
Tabla 7: Códigos del análisis de datos de la entrevista
Todos los códigos se derivaron de palabras utilizadas frecuentemente por los participantes en sus
retroalimentación durante las sesiones informativas. El código “Riesgos Calculados” describe el
el proceso de los participantes al evaluar sus opciones para su próximo paso. Los resultados de
sus decisiones generalmente se clasifican en dos grupos:oportunidadesydesventajas. El
Los participantes señalaron que algunas decisiones ayudaron a crear oportunidades que permitieron
avanzar rápidamente y contribuir a ayudarles a ganar el juego, mientras que otros
Las decisiones crearon inconvenientes que tendieron a frenar su capacidad para avanzar.
El código “Adaptabilidad” refleja un atributo que los participantes consideraron necesario
tener éxito jugando “Decisiones difíciles”. Muchos de los participantes creían que tener la
flexibilidad para cambiar su estrategia mientras jugaban dada su situación actual era
62

un elemento importante para ganar el juego. Por último, el código “Suerte” deriva del
observación de los participantes de que el azar fue un factor en su resultado en “Decisiones difíciles”.
5.4 Hallazgos
La siguiente sección resume los hallazgos de la retroalimentación proporcionada por los participantes.
después de una sesión de juego de “Decisiones difíciles”. Los hallazgos están organizados por
códigos definidos en el apartado anterior.
5.4.1 Riesgos calculados
Varios participantes reconocieron que la clave para gestionar con éxito sus conocimientos técnicos
la deuda estaba asumiendo riesgos calculados. Los participantes encontraron que decidir sobre el tipo de riesgo a tomar
y cuándo asumir el riesgo, evaluando el resultado y respondiendo a cómo otros
Los jugadores jugados contribuyeron a su éxito en el juego.
5.4.1.1 Oportunidades
Los participantes descubrieron una serie de estrategias para incurrir en deuda técnica que crearon
oportunidades para que puedan adelantarse a los demás jugadores en el juego. Algunos jugadores encontrados
que una estrategia exitosa era cruzar muchos puentes al comienzo del juego para conseguir
por delante de los demás jugadores. Cuando hubo suficiente distancia entre ellos y el otro.
jugadores, comenzaron a jugar la deuda saltándose turnos porque tenían suficiente tiempo
para pagar sus deudas antes de que los otros jugadores los alcancen. Un número de participantes
desarrolló la estrategia de cruzar puentes sólo a medida que se acercaban al “FIN”. Ellos sintieron
que podían permitirse el lujo de correr más riesgos hacia el final del juego porque no era tan
Para ellos era importante saber cuántos puentes les quedaban mientras pudieran cruzar el
63

línea de meta primero. Un participante incluso observó que si hubiera dos puentes cerca
juntos, valió la pena cruzar ambos puentes porque lo puso mucho más por delante del resto.
otros jugadores. Por otro lado, otros jugadores descubrieron que para seguir moviéndose
adelante en el juego, era más beneficioso saltarse un turno para pagar parte de su deuda
en lugar de perder un turno porque habían acumulado demasiada deuda. Algunos también encontraron
que podrían aprovechar las herramientas que recopilaron para ayudarlos a seguir adelante porque
podrían cambiar sus herramientas por un turno extra.
De hecho, todos los participantes se dieron cuenta al final del juego de que tomar puentes era
inevitable. Una participante hizo un comentario interesante sobre su estrategia con respecto
a tomar puentes. Su estrategia inicial fue jugar el juego con cautela, por lo que evitó
cruzando cualquier puente mientras avanzaba hacia la casilla "FIN" en el tablero de juego.
Sin embargo, cuando vio que se estaba alejando cada vez más de los otros jugadores,
se dio cuenta de que necesitaba cruzar más puentes para alcanzar a los demás
jugadores en el juego.
Curiosamente, los analistas de negocios y los gerentes de proyectos (es decir, partes interesadas no técnicas)
parecían jugar el juego de manera más agresiva que los desarrolladores y evaluadores (es decir, técnicos
partes interesadas). En particular, los analistas de negocios y gerentes de proyectos tendieron a cruzar puentes
siempre que pudieron, especialmente en la primera ronda. Por otro lado, los desarrolladores y
Los evaluadores dudaron a la hora de cruzar puentes y prefirieron seguir el camino del juego y
recoger herramientas. Sin embargo, ambos grupos se dieron cuenta en la segunda ronda de que habían movido el
64

más rápido en el juego cuando pudieron encontrar un equilibrio entre cruzar puentes,
recogiendo herramientas y saltándose un turno para devolver un puente.
5.4.1.2 Inconvenientes
Asimismo, los participantes también descubrieron estrategias que fueron perjudiciales para su éxito en
cruzando la línea de meta. Por ejemplo, uno de los jugadores había jugado agresivamente, cruzando
todos los puentes en la primera ronda para acumular los puntos extra recompensados por cruzar
primero el cuadro “FIN”. Otro jugador en el mismo juego jugó mucho más
juego conservador, evitando puentes y recogiendo herramientas y, en última instancia, terminando último en
la primera ronda. Sin embargo, cuando comenzó la segunda ronda, el jugador agresivo de repente
descubrió que no podía avanzar tan rápido en el juego porque todos los obstáculos lo retenían.
la deuda que había acumulado desde la primera vuelta. Al final, el jugador conservador,
aunque se movió más lentamente en la primera ronda, terminó la segunda ronda más rápido,
acumuló puntos extra y ganó el juego.
5.4.2 Adaptabilidad
A lo largo del juego, los participantes reconocieron que necesitaban adaptar su estrategia.
dependiendo del contexto actual del juego. Algunos participantes observaron que sus
La estrategia dependía de la ubicación de los otros jugadores en el tablero de juego. Por ejemplo,
Varios participantes descubrieron que una vez que otro jugador del juego cruzó la casilla "FIN"
primero en acumular los puntos extra, su motivación para seguir jugando agresivamente para terminar
disminuye más rápidamente. En ese momento, los participantes prefirieron tomarse su tiempo y recoger
más herramientas para aumentar sus posibilidades de ganar el juego porque ya no había
motivo para llegar rápidamente a la casilla “FIN”.
sesenta y cinco

Casi todos los participantes coincidieron en que cambiaron su estrategia en la segunda ronda para
reflejar lo que habían aprendido al jugar la primera ronda. De la misma manera, con la introducción
de la tarjeta “Game Changer” en la segunda ronda, los participantes ajustaron su estrategia para
maximizar el beneficio o minimizar las consecuencias de la tarjeta. Estos jugadores descubrieron que,
A medida que avanzaba el juego, adaptaron su estrategia para beneficiarse de la repetición exitosa.
enfoques utilizados por otros jugadores en el juego y evitar repetir sus errores.
No obstante, muchos de los participantes comentaron que su estrategia general habría sido
diferente si supieran de antemano que habría múltiples rondas del juego;
sin embargo, se dieron cuenta de que, como en la industria, es imposible predecir la dirección de un
proyecto de software hasta que el equipo del proyecto reciba los comentarios de los clientes.
5.4.3 Suerte
Además de la estrategia, algunos jugadores observaron que la suerte desempeñaba un papel a la hora de poder
gestionar con éxito la deuda técnica. Un jugador observó que dependía de la suerte cuando
La carta "Game Changer" fue seleccionada para la segunda ronda porque las instrucciones en la
La tarjeta podría funcionar a su favor o en su contra. Del mismo modo, otro jugador
terminó segundo con éxito en ambas rondas del juego sin necesidad de cruzar ningún
puentes porque sacó un número de 6 en los dados. Otro jugador comentó que
Aunque hizo todo bien (tomó atajos mínimos y recopiló herramientas),
no avanzó mucho en el tablero de juego porque lanzó valores bajos de dados. Ella vino
La analogía de que sus bajas tiradas de dados era como tener un equipo de desarrollo que no
todo “según los libros” pero cuya productividad es lenta debido a la mala dinámica del equipo
o falta de desarrolladores experimentados en el equipo. Al final, el jugador tuvo que
66

cambió su estrategia y tomó más atajos para mantenerse al día con todos los demás
jugadores en el tablero de juego.
5.5 Comentarios
Durante la sesión informativa, hubo muchas sugerencias para mejorar las “Decisiones difíciles”. Por ejemplo,
Un jugador describió cómo sentía que los elementos de “Decisiones difíciles” coincidían con los de Scott Ambler.
triángulo de hierro del desarrollo de software [56], que se muestra en la Figura 4:
Figura 4: El Triángulo de Hierro del Desarrollo de Software [56]
Identificó que las herramientas representaban el alcance y el camino del juego y los puentes
representó el cronograma. Sin embargo, señaló que faltaban “decisiones difíciles”
elementos para representar los recursos, ubicados en la tercera esquina del triángulo de hierro. Él sintió
tener un elemento en el juego que representara recursos haría que los jugadores fueran más
estratégicos para adquirir herramientas y cruzar puentes.
67

También hubo sugerencias para hacer que el tablero de juego refleje mejor la realidad. Un número
de los participantes sintieron que el riesgo (los puentes) estaba representado de manera demasiado lineal, lo que no sería
Este es el caso de la vida real, donde los riesgos crecen exponencialmente. También sintieron que sería más
realista que los puentes más cercanos a la casilla “INICIO” tengan una penalización mayor que la
puentes más cercanos a la casilla “FIN” y por la penalización en los puentes adquiridos en la primera
ronda aumentará significativamente si pasan a la segunda ronda. Otro
El participante señaló que el juego no reflejaba el principio ágil de las características de construcción.
solo cuando sea necesario (para evitar la arquitectura), como es la práctica común de la industria. Aún otra
El participante reconoció que las "decisiones difíciles" permitían a los jugadores completar el juego sin
recopilar herramientas, mientras que en la industria sería casi imposible que una organización
ganar dinero entregando un producto sin funciones.
No obstante, muchos de los participantes coincidieron en que las “decisiones difíciles” eran útiles para
Demostrar los conceptos y el impacto de la deuda técnica, particularmente desde un punto de vista técnico.
perspectiva. Varios pensaron que el juego también sería útil como herramienta para comprender
y mostrando las diferentes perspectivas que tienen los ingenieros de software y gerentes de negocios
con respecto a la toma de riesgos. Uno de los problemas en el desarrollo de software que el
Los participantes señalaron fue que los ingenieros de software y los gerentes de negocios tienen diferentes
Objetivos: los ingenieros de software se centran en ofrecer software de calidad, mientras que los negocios
Los gerentes se centran en ofrecer funciones. Sintieron que las “decisiones difíciles” permitirían
Tanto los ingenieros de software como los gerentes de negocios para obtener información y una mejor comprensión.
en el proceso de toma de decisiones de cada uno para tomar riesgos como un medio para ayudar a mejorar
comunicación entre ellos.
68

5.6 Conclusión
Este capítulo describe la metodología y los hallazgos de un estudio de juego que demandó al “Hard
Juego de mesa Choices. “Decisiones difíciles” fue desarrollado por Communicating the Benefits
del grupo de proyecto Architecting Within Agile como una herramienta para enseñar a los jugadores sobre el concepto de
deuda técnica. Es una metáfora del ciclo de lanzamiento de software, donde puente y herramienta
Las casillas de juego representan las compensaciones que los profesionales hacen al intentar garantizar que
el lanzamiento se entrega a tiempo. El propósito de este estudio de juego es validar la
conclusiones del estudio de entrevista sobre deuda técnica a través del juego (resultados presentados en
Capítulo 6). Las ideas, comentarios y debates generados por los participantes, que
incluidos desarrolladores, gerentes de proyectos, evaluadores y analistas de negocios, brindaron oportunidades
investigar más a fondo cómo los profesionales del software caracterizan y gestionan la deuda técnica.
69

CAPÍTULO 6
DISCUSIÓN
Este estudio se propuso identificar pautas para ayudar a los profesionales del software a reconocer y
gestionar la deuda técnica. La discusión en este capítulo se centrará en identificar aquellos
pautas respondiendo las preguntas de investigación de esta tesis utilizando los hallazgos de la
entrevistas y estudios de juegos.
6.1 Definición y caracterización de la deuda técnica
Los participantes de ambos estudios asociaron fuertemente la deuda técnica con la realización de transacciones comerciales.
apagados. Esta asociación también estuvo de acuerdo con los hallazgos de la revisión de la literatura. En “Duro
Opciones”, los jugadores hicieron concesiones entre avanzar lo más rápido posible
y acumular la mayor cantidad de puntos para ganar el juego. Los factores que los jugadores del juego
considerados al hacer estas compensaciones estaban directamente relacionados con cómo se moverían en
su siguiente turno. Por otro lado, los participantes de la entrevista tenían más variables y
incertidumbres a considerar al evaluar sus compensaciones. En particular, la entrevista
Los participantes tuvieron que evaluar no sólo las implicaciones técnicas sino también el impacto en la
valor empresarial entregado. Tales compensaciones incluían, por ejemplo, decidir si era mejor
posponer el lanzamiento para crear un producto de mayor calidad, lo que requeriría que el equipo de ventas
cambiar su mensaje a los clientes, o lanzar el producto inmediatamente para
para capturar la cuota de mercado. Por lo tanto, los equipos de proyecto se beneficiaron al involucrar a todos los participantes del proyecto.
partes interesadas (técnicas y no técnicas) en el proceso de decisión para incurrir en deuda técnica.
70

En la literatura, la deuda técnica se clasifica en deuda no intencional e intencional [4].
Sin embargo, ambos estudios no pudieron encontrar muchos casos en los que los participantes
Deuda técnica incurrida involuntariamente, como código descuidado o desordenado. De hecho, los participantes
de ambos estudios incurrieron principalmente en deuda técnica debido a decisiones de proyecto. Cuando el
Los participantes tomaron malas decisiones y contrajeron deudas “involuntarias”. Estas malas decisiones
resultó en la creación de riesgos, como ralentizar el progreso y causar dolor, incluida una mala
calidad, mal desempeño y pobre mantenibilidad. Por otra parte, cuando el
Los participantes tomaron buenas decisiones, crearon oportunidades que les trajeron el éxito.
para alcanzar sus objetivos, incluida la obtención de “decisiones difíciles” y la entrega de su producto.
rápidamente al mercado. Por tanto, otra forma de clasificar la deuda técnica es como riesgos y
oportunidades.
Ambos estudios también encontraron que los participantes reconocían que la deuda técnica era inevitable.
por la realidad empresarial. Los participantes reconocieron que, sin incurrir en
deuda técnica, se moverían demasiado lentamente para mantenerse al día con su competencia.
Por último, los entrevistados informaron que la deuda técnica era difícil de medir.
porque el valor de la deuda era diferente según dónde se contraía en el código.
En algunos casos, el valor de la deuda técnica no tenía valor porque se contrajo en un
Fragmento de código poco utilizado. Además, factores externos, como la dirección del mercado
y la demanda de los clientes también afectó el valor de la deuda técnica y podría generar un
las deudas sin valor adquieren de repente valor. Los jugadores del juego no hicieron similares.
observaciones porque a cada puente se le asignó una penalización cuantificable y la penalización fue
71

lo mismo independientemente de dónde cruzó el jugador el puente en el tablero de juego. Sin embargo,
Los jugadores reconocieron esta desviación de la realidad en sus comentarios sobre el juego.
6.2 Motivaciones para incurrir en deuda técnica
Ambos estudios demostraron que las decisiones y estrategias adoptadas por los participantes
estaban fuertemente motivados por su deseo de "ganar". Para los jugadores, esto significó
obtener la mayor cantidad de puntos, mientras que para los participantes de la entrevista, era capturar un mercado
compartir. En ambos casos, "ganar" también se asoció con quedar primero: ser el primero
jugador para cruzar el cuadrado "FIN" para acumular puntos extra o ser la primera empresa en ofrecer
un producto al mercado. En consecuencia, las limitaciones de tiempo fueron siempre la razón principal para
incurrir en deuda técnica. No obstante, los participantes en ambos estudios enfrentaron obstáculos a lo largo del camino.
manera que incluía aleatoriedad e imprevisibilidad, como la tirada de un dado, "Juego
Tarjetas Changer”, el cambio en la dirección del mercado, trabajar en un dominio nuevo y poco claro
requisitos. Curiosamente, los obstáculos que enfrentaron los participantes no estaban directamente relacionados
al trabajo que tenían que hacer para lograr su victoria. Más bien, estos obstáculos fueron
riesgos tangenciales que los participantes debían tener en cuenta para garantizar
su éxito.
Los participantes en ambos estudios utilizaron deuda técnica para mitigar sus riesgos tangenciales. Pero,
Descubrieron que cuándo contrajeron su deuda y cómo la contrajeron afectó en gran medida su
éxitos. Por ejemplo, los participantes de ambos grupos informaron que incurrir en una gran
cantidad de deuda técnica al principio para separarse de la competencia antes
Pagar la deuda funcionó como una estrategia para ayudarlos a salir adelante. Los jugadores del juego también
72

descubrió que si otro jugador los ganaba para cruzar primero el cuadro “FIN”, cambiaban
su estrategia para ganar recolectando más herramientas y ganando más puntos. Esta estrategia,
aunque no fue mencionado por los participantes de la entrevista en este estudio, ha demostrado ser
éxito para productos como el iPod de Apple y Facebook.
Las observaciones de los dos estudios también sugieren que existe una diferencia en las actitudes hacia
incurrir en deuda técnica entre los desarrolladores y la administración. En las entrevistas, proyecto
Los gerentes eran más propensos a asumir deuda técnica porque se dieron cuenta de que su proyecto
necesario para cumplir también con sus objetivos comerciales. Por el contrario, era menos probable que los desarrolladores asumieran
deuda técnica porque se dieron cuenta de que tendrían que hacer frente a la deuda
problemas de mantenimiento a diario. De manera similar, al reproducir “Hard Choices”, el proyecto
Los gerentes y analistas de negocios estaban más inclinados a cruzar puentes para ayudarlos.
avanzar lo más rápido posible. Sin embargo, los desarrolladores y evaluadores se mostraron más reacios.
sobre cruzar los puentes y prefirió tomar la ruta más larga y recoger herramientas. El
Los desarrolladores y evaluadores también fueron mejores a la hora de esforzarse por deshacerse de sus puentes que
los gerentes de proyecto y analistas de negocios. Sin embargo, todos los participantes coincidieron en que
incurrir en deuda técnica valió la pena porque les ayudó a ganar, a pesar del dolor que supuso.
infligidos, incluida la desaceleración de su progreso, un desempeño deficiente y un aumento
problemas de complejidad y mantenimiento.
6.3 Estrategias para gestionar la deuda técnica
Finalmente, los hallazgos de ambos estudios mostraron que gestionar la deuda técnica es muy parecido a
gestión de riesgos. Al igual que la gestión de riesgos, la gestión técnica de la deuda es un acto de equilibrio que
73

se esfuerza por alcanzar un nivel de deuda que permita al proyecto alcanzar sus objetivos mientras
mitigar sus fallos. Los participantes en el estudio del juego descubrieron que su éxito
dependía de su capacidad para encontrar una estrategia para contraer la cantidad justa de deuda; si ellos
incurrieron en demasiada o muy poca deuda o se endeudaron demasiado pronto, ralentizarían su
avance hacia la casilla “FIN”. Una estrategia para mantener este equilibrio que tanto
grupos de participantes reconocieron era pagar la deuda técnica con la mayor frecuencia y
lo antes posible.
La gestión de riesgos requiere que todas las partes interesadas se conviertan en propietarias de la mitigación de los riesgos.
posibles fallos. Esto está respaldado por los hallazgos del estudio de entrevistas en el que varios
de los participantes de la entrevista reconocieron la importancia de utilizar la comunicación para aumentar la
visibilidad de la deuda técnica para las partes interesadas tanto técnicas como no técnicas.
La comunicación también fue importante para convencer a todas las partes interesadas de que aceptaran el mismo
estrategia de gestión de la deuda técnica. Como resultado, las partes interesadas pudieron trabajar
juntos para encontrar soluciones porque todos podían ver cómo la deuda técnica impactaba a cada uno
los objetivos de otros. El estudio del juego no reportó hallazgos similares porque los participantes
trabajaron individualmente para jugar el juego. En este caso, el juego no refleja fielmente
Escenarios de la vida real donde el desarrollo de productos siempre requiere un esfuerzo de equipo.
En ambos estudios, un enfoque común para gestionar la deuda técnica fue hacer deliberadamente
el esfuerzo por pagar la deuda. Por ejemplo, en el estudio del juego, los jugadores que ganaron
el juego eran los que tendían a saltarse un turno para deshacerse de sus puentes cuando tenían
la oportunidad de hacerlo en lugar de permitir que los puentes se acumulen hasta el punto en que
74

estaban perdiendo turnos. Asimismo, en el estudio de entrevista, varios participantes lograron
su deuda técnica asignando específicamente del 5 al 10% de cada ciclo de lanzamiento para pagar
recuperar su deuda técnica. También hubo otros participantes que incorporaron tiempo extra
en su esfuerzo estima pagar su deuda o utilizó funciones como una oportunidad para abordar
deuda técnica en la misma área del código.
Por último, un aspecto importante de la gestión de riesgos implica utilizar experiencias pasadas y
lecciones aprendidas para crear heurísticas que puedan aplicarse para mitigar riesgos similares en el futuro.
Esto fue especialmente evidente en los hallazgos del estudio del juego, donde los jugadores
identificaron que ajustaron su estrategia de juego entre las dos rondas en función de su
errores al jugar la primera ronda. Los jugadores descubrieron que al hacerlo, eran más
exitoso en jugar la segunda ronda del juego. Aunque este hallazgo no fue fuertemente
identificado en el estudio de la entrevista como un enfoque para gestionar la deuda técnica, muchos
Los participantes de la entrevista incluyeron comentarios en sus respuestas a las preguntas de la entrevista que
demostraron que habían evaluado sus decisiones en retrospectiva y reflexionaron sobre cómo las
He hecho las cosas de manera diferente. Como resultado, investigaciones como ésta son beneficiosas para
profesionales del software en la gestión de su deuda técnica con el objetivo de capturar y documentar
los conocimientos, experiencias y lecciones aprendidas que se pueden aplicar a futuros proyectos de software.
6.4 Validación del estudio de replicación
Los hallazgos del estudio de replicación de Taksande [46] se correlacionaron fuertemente con los resultados de
el estudio de entrevista realizado para esta tesis. Por ejemplo, los hallazgos de Taksande coincidieron
con los hallazgos de este estudio de que la deuda técnica se considera compensaciones inevitables que
proyectos realizan para cumplir con las limitaciones de presupuesto y cronograma. Además, Taksande
75

informó que los participantes de la entrevista en su estudio también consideraban la deuda técnica como un
comprometer la funcionalidad, calidad y corrección del software. Ambos estudios
descubrió que los participantes de la entrevista comúnmente incluían trucos, soluciones y
codificación descuidada como parte de su definición de deuda técnica, contrariamente a la teoría de Cunningham.
afirmación de que el código desordenado no es una forma de deuda técnica.
De manera similar a este estudio, Taksande encontró que los participantes de la entrevista generalmente no incurrieron en
deuda técnica sin querer; más bien, incurrieron en deuda técnica al tomar decisiones.
Taksande clasificó estas decisiones en buenas y malas decisiones. Él explicó
que las buenas decisiones eran decisiones intencionales tomadas para cumplir con limitaciones de presupuesto y tiempo
mientras que las malas decisiones llevaron a la organización a incurrir en enormes pérdidas. Este estudio amplió
esta clasificación para describir la deuda técnica como oportunidades o riesgos del proyecto.
Además, ambos estudios informaron que la razón más común para incurrir en gastos técnicos
La deuda tiene limitaciones de tiempo porque los compromisos con el cliente siempre tienen prioridad.
Los hallazgos de Taksande validaron los hallazgos de este estudio de que otras razones para incurrir
La deuda técnica incluye requisitos cambiantes, generalmente debido a que los clientes no saben qué
quieren que la administración reciba nueva información crucial sobre el mercado y decisiones que
alguna vez fueron óptimos, pero han demostrado ser problemáticos con el tiempo, especialmente a medida que el proyecto
El equipo se familiariza más con su dominio. Sin embargo, a diferencia de este estudio, Taksande no
No encontré ningún participante de la entrevista que reportara a los desarrolladores de software sin experiencia como
fuente de deuda técnica.
76

Los hallazgos del estudio de Taksande también coincidieron con este estudio en que los profesionales del software
siente que vale la pena incurrir en deuda técnica porque el costo de oportunidad de cumplir
tiempo y presupuesto superaron con creces los síntomas negativos de calidad reducida, aumento
complejidad y bajo rendimiento. En ambos estudios, los participantes de la entrevista describieron la
impacto de incurrir en deuda técnica en su proyecto para incluir mayores costos y recursos
necesarios para soportar y mantener el software y el riesgo de hacer que los clientes estén insatisfechos,
potencialmente perdiendo su buena voluntad y fe.
Además, el estudio de replicación de Taksande informó estrategias de gestión análogas a
los descritos en este estudio. En particular, los hallazgos de Taksande enfatizaron fuertemente
visibilizar la existencia de deuda técnica a través de la documentación. Él informó un
número de participantes de la entrevista que realizaron “auditorías arquitectónicas” periódicas y que
realizó un seguimiento de la deuda técnica en su cartera de proyectos o tablero de tareas. Las mismas técnicas fueron
también descubierto en este estudio. Ambos estudios también encontraron que otro enfoque para gestionar
La deuda técnica es mantener un diálogo abierto con partes interesadas no técnicas (por ejemplo, proyecto
gerentes, clientes) para que comprendan por qué existe la deuda técnica y su impacto en
el proyecto. Sin embargo, el estudio de Taksande no encontró ningún participante en la entrevista que
gestionó su deuda técnica dedicando específicamente tiempo en su ciclo de lanzamiento a pagar
de sus deudas como algunos de los participantes de la entrevista en este estudio.
Finalmente, el estudio de Taksande encontró que muchos de los participantes de la entrevista sentían que trabajar
con deuda técnica fue una buena experiencia de aprendizaje para los desarrolladores en su software
proyectos. Los participantes de la entrevista sintieron que las experiencias pasadas con deuda técnica enseñaron
77

decirles qué hacer y qué no hacer la próxima vez que necesitaran incurrir en deuda técnica para
razones similares. Aunque los participantes de la entrevista para este estudio no hicieron lo mismo
observación, los jugadores en el estudio del juego informaron que obtuvieron información de
sus experiencias actuales con deuda técnica para mejorar su estrategia en el futuro.
6.5 Conclusión
Los hallazgos de esta tesis sugieren que la deuda técnica es más que una simple cuestión técnica; él
es un problema tridimensional definido por decisiones técnicas, valor comercial entregado y
tiempo. Los proyectos de software intentan constantemente tomar decisiones técnicas que entreguen
el mayor valor comercial en el menor tiempo posible. Sin embargo, estas decisiones resultan
en deuda técnica si, en algún momento en el futuro, ralentiza el trabajo del equipo de desarrollo
capacidad de continuar entregando valor comercial.
Pero no todas las decisiones técnicas son deuda técnica. Si en un proyecto se toman decisiones que no
entregar valor comercial en cualquier punto durante el ciclo de vida del proyecto de software, como
Al escribir código de mala calidad, estas decisiones no son deuda técnica. Asimismo, técnico
Las deficiencias, como defectos y características no implementadas, tampoco son deuda técnica.
porque no obstaculizan la capacidad del equipo para continuar entregando valor comercial en el
futuro.
Sin embargo, como lo muestran los hallazgos de esta tesis, la deuda técnica es necesaria para que los proyectos
sobrevivir en el negocio del software. Por lo tanto, los profesionales del software se beneficiarían de tener
modelos, herramientas y procesos que les ayudan a pronosticar el valor comercial futuro de sus
presentar decisiones técnicas. Tener la capacidad de predecir los resultados comerciales a largo plazo.
78

de decisiones técnicas a corto plazo ayudaría a los profesionales del software a elegir los tipos correctos
de deuda técnica para incurrir y evitar aquellas que causarían demasiado dolor, tanto para
profesionales del software y sus clientes en el futuro.
A continuación se presenta un conjunto de pautas identificadas a partir de los resultados de esta tesis para ayudar
Los profesionales del software reconocen y gestionan la deuda técnica:
G1:La deuda técnica son compensaciones entre cuestiones técnicas y comerciales. Un proyecto debe
hacer estas concesiones a lo largo de su ciclo de desarrollo. Como tal, la decisión de
incurrir en deuda técnica debería implicar aportes tanto de técnicos como de no técnicos.
partes interesadas.
G2:La deuda técnica es inevitable. Sin él, un proyecto de software avanza demasiado lento
para mantenerse al día con su competencia. Los equipos de proyecto no deben evitar la deuda técnica; ellos
debería gestionarlo.
G3:La deuda técnica puede crear oportunidades o riesgos. Cuando un proyecto incurre en problemas técnicos
deuda como resultado de tomar buenas decisiones, creaoportunidadesPara el proyecto.
Cuando un proyecto incurre en problemas técnicos como resultado de tomar malas decisiones, creariesgos
Para el proyecto.
G4:Los equipos de proyecto incurren en deuda técnica paraganar(es decir, ser el primero en llegar al mercado, captar una gran
cuota de mercado). Los equipos de proyecto utilizan la deuda técnica para mitigar los riesgos tangenciales,
que incluyen limitaciones de tiempo y presupuesto, requisitos cambiantes o poco claros y
incertidumbre sobre la dirección del mercado. Estos riesgos tangenciales afectan el desempeño de un proyecto.
posibilidades de ganar.
79

G5:Los promotores son más reacios a incurrir en deuda técnica que los gestores de proyectos
debido a objetivos diferentes. La gestión de proyectos está más motivada para incurrir
deuda técnica porque quieren cumplir sus objetivos comerciales, mientras que
El desarrollo está menos motivado porque tienen que mantener el código a diario.
base.
G6:Gestionar la deuda técnica como gestionar riesgos. Para gestionar la deuda técnica, un proyecto
necesita encontrar la cantidad correcta de deuda técnica en la que incurrir, para que todo el proyecto
propietarios de partes interesadas para mitigar los posibles fallos y aprender del pasado.
experiencias.
G7:Gestionar con éxito la deuda técnica requiere hacer un esfuerzo para pagar la deuda
regularmente. Esto evita permitir que la deuda técnica se acumule fuera de control y
eventualmente, abrumar el proyecto.
6.6 Limitaciones de este estudio
Existen varias limitaciones en este estudio. El estudio se centra en las perspectivas de
profesionales de software que desarrollan sistemas basados en aplicaciones y web. No es asi
incluir las opiniones de los profesionales del software que trabajan en sistemas críticos para la seguridad, en tiempo real
sistemas, firmware integrado, aplicaciones móviles y software de código abierto.
Además, la mayoría de los participantes entrevistados para este estudio son desarrolladores de software.
y arquitectos; por lo tanto, este estudio examina principalmente la deuda de diseño y no aborda otros
formas de deuda técnica, como pruebas, documentación, deuda por defectos. Además, el
La mayoría de los participantes entrevistados para este estudio son hombres, por lo que el estudio no pudo
determinar si el género influyó en cómo se percibe la deuda técnica.
80

Desde un punto de vista metodológico, aproximadamente el 50% de los participantes de la entrevista en
el estudio principal trabajó para la misma organización. Todos estos participantes de la entrevista
Habían trabajado juntos en el mismo proyecto en algún momento, aunque, en el momento de la
En la entrevista, estaban trabajando en varios proyectos diferentes. Además, el investigador
También era empleado de la misma organización. En segundo lugar, el análisis de los datos fue
realizado por un solo investigador que es nuevo en la investigación cualitativa. Como resultado, el
El análisis puede estar sesgado por la perspectiva del investigador y puede haber limitado su capacidad para
buscar datos adicionales. En tercer lugar, los datos recopilados al jugar "Decisiones difíciles"
omitió incluir datos de sesiones adicionales que fueron realizadas por otros investigadores en
el grupo de proyectos Comunicar los beneficios de la arquitectura dentro del desarrollo ágil,
lo que podría afectar la exhaustividad de los hallazgos de este estudio. Por último, los hallazgos
Los resultados de ambos estudios se obtuvieron de entrevistas, grupos de discusión y comentarios. Como un
Como resultado, los hallazgos están sujetos a las opiniones de los participantes y se basan en la
interpretación del investigador. Además, la exactitud de los comentarios del
El grupo de discusión y la retroalimentación del estudio secundario están limitados por la opinión del investigador.
memoria y su capacidad para registrar con precisión los comentarios.
81

CAPÍTULO 7
CONCLUSIONES Y TRABAJO FUTURO
Esta tesis identificó pautas para ayudar a los profesionales del software a reconocer y gestionar
deuda técnica. Los resultados de una serie de entrevistas de una hora de duración con diecinueve
profesionales del software en la industria y de jugar el juego “Decisiones difíciles” con tres
grupos de profesionales de software revelaron un conjunto de pautas que caracterizan la técnica
deuda. Este capítulo resume las contribuciones de investigación de esta tesis y hace
sugerencias para trabajos futuros.
7.1 Resumen de objetivos de investigación
Se ha realizado muy poca investigación académica para estudiar la deuda técnica. La existencia
La literatura sobre el tema proviene principalmente de contribuciones del sector del desarrollo de software.
comunidad a través de blogs y debates en línea. El objetivo de esta investigación es identificar
las características de la deuda técnica y las estrategias para gestionarla. Lograr esto
objetivo, esta tesis tuvo como objetivo responder las siguientes preguntas:
• ¿Cómo definen y caracterizan los profesionales del software la deuda técnica?
• ¿Cuáles son las motivaciones para incurrir en deuda técnica en un proyecto de software?
• ¿Cuáles son las estrategias para gestionar la deuda técnica en un proyecto de software?
La investigación se basa en la aplicación de técnicas de investigación cualitativa para analizar la
Experiencias y lecciones aprendidas de los profesionales del software de la industria. Los hallazgos de
Dos estudios que involucran a profesionales de software de la industria se correlacionan en gran medida con cada uno.
otros y con la información encontrada en la revisión de la literatura. Es más, los hallazgos
corroborado con los resultados de un estudio de replicación. El resultado de esta investigación resultó
82

en un conjunto de pautas que caracterizan la deuda técnica, que los profesionales del software pueden utilizar
para ayudarles a reconocer y gestionar la deuda técnica de sus proyectos.
7.2 Aportes de este trabajo
Mis contribuciones en esta tesis:
• Se analizó y revisó la literatura existente sobre deuda técnica para examinar cómo se
percibido actualmente por la comunidad de desarrollo de software;
• Desarrolló un proceso de entrevista utilizando investigación cualitativa para investigar cómo
Los profesionales del software en la industria perciben la deuda técnica. Esto incluyó la creación de un
Guía de entrevista semiestructurada centrada en explorar las habilidades de un profesional de software.
conocimientos, experiencias y lecciones aprendidas con deuda técnica;
• Realicé una serie de entrevistas de una hora de duración con diecinueve software
practicantes. Los resultados de las entrevistas se analizaron utilizando constantes
análisis comparativo para comprender la definición, atributos, causas, síntomas y
gestión de deuda técnica;
• Diseñé el juego de mesa “Hard Choices” con investigadores del programa Communicating
los beneficios de la arquitectura dentro del proyecto de desarrollo ágil en el SEI en
Carnegie Mellon University en Pittsburgh, PA, para presentar a los jugadores el concepto de
deuda técnica;
• Realicé una serie de sesiones en conferencias y talleres para jugar “Decisiones difíciles” con
desarrolladores de software, analistas de negocios, gerentes de proyectos y evaluadores de control de calidad. El
Se examinaron los comentarios y la retroalimentación de la sesión informativa para validar la
hallazgos de las entrevistas;
83

• Desarrolló un conjunto de pautas basadas en los hallazgos tanto de la entrevista como del juego.
estudios que tienen como objetivo ayudar a los profesionales del software a reconocer y gestionar sus problemas técnicos.
deuda en futuros proyectos de software. Estas directrices caracterizan la deuda técnica como
compensaciones inevitables que pueden crear oportunidades o riesgos para un proyecto de software.
Los equipos de proyecto pueden gestionar con éxito su deuda técnica mediante abiertamente
comunicar su existencia y su impacto a todos los actores del proyecto para
que todos se conviertan en propietarios de la mitigación de sus riesgos. Además, los equipos de proyecto
deberían hacer un esfuerzo regular y activo para pagar su deuda técnica a
Evite sentirse abrumado por ello.
El trabajo de esta tesis está validado por un estudio de replicación realizado por Nitin Taksande.
[46] en la Universidad de Maryland, condado de Baltimore. Además, los resultados de este
La investigación ha dado lugar a una serie de publicaciones [52, 57-59] (ver Apéndice A), que incluyen
un artículo recientemente aceptado para un próximo número especial deSoftware IEEEsobre deuda técnica
[59]. El documento explica que la deuda técnica es un acto de equilibrio grande y complejo entre
varias preocupaciones a corto y largo plazo utilizando los resultados del estudio de entrevista
descrito en esta tesis y del estudio de replicación de Taksande. Describe la entrevista
Metodología de estudio utilizando información del Capítulo 3 de esta tesis. Es más, los hallazgos
se basan en comparar y fusionar los resultados de nuestro estudio (Capítulo 4) y de
El estudio de Taksande y la identificación de aquellos que tuvieron el mayor apoyo de los datos de ambas entrevistas.
conjuntos.
7.3 Trabajo futuro
El trabajo futuro en esta área de investigación incluye:
84

• Realizar estudios adicionales para abordar las limitaciones de este estudio y profundizar
validar y verificar los hallazgos descritos en esta tesis;
• Investigar cómo ven los profesionales de negocios la deuda técnica y evaluar la
similitudes y diferencias con la forma en que los profesionales del software ven la deuda técnica;
• Desarrollar mejores herramientas para medir y rastrear la deuda técnica de un software
proyecto. Actualmente, herramientas como el complemento de deuda técnica de Sonar, propiedad de CAST
software y el método de evaluación de la calidad del software de SIG/TÜiT han desarrollado
Técnicas patentadas para medir y rastrear la deuda técnica. Sin embargo, sus
Los enfoques se centran en evaluar la cantidad de deuda técnica en un proyecto de software.
a través de métricas de código (por ejemplo, líneas de código, complejidad del código, duplicación, código
cobertura). Mis hallazgos sugieren que cuestiones empresariales como el crecimiento, los consumidores
La capacidad de respuesta y las tendencias del mercado también contribuyen al "valor" de la tecnología.
deuda en un proyecto de software. Por lo tanto, un área de investigación es examinar
técnicas que modelan la cantidad y el valor de la deuda técnica en relación con todos los
Posibles cambios en el software y su impacto en el aspecto técnico y empresarial.
aspectos del proyecto;
• Investigar estrategias para gestionar la deuda técnica. Un posible enfoque es
aprovechar los matices financieros de la metáfora y desarrollar estrategias que sean
basado en teorías financieras y económicas, como el valor actual neto (VAN), el valor real
opciones, costos de oportunidad y retorno de la inversión (ROI). Guo y Seaman tienen
Ya hemos comenzado a trabajar en esta área utilizando la teoría de la gestión de carteras [29].
85

7.4 Conclusión
Como cualquier negocio, el desarrollo de software está impulsado por la necesidad de captar cuota de mercado.
a través de la satisfacción de las necesidades del cliente y la derrota de la competencia. Estas realidades empresariales
hacen imposible que los proyectos de software sobrevivan sin incurrir en deuda técnica. De este modo,
Los equipos de proyectos de software no deben evitar incurrir en deuda técnica a pesar de que lo harán.
necesidad de hacer concesiones en su calidad técnica. En cambio, los equipos de proyectos de software
deberían utilizar la deuda técnica como herramienta estratégica para ayudarles a crear oportunidades para lograr
sus objetivos comerciales. La clave para utilizar con éxito la deuda técnica está en el software
la capacidad del equipo del proyecto para gestionarlo. La gestión de la deuda técnica requiere una gestión eficaz
habilidades de comunicación porque la deuda técnica no es fácilmente vista ni comprendida por personas que no son
partes interesadas técnicas, pero depende de que todas las partes interesadas del proyecto tomen
propiedad para mitigar sus riesgos. En consecuencia, esta tesis pretende identificar un conjunto de pautas
para ayudar a los profesionales del software a reconocer y gestionar la deuda técnica en su proyecto. El
Las contribuciones de esta tesis han ampliado el conocimiento existente, en gran medida capturado en
blogs y grupos de discusión en línea, para incluir los conocimientos, la experiencia y las lecciones aprendidas
de los profesionales del software en la industria. Sin embargo, aún queda mucho por hacer
trabajo por hacer en esta área temática para desarrollar estrategias y herramientas que puedan ayudar a proyectar
Los equipos gestionan con éxito su deuda técnica.
86

REFERENCIAS
1. Cunningham, W.El sistema de gestión de cartera WyCash. Informe de experiencia de
OOPSLA '92 [Artículo Wiki] 26 de marzo de 1992 [consultado el 3 de febrero de 2010];
Disponible de:http://c2.com/doc/oopsla92.html .
2. Cunningham, W.Ward explica la metáfora de la deuda. [Artículo Wiki] 5 de septiembre de 2009
[consultado el 3 de febrero de 2010]; Disponible de:
http://c2.com/cgi/wiki?WardExplainsDebtMetaphor .
3. McKay, J.Cuando la deuda técnica se convierte en quiebra técnica. james mckay dot net [Blog] 6 de
abril de 2009 [consultado el 11 de febrero de 2010]; Disponible de:
http://jamesmckay.net/2009/04/when-technical-debt-becomes-
technicalbankruptcy/ .
4. McConnell, S.Gestión de la deuda técnica. Libro blanco sobre mejores prácticas [PDF] 1 de junio de
2008 [consultado el 29 de noviembre de 2010]; Disponible de:
http://www.construx.com/Page.aspx?cid=2801 .
5. Berteig, M.Deuda técnica. Agile Advice [Blog] 2006 [consultado el 9 de febrero de 2010];
Disponible de:http://www.agileadvice.com/archives/2006/12/technical_debt.html .
6. Fowler, M.Cuadrante de Deuda Técnica. Martin Fowler [Blog] 14 de octubre de 2009 [consultado el
3 de febrero de 2010]; Disponible de:
http://www.martinfowler.com/bliki/TechnicalDebtQuadrant.html .
7. Fowler, M.Deuda técnica. Martin Fowler [Blog] 26 de febrero de 2009 [consultado el 3 de
febrero de 2010]; Disponible de:
http://www.martinfowler.com/bliki/TechnicalDebt.html .
8. Churchville, D.Deuda técnica: gasto deficitario para geeks. Agile Project Planning [Blog] 20 de
marzo de 2005 [consultado el 9 de febrero de 2010]; Disponible de:
http://www.extremeplanner.com/blog/2005/03/technical-debt-deficit-
spendingfor.html .
9. Marick, B.Deuda técnica: deuda e historia. Exploración a través del ejemplo [Blog] 22 de junio de
2008 [consultado el 9 de febrero de 2010]; Disponible de:
http://www.exampler.com/blog/2008/06/22/technical-debt-paying-it-down/ .
87

10. Theodoropoulos, T.Deuda Técnica - Parte 1: Definición. Blog de Acrowire [Blog] 12 de noviembre
de 2010 [consultado el 11 de marzo de 2011]; Disponible de:
http://blog.acrowire.com/technical-debt/technical-debt-part-1-definition/ .
11. Cartwright, I.Cinco tipos de deuda técnica. lo que todavía no sé [Blog] 5 de enero de 2009
http://blog.iancartwright.com/2009/01/five-kinds-of-technical-debt.html .
12. Martín, R.Un desastre no es una deuda técnica.[Blog] 22 de septiembre de 2009 [consultado el 3 de
febrero de 2010]; Disponible de:http://blog.objectmentor.com/articles/2009/09/22/amess-is-not-
a-technical-debt .
13. Deuda técnica. [Wikipedia] 1 de mayo de 2011 [consultado el 5 de junio de 2011]; Disponible
de: http://en.wikipedia.org/wiki/Technical_debt .
14. Webb, D.Cómo evitar la deuda técnica y aumentar la flexibilidad de los sistemas. Desarrollo
de aplicaciones [Artículo] 20 de marzo de 2008 [consultado el 10 de febrero de 2010];
Disponible de:http://www.eweek.com/c/a/Application-Development/How-to-Avoid-
Technical-Debt-and-Increase-Systems-Flexibility/ .
15. Dyson, P.Deuda Técnica y Lean Startup. Blog de Paul Dyson [Blog] 15 de agosto de 2011
[consultado el 12 de noviembre de 2011]; Disponible de:
http://pauldyson.wordpress.com/2011/08/15/technical-debt-and-the-lean-startup/ .
16. Dyson, P.¿Un modelo económico de deuda técnica?Blog de Paul Dyson [Blog] 2011 [citado;
Disponible de:http://pauldyson.wordpress.com/2011/08/18/an-economicmodel-of-
technical-debt/ .
17. Salvaje, B.Pagar la deuda técnica. BrandonSavage.net [Blog] 23 de marzo de 2009
[consultado el 3 de febrero de 2010]; Disponible de:http://www.brandonsavage.net/
payingdown-technical-debt/ .
18. Casey, K.Gestión de la deuda técnica. Blog de Keith Casey [Blog] 2 de marzo de 2009
[consultado el 3 de febrero de 2010]; Disponible de:http://caseysoftware.com/blog/
technicaldebt .
19. Tosi, J.La deuda técnica y el monstruo boogie. Blog de gestión ágil [Blog] 19 de julio de 2010
[consultado el 5 de septiembre de 2011]; Disponible de:
http://blogs.versionone.com/agile_management/2010/07/19/technical-debt-and-
theboogie-monster/ .
88

20. Ries, E.Adopte la deuda técnica. Lecciones aprendidas [Blog] 29 de julio de 2009 [consultado el 3 de
febrero de 2010]; Disponible de:
http://www.startuplessonslearned.com/2009/07/embrace-technical-debt.html .
21. Gat, I.,Declaración inicial.Cortador de TI Diario, 2010.23(10): pág. 3-10.
22. Chin, S., et al.,La economía de la deuda técnica.Cortador de TI Diario, 2010.23(10): pág.
11-18.
23. Gat, I.Deuda técnica. SPAMCAST 112 [Podcast] 12 de diciembre de 2010 [consultado el 24 de
marzo de 2011]; Disponible de:http://www.spamcast.libsyn.com/s-pa-mcast-112-israel-gat-
technical-debt .
24. Highsmith, J.Las implicaciones financieras de la deuda técnica. Jim Highsmith.com [Blog] 19 de
octubre de 2010 [consultado el 24 de marzo de 2011]; Disponible de:
http://www.jimhighsmith.com/2010/10/19/the-financial-implications-of-technicaldebt/
.
25. Steve.Deuda técnica: el umbral del dolor aceptable. Technoetic [Blog] 19 de septiembre de 2006
http://blog.technoetic.com/2006/09/19/threshold-of-pain/ .
26. Libra esterlina, C.,Gestión de la deuda de software: construcción para un cambio inevitable.
2011, Boston, MA: Pearson Education Inc. 244.
27. Evaluación y Valoración Técnica de Deuda. 2011 [citado; Disponible de: http://
www.cutter.com/consulting-and-training/technical-debt-assessment.html .
28. Barton, B. y C. Sterling,Gestionar carteras de proyectos de forma más eficaz mediante la inclusión de
la deuda de software en el proceso de decisión.Cortador de TI Diario, 2010.23(10): pág. 19-24.
29. Guo, Y. y CB Seaman,Un enfoque de cartera para la gestión técnica de la deuda, en
Segundo Taller Internacional sobre Gestión de Deuda Técnica (MTD 2011). 2011, ACM:
Waikiki, Honolulu, Hawaii, EE. UU. pag. 31-34.
30. Hilton, R.Cuándo trabajar con la deuda técnica. Absolutely No Machete Malabares [Blog] 22 de
julio de 2011 [consultado el 12 de noviembre de 2011]; Disponible de:
http://www.nomachetejuggling.com/2011/07/22/when-to-work-on-technical-debt/ .
31. Laribee, D.Uso de técnicas ágiles para pagar la deuda técnica. MSDN Magazine [Artículo]
2009 [consultado el 23 de febrero del 2011]; Disponible de:
http://msdn.microsoft.com/en-us/magazine/ee819135.aspx .
89

32. Brown, K.Pagar la deuda técnica. Líneas de comentarios de Kyle Brown [Blog] 2010
[citado; Disponible de:
http://www.ibm.com/developerworks/websphere/techjournal/1001_col_brown/1001
_col_brown.html .
33. neilj.Cómo administro la deuda técnica. Fragile [Blog] 8 de enero de 2011 [consultado el 25 de
febrero de 2011]; Disponible de:http://fragile.org.uk/2011/01/how-i-manage-technicaldebt/ .
34. Ropa, S.Gestión de la deuda técnica. Blog de gestión ágil [Blog] 11 de julio de 2011 [consultado el 12
de noviembre de 2011]; Disponible de:
http://blogs.versionone.com/agile_management/2011/07/11/managing-
technicaldebt/?mkt_tok=3RkMMJWWfF9wsRoguqzJZKXonjHpfsX77u0sXbHr08Yy0EZ5
VunJEUWy3YADT9QhcOuuEwcWGog81glKCemaco9O%2Fw %3D%3D .
35. Theodoropoulos, T.Deuda Técnica - Parte 2: Identificación. Blog de Acrowire [Blog] 6 de diciembre de
2010 [consultado el 11 de marzo de 2011]; Disponible de:
http://blog.acrowire.com/technical-debt/technical-debt-part-2-identification/ .
36. Kruchten, P.¿De qué colores es su cartera de pedidos? (revisado). Conferencia Agile Vancouver
[Diapositivas de PowerPoint] 3 de noviembre de 2009 [consultado el 3 de noviembre de 2009];
Disponible de:http://philippe.kruchten.com/talks/ .
37. REPARTO.Cómo monetizar la deuda técnica de la aplicación. [PDF] 2011 [consultado el 8 de
marzo de 2011]; Disponible de:http://www.castsoftware.com/campaigns/how-
tomonetize-application-technical-debt?gad=otd .
38. Nugroho, A., J. Visser y T. Kuipers,Un modelo empírico de deuda técnica e
intereses, enActa del II Trabajo de Gestión de Deuda Técnica. 2011, ACM:
Waikiki, Honolulu, Hawaii, EE. UU.
39. Lehman, MM,Leyes de la evolución del software revisadas, enQuinto Taller Europeo sobre
Tecnología de Procesos de Software (EWSPT '96). 1996, Springer-Verlag: Nancy, Francia. pag.
108-124.
40. Lehman, MM, et al.,Métricas y leyes de la evolución del software: la visión de los noventa,
enCuarto Simposio Internacional sobre Métricas de Software (METRICS '97). 1997:
Albuquerque, Nuevo México. pag. 20-32.
41. Perry, DE y AL Wolf,Fundamentos para el estudio de la arquitectura del software. Notas
de ingeniería de software de ACM SIGSOFT, 1992.17(4): pág. 40-52.
90

ubc_2012_fall_lim_erin2.en.es.pdf

ubc_2012_fall_lim_erin2.en.es.pdf

Recomendados

Recomendados

Más contenido relacionado

Similar a ubc_2012_fall_lim_erin2.en.es.pdf

Similar a ubc_2012_fall_lim_erin2.en.es.pdf (20)

Más de Nicanor Sachahuaman

Más de Nicanor Sachahuaman (16)

Último

Último (15)

ubc_2012_fall_lim_erin2.en.es.pdf