|
 Si monitorizamos el avance del trabajo sobre un plan previo, podemos tener como resultado: que estamos en fechas, o que vamos retrasados, pero nunca adelantados. Y aunque es una herramienta útil para cumplir fechas, también es un freno para reducirlas; de hecho, al seguir el avance de un sprint con un gráfico burn-down, siempre sale o sub-estimado, o bien; pero nunca sobre-estimado.
La gestión predictiva hace planes detallados de duración considerable, y registra el trabajo realizado en cada momento. La gestión ágil lo hace de forma diferente: trabaja con planes detallados cortos (iteraciones o sprints) y registra, no lo que se ha trabajado, sino lo que falta para terminar. Son los gráficos de avance: burndown.
Trabajar en iteraciones cortas, y medir el avance sobre el trabajo pendiente, y no sobre el realizado ofrece ventajas frente al método de gestión clásica, pero tienen un problema común: la ley de Parkinson. "El tiempo invertido en un trabajo varía en función del tiempo disponible". "Las tareas se expanden o se comprimen según el tiempo que dispongamos para hacerlas". "Todo proyecto tiende a alargarse en el tiempo hasta completar el que tiene asignado".
Vamos a poner en práctica una prueba: no estimar la pila del sprint.
Es posible que la estimación del cliente en la pila del producto con unidades relativas, para prever los hitos de cada release, nos de un nivel de seguimiento suficiente del avance del proyecto, y de la velocidad del equipo (no en horas ideales de tareas, sino en puntos de función). Es posible que sea un error trabajar con un scrum-ban: tratando a las tareas de sprint como "tareas kanban" que irán pasando de pendiente a en curso y finalizadas, pero no nos puede afectar la Ley de Parkinson, porque no vamos a determinar previamente cuánto nos van a costar, y tampoco nos deprimirá un sprint backlog sub-estimado, de forma que tendremos un ritmo de trabajo más sostenible (esperamos).
El avance se demostrará al ver entrar y salir del escenario kanban las historias de usuario al ritmo de puntos previsto por el propietario de producto en su burn-up.
¿Habéis probado métodos similares? ¿Algún consejo?.
 |
RSS de los comentarios
Estoy de gestor de un proyecto trabajando con los recursos internos de la empresa que ha contratado mis servicios. Si no le pongo fechas de fin de las tareas no avanzamos. Pongo tareas con fechas de días porque creo totalmente en la ley de Parkinson.
Esto que comentas esta muy bien y me encantaría pero funciona cuando tus recursos tienen cierto nivel.