Semanas de cuarenta horas como práctica, no como guía. Las horas extra son señal de fracaso.
El nombre original de XP para esto era "semana de 40 horas". La idea fue controversial entonces y sigue siendo controversial ahora: horarios de trabajo regulares, sin horas extra como práctica estándar.
Esto no es un beneficio ni algo agradable de tener. Es una práctica central de XP porque:
Los desarrolladores cansados cometen errores. Los estudios muestran que la productividad cae drásticamente después de 50 horas/semana. Después de 60 horas, produces más bugs que funcionalidades.
El descanso permite la creatividad. Los problemas complejos necesitan mentes frescas. La idea que resuelve un bug a menudo llega después de alejarse.
El agotamiento destruye equipos. Los equipos que funcionan con las reservas vacías eventualmente colapsan. La gente renuncia, se enferma o se desconecta mentalmente. El "crunch" que salva la fecha límite mata al equipo.
El ritmo sostenible es sostenible. Puedes trabajar semanas de 40 horas indefinidamente. No puedes trabajar semanas de 60 horas indefinidamente—algo se rompe.
El Mito de la Productividad
Después de 50 horas/semana, las horas adicionales generan tantos bugs que crean productividad negativa. Entregarías más trabajando menos.
En XP, las horas extra no son heroísmo—son una señal de advertencia. Significa que algo está mal:
Cuando trabajas horas extra para cumplir una fecha límite, estás tratando síntomas, no causas. El problema subyacente permanece. En la siguiente fecha límite, trabajarás horas extra de nuevo.
La respuesta de XP: Exponer el problema. Decirle al cliente "no podemos hacer todo esto para entonces". Ajustar alcance, línea de tiempo o recursos. No pretender que todo está bien mientras te quemas.
El equipo se da cuenta de que no puede terminar todas las funcionalidades para el lanzamiento. Le dicen al product owner inmediatamente, negocian la reducción del alcance y entregan un lanzamiento más pequeño pero de alta calidad a tiempo.
El equipo trabaja semanas de 70 horas durante tres meses para cumplir una fecha límite. Entregan a tiempo pero el código está plagado de bugs. Dos desarrolladores renuncian por agotamiento. Los bugs toman seis meses en corregirse.
Los desarrolladores a menudo confunden "estado de flujo" con "trabajar muchas horas".
La zona es valiosa:
Marcha de la muerte es destructiva:
XP apoya la zona. La programación en parejas protege el enfoque. Las iteraciones pequeñas proporcionan objetivos claros. Los equipos completos reducen las interrupciones.
Pero la zona ocurre en horas de trabajo normales. No necesitas semanas de 60 horas para entrar en estado de flujo. De hecho, el agotamiento previene el flujo.
Un buen día: 4-6 horas de trabajo enfocado en la zona, más comunicación, planificación y aprendizaje. Un mal día: 10 horas de trabajo fragmentado, sin entrar nunca en flujo.
El desarrollo de software es trabajo creativo. La creatividad requiere descanso.
Por qué importa el descanso:
Prácticas de XP que apoyan el descanso:
La gerencia debe proteger el descanso. Si el liderazgo celebra a los "héroes de medianoche" o envía correos a todas horas, el ritmo sostenible son solo palabras. La cultura se establece por lo que se recompensa.
Si alguien resuelve un problema difícil después de alejarse durante el fin de semana, celébralo. Es prueba de que el descanso funciona.
Los productos de software viven durante años. Los equipos necesitan trabajar a un ritmo que puedan sostener durante años.
Mentalidad de sprint: Empuja fuerte ahora, descansa después. Esto funciona para carreras cortas pero no para construir software. Siempre hay otra fecha límite. "Después" nunca llega.
Mentalidad de maratón: Controla tu ritmo. Trabaja a una velocidad que puedas sostener indefinidamente. Construye hábitos que apoyen la salud y productividad a largo plazo.
Señales de ritmo insostenible:
Si ves estas señales, el ritmo es un problema—sin importar lo que diga la gerencia sobre "crunch temporal".
Siempre Hay una Fecha Límite
No creas que 'solo empuja hasta esta fecha límite y las cosas se calmarán'. El software siempre tiene otra fecha límite. Si las horas extra son normales ahora, serán normales para siempre.