Juego de preguntas para gamificar la introducción a la deuda técnica ¡Bienvenidos al desafío "Código en Equilibrio"! En este juego, competirán en eq

Juego de preguntas para gamificar la introducción a la deuda técnica

¡Bienvenidos al desafío "Código en Equilibrio"! En este juego, competirán en equipos para demostrar quién entiende mejor qué es la deuda técnica, sus consecuencias y cómo los atajos afectan la calidad del código a largo plazo. ¡Prepárense para aprender, colaborar y divertirse!

Objetivo del juego

Ser el equipo con más puntos al responder correctamente preguntas sobre la deuda técnica, sus consecuencias y la relación con la calidad del código.

Narrativa / Temática

Ustedes son un equipo de jóvenes programadores que deben construir un software para un proyecto importante. Pero cuidado, si toman atajos sin pensar, la "deuda técnica" se acumula y el código se vuelve difícil de mantener. ¿Podrán entender bien este concepto para evitar problemas futuros y crear código de calidad?

Equipos

Formar entre 3 y 6 equipos, cada uno con 3-5 integrantes. Cada equipo elige un nombre relacionado con tecnología (Ej: Los Debuggers, Los Codificadores, Los Ingeniosos, etc.).

Reglas del juego

1. El juego tiene 3 rondas, cada ronda con preguntas de dificultad creciente: Fácil, Medio y Difícil.
2. En cada ronda, se hará una pregunta por equipo, en orden. El moderador (docente) proyecta la pregunta y los equipos tienen 30 segundos para discutir y responder.
3. Las respuestas se dan en voz alta o se escriben en un papel para mostrar al docente, según preferencia.
4. Si un equipo responde incorrectamente, otro equipo puede intentar responder para ganar puntos extra (respuesta abierta).
5. Las preguntas incluyen un breve comentario que explica la respuesta correcta para reforzar el aprendizaje.
6. Al final de las 3 rondas, el equipo con más puntos gana y recibe un reconocimiento especial.
7. Si hay empate, se realiza una ronda de desempate con preguntas difíciles y doble puntuación.

Sistema de puntos y tabla de puntuación

Mecánicas especiales opcionales

• Comodín "Doble Puntos": Cada equipo puede usarlo una vez en cualquier pregunta para intentar ganar el doble de puntos.
• Ronda de desempate: Preguntas difíciles con doble puntaje para resolver empates.

Banco de preguntas

Preguntas fáciles (6 preguntas)

1. ¿Qué es la deuda técnica?

   Respuesta: Es cuando se usan atajos en la programación que facilitan el trabajo inmediato pero causan problemas en el futuro.

   Explicación: La deuda técnica es como pedir un préstamo: ayuda ahora, pero después hay que pagar con intereses (más trabajo).

2. ¿Por qué es importante evitar la deuda técnica?

   Respuesta: Porque puede hacer que el código sea difícil de entender, arreglar o mejorar luego.

   Explicación: Si acumulamos deuda técnica, el trabajo futuro será más lento y complicado.

3. ¿Qué significa tomar un atajo al programar?

   Respuesta: Es hacer algo rápido sin seguir las mejores prácticas o sin pensar en el futuro.

   Explicación: Atajos facilitan el trabajo ahora pero pueden generar problemas después.

4. ¿La deuda técnica siempre es negativa?

   Respuesta: No, a veces es útil para terminar rápido, pero hay que planificar cómo pagarla después.

   Explicación: Tomar decisiones rápidas puede ser necesario, pero sin control, la deuda crece demasiado.

5. ¿Qué pasa si no se "paga" la deuda técnica?

   Respuesta: El código se vuelve confuso y difícil de mantener.

   Explicación: Ignorar la deuda técnica hace que el software sea menos eficiente y más propenso a errores.

6. ¿Quién es responsable de la deuda técnica en un proyecto?

   Respuesta: El equipo de desarrollo, porque ellos deciden cuándo tomar atajos o no.

   Explicación: Los programadores deben equilibrar rapidez y calidad para evitar deuda excesiva.

Preguntas medias (7 preguntas)

7. ¿Cómo afecta la deuda técnica a la calidad del código a largo plazo?

   Respuesta: Disminuye la calidad porque el código se vuelve más difícil de entender y modificar.

   Explicación: Los atajos pueden causar errores y confusión que hacen que el código pierda calidad.

8. ¿Qué relación hay entre la planificación y la deuda técnica?

   Respuesta: Una buena planificación ayuda a evitar o controlar la deuda técnica.

   Explicación: Pensar antes de programar reduce la necesidad de atajos que generan deuda.

9. ¿Qué ejemplo cotidiano puede representar la deuda técnica?

   Respuesta: Usar cinta adhesiva para arreglar algo en vez de repararlo bien.

   Explicación: Es una solución rápida que funciona ahora pero no es duradera.

10. ¿Cómo pueden los atajos afectar el trabajo en equipo?

    Respuesta: Pueden causar confusión y desacuerdos si el código no es claro para todos.

    Explicación: Código desordenado dificulta que otros comprendan y colaboren.

11. ¿Qué debe hacer un equipo si detecta mucha deuda técnica?

    Respuesta: Planificar tiempo para corregir y mejorar el código antes de seguir avanzando.

    Explicación: "Pagar" la deuda técnica evita problemas mayores en el futuro.

12. ¿Por qué es mejor evitar atajos innecesarios en el código?

    Respuesta: Porque a largo plazo el código será más estable y fácil de mantener.

    Explicación: Evitar atajos mejora la calidad y reduce errores futuros.

13. ¿Qué puede pasar si un programa con mucha deuda técnica se necesita modificar rápido?

    Respuesta: Será difícil y puede causar más errores o retrasos.

    Explicación: La deuda técnica complica las modificaciones y mantenimiento.

Preguntas difíciles (5 preguntas)

14. ¿Cómo se relaciona la deuda técnica con el concepto de "intereses" en un préstamo?

    Respuesta: Los "intereses" son el esfuerzo extra que se debe hacer para corregir problemas causados por atajos.

    Explicación: Tomar atajos es como pedir dinero prestado; luego hay que trabajar más para pagar ese "préstamo".

15. ¿Cuál es una estrategia efectiva para manejar la deuda técnica en un proyecto?

    Respuesta: Revisar y refactorizar el código periódicamente para mejorar su calidad.

    Explicación: La refactorización ayuda a "pagar" la deuda técnica antes de que crezca demasiado.

16. ¿Qué significa "refactorizar" el código en relación con la deuda técnica?

    Respuesta: Mejorar y reorganizar el código sin cambiar su función para reducir la deuda técnica.

    Explicación: Refactorizar corrige atajos y mejora la calidad del código.

17. ¿Qué riesgos tiene ignorar la deuda técnica en proyectos grandes?

    Respuesta: El proyecto puede volverse inmanejable, con muchos errores y retrasos.

    Explicación: La deuda técnica acumulada puede detener el avance del proyecto y aumentar costos.

18. ¿Por qué es importante explicar la deuda técnica con ejemplos cotidianos a principiantes?

    Respuesta: Porque facilita la comprensión de un concepto abstracto relacionándolo con su realidad.

    Explicación: Usar ejemplos prácticos ayuda a conectar ideas difíciles con experiencias conocidas.