Sin embargo, en la misma organización de desarrollo, algunos desarrolladores pueden quedarse ellos mismos a terminar cierta cantidad de trabajo, aún si el líder no le pidió que lo haga. Esto suele estar bien visto. Se entiende que cuando estás programando una solución a un problema no quieres abandonarlo por la mitad sólo porque son las 6 pm... pero a veces los desarrolladores se van de tema con esto.
De hecho, si estás en un proyecto de XP (o no), es mejor para tí que no trabajes muchas horas de más. Por ejemplo, si estás trabajando 12 horas todos los días en una iteración y terminas entregando 10 puntos en esa iteración, cuando el líder mire la velocidad anterior va a planear cerca de 10 ó 12 puntos de trabajo en la próxima iteración. Si esto pasa continuamente tu líder va a olvidar que esto era sólo un excepción en una iteración en la que te mataste por 12 horas, y rápidamente se va a convertir en la norma. Un líder novato o poco orientado a las personas va a estar propenso en caer fácilmente en este error. La próxima vez, si estás de vacaciones por una iteración, la gente restante en el equipo debe alcanzar el mismo resultado al que llegaban contigo, lo que implícitamente significa que ellos trabajarán 12 horas o más.
Mientras que tu equipo (y la mayoría de los líderes) serán bien vistos por los stakeholders por tener terminado un montón de trabajo constante en una iteración, vos como desarrollador vas a sufrir de agotamiento. Y sabes bien que la próxima vez que no estés ahí tu equipo va a sufrir, ya que otros en el equipo pueden no estar preparados para una maratón de 12 horas.
De lo que estoy hablando acá es de como lograr un ritmo sostenible en el equipo. No sólo da predecibilidad para que la gente planifique sus iteraciones mejor, sino que también mantiene al equipo en marcha juntos por meses, sin agotarse.
Si sos desarrollador o líder, por favor no abuses de vos mismo o de tu equipo matándose de trabajo todas las noches.
No hay comentarios.:
Publicar un comentario