Liberarse de la deuda técnica

Platzi ofrece un especial de Navidad con precios reducidos hasta el 25 de diciembre, proporcionando una amplia gama de cursos en inglés, programación, Excel, ciencia de datos, inteligencia artificial, marketing y más. Esta es una gran oportunidad para expandir tus habilidades en diversas áreas a través de una plataforma de aprendizaje reconocida.

Además, Platzi presenta un curso introductorio gratuito de GitHub Actions, ideal para quienes desean implementar integraciones y despliegues continuos en sus proyectos de desarrollo.

En este video, exploramos cómo el equipo de desarrollo web de Platzi abordó una deuda técnica. Mariangélica Useche comparte valiosos consejos para superar los desafíos actuales de tu equipo de desarrollo.

Conéctate con Platzi a través de sus redes sociales:

Para más detalles, te invitamos a ver el video original en YouTube.

Related Articles

Responses

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

  1. Acabo de ver las críticas de la peli de blanca nieves y llegué aquí.. y pues otra amarga realidad. La deuda técnica nos ha llevado a miles de malentendidos con jefes y clientes, es lo más fregado que nos puede pasar en nuestro afan por salir adelante

  2. En mi equipo pasamos de un mono repo a MFEs porque el mono repo abarcaba muchas páginas de equipos diferentes, además de que la app la construyeron los dinosaurios y usaba backbone viejito y para poder actualizar a react sin afectar a otros equipos, cada equipo empezó a migrar a MFEs a su ritmo. Nosotros resolvimos el problema de actualizar una versión de una librería en 10+ repos simulando un dependabot porque no lo han habilitado en nuestro github jaja. También tenemos un repo con puras configuraciones, eslint, jest, storybook, webpack, etc, para mantener configuraciónes consistentes en todos los MFEs. Ahora mantenemos cerca de 30 repos de UI y back y de alguna manera creo que estanos mucho mejor que con el monorepo 😅

  3. Cómo salir de la deuda técnica

    00:03 – 🔄 Un cambio simple en la interfaz tomó 3 días debido a la falta de mantenibilidad del código y una pobre experiencia de desarrollo.

    01:08 – ❓ Los managers con conocimientos técnicos se preguntaban por qué un cambio simple tomaba tanto tiempo.

    01:28 – 💼 La presión para entregar cambios llevó al equipo a experimentar burnout.

    02:01 – 🔥 El burnout es común en la ingeniería de software, impulsado por exceso de trabajo y falta de control en decisiones.

    02:23 – 🚨 La prioridad en entregar valor a los estudiantes hizo que el equipo no abordara la deuda técnica.

    03:00 – 🧑‍💻 El manager intentó hacer el cambio por sí mismo, pero también le tomó 3 días, revelando los problemas subyacentes.

    03:36 – 📝 El proceso para realizar un cambio incluía múltiples pasos complicados, que extendían el tiempo necesario.

    05:28 – ⏳ Los despliegues de micro frontends añadían 15 minutos extra por cada uno, acumulando más tiempo en el proceso.

    06:12 – 🏛 Las empresas antiguas, como bancos, enfrentan desafíos similares al intentar implementar nuevas tecnologías.

    06:28 – 📉 La deuda técnica puede afectar la capacidad de una empresa para entregar valor constante, lo que puede llevar a su fracaso.

    07:13 – 🛠 Cambios en la arquitectura, refactorización y automatizaciones, aunque invisibles para el usuario, agregan valor positivo.

    07:46 – 🚀 El equipo consideró cambiar de un sistema de multirepo a monorepo para mejorar la eficiencia.

    09:02 – 🔄 Un monorepo permite compartir código eficientemente y mantener control de versiones en todos los proyectos.

    09:32 – 📄 El equipo decidió realizar una prueba de concepto para evaluar la viabilidad de adoptar un monorepo.

    10:03 – 🌟 El momento para la prueba de concepto coincidió con un rebranding de la plataforma, lo que facilitó el cambio.

    10:46 – 💡 Se adoptó una nueva forma de trabajar con monorepo, mejorando significativamente los procesos.

    11:03 – ⚙ En 2024, un simple pull request (PR) actualiza la librería en todas las aplicaciones dentro del monorepo.

    12:00 – 🚀 Los 12 pasos anteriores se simplificaron a un solo PR, acelerando enormemente los procesos de desarrollo.

    12:40 – 🔧 La implementación de monorepo eliminó las barreras que antes complicaban la entrega de valor.

    13:10 – ⏩ Ahora, el equipo puede responder más rápidamente a las necesidades de los estudiantes y del producto.

    14:20 – 🛡 Se mejoró la mantenibilidad y la experiencia de desarrollo, evitando futuros problemas de burnout.

    15:30 – 📈 La eficiencia aumentó considerablemente, permitiendo al equipo enfocarse en innovación y mejoras constantes.

    16:00 – 💪 La adopción de monorepo fortaleció la colaboración y el control de versiones, mejorando el rendimiento global del equipo.

  4. Excelente mi niña, me encantó tu gracia para explicar, te felicito, parar para avanzar, no parar de estudiar son la clave👏👏👏👏🎉🎉🎉

  5. Muy buen video, me gusta la explicación impecable de la persona al igual que el ejemplo, incluyendo un curso relacionado y aprendiendo un nuevo término “deuda técnica” Sigan haciendo este tipo de videos!

  6. Que historia tan interesante, conocer proceso de desarrollo reales, tecnologías que si se utilizan. Y esta bueno el nuevo diseño de Platzi, pero aún tienen varias mejoras, el que más noto es en el chat de los lives cuando hago la ventana con un width pequeño y height alto, o cuando está en un monitor vertical 🙁

  7. Quizás lo q más da sentido de todo el video sea el final. La deuda técnica existe, es real, pero la voluntad de cambiar y de hacer las cosas bien también, es real. Si el codigo no me gusta lo cambio (local) y luego lucho por cambiarlo y q lo entienda el equipo (en prod). Yo no se, estoy borracho jjj

  8. Yo llevo un tiempo buscando soluciones a este problema, pdro en backends python y docker. Parece un problema sin solucion sencilla…

  9. Recuerdo cuando en una clase de maquetado con css, la profesora va y muy tranquila pone un !important al codigo, jajaja que que algo tiene que ver eso con que se pierda la claridad del codigo

  10. La solución es dividir las tareas para dos grupos, uno que tenga TODO el boundle de ingeniería que nos mostraste (todas esas etapas, revisiones, etc) y otro encargado de tareas de mínimo esfuerzo (colores, detalles de css, cambio de imágenes, etc). Esto es como en los negocios que tienen una caja chica, donde precisamente sirve para dar un flujo rápido a transacciones de menor valor y otro donde tienes un ejecutivo de cuenta. Me hago entender? No todo el proceso debe estar apegado a una norma de super cuidados.