- Hoy en día, programar es mucho más estresante que en los 90 y a principios de los 2000
- En ese entonces, las cosas solo se volvían una locura cerca de las fechas límite, y el resto del tiempo era relativamente tranquilo
- Vale la pena pensar por qué el estrés ha aumentado durante las últimas décadas
- No es por la competencia, los cambios del mercado ni las fechas límite estrictas, sino por la forma de trabajo basada en sprints
1. Los sprints no se detienen
- Los sprints son fechas límite continuas que nunca terminan
- El modelo waterfall estaba alineado con fechas límite y eventos reales
- Los sprints son fechas límite artificiales, sin pausas naturales
- El estrés a corto plazo puede ser bueno para la salud, pero el estrés a largo plazo es perjudicial para el cuerpo
2. Los sprints no son voluntarios
- No es lo mismo que un equipo decida voluntariamente desplegar código cada dos semanas
- Todos los aspectos del sprint están reglamentados
- La autonomía cumple un papel importante en la experiencia de trabajo
- El trabajo impuesto provoca estrés e incomodidad
3. Los sprints ignoran actividades de apoyo importantes
- Los sprints no dan tiempo para prepararse para la siguiente tarea
- Para poder realizar el trabajo, se necesita tiempo de preparación
- Los sprints intentan separar la preparación de la ejecución, pero eso genera estrés
Scrumban: la imagen real (y peor)
- La mayoría de las implementaciones de Scrum son una mezcla de waterfall y Scrum
- Siempre hay una gran fecha límite en segundo plano
- Cuando esa gran fecha límite se acerca, Scrum se interrumpe y el estrés aumenta
Conclusión
- En los sprints no hay descanso, falta autonomía y falta tiempo de preparación
- Los desarrolladores deberían poder controlar su trabajo y su proceso
- Para lograrlo, hace falta esfuerzo, como construir una organización ética o pasarse al trabajo freelance
Resumen de GN⁺
- Este texto explica por qué el método Scrum genera estrés constante en los desarrolladores
- Las principales causas son las fechas límite continuas de los sprints, la falta de autonomía y la falta de tiempo de preparación
- Hay que permitir que los desarrolladores controlen su forma de trabajar
- Otro enfoque con funciones similares es el método Kanban
8 comentarios
Incluso cuando se llevan a cabo proyectos como los del sector público de SI, los empujan sin descanso en phase 1, 2, 3... de esa manera. Y en cada phase individual vuelven a ocurrir muchísimos cambios. Así es absolutamente imposible cumplir el propósito original de Scrum de desarrollar con éxito. Al final, en medio de este caos frenético y desordenado, solo los desarrolladores terminan hechos polvo.
Soy PM en activo.
En los procesos ágiles/Scrum que sentí que funcionaban bien, cuando terminaba un sprint importante hacíamos una retrospectiva y nos daban tiempo para descansar. Tanto el equipo de desarrollo como el de planificación tenían un momento para recuperarse antes de preparar lo siguiente.
En la forma de trabajo que, igual que en el artículo, sentí que no funcionaba, además de los plazos impuestos en cascada, dentro del equipo de producto también se hacía funcionar Scrum al mismo tiempo, lo que aumentaba el estrés. Y como esas fechas límite no se podían mover, pasábamos semanas corriendo sin tiempo ni para descansar ni para hacer retrospectiva; se sentía como una carrera que no termina.
Entiendo que la intención de waterfall es identificar los requisitos lo más temprano posible y, como hay dependencias entre las tareas de diseño, implementación y pruebas, hacer el trabajo en orden; y que la intención de agile y los sprints es dividir en partes pequeñas el trabajo que sería demasiado grande para diseñar o implementar de antemano con waterfall. Creo que ambos tienen pros y contras, y que en vez de seguir una metodología de forma dogmática, quizá bastaría con elegir solo lo necesario según la situación. Como sostiene el artículo, también debería haber descansos, así como tiempo de preparación para revisiones técnicas o para crear prototipos. Sin importar quién decida el orden del trabajo, si se entienden los factores que estorban y se fijan las prioridades de acuerdo con el flujo real del trabajo, no creo que la presencia o ausencia de autonomía para los desarrolladores importe tanto.
¿Será que en otros países hay tantos gerentes sin experiencia alguna en desarrollo que intentan aplicar ciegamente los procedimientos de las metodologías de desarrollo, y por eso aparecen textos así en blogs extranjeros? Se siente como ver los conflictos entre planificadores y desarrolladores que no conocen en absoluto el trabajo real en nuestro país.
Aunque quien mejor puede decidir las prioridades según el flujo real del trabajo sería el propio desarrollador, creo que el enfoque mismo de quitarle esa autonomía y hacer que otra persona la sustituya termina provocando, más bien, una separación entre la práctica real y la planificación del equipo.
Si gestionar en sí mismo también es un área de especialización, entonces incluso si se trata de un gerente sin experiencia en desarrollo, cuando se enfrenta al momento en que la gestión de recursos de desarrollo no está funcionando bien, pienso que la respuesta a esa situación debe ser que el gerente se adapte o responda. Sin embargo, he visto demasiadas veces que esa responsabilidad termina trasladándose a los colaboradores individuales...
Sí, al final la responsabilidad debería recaer en el gerente. Pero parece que en la realidad no es así. Es como cuando un CEO que solo sabe gestionar no entiende en absoluto el negocio de la empresa y a veces termina llevándola a la ruina.
Hay demasiados PM que solo se la pasan rebotando tareas 😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭
Opiniones en Hacker News
Citando a Rich Hickey, un programador resuelve problemas no como un corredor de distancias cortas, sino arrancando un nuevo sprint cada 100 yardas con una señal de salida
He llegado a odiar los procesos de software. Si ajustas bien el tamaño del equipo y les das a los desarrolladores la autoridad para cumplir sus objetivos, pueden hacerlo bien sin el flujo de productividad de la gerencia. Agile y similares existen para que los gerentes justifiquen su sueldo
Me pregunto qué significa que "los sprints no sean voluntarios". El equipo elige las características del sprint, no se asignan al azar. Es una colaboración entre liderazgo, miembros del equipo y partes interesadas externas al equipo. Me gustaría que explicaran por qué Scrum es demasiado rígido
Desde que apareció Scrum, pensé que no tenía sentido que los desarrolladores estuvieran haciendo sprints todo el tiempo. Un sprint es corto e intenso, y después necesitas descansar. Convertir todo el trabajo en sprints es una locura
Muchas veces Scrum en realidad se convierte en un peor "Scrumbanfall". Al principio se usó Scrum para facilitar la comunicación de equipos remotos, pero poco a poco se transformó en objetivos impulsados por marketing y sprints estresantes. El desgaste de los desarrolladores se hace evidente
A principios de los 2000, los equipos de ingeniería trabajaban por su cuenta sin project managers. El software no estaba tan interconectado como ahora y los ciclos de despliegue eran más largos. Hoy, con CI/CD y el despliegue continuo, todo va rápido. SCRUM genera estrés
La mayoría de las conversaciones se pueden resumir en: "en mi trabajo Scrum no funciona por X, Y, Z" y "eso no es Scrum ideal"
Llevo 40 años desarrollando software y, uses el método que uses, tienes que dividir el trabajo y mostrar que estás cumpliendo los objetivos. En equipos pequeños, con una base de código simple, Kanban puede ser suficiente, pero en equipos grandes o con soluciones complejas se necesitan reportes
No usamos Agile, Scrum ni standups. Reajustamos prioridades en una reunión semanal y seguimos el avance con un sistema de tickets. Dejamos que los desarrolladores trabajen de forma autónoma. Hay que dedicar más tiempo a programar que a reuniones o reportes TPS
Después de trabajar en 8 empresas, el enfoque Shape Up de Basecamp ha sido el más exitoso. Lo importante es preguntar no "cuántos días", sino "cuánto tiempo vamos a invertir". Shape Up ofrece tiempo de enfriamiento entre ciclos de 6 semanas y entrega productos exitosos de forma consistente