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.
Son las 9:30. El equipo está reunido. Cada persona responde por turno a las tres preguntas: 'Qué hice ayer, qué hago hoy, cuáles son mis bloqueos.' Quince minutos después, todos regresan a sus pantallas sin que nada haya cambiado. Este daily no sirvió para nada.
Existe en la industria tecnológica un arquetipo admirado: el desarrollador brillante y solitario que produce más código que diez desarrolladores ordinarios. Este arquetipo influye en las contrataciones, justifica paquetes salariales desiguales y crea culturas de equipo disfuncionales. También es, en gran medida, un mito.
Tu organización ha implementado SAFe. Ahora tienes ARTs, PI Plannings, System Demos y talleres de Inspect & Adapt. Tu organización también es más lenta, tiene más reuniones y resulta más frustrante para los ingenieros que antes. Esto no es un error en tu implementación de SAFe. Con frecuencia es una característica.
La estimación es a menudo una ficción compartida: los desarrolladores dan cifras que saben imprecisas, la gerencia las toma como compromisos, y cuando las estimaciones se superan, todos se sorprenden de sorprenderse. #NoEstimates dice: pongamos fin a la ficción. La pregunta es: ¿con qué la reemplazamos?
La base de datos de producción cayó el viernes a las 18h. El post-mortem tuvo lugar el lunes. En el informe: cinco puntos de mejora de procesos, tres acciones de remediación técnica y una mención discreta de que 'el incidente fue causado por un error humano durante la migración.' Esa frase es lo contrario de un post-mortem blameless.
Si tu equipo pasa más tiempo debatiendo monorepo vs polyrepo que escribiendo código, es señal de que el debate está mal planteado. Ambos enfoques funcionan. La verdadera pregunta es: ¿qué estructura se adapta a tu organización y a tu ciclo de entrega?
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.
