- Grado de avance respecto a lo planificado.
- Calidad del desarrollo.
- % de pruebas superadas.
- Revisiones de código.
- etc...
Todas las metricas que se usen se pueden ser mejor o peores para conocer el estado del desarrollo y llevar a la culminación de la tarea dependiendo de la incertidumbre de culminación de la tarea que presenta el desarrollador encargado de la tarea.
La incertidumbre de culminación de tareas es la probabilidad de que un programador haya implementado una tarea de acuerdo a como el responsable quiere que lo haga.
Cuando el responsable de una tarea piensa (diseña) la tarea no habria mejor persona para acometerla que esa misma persona (no lo va a hacer porque lo que tiene que hacer es diseñarla para que lo haga otros y esa persona pueda hacer otra cosa) y si esa persona acometiera la tarea es casi seguro que al hacerlo se encontrara con realidades (esto es mejor asi, esto asi no sale, etc..) que variarían la forma que tenia pensada en que se acomete la tarea y posiblemente hasta cambios de diseño. Con esta premisa, es lógico pensar que otra persona (un desarrollador) presenta una incertidumbre de culminación de tareas muy alto.
Para evitarlo, es básica la formación continua de los programadores y asegurarse de que comprenden el marco de trabajo que se usa para el desarrollo del proyecto. Pero es muy optimista pensar que con esto vale, se deben usar técnicas con mas supervisión como programación extrema. Quizas la mejor opción es seleccionar un dia al azar y pasar la mayor parte del dia sentado en el sitio del programador, hablar con el, ver como plantea las cosas, que esta haciendo, que es lo que ha entendido, etc.. La claves es asegurarse de que ha entendido el marco de trabajo y que va a culminar la tarea como espera el responsable que se va a resolver.
No hay comentarios:
Publicar un comentario