Timeboxing

8 de julio de 2020Administración del tiempo

En la gestión del tiempo, el timeboxing asigna un período de tiempo fijo, denominado timebox, dentro del cual tiene lugar la actividad planificada. Es empleado por varios enfoques de gestión de proyectos y para la gestión personal del tiempo.

Timebox: no alcance

Mary Poppendieck, líder en desarrollo de software Lean

Tabla de contenido

1 En gestión de proyectos
2 En gestión personal del tiempo
3 Relación con otros métodos
4 Referencias
5 Fuentes
- 5.1 Relacionado

En gestión de proyectos

Timeboxing se utiliza como una técnica de planificación de proyectos. El cronograma se divide en varios períodos de tiempo separados (cajas de tiempo), cada parte tiene sus propios entregables, fecha límite y presupuesto. A veces se denomina programación como variable independiente (SAIV).

Como alternativa a la fijación del alcance

En la gestión de proyectos, generalmente se consideran tres restricciones de tiempo (a veces cronograma ), costo (a veces presupuesto ) y alcance; con calidad a menudo agregada como una cuarta restricción (representada como la mitad de un triángulo), La suposición es que un cambio en uno la restricción afectará a los demás.

Sin timeboxing, los proyectos generalmente funcionan a un alcance fijo, en cuyo caso cuando queda claro que algunos entregables no pueden completarse dentro de los plazos planificados, o bien la fecha límite debe extenderse (para permitir más tiempo para completar el alcance fijo) o más personas están involucradas (para completar el alcance fijo al mismo tiempo).

A menudo, ambos suceden, lo que resulta en retrasos en la entrega, aumento de los costos y, a menudo, calidad reducida (según el principio The Mythical Man-Month ).

Con timeboxing, la fecha límite es fija, lo que significa que el alcance debería reducirse. Como esto significa que las organizaciones deben centrarse primero en completar los entregables más importantes, el timeboxing a menudo va de la mano con un esquema para priorizar los entregables (como con el método MoSCoW ).

Para gestionar el riesgo

Los timeboxes se utilizan como una forma de gestión de riesgos., para identificar explícitamente las relaciones inciertas de tareas / tiempo, es decir, trabajos que pueden extenderse fácilmente más allá de su fecha límite. Las limitaciones de tiempo son a menudo un impulsor principal en la planificación y no deben cambiarse sin considerar las rutas críticas del proyecto o subproyecto.

Es decir, generalmente es importante cumplir con los plazos. Los factores de riesgo para plazos vencidos pueden incluir complicaciones aguas arriba del proyecto, errores de planificación dentro del proyecto, problemas relacionados con el equipo o ejecución defectuosa del plan. Los problemas anteriores pueden incluir cambios en la misión del proyecto o respaldo / apoyo de la administración.

Un error de planificación común es el desglose inadecuado de la tarea, que puede conducir a una subestimación del tiempo requerido para realizar el trabajo. Los problemas relacionados con el equipo pueden incluir problemas con la comunicación entre equipos; falta de experiencia o funcionalidad cruzada requerida;

Para permanecer en la fecha límite, se evalúan comúnmente las siguientes acciones contra las restricciones triples:

Reduzca el alcance: elimine los requisitos de menor impacto (los que el usuario no perderá directamente)

El tiempo es la restricción fija aquí

Aumente el costo: por ejemplo, agregue horas extras o recursos

Adopción en el desarrollo de software

Muchos proyectos exitosos de desarrollo de software utilizan timeboxing, especialmente los más pequeños. La adopción de timeboxing más que triplicó la productividad del desarrollador en DuPont en los años 80. En algunos casos, las aplicaciones se entregaron por completo dentro del tiempo estimado para completar solo una especificación.

Sin embargo, Steve McConnell argumenta que no todos los productos son adecuados y que el timeboxing solo debe usarse después de que el cliente acepte reducir las características, no la calidad. Hay poca evidencia de una fuerte adopción entre la clase más grande de proyectos.

Timeboxing ha sido adoptado por algunas metodologías notables de desarrollo de software :

Método de desarrollo de sistemas dinámicos (DSDM)

En el desarrollo de software lean, la programación de extracción con Kanban proporciona una gestión del tiempo a corto plazo. Cuando se desarrolla un sistema grande y complejo, cuando se requiere una planificación a largo plazo, el timeboxing está en capas arriba.

El proceso de desarrollo de software de desarrollo rápido de aplicaciones (RAD) presenta desarrollo iterativo y creación de prototipos de software. Según Steve McConnell, el timeboxing es una “mejor práctica” para RAD y una duración típica de timebox debe ser de 60 a 120 días.

Scrum fue influenciado por ideas de timeboxing y desarrollo iterativo. Las unidades regulares de timeboxed conocidas como sprints forman la unidad básica de desarrollo. Una duración típica para un sprint es menos de 30 días. Las reuniones de planificación de sprint, retrospectiva de sprint y revisión de sprint están en timeboxed.

En las metodologías de programación Extreme, la planificación del desarrollo se divide en tiempo en iteraciones, generalmente de 1, 2 o 3 semanas de duración. La empresa revalúa las historias de usuarios pendientes antes de cada iteración.

El desarrollo ágil de software aboga por pasar del desarrollo basado en planes al desarrollo basado en valores. La calidad y el tiempo son fijos, pero se permite flexibilidad en el alcance. La entrega de las características más importantes primero conduce a un retorno de la inversión más temprano que el modelo en cascada.

La falta de especificaciones detalladas generalmente es el resultado de una falta de tiempo, o la falta de conocimiento del resultado final deseado (solución). En muchos tipos de proyectos, y especialmente en ingeniería de software, es imposible analizar y definir todos los requisitos y especificaciones antes del inicio de la fase de realización.

Timeboxing puede ser un tipo de contratación favorable para proyectos en los que la fecha límite es el aspecto más crítico y cuando no todos los requisitos están completamente especificados por adelantado. Esto también permite que nuevos comentarios o ideas descubiertas durante el proyecto se reflejen en el resultado final.

En gestión personal del tiempo

Timeboxing también se puede usar para tareas personales, en cuyo caso utiliza una escala de tiempo reducida (por ejemplo, treinta minutos) y de entregables (por ejemplo, una tarea doméstica en lugar de entregable del proyecto).

También se dice que el timeboxing personal actúa como un truco de la vida para ayudar a frenar las tendencias perfeccionistas (al establecer un tiempo firme y no comprometerse demasiado con una tarea) que también puede mejorar la creatividad y el enfoque (al crear un sentido de urgencia o una mayor presión).

Relación con otros métodos

Timeboxing actúa como un componente básico en otros métodos de gestión del tiempo personal:

La técnica Pomodoro se basa en cajas de tiempo de 25 minutos de concentración enfocada separadas por descansos que permiten que la mente se recupere.

Andy Hunt da timeboxing como su ‘T’ en SMART.

Referencias

Poppendieck, Mary (2010). Desarrollo líder de software Lean: los resultados no son el punto. Upper Saddle River, Nueva Jersey: Addison-Wesley. pags. 139. ISBN 978-0-321-62070-5.

Boehm, Barry W.; Boehm, Barry; Turner, Richard (2004). Equilibrio de la agilidad y la disciplina: una guía para los perplejos. Addison-Wesley Profesional. ISBN 9780321186126.

Cuáles son las restricciones triples en la gestión de proyectos archivado 2006-08-20 en Archive.today, artículo de Rod Hutchings sobre Project Management Australia archivado 2009-02-16 en la Wayback Machine (22 de octubre de 2008)

Chatfield, Carl. “Un curso corto en gestión de proyectos”. Microsoft

Dobson, Michael (2004). Las triples restricciones en la gestión de proyectos. Viena, Va: Conceptos de gestión. ISBN 1-56726-152-3.

Kanabar, Vijay (2008). Fundamentos de MBA: Gestión de proyectos. Nueva York: Kaplan Pub. pags. 51.ISBN 978-1-4277-9744-5.

Leffingwell, Dean (2011). Requisitos de software ágiles: prácticas de requisitos lean para equipos, programas y la empresa. Upper Saddle River, Nueva Jersey: Addison-Wesley. pp. 17-19. ISBN 978-0-321-63584-6.