DEV Community: Judlup Luna

No todos los proyectos se desarrollan con IA igual

Judlup Luna — Sat, 11 Jul 2026 15:57:50 +0000

Por qué los proyectos nuevos, pre-IA y legacy necesitan estrategias diferentes

La inteligencia artificial está cambiando la forma en que construimos software. Hoy podemos usar asistentes y agentes para generar código, explicar módulos, crear pruebas, revisar errores, proponer arquitecturas o documentar partes de un sistema. Todo eso suena poderoso, y lo es, pero hay una idea que muchas veces se pasa por alto: no todos los proyectos están igual de preparados para trabajar con IA.

No es lo mismo usar IA en un proyecto que apenas empieza, que usarla en un producto que ya tiene varios años de evolución, o en un sistema legacy donde tocar una línea de código puede romper un comportamiento que nadie entiende del todo. La IA puede acelerar el desarrollo, pero cuando el proyecto no tiene contexto suficiente, también puede acelerar errores, deuda técnica y decisiones mal alineadas.

Por eso, antes de hablar de desarrollo asistido por IA, necesitamos hablar del estado real del proyecto. No se trata solo de preguntarle mejor a la IA, sino de preparar mejor el conocimiento que la IA necesita para ayudar.

Ahí es donde entra Kaddo.

El error: pensar que la IA funciona igual en todos los proyectos

Una idea común es asumir que basta con abrir un editor con IA, conectar el repositorio y empezar a pedir cambios. Podemos pedirle cosas como “agrega esta funcionalidad”, “refactoriza este módulo”, “crea una API” o “moderniza este código”. El problema es que esas instrucciones no significan lo mismo en todos los proyectos.

En un proyecto nuevo, la IA puede ayudar a estructurar desde cero. En un proyecto existente, primero necesita entender qué ya existe antes de proponer cambios. Y en un sistema legacy debe actuar con mucho más cuidado, porque muchas decisiones no están documentadas y parte del conocimiento vive en la cabeza de pocas personas.

El problema no es usar IA. El problema es usarla sin considerar el estado real del proyecto.

Para trabajar con IA de forma más responsable, podemos pensar en tres tipos de proyectos: new, pre-IA y legacy. Esta clasificación no busca etiquetar un proyecto para siempre, sino responder una pregunta práctica: ¿qué necesita saber la IA antes de ayudarnos a construir?

1. New projects: cuando el conocimiento se puede crear desde el inicio

Un proyecto new es un proyecto que está empezando. Todavía no tiene demasiada deuda técnica, decisiones ocultas o capas históricas difíciles de entender. Eso no significa que sea fácil, pero sí representa una oportunidad muy valiosa: crear una base de conocimiento desde el primer día.

En este tipo de proyecto, el mayor riesgo no suele ser romper algo existente, sino avanzar rápido sin dejar claridad sobre lo que se está construyendo. Al comienzo todo parece evidente: el equipo sabe qué quiere hacer, las decisiones están frescas, los acuerdos viven en conversaciones recientes y la arquitectura todavía parece simple. Sin embargo, con el tiempo, esa claridad empieza a diluirse.

Lo que al inicio era una conversación rápida termina convirtiéndose en una decisión invisible. Después llega una nueva persona al equipo, se retoma el proyecto semanas más tarde o se usa un agente de IA para continuar el trabajo, y muchas respuestas empiezan a depender de suposiciones.

En un proyecto nuevo, la IA puede ser muy útil para ayudar a definir el contexto del negocio, la intención del producto, los primeros módulos, las decisiones iniciales de arquitectura, el roadmap, los work items y los criterios de entrega. Pero la IA no debería inventar el negocio ni decidir sola la arquitectura. Su rol debería ser ayudar a estructurar el pensamiento del equipo.

En este escenario, la clave no es darle a la IA un repositorio enorme para analizar, porque probablemente ese repositorio todavía no existe o está apenas naciendo. La clave es construir una base mínima de conocimiento que acompañe el crecimiento del proyecto. No hace falta documentarlo todo; hace falta documentar lo suficiente para que el equipo y la IA entiendan qué problema se está resolviendo, para quién se está construyendo, qué decisiones se han tomado, qué restricciones existen y cómo se espera que evolucione el producto.

Cómo ayuda Kaddo en proyectos new

En proyectos nuevos, Kaddo ayuda a crear una estructura inicial de conocimiento sin convertir el proceso en una carga innecesaria. La idea no es empezar con una documentación gigante, sino con una base mínima que conecte negocio, producto, tecnología, delivery, roadmap y work items.

Esto permite que el proyecto nazca con memoria desde el inicio. Y eso cambia mucho la forma en que se usa IA, porque un agente no solo necesita código para ayudar; también necesita intención.

Un proyecto nuevo bien preparado puede usar IA para acelerar sin perder dirección.

2. Pre-IA projects: cuando el proyecto existe, pero no fue preparado para agentes

Un proyecto pre-IA es un proyecto que ya existe, pero que fue creado antes de que el equipo pensara seriamente en asistentes, copilotos o agentes de IA. Puede ser un proyecto sano, con buen código, pruebas y documentación parcial, pero probablemente no fue diseñado para responder preguntas como: qué contexto necesita un agente antes de modificar un módulo, qué decisiones arquitectónicas debe respetar o qué partes del código están conectadas con cada capacidad del negocio.

Este tipo de proyecto es muy común. No necesariamente está roto y no necesariamente es legacy. Simplemente no fue preparado para trabajar con IA de forma consistente.

El problema aparece cuando cada asistente o agente empieza a explorar el repositorio desde cero. Lee archivos, intenta inferir arquitectura, busca patrones, analiza nombres de carpetas y propone cambios a partir de señales parciales. Esa exploración se repite una y otra vez, porque cada nueva sesión vuelve a descubrir lo mismo.

El resultado es que la IA puede ayudar, pero no siempre de forma alineada. Un agente puede entender el proyecto de una manera hoy y de otra forma mañana. Un desarrollador puede explicarle el contexto de una forma y otro desarrollador de otra. Así, el proyecto empieza a depender demasiado de prompts individuales, en lugar de tener una base compartida de conocimiento.

En un proyecto pre-IA, el primer paso no debería ser pedirle a la IA que cambie código. El primer paso debería ser entender el proyecto.

Antes de implementar, conviene reconstruir capacidades del producto, arquitectura actual, módulos principales, dependencias, convenciones, roadmap, ownership, riesgos y decisiones existentes. La IA puede ayudar mucho en esa exploración, pero necesita trabajar sobre un contexto preparado, no sobre piezas sueltas.

La pregunta cambia. Ya no es solo: “¿qué puede generar la IA?”. La pregunta correcta es: ¿qué necesita entender la IA antes de generar algo?

Cómo ayuda Kaddo en proyectos pre-IA

En proyectos pre-IA, Kaddo ayuda a pasar de un repositorio existente a una capa de conocimiento más clara. El flujo puede iniciar escaneando señales técnicas del repositorio, preparando un context pack para agentes LLM y usando agentes especializados para interpretar capacidades, arquitectura, roadmap y posibles work items.

Después, ese conocimiento puede conectarse con ownership, decisiones y partes reales del código. Además, comandos como guard ayudan a detectar cuando el código cambia pero el conocimiento relacionado no se actualiza, mientras que explain permite entender qué sabe Kaddo del proyecto y qué falta por completar.

Esto cambia la dinámica. La IA deja de trabajar solo desde archivos sueltos y empieza a trabajar desde conocimiento estructurado.

Kaddo no pretende “entender mágicamente” el proyecto. Su valor está en ordenar señales, preparar contexto y facilitar que humanos y agentes trabajen mejor sobre una base compartida.

3. Legacy projects: cuando cambiar código implica riesgo real

Un proyecto legacy no es simplemente un proyecto viejo. Un sistema legacy es un sistema donde el cambio es riesgoso porque el conocimiento está incompleto, disperso o concentrado en pocas personas.

Puede tener código antiguo, poca documentación, dependencias frágiles, reglas de negocio escondidas, módulos que nadie quiere tocar y procesos que funcionan en producción aunque nadie se atreva a modificarlos. También puede seguir generando mucho valor para la organización. De hecho, muchos sistemas legacy son críticos precisamente porque llevan años sosteniendo procesos importantes.

En este tipo de proyecto, la IA puede ser útil, pero también puede ser peligrosa si se usa con demasiada confianza. Una sugerencia aparentemente correcta puede romper una regla invisible. Una refactorización elegante puede ignorar una decisión histórica. Una recomendación de modernización puede desconocer dependencias operativas que nunca fueron documentadas.

En legacy, el problema no es solo técnico. Es un problema de conocimiento.

Antes de cambiar, hay que entender. Antes de modernizar, hay que mapear riesgos. Antes de automatizar, hay que identificar zonas frágiles.

Por eso, en un proyecto legacy, la IA no debería entrar como “desarrollador rápido”, sino como apoyo para una exploración controlada. El objetivo inicial no es producir más código, sino reducir incertidumbre.

En este escenario conviene identificar riesgos, unknowns, módulos críticos, ownership, dependencias ocultas, reglas de negocio implícitas, candidatos de modernización y zonas que no deberían tocarse sin validación humana. La IA puede ayudar a analizar, resumir, comparar y proponer hipótesis, pero las decisiones deben seguir bajo control del equipo.

En legacy, la velocidad sin contexto es una amenaza.

Cómo ayuda Kaddo en proyectos legacy

En proyectos legacy, Kaddo ayuda a trabajar con más cuidado. No promete modernizar un sistema con magia ni reemplazar el criterio del equipo. Su valor está en ayudar a estructurar señales, riesgos y conocimiento antes de cambiar código.

En un proyecto legacy, Kaddo puede ayudar a construir artefactos como riesgos, unknowns, candidatos de modernización, arquitectura actual, capacidades del producto, roadmap, work items pequeños y ownership asociado al código. Esto permite que la evolución del sistema sea más trazable.

En lugar de pedirle a la IA “moderniza este sistema”, el equipo puede avanzar por piezas más pequeñas, con contexto, con riesgos visibles y con mayor control.

La diferencia no está en la IA, está en el contexto

Los tres tipos de proyecto pueden beneficiarse de la IA, pero no de la misma forma. Un proyecto nuevo necesita crear conocimiento desde el inicio. Un proyecto pre-IA necesita reconstruir y estructurar contexto antes de evolucionar. Un proyecto legacy necesita reducir incertidumbre antes de cambiar código.

Tipo de proyecto	Qué necesita primero	Riesgo principal	Enfoque recomendado
New	Crear base de conocimiento	Avanzar sin dirección	Estructurar intención, roadmap y decisiones desde el inicio
Pre-IA	Reconstruir contexto	Que la IA interprete desde señales parciales	Escanear, empaquetar contexto y alinear agentes
Legacy	Reducir incertidumbre	Romper reglas invisibles	Mapear riesgos, ownership y cambios pequeños

La idea central es simple: la IA no debería abordar todos los proyectos igual porque no todos los proyectos tienen el mismo nivel de conocimiento disponible.

Kaddo como capa de conocimiento para IA

Kaddo parte de una idea muy concreta: los proyectos ya tienen conocimiento, pero suele estar disperso. Parte vive en el código, parte en tickets, parte en documentos, parte en conversaciones, parte en decisiones que nadie escribió y parte en personas que han estado cerca del sistema durante años.

El objetivo de Kaddo es acercar ese conocimiento al repositorio y convertirlo en contexto útil para humanos y agentes de IA. No se trata de hacer documentación pesada, sino de crear una capa mínima, viva y accionable de conocimiento.

Esa capa ayuda a responder preguntas clave: qué sabemos del proyecto, qué falta por entender, qué decisiones existen, qué partes del código están relacionadas, qué work items están activos, qué ownership existe y qué debería revisar el equipo antes de cambiar algo.

CLI determinístico, interpretación humana y agentes LLM

Una parte importante de Kaddo es la separación de responsabilidades. El CLI hace trabajo determinístico: escanea, empaqueta contexto, crea estructura, detecta señales, relaciona cambios con conocimiento y explica el estado del proyecto.

Pero Kaddo no intenta reemplazar la interpretación humana. La interpretación ocurre con humanos y agentes LLM externos, usando el contexto que el proyecto ha preparado.

Esto es importante porque evita una falsa sensación de autonomía. Kaddo no dice: “yo entiendo tu proyecto, confía en mí”. La propuesta es más responsable: “aquí está el contexto estructurado; úsalo con tu equipo y tus agentes para tomar mejores decisiones”.

Esa diferencia importa mucho cuando hablamos de proyectos reales.

El ciclo de Kaddo

Kaddo puede verse como un ciclo de conocimiento que acompaña la evolución del proyecto. Primero se escanean señales técnicas, luego se prepara contexto para agentes, después se interpreta el estado del proyecto y se crean artefactos como roadmap, work items y ownership. A partir de ahí, guard ayuda a detectar posibles desalineaciones entre cambios de código y conocimiento, mientras que explain permite entender qué sabe Kaddo, qué falta y cómo está evolucionando el proyecto.

Este ciclo no busca crear más proceso por deporte. Busca evitar que cada interacción con IA empiece desde cero.

Por qué esto importa para equipos reales

En equipos reales, el problema no es solo escribir código. El reto está en coordinar conocimiento: saber qué se decidió, por qué se decidió, qué no se debe romper, qué partes del sistema son críticas, quién entiende cada módulo y qué cambios requieren más cuidado.

La IA puede ayudar mucho en ese escenario, pero solo si trabaja con contexto real. Sin contexto, la IA puede sonar segura y estar equivocada. Con contexto, puede convertirse en una herramienta mucho más útil para explorar, construir, revisar y evolucionar.

No se trata de IA-first, se trata de knowledge-first

Muchos equipos están intentando volverse AI-first. Eso puede sonar atractivo, pero antes de ser AI-first, muchos proyectos necesitan ser knowledge-first.

La IA necesita una base sobre la cual razonar. Un proyecto sin conocimiento estructurado obliga a la IA a adivinar; un proyecto con conocimiento vivo le permite colaborar.

Esa es la diferencia, no se trata de usar menos IA. Se trata de usarla mejor.

Conclusión

No todos los proyectos se desarrollan con IA igual, un proyecto nuevo necesita crear conocimiento desde el inicio. Un proyecto pre-IA necesita reconstruir y estructurar contexto antes de evolucionar. Un proyecto legacy necesita reducir incertidumbre antes de cambiar código.

La IA puede ser útil en los tres casos, pero la estrategia debe cambiar. Kaddo propone una forma de abordar esa diferencia: construir una capa viva de conocimiento cerca del código, preparar contexto para humanos y agentes de IA, y mantener trazabilidad entre decisiones, trabajo y evolución del sistema.

Porque el futuro del desarrollo asistido por IA no depende solo de mejores modelos. Depende también de mejores proyectos para trabajar con IA.

Y un mejor proyecto no es solo el que tiene más código, es el que recuerda por qué ese código existe.

You Don't Know JS: Up & Going: Una guía esencial para principiantes

Judlup Luna — Mon, 16 Oct 2023 21:25:56 +0000

Si estás comenzando tu viaje en el mundo de la programación o simplemente quieres adentrarte en el universo de JavaScript, es probable que alguien te haya recomendado el libro "You Don't Know JS: Up & Going" de Kyle Simpson. Pero, ¿de qué trata este libro y cómo puede ayudarte en tu proceso de aprendizaje? Aquí te lo explicamos.

¿De qué trata "You Don't Know JS: Up & Going"?

"You Don't Know JS: Up & Going" es el primer libro de la serie "You Don't Know JS". Esta serie tiene como objetivo proporcionar una comprensión completa de JavaScript, profundizando en sus mecanismos centrales y matices. El libro está diseñado para aquellos con experiencia limitada en programación, presentándoles los bloques básicos de la programación y los mecanismos centrales de JavaScript.

Características clave:

Aprende los bloques esenciales de programación, incluyendo operadores, tipos, variables, condicionales, bucles y funciones.
Familiarízate con los mecanismos centrales de JavaScript, como valores, cierres de funciones, "this" y prototipos.
Obtén una visión general de otros libros de la serie y comprende la importancia de captar todos los aspectos de JavaScript.

Comprar el libro

¿Cómo leer ""You Don't Know JS: Up & Going"

Si bien puedes leer el libro de principio a fin, también puedes optar por leer las partes que sean más relevantes para tu nivel actual de conocimiento y experiencia. Te recomendamos comenzar con los bloques esenciales de programación para tener una base sólida. Luego, puedes adentrarte en los mecanismos centrales de JavaScript para entender cómo funciona el lenguaje en profundidad.

Partes recomendadas

Si eres un principiante, te sugerimos comenzar con los bloques básicos de programación para obtener una comprensión fundamental. A medida que te sientas más cómodo, puedes explorar los mecanismos centrales de JavaScript, lo que te proporcionará una visión más profunda del lenguaje.

Conclusión

"You Don't Know JS: Up & Going" es una herramienta invaluable para aquellos que desean comprender JavaScript en su totalidad. Aunque puede parecer un poco desafiante al principio, su enfoque detallado y su explicación clara de los conceptos lo convierten en una lectura esencial para cualquier aspirante a desarrollador de JavaScript.

Recuerda, no tienes que entender todo de inmediato. Tómate tu tiempo para digerir la información y no dudes en volver a las secciones que encuentres más desafiantes. Con paciencia y perseverancia, descubrirás que "You Don't Know JS" puede llevarte a un nuevo nivel de comprensión y habilidad en el mundo de JavaScript.

Buenas prácticas en desarrollo de software

Judlup Luna — Sat, 04 Feb 2023 07:01:23 +0000

El desarrollo de software es un proceso complejo y requiere de mucha planificación y ejecución adecuada para garantizar un producto de alta calidad. Aquí hay algunas buenas prácticas que deben seguirse para lograr un buen desarrollo de software:

Planificación: Antes de comenzar el desarrollo, es importante tener un plan claro y detallado de lo que se desea lograr. Este plan debe incluir los objetivos, el alcance, los requisitos del usuario, el plazo de entrega y el presupuesto.
Documentación: La documentación es esencial para un buen desarrollo de software. Todos los procesos y decisiones importantes deben ser documentados para que sea fácil de seguir y mantener.
Pruebas: Las pruebas son una parte esencial del desarrollo de software. Todos los componentes del software deben ser probados exhaustivamente para asegurarse de que cumplen con los requisitos y funcionan correctamente.
Codificación limpia: Es importante escribir código limpio y bien estructurado. Esto ayuda a mantener el software fácil de leer y de mantener, y a reducir los errores y los problemas de compatibilidad.
Control de versiones: El control de versiones es esencial para el desarrollo de software. Permite realizar un seguimiento de los cambios realizados en el código y hacer copias de seguridad fáciles.
Colaboración: La colaboración es clave en el desarrollo de software. Es importante trabajar en equipo y compartir ideas para lograr un producto de alta calidad.
Seguridad: La seguridad es un aspecto crítico en el desarrollo de software. Es importante tomar medidas para proteger los datos y asegurarse de que el software sea seguro y cumpla con los estándares de seguridad.

Siguiendo estas buenas prácticas, se puede lograr un desarrollo de software eficiente, de alta calidad y con una buena documentación. Al final, esto asegurará un producto final sólido y satisfactorio para los usuarios.

Generando equipos de desarrollo de software competitivos

Judlup Luna — Wed, 18 Jan 2023 22:20:13 +0000

La industria de la tecnología hoy en día está en un constante crecimiento acelerado, lo que ha generado que se requiera mucho más talento para contribuir a la construcción de los retos que surgen en cada una de las compañías; con este proceso acelerado surgen muchos problemas ligados, de los más comunes es el proceso de adaptación de nuevos miembros al equipo (del cuál luego hablaré), cómo ayudar a desarrollar la carrera de cada miembro, los retos técnicos, mantener el equipo alineado y motivado, entre muchos más.

Precisamente ahí es donde el desarrollo de un equipo que tenga una serie de características intangibles pero esenciales para alcanzar los objetivos propuestos en el colectivo son importantes, dentro de las características que se pueden destacar de un equipo que logra lo que se propone tenemos:

Comunicación
Independencia
Participación activa
Visión compartida
Know-how colectivo
Ownership
Colaboración

Para lograr cada una de estas características es importante que el equipo haga consciencia de que cada paso es necesario para cultivar esa cultura que en un corto/mediano plazo les permitirá llegar a tener un proceso que facilite el desarrollo del día a día.

Los siguientes aspectos permititen la construcción de un equipo competitivo:

Reglas claras
Establecer unas reglas claras, y con un enfoque a promover la participación, la comunicación y el respeto por las diversas ideas es fundamental cuando el objetivo en todos los miembros es el mismo y está claro en todo momento.

Todos viendo el mismo horizonte
Difundir la visión dentro del equipo es algo esencial, la información es un privilegio, pero un equipo que no tiene la información que le permita saber hacía dónde se dirigen genera mucha penumbra y hace que todo sea difícil de avanzar, invertir tiempo en que cada miembro del equipo tenga claros los objetivos facilitará mucho el poder avanzar sin tantas trabas.

El problema es de todos, la solución también
Permitir que cada miembro del equipo participe de manera activa sin temor a ser señalado o cuestionado y reconociendo cada participación incrementa y fomenta el espíritu de comunicación en los miembros del equipo, además de que hacer esto facilita la construcción de soluciones con muchos más puntos de vista pero con el mismo enfoque, el resultado, una solución robusta, contundente y eficaz.

Una persona que decide todo solo no es funcional
Un equipo donde un miembro lleva total y arbitrariamente las decisiones puede denotar un autoritarismo que puede generar un mal ambiente, una desmotivación que crece constantemente dentro de los miembros del equipo al solo limitarse a recibir porciones de trabajo para realizar sin un objetivo claro en su mente, sin entender el impacto del mismo en el equipo y en el proyecto, de ahí que la delegación de las actividades sea una clave en el éxito de un equipo productivo y competitivo, un colectivo que puede expresar sus opiniones y aportar soluciones en la construcción del proyecto sabiendo que no siempre se podrán implementar todas las posibilidades, pero si siempre serán escuchadas y se implementarán en aras de la conveniencia del proyecto y no de un interés particular va a mantener motivado al equipo.

O todos en la cama, o todos en el piso
También hay que tener un sacramento importante dentro del equipo, como un código de la calle que reza: "No señalar en público, reconocer en público, corregir en privado" esto facilita la construcción de un equipo que no tiene miedo a equivocarse, por lo que lo hará más rápido y le permitirá aprender de ello lo más pronto, el nivel de madurez es superior al de un equipo monosílabo centrado en el líder y no en el equipo, bien dicen, si sale todo bien, felicidades a todos, y si sale algo mal, nos sale mal a todos, no particularizar los errores y asumirlos como equipo facilita el aprendizaje y superar situaciones complejas.

La confianza en todos los aspectos es esencial
Como en todo proceso, el desarrollo de procesos independientes se da con confianza, pero el líder es quién da el primer paso encomendando tareas con un alcance global claro, pero dejando el camino despejado para que el miembro del equipo desarrolle la habilidad de planear, identificar, ejecutar y sobre todo equivocarse sin reproches, incrementando su nivel de confianza a la par que sus habilidades van creciendo de manera que el equipo se va consolidando desde lo individual.

Conocer el equipo es fundamental
Conocer a cada miembro del equipo, esto es fundamental, conocer sus objetivos, deseos, debilidades va a facilitar al asignación acertada de las tareas, por otra parte, conociendo los anhelos profesionales de cada miembro del equipo es más fácil identificar oportunidades en el día a día que les permita bien sea hacer una actividad en un enfoque en el que esa persona quiere crecer, de allí la importancia de que el interés y escucha por parte del líder es fundamental y debe ser siempre genuino.

Todo se centra en la comunicación
Cuando el equipo puede comunicarse mejor, empieza la etapa en la que los obstáculos que se presentan se pueden resolver más rápido mediante la intervención de los diferentes miembros, una característica de un equipo sólido que puede llegar tan lejos como se lo propongan.

SCRUM ayuda, y mucho…

Ahora, como medir si todo funciona, personalmente trabajo utilizando metodologías ágiles, particularmente SCRUM, dentro de esta metodología existe una ceremonia que muchos obvian, pero desde el punto de vista de equipo es la más importante, la retrospectiva, esta ceremonia no debería ser opcional; hace un tiempo, trabajando con un equipo de desarrollo de Estados Unidos vi que utilizaban una herramienta llamada Easy Retro, lo que me llamó la atención de esta herramienta y cómo la utilizaban era que era: anónima, concreta, daba un golpe de confianza, reconocimiento y visibilizaba lo que muchos piensan, pero pocos dicen, así luego de esto, esta herramienta me ha acompañado en mis experiencias como líder.

En esta plataforma se crean tableros en tiempo real que permiten a los miembros del equipo escribir de manera anónima diferentes tarjetas que he repartido en cuatro columnas sencillas: "¿Qué hicimos bien?", "¿Qué podemos mejorar?", "Reconocimientos" y "Preguntas", la siguiente imagen es una refererencia de cómo luce la plataforma:

El valor de estas cuatro preguntas:

"¿Qué hicimos bien?"
Permite identificar las cosas que se lograron por parte del equipo, en lo técnico o en las habilidades del equipo, este es el espacio para escribir de lo que todo el equipo se siente orgulloso de haber logrado en el último sprint, visibilizar cuanto se puede conseguir si todos trabajan en conjunto y cómo los aportes individuales ayudan a todo el equipo a lograr lo comprometido.

"¿Qué podemos mejorar?"
Siempre reconocer lo bueno es fácil en estos casos, decir en qué se falla sin temor a ser identificado o sufrir alguna represalia o presión es clave, en un comienzo el equipo se toma un tiempo en escribir aquí, luego de que el primero se anima, la magia ocurre, problemas técnicos, de alcance, de comunicación, o cualquier problema que surgió durante el sprint aparecerá en el tablero de manera anónima, todos ven y entienden el problema, pero lo más importante, pueden expresarlo, cómo líder poder ver esta información, entenderla, y adoptarla potencializa y acelera la consolidación del equipo, fortaleciendo al equipo a decir cosas incómodas de una manera segura, el día que una situación realmente se pone tensa, el equipo la podrá soportar llegando a soluciones objetivas y sin fricciones que se tornen personales.

"Reconocimientos"
Esta sección cuando trabajé con el equipo de Estados Unidos, fue una de las que más me llenó de confianza y me gustó, apesar de que en un comienzo se me hacía un poco innecesaria, luego entendí el valor que tiene en lo individual y para todo el equipo; en esta sección el equipo escribe agradecimientos o reconocimientos a personas del equipo por su labor o por un reto encarado durante el sprint que facilitó la obtención de los resultados, dan la bienvenida a los nuevos miembros o los felicitan por sus primeros "pinitos", ver como el nombre de todos empieza a aparecer llena de mucha satisfacción y por ende cada miembro del equipo sabrá que todo esfuerzo no pasará en desapercibido en el equipo.

"Preguntas"
Esta última sección está dedicada a las preguntas que se mantienen en silencio o que por pena no se hacen en público o en privado, algo particular de esta sección es que termina siendo la sección más graciosa de la retrospectiva, allí propuestas de viajes, preguntas irreverentes o bromas con los logros de alguien en particular o del equipo amenizan la reunión y saca una sonrisa en cada miembro del equipo.

Luego de unos 10 minutos de silencio de ver como aparecen mensajes en el tablero, el líder procede a leer tarjeta tras tarjeta, sección tras sección y dará respuesta o reflexión a cada punto, será la voz del grupo para y por el grupo.

Cultura, lo es todo

Un equipo competitivo es algo que se dice fácil, pero que cuesta mucho construirlo, esto surge desde el proceso de selección, desde allí el enfoque a la cultura del equipo como punto decisorio por encima de lo técnico garantiza que las personas van a compartir los mismos valores y cultura facilitando los procesos de integración al equipo del nuevo miembro, así como el onboarding técnico al encontrar un equipo sólido, que se comunica y siempre está dispuesto a ayudar a los demás.

Un equipo competitivo se construye desde el mindset, no desde lo técnico, no caer en micromanagement, no ser invasivo, dejar opinar, equivocarse, participar, delegar, dejar liderar micro procesos, animar, dar confianza y seguridad a los miembros les permitirá sprint tras sprint construir lo que a mediano plazo será el equipo ideal, nada como que un miembro sugiera algo y en los siguientes sprints vea al menos parcialmente que su sugerencia fue tomada en cuenta y está siendo implementada, ese incentivo motiva y motiva muchísimo.

Paciencia, todo es un proceso..

Si pensáramos en como se da este proceso diría que es por etapas de la siguiente manera:

La primer etapa del proceso de formación de un equipo competitivo es de mucha paciencia, identificar puntos a mejorar, iterarlos y entender que los resultados no se ven de forma instantánea sino al paso de los sprints (en el caso que se trabaje con metodologías ágiles).

La segunda etapa es enfocarse con mayor contundencia en cumplir con compromisos más exigentes con la mayor disposición del equipo y con todo el interés por cada miembro del equipo.
El liderazgo de equipos competitivos es un reto que hoy en día da réditos a quienes están involucrados en este proceso, no solo al líder del equipo; Los retos de la industria tech cada día son más exigentes, por lo tanto crear y ser parte de un equipo competitivo que va más allá de las hard skills o habilidades técnicas es fundamental para la obtención de los objetivos, allí es donde las soft skills y la cultura hacen parte importante del éxito de un equipo élite.

Gracias por tomarse el tiempo de leer este contenido, espero les sea de utilidad 😊✌

Roadmap del consultor tecnológico

Judlup Luna — Sun, 01 May 2022 23:50:29 +0000

En la actualidad el mundo de la tecnología avanza a pasos agigantados, desde que apareció el COVID-19, a pesar de lo devastador que ha sido y el daño causado, algunos sectores productivos se han visto beneficiados en medio de todo lo malo, este ha sido el caso particular del sector de la tecnología, sector el cual ha crecido y avanzado en tiempo record lo que se esperaba pasaría en al menos el próximo quinquenio, esto ha permitido que empresas como Zoom hayan crecido exponencialmente, con este boom también es normal que muchas personas de diversas profesiones empiecen a ver en la programación una vía de desarrollo profesional y personal, las comodidades del trabajo remoto, los excelente beneficios y los salarios han provocado un gran éxodo de personas al área de la tecnología.

Ahora, gracias a esta escalada también la demanda de mentes con capacidades extraordinarias que puedan encaminar y conseguir los retos que se viene presentando son apetecidas en todo el mundo, ahí es donde roles como el de consultoría empiezan a ser trascendentes y se empieza a hablar de transformación digital, muchas compañías empezaron a moverse por integrar procesos tecnológicos en sus procesos, ya no como método de competencia, sino como vía de supervivencia.

Es claro que ante estas oportunidades de un magnífico momento muchas personas pueden optar por empezar a hacerse llamar “consultores” que se terminan aprovechando de empresarios con un afán por no desaparecer y con un mundo de desconocimiento e incertidumbres y terminan accediendo ante estas personas que, por el contrario de llegar a facilitar el proceso, pueden terminar siendo la estocada que le faltaba a la empresa al encaminar erradamente las estrategias y generar un desangre de recursos de una compañía sin ningún resultado.

Un consultor no es precisamente alguien que recién egresa o domina una tecnología para realizar una implementación, un consultor es una persona que tiene la preparación y conocimiento para asumir retos, pero lo más importante es que tiene una amplia experiencia en procesos complejos en donde la toma de decisiones es clave para el éxito u obtener los resultados esperados.

Una ruta para ser consultor empieza sin siquiera pensar en que ese será el fin, un consultor no es más que alguien que es un apasionado por lo que hace, que para llevarlo a un ejemplo, veamos alguien que empieza como programador, su inicio se fundamenta en los primeros años de adolescencia, el gusto por entender cómo funciona un computador puede llevarlo a tomarse horas y horas buscando acerca de esto, lo cual con el tiempo terminará preguntándose cómo puedo hacer mi propio software y cuales son los recursos necesarios para llevar a cabo el cometido, de esa manera termina aprendiendo un lenguaje de programación, digamos, JavaScript, luego de un tiempo termina su bachillerato y decide ingresar a la universidad a estudiar ingeniería de sistemas, allí solidifica sus hipótesis y empieza a ir por un camino más amplio, sus límites se amplían, participa de proyectos en los que adquiere más conocimientos y expertise en otras tecnologías que no conocía, cerca de finalizar su carrera ya tiene varios proyectos en su mochila, de esa manera consigue su primer trabajo que le permite pagarse sus estudios y lo más importante, empezar la vida profesional, tiempo después obtiene su título y continúa su proceso en la compañía que confió en sus capacidades y le brindó la oportunidad de iniciar como desarrollador junior, de esa manera pasó por un proceso de varios proyectos en los que no solo interactuó como desarrollador, si no se interesó por aportar en la construcción de la solución generando diálogos no técnicos con los clientes internos y externos de los proyectos, lo cuál le permitió adquirir uno de los soft skills más importantes, la comunicación, con el paso del tiempo sus contribuciones al equipo subieron tanto de calidad y precisión, que la empresa decide nombrarlos desarrollador semi senior, su pasión lo llevó a dar más de lo que debía estar dando en su cargo, su carrera continuó avanzando y años más tarde con mucho conocimiento de negocio, contacto con clientes, resolución de problemas y ponencias sobre implementación de buenas prácticas, la empresa decide ascender al desarrollador senior, camino donde empieza a dar mentorías a sus compañeros, a asumir tareas complejas y a ser un referente de su equipo, adicional en su tiempo libre decide hacer certificaciones y estudios complementarios que le permitan adquirir nuevas habilidades, luego de esto la compañía lo cita y le plantea 3 caminos para su carrera, desarrollador senior con un grado superior, arquitecto de software junior o technical lead, cada uno tiene implicaciones distintas a futuro, opta por arquitecto junior, allí empezó a aportar de la mano de arquitectos con una mayor experiencia en la construcción de nuevas soluciones de clientes, sus skills de negociación, entendimiento, dimensionamiento y toma de decisiones fueron creciendo, un tiempo después la empresa decide otorgarle un ascenso como arquitecto senior, allí empieza a tomar las riendas de un proyecto grande en el cuál él decide la tecnología y tiene la capacidad de asesorar a un cliente en cuanto a qué es lo mejor para su implementación, sustentar sus decisiones con el equipo no técnico de la compañía, generar los reportes, traducir todo el proceso al equipo técnico y velar por la correcta construcción de la solución, así como el seguimiento en los ajustes en vivo que iban ocurriendo durante el proceso, debido a esta gran labor la empresa recibe una serie de reconocimientos y otras empresas empiezan a buscar la mente detrás de este logro, en ese punto la decisión moral es ofrecer servicios de consultoría a través de la compañía, entra a otro mercado donde pasa a ser un referente público en temas especializados, luego de un tiempo toma la decisión de dejar la compañía con el mayor agradecimiento y luchando por un sueño propio se convierte en un consultor.

En el anterior ejemplo se denotan habilidades del tipo “hard” como lo son los conocimientos técnicos en una tecnología, los cuales le permitieron avanzar en su carrera profesional, pero dentro de los procesos que también supo entender fue la consecución de habilidades del tipo “soft”, como la comunicación, el liderazgo, el entendimiento de los procesos en ambientes técnicos y no técnicos, además de poder llevarlos de un extremo a otro de manera clara y acertada, de acuerdo al libro Leadership Today, algunos los soft skills que se evidencian en esta persona y que en últimas le facilitaron construir una carrera que se consolidó fueron:

Liderazgo
Comunicación
Confianza
Responsabilidad
Honestidad
Asertividad
Visión
Escuchar
Inteligencia emocional
Sustentabilidad técnica y personal
Conciencia
Empatía
Motivación
Superación
Creatividad
Iniciativa
Auto confianza
Resiliencia
Perseverancia
Estimación
Coherencia
Cohesión

De todo lo anterior podemos evidenciar como el proceso no es una cuestión de meses, es el resultado de una vida de dedicación, enfoque y pasión hacia lo que se hace, lo cual termina convirtiéndose en un profesional que puede contribuir con sus conocimientos y experiencias a otras compañías que tienen diferentes retos y que de no resolverlos de manera oportuna y eficiente, podrían terminar desencadenando una serie de consecuencias que incluso podrían terminar con la compañía, de allí la importancia de realmente contar con profesional con una trayectoria que les facilite la toma de decisiones y las mejores vías de implementación de soluciones que los lleve al siguiente nivel.

Por último, es importante ser bueno técnicamente, pero es aún más importante ser bueno como ser, crecer en valores y llevarlos al plano profesional con el objetivo de engrandecer a quienes confían en las habilidades técnicas, por otra parte el desarrollo de habilidades blandas o “soft skills” les permitirá crecer mucho más rápido en todos los aspectos, en ese punto es donde muchos profesionales se quedan y no encuentran una vía para llevar su carrera profesional al siguiente nivel.

Serverless Community Call 18/11 Serverless Console

Judlup Luna — Wed, 17 Nov 2021 13:40:25 +0000

Serverless Community Call será el día 18 de noviembre, allí se dará a conocer los nuevos cambios de este gran Framework, la actualización más importante es Serverless Console, la cuál está enfocada en potencializar la administración de los recursos, equipos, integraciones (PagerDutty, Slack, DataDog, New Relic, etc), alertas y logs, de esta manera pasa de ser un Framework a una potente herramienta Cloud.

Personalmente he utilizado Serverless Framework y me ha gustado su versatilidad y la manera en que administra facilmente los recursos, por otra parte, la documentación es amplia, y en casos particulares en opciones de configuración muy específicas, se puede acudir a la documentación de CloudFormation de AWS y se puede hacer uso de parámetros no definidos en la documentación.

¿Ya han tenido experiencia con este Framework?

Comparte este post, probablemente sea útil para alguien en tu red, si tienes alguna duda o comentario, no dudes en dejarlo en la parte de abajo.

Regístrate: https://app.livestorm.co/serverless/serverless-community-call-november-2021

🤯Aprende a fácilmente a programar para la web con estos 2 sitios

Judlup Luna — Thu, 28 Oct 2021 13:42:22 +0000

Para quienes se están preguntando, ¿cómo puedo empezar a programar para web? quiero compartirles estos dos sitios bastante útiles:

En este sitio pueden encontrar amplia cantidad de tutoriales y lo mejor, organizado y con casos prácticos, mi sugerencia es que inicien por la sección "Programación Web"
https://www.tutorialesprogramacionya.com/

Otra herramienta muy útil es W3 School, en inglés, pero con un contenido organizado, lleno de casos prácticos y fácil para tener como guía de referencia.
https://www.w3schools.com/

Si conocen algún otro sitio que recomienden, por favor, coméntenlo para que así otras personas puedan obtener este valioso conocimiento. #programacion

DynamoDB Data Modeling (Single Table)

Judlup Luna — Mon, 20 Sep 2021 22:17:01 +0000

Source: https://youtu.be/OfZgHXsYqNE

Steps of the process

Draw an entity diagram
Identify the relationships between entities (1:1, 1:N, N:M)
List down all the access pattern for each entity
Identity the primary key ( Hash + Sort) for each entity
Identify the secondary indexes for additional access patterns if required

Example | Project Management Tool

SAAS Tool
Multi-Tenant Support
Manage Projects and Employees

Step 01 - Draw and ERD

Step 02 - Identify Relationships

Step 03 - Identify Access Patterns

Organization

Organization CRUD operations
Find all the projects of an organization
Find all the employees of and organization
Find all projects and employees of an organization
Find an organization by name

Project

Project CRUD operations
Find a project by name
Find the employees assigned to a project
Find agile projects
Find fixed-bid projects
Find on hold projects

Employee

Employee CRUD operations
Find all the projects an employee is part of
Find an employee by name

Project-Employee

Assign an employee to a project

Step 04 - Identify Primary Key

Pk must be unique

Example Queries

Organization (org-id=1234)

Organization CRUD operations - PK=ORG#1234, SK=#METADATA·1234
Find all the projects of an organization - PK=ORG#1234, SK begins_with(PRO#)
Find all the employees of an organization - PK=ORG#1234, SK begins_with(EMP#)
Find both employees and projects - PK=ORG#1234
Find organization by name - Not satisfied yet

Project (org-id=1234, project-id=100)

Project CRUD operations - PK= ORG#1234, SK=PRO#agile#100
Find a project by name - Not yet satisfied
Find the employees assigned to a project - PK=ORG#1234#PRO#100
Find agile projects - PK=ORG#1234, SK begins_with(PRO#agile)
Find fixed-bid projects - PK=ORG#1234, SK begins_with(PRO#fixed-bid)
Find on-hold projects - Not yet satisfied

Employee(org-id=1234, emp-id=300)

Employee CRUD operations - PK= ORG#1234, SK EMP#300
Find all projects an employee is part of - No yet satisfied
Find all employees by name - No yet satisfied

Step 05 - Identify Secondary Indexes

Find all projects an employee is part of - Use an inverted index

Query on GSI - PK = ORG#1234#EMP#300

Find all organizations, projects, employees by name - GSI Overloading

Find by org name - PK=ORG#1234, filterName=ORG#HappyInc

Find by emp name - PK=ORG#1234, filterName=EMP#Manoj

Find On-hold projects - Use a Sparse Index

You can Query or scan the GSI to find all the on-hold projects

Using Filter Conditions

These are used after the run queries and is necessary to add an extra filter with fields that aren't indexes nor keys.
A filter query is applied after the query finished, but before the results are returned. A query consumes the same amount of read capacity, it not been affected if a filter condition exist
Use filter conditions if the secondary indexes cost more than the filter conditions due to low query velocity or frequency.

Inverted Index

Query on GSI - PK=ORG#1234#EMP#300

The reason to use an inverted index is because of the value to filter that I need is the SK value, so, I can't use a query method without specified a PK, in this way we can swap the PK and SK to become SK in PK and now is possible to do the query.

Note: It's necessary create an index table

GSI

It's used when you need to make a search using a field different to SK to complement the search keys, so, you can create a GSI to make possible it query, in above example, the GSI is created for enable the filter by name query using PK + a new field called Data

Find by org name - PK=ORG1234, Data=ORG#HappyInc
Find by emp name - PK=ORG#1234, Data=EMP#Manoj

Note: It's necessary create an index table

.Net Core 3.0 near to real world ;)

Judlup Luna — Mon, 30 Sep 2019 04:17:09 +0000

The past 4th septembre, Microsoft released dotnet 3.0, this is most stable
version(Microsoft expectancy to world developers), with It Microsoft show their interest into participated actively in real world development environment with their C# (v 8.0), obviousely all this is a nice dream ( for their and their development community), and It's a result to a great and strong work, Microsoft with .Net Core, ASP and Xamarin show us their interest in became in a main tool to real world developers, now with Dotnet Core 3.0 her compatibility with others operative systems as Linux (mainly) and Mac OS, close the existent gap around of developer world.

At this point is necessary remember that the top of OS use in Azure after Microsoft integrate Linux in their platform is Linux OS in differente flavours, with the arraived of Dotnet Core open the opportunities to C# community and potentializes It, this time at difference when Microsoft launched Windows Mobile and their OS, at these moment this iniciative was a great mistake for Microsoft and their community.

Although Microsoft isn't my preferer development environment, this time I think that this is the best success of Microsoft to the next years, open the possibilities to the community is the smarter decition for this company.

dotnet build
dotnet run
dotnet publish

Is a nice cli interface, but as all, always exist some to improve, the management of final product is some confused, the management of different versions or integration of severals architectures, and the compatiblity with 64 bits libraries. Other point less is the visual studio requirements and size of updates.

As a plus point the documentation at site is grow, their structure is nice and this is oriented to practical and quick exercises to ease to curve learn, making interactive the learning.

This references can help you to learn .Net Core:

https://dotnet.microsoft.com/learn/dotnet/hello-world-tutorial/intro

https://www.youtube.com/watch?list=PLdo4fOcmZ0oWoazjhXQzBKMrFuArxpW80&v=eIHKZfgddLM

Dowload center:

https://dotnet.microsoft.com/download

Remember update Visual Studio to use Dotnet core 3.0
Remember you only can use Dotnet 3.0 with Visual Studio 2019

React Native VS Ionic

Judlup Luna — Thu, 31 Jan 2019 16:46:17 +0000

What's the best React Native or Ionic? put below your opinion

13! :]

Hola Mundo

Judlup Luna — Wed, 30 Jan 2019 00:09:28 +0000

Hola Mundo