Aprenda estrategias modernas de gestión de proyectos, planificación de releases, integración de QA y escalado de equipos. Insights para líderes de ingeniería y gerentes de proyectos.
Tu codebase tiene 47 feature flags activos. Cinco están documentados. Tres están vinculados a funcionalidades entregadas hace nueve meses y nadie pensó en eliminarlos. Dos son conflictivos: activar ambos al mismo tiempo produce un comportamiento indefinido. Acabas de descubrir por qué los feature flags no son gratuitos.
El equipo pasó tres semanas modelando los bounded contexts, los aggregates y los domain events de su aplicación de gestión de contenidos. La aplicación hace CRUD sobre cinco tablas. Esa es la señal de que DDD se está usando como fin en sí mismo, no como herramienta.
"Necesitamos un sprint de deuda técnica." Esta frase se pronuncia en cientos de equipos cada trimestre. Lo que ocurre a continuación: dos semanas de refactorización sin dirección clara, cuyo valor es imposible de comunicar a la dirección, y que no cambia fundamentalmente los problemas más dolorosos.
¿Cuántos días pasa un nuevo desarrollador intentando poner en marcha el proyecto en local antes de poder contribuir realmente? En la mayoría de los equipos, la respuesta está entre dos y diez días. La documentación de onboarding existe, solo que es incorrecta.
¿Cuántas veces has tenido un 1-on-1 donde tu manager abrió Jira para revisar tus tickets en curso? Esa reunión podría haber sido un correo o una consulta al tablero Kanban. Un 1-on-1 que parece un reporte de estado es un 1-on-1 desperdiciado.
Tu equipo tiene una página de Notion con el plan del próximo trimestre. Fue redactada la semana pasada. Tres personas añadieron comentarios. Dos pusieron un emoji. El plan no ha cambiado. Nadie ha tomado una decisión. Eso es el async sin control: mucha actividad, poca resolución.
¿Cuándo está terminada una epic? La pregunta debería tener una respuesta simple. En la práctica, en la mayoría de los equipos, es el inicio de una larga conversación. La epic crece, se divide, se reabre, migra de un sprint a otro. No es un problema de implementación de Scrum. Es un problema de definición.
"Nuestra velocity es de 42 puntos por sprint." Esta frase se pronuncia con orgullo en cientos de reuniones de planificación cada semana. ¿Qué dice exactamente? Que el equipo cierra tickets a un ritmo constante. Lo que no dice: si esos tickets crean valor, si las estimaciones son realistas, si el equipo está bien.
¿Cuántas veces has visto una release convertirse en un cajón de sastre de funcionalidades a medio terminar, correcciones de última hora y tickets migrados desde tres sprints anteriores? La release ha perdido su sentido porque solo se usa como contenedor de entrega, no como herramienta de gestión.
"Como usuario, quiero poder iniciar sesión para poder acceder a mi cuenta." Este ticket se ha escrito millones de veces. No describe nada útil sobre lo que el desarrollador debe hacer. Ese es el problema central de la user story como unidad de trabajo.
