Adaptarse a un nuevo equipo de desarrollo implica mucho más que escribir código. Desde configurar tu estación de trabajo hasta estimar tareas con precisión, los primeros meses en un entorno profesional de tecnología están llenos de aprendizajes que van más allá de lo técnico. Esta conversación entre dos compañeros de trabajo muestra vocabulario y situaciones reales que cualquier profesional del software encontrará en su día a día.
¿Qué significa hacer onboarding en un equipo de desarrollo?
Cuando alguien se incorpora a un nuevo trabajo, el proceso inicial se llama onboarding [0:24]. En este caso, el desarrollador lleva tres meses en la empresa y reconoce que tuvo un rough onboarding, es decir, un inicio complicado. El problema fue configurar su workstation (estación de trabajo): alguien le indicó instalar un C shell y terminó instalando un seashell por confusión [0:37]. Este tipo de malentendidos es común cuando trabajas en otro idioma y refuerza la importancia de confirmar instrucciones técnicas.
¿Por qué no se debe hacer deploy a producción un viernes?
Una regla no escrita en muchos equipos de ingeniería es nunca desplegar a producción un viernes [0:54]. En la conversación, se menciona que un compañero llamado Sebastián hizo exactamente eso y took down the entire platform, es decir, tiró toda la plataforma. Esto obligó al equipo a trabajar el sábado, en su day off (día libre). La expresión que usan es que Sebastián les hizo un Del Monte, una forma coloquial de decir que causó un desastre.
¿Cómo funciona un standup en un equipo ágil?
Un standup [1:20] es una reunión breve y diaria donde cada miembro del equipo comparte tres cosas:
- En qué está trabajando actualmente.
- Cuál es el progreso de sus tareas.
- Si tiene algún blocker (impedimento).
En esta conversación, el desarrollador explica que está conectando una nueva página de login al backend de MySQL [1:36]. La tarea resultó más compleja de lo esperado: estaba estimada como un two pointer (dos puntos de esfuerzo) pero necesita convertirse en un five pointer [1:48].
¿Qué son los story points y cómo se estiman correctamente?
Los story points son una forma de medir la complejidad de una tarea en metodologías ágiles. Cuando un ticket se marca como dos puntos pero termina siendo cinco, significa que la estimación inicial fue incorrecta [1:48]. El consejo que recibe es claro: la próxima vez, conviene dividir la tarea en dos más pequeñas (break that up into two smaller tasks) para que sea más fácil de gestionar [2:00]. Aprender a estimar bien es una habilidad fundamental en cualquier equipo de desarrollo.
¿Qué es un blocker y cómo comunicarlo?
Un blocker [2:22] es cualquier impedimento que detiene tu avance. En este caso, el desarrollador necesita que su compañera Samantha termine el styling de los componentes [2:25]. Ella ya completó otros componentes la semana anterior y su branch (rama de código) estaba lista para deployment (despliegue), solo esperaba un code review (revisión de código) [2:40].
Algunas expresiones clave de esta parte:
- Ready to merge: listo para fusionar el código con la rama principal.
- Waiting on code review: esperando que alguien revise el código.
- Ready for deployment: preparado para ser desplegado.
Comunicar tus blockers con claridad permite que el equipo busque soluciones rápidas y nadie se quede estancado sin necesidad.
Trabajar en tecnología requiere dominar no solo herramientas y lenguajes de programación, sino también el vocabulario que hace posible la colaboración efectiva. ¿Cuál de estas expresiones ya usas en tu equipo y cuál te resultó nueva? Compártelo en los comentarios.
