Capítulo 15: Sustainable Pace
Capítulo 15: Sustainable Pace
Miércoles de la tercera semana. Después del estrés del bug de ayer, Diego siente que están atrasados. Quiere compensar quedándose hasta tarde. Carlos va a tener la conversación más importante del proyecto: la que separa un equipo que sobrevive de uno que prospera.
Anterior: Whole Team en crisis | Siguiente: On-site Customer
La propuesta de Diego
Son las 5 de la tarde. Diego no ha guardado sus cosas.
Diego (Dev): “Carlos, me quiero quedar un par de horas extra. Con el bug de ayer perdimos medio día y hay stories que no vamos a completar esta semana.”
Carlos (TL): “No.”
Diego (Dev): “¿No? Ni siquiera lo pensaste.”
Carlos (TL): “No necesito pensarlo. La regla es clara: máximo 40 horas semanales. Si te quedas hasta las 8 hoy, te convertiste en el tipo que se queda hasta las 8. Y la semana que viene será hasta las 9.”
Diego (Dev): “Es solo un día.”
Carlos (TL): “Siempre es ‘solo un día’. Hasta que llevas tres meses trabajando 50 horas semanales y tu código es peor que cuando trabajabas 40.”
La historia de Elena
Elena ha estado escuchando. Se acerca.
Elena (Dev): “Diego, déjame contarte algo. En mi proyecto anterior, trabajábamos 10 horas diarias las últimas seis semanas antes del lanzamiento. El líder técnico decía que era temporal.”
Diego (Dev): “¿Y qué pasó?”
Elena (Dev): “Lanzamos a tiempo. Pero el producto tenía tantos bugs que pasamos las siguientes ocho semanas arreglándolos. Trabajando 10 horas diarias otra vez. Dos personas del equipo renunciaron. Yo tuve que tomar licencia por estrés.”
Diego (Dev): ”…”
Elena (Dev): “Las horas extra son un préstamo con intereses altísimos. Las pagas siempre. Con bugs, con rotación, con salud.”
El argumento de Kent Beck
Carlos aprovecha el silencio.
Carlos (TL): “Kent Beck es categórico con esto. Sustainable Pace no es un consejo: es una práctica. Igual que TDD o pair programming. Un equipo cansado comete errores. Un equipo que comete errores gasta tiempo arreglándolos. Entonces trabaja más horas para compensar, comete más errores, y el ciclo se alimenta solo.”
Diego (Dev): “Pero el bug de ayer no fue por cansancio.”
Carlos (TL): “¿Estás seguro? Esa lógica se escribió el jueves pasado a las 5 de la tarde. ¿Estábamos al cien por ciento de concentración?”
Diego (Dev): “No lo sé.”
Carlos (TL): “Yo tampoco. Pero sé que a las 3 de la tarde mi cerebro es mejor que a las 6. Y el tuyo también.”
Calidad sobre velocidad
Ana se une a la conversación. Ha escuchado desde su escritorio.
Ana (PO): “Diego, entiendo la frustración. Yo también siento presión de los stakeholders. Pero, ¿sabes qué me haría más daño que no completar una story esta semana?”
Diego (Dev): “¿Qué?”
Ana (PO): “Otro bug como el de ayer. Martín perdió confianza por unas horas. Si pasa otra vez, pierdo credibilidad con la directora de operaciones. Prefiero una feature menos que un bug más.”
Carlos (TL): “Calidad sobre velocidad. Siempre. La velocidad viene como consecuencia de la calidad, no al revés.”
Diego se queda pensando. Mira a Elena, que asiente sin decir nada.
Diego (Dev): “Ok. Me voy. Pero mañana empiezo a primera hora con esto.”
Carlos (TL): “Con mente fresca y café. Vas a resolver en una hora lo que hoy te tomaría tres.”
Lo que no se dice
El equipo sale a las 6. En el ascensor, Diego le dice algo a Elena en voz baja.
Diego (Dev): “¿De verdad tuviste que tomar licencia?”
Elena (Dev): “Dos semanas. No podía dormir. Soñaba con mensajes de error. Mi médico me dijo que era burnout clásico.”
Diego (Dev): “Lo siento.”
Elena (Dev): “No lo sientas. Aprendí. Por eso defiendo sustainable pace con tanta fuerza. No es pereza, Diego. Es supervivencia profesional.”
Diego llega a su casa a las 6:30. Cocina. Lee un rato. Duerme bien. A la mañana siguiente resuelve el problema pendiente en 45 minutos.
El ritmo del equipo
A partir de esta semana, nadie vuelve a proponer horas extra. No porque esté prohibido, sino porque todos entienden por qué no funciona. El equipo desarrolla un ritmo:
- 9:00: Llegan, café, stand-up de 10 minutos
- 9:15 a 12:30: Pair programming con rotación
- 12:30 a 13:30: Almuerzo real, fuera de la pantalla
- 13:30 a 17:30: Pair programming con rotación
- 17:30 a 18:00: Integración final, empujar código, CI verde
- 18:00: Todos se van
Ocho horas productivas. Cinco días. Cuarenta horas. Ni una más.
Práctica XP del capítulo
Sustainable Pace (40-Hour Week): Kent Beck establece que un equipo XP no debe trabajar más de 40 horas semanales, y si hay overtime una semana, la siguiente no debe tenerlo. La razón no es ética (aunque lo es): es práctica. Los estudios demuestran que después de 40 horas de trabajo cognitivo intenso, la productividad neta baja porque el tiempo extra se gasta en arreglar errores producidos por el cansancio. Sustainable Pace es la práctica que sostiene todas las demás: sin descanso, TDD se degrada, el pair programming se vuelve hostil y las estimaciones se inflan.
¿Qué hace cada uno?
| Persona | Rol en este capítulo |
|---|---|
| Ana | Prioriza calidad sobre velocidad, apoya sustainable pace |
| Carlos | Defiende la regla de 40 horas, explica las consecuencias |
| Diego | Quiere sacrificar descanso, acepta que es contraproducente |
| Elena | Comparte experiencia de burnout, valida la posición de Carlos |
Anterior: Whole Team en crisis | Siguiente: On-site Customer