Sin embargo, a veces las consultorías e incluso las empresas de productos se encuentran con que tienen que facturar en horas o cobrar horas debido a una gestión poco inteligente. En este caso, los datos de Scrum pueden recogerse de forma que ofrezcan una estimación de horas y una finalización más precisas que la planificación tradicional. En los primeros años en PatientKeeper, estábamos experimentando con Scrum hiperproductivo y queríamos una estimación detallada por hora. Durante varios años, recopilamos decenas de miles de puntos de datos hasta que nos enseñaron que podíamos ir más rápido sólo con la estimación de puntos (en ese momento abandonamos cualquier seguimiento horario).
Cuando implantamos un Scrum automatizado de tipo C allá por 2002 en PatientKeeper, hicimos un análisis de usuario sobre qué pedir a los desarrolladores para minimizar su tiempo administrativo (despilfarro) y adelgazar la organización. No conozco ningún otro estudio de usuarios de este tipo sobre la eliminación de los residuos administrativos para los desarrolladores.
Se nos ocurrió una respuesta contraintuitiva. Aunque todo lo que queríamos saber era cómo actualizar el Burndown Chart, nuestros desarrolladores nos dijeron que no preguntáramos por el tiempo restante de una tarea por las siguientes razones:
1. En cinco tareas se tardó más de 60 segundos en responder a la pregunta, y 60 segundos era el criterio de diseño del sistema de informes del proyecto.
2. Les hacía pensar demasiado y no querían molestarse cuando pensaban que la estimación resultante no era necesariamente exacta.
3. Consideraban que la estimación del tiempo restante tenía una gran variabilidad y, por tanto, era de alto riesgo. Si la estimación actual se disparaba, sabían el tiempo invertido y el porcentaje completado. Todo lo demás eran puras conjeturas.
Se trataba de ingenieros profesionales de alto nivel. En el equipo había varios doctores del MIT y de otros centros. Todos los fundadores de la empresa eran licenciados del MIT. Como resultado, mi opinión era que ellos daban las respuestas "correctas" a las preguntas basándose en las mejores prácticas y no en una respuesta que obtendrías de ingenieros inexpertos, quizá poco motivados, que sabían poco sobre el Scrum.
Tomando el tiempo invertido y el porcentaje completado en cada tarea tocada cada día, el sistema autocalcula el tiempo restante para actualizar el Scrum Burndown Chart. Si una tarea está 50% terminada y se ha invertido un día, se supone que el tiempo restante es de un día. La nueva estimación total de la tarea es de dos días. La estimación original de la tarea se archiva en el sistema para su análisis histórico. El Cuadro de Burndown recalcula automáticamente cada estimación para cada elemento tocado durante un día.
El tiempo restante para la finalización del Sprint es todo lo que se informa públicamente y el equipo sigue centrado en lo que se necesita para llegar a "Hecho" al final del Sprint y ni siquiera siente que las preguntas formuladas se relacionan con la presentación de informes de tiempo de ninguna manera. Se trata simplemente de la forma más sencilla de obtener los datos necesarios para actualizar el gráfico desplegable.
Un efecto secundario de este enfoque es que las empresas de consultoría que facturan a los clientes por horas pueden generar la facturación desde nuestro sistema automatizado sin rellenar ninguna hoja de horas.
En una clase de formación Scrum celebrada ayer en Copenhague con jefes de proyecto experimentados que trabajan en el nivel 5 de CMMI en IBM y otros lugares, se coincidió en general en que pedir a los desarrolladores que rellenen hojas de asistencia reduce la productividad del equipo en al menos 10%. Odian hacerlo, es trabajo duplicado, es obviamente "despilfarro", y sólo lo hacen las empresas que no tienen ni idea de desarrollo ajustado de productos. He sido consultor en algunas empresas en las que los informes de tiempo son tan complejos que los desarrolladores se inventan las hojas de tiempo, la empresa miente a los clientes y la alta dirección toma malas decisiones basándose en datos erróneos, lo que compromete el éxito de la empresa en el mercado. Mi informe final a la alta dirección fue que el 50% de toda su productividad de desarrollo se perdió debido a la implementación de la hoja de tiempos.
Cualquier jefe de proyecto con sentido común no "desperdiciará" 10% o más de la productividad del equipo de desarrollo. Moverá cielo y tierra para evitarlo y conseguir que se hagan más funciones antes y con mayor calidad.
La recomendación a las organizaciones de desarrollo de software que tienen que facturar horas es:
1. Suprimir todos los informes horarios.
2. Implemente la parte de los informes de Tipo C Scrum descrita anteriormente. No es necesario implantar un Tipo C Scrum para hacerlo. La forma de hacerlo se detalla en el borrador actual del libro "The Scrum Papers". Aquellos que estén dispuestos a dar su opinión editorial, envíenme un correo electrónico y se pondrá a su disposición una copia del último borrador.
3. Autogenerar informes de tiempo para el cliente a partir del enfoque Tipo C Scrum. Nunca lo utilice para informar del progreso del desarrollo.
4. Este enfoque proporciona información más precisa que cualquier otro sistema de control horario jamás creado:
- Developers nunca "maquillan" los datos de las fichas horarias.
- Se dispone del tiempo exacto para cada tarea.
- Proporciona un análisis "microcosteado" del trabajo en curso.
- Nunca se miente a los clientes. Sólo se les factura el trabajo real.
A las organizaciones que no facturan en horas, les recomendamos que abandonen por completo el seguimiento del tiempo y pasen únicamente a la estimación puntual relativa.
Los equipos que hacen esto tienen estimaciones más precisas y mayor velocidad. Vea por qué los puntos de historia son mejores que las horas.
Spanish 
English 
French