Por qué las hojas de horario son patéticas

Tiempo del programador frente a puntuación de calidad del software. Totalmente desvinculados.

En realidad las hojas de asistencia son peores que penosas:
* desmotivan a los desarrolladores
* 10-15% la pérdida de productividad es la mínima
* los desarrolladores tienen que fingir el tiempo necesario para rellenarlos correctamente
* se utilizan datos erróneos en los informes y la dirección toma decisiones equivocadas
* se engaña a los clientes
* no tienen nada que ver con la producción de código de calidad
* centran toda la organización en datos falsos en lugar de en la producción

Sin embargo, esto no basta para que muchos directivos renuncien a las hojas de horarios. Al igual que en el proceso en cascada, existe una dependencia psicológica tan fuerte que es como si estuvieran drogados.

Sin embargo, la situación es aún peor. La mayoría de los directivos tienen en la cabeza información completamente errónea y por eso toman continuamente malas decisiones. Uno de mis alumnos me dijo hace poco: "¡Quiere decir que todo lo que me ha dicho mi jefe es erróneo!".

Sí, José, todo lo que te ha dicho tu jefe está mal:
* no hay correlación entre el tiempo de desarrollo y la producción de software
* no hay correlación entre el tiempo empleado y la calidad del código
* no hay relación entre "gente de calidad" y producción de código

La única correlación entre el tiempo del desarrollador y la calidad del código de producción son los puntos de historia de calidad medidos como entregables para un equipo específico.

Las investigaciones realizadas durante muchos años en la Universidad de Yale ofrecen algunos de los mejores datos sobre este tema: véase Joel sobre el software:
* para un solo proyecto los tiempos de codificación peor/mejor son 1/10
* En muchos proyectos, los mejores y peores tiempos de codificación son 1/25.
* los ratios anteriores son los mismos para los peores y los mejores estudiantes de Yale
* la calidad del código producido es completamente independiente del tiempo empleado

Por alguna razón, muchos responsables de desarrollo toman decisiones sin ningún tipo de datos sobre esta cuestión y sus suposiciones están completamente fuera de la realidad.

Tom Poppendieck me dijo hace poco que un director competente hizo una investigación en sus equipos XP para ver qué número de horas por semana producía la máxima cantidad de código de producción de calidad. Después de probar con semanas más cortas y semanas con horas extra, el mejor número de horas para que los equipos produjeran la mayor cantidad de código de calidad fue ¡una semana laboral de 16 horas!

Créeme, tienes que deshacerte de esas estúpidas hojas de tiempo y centrarte en la producción real de software antes de que un competidor ágil te deje fuera del negocio.