En la gestión del tiempo , el timeboxing asigna un período de tiempo fijo, llamado timebox , dentro del cual tiene lugar la actividad planificada. Se utiliza en varios enfoques de gestión de proyectos y para la gestión del tiempo personal.
En la gestión de proyectos
El timeboxing se utiliza como técnica de planificación de proyectos . El cronograma se divide en varios períodos de tiempo separados (espacios de tiempo), y cada parte tiene sus propios entregables, fecha límite y presupuesto. [ cita requerida ] A veces se lo conoce como horario como variable independiente (SAIV). [1]
Como alternativa a fijar el alcance
En la gestión de proyectos , generalmente se considera que existen tres limitaciones de tiempo (a veces programa ), costo (a veces presupuesto ) y alcance ; [2] [3] [4] [5] [6] con calidad a menudo agregada como una cuarta restricción (representada como el medio de un triángulo), [7] [8] [9] La suposición es que un cambio en uno la restricción afectará a los demás. [5]
Sin timeboxing, los proyectos suelen funcionar con un alcance fijo, [10] en cuyo caso, cuando queda claro que algunos entregables no se pueden completar dentro de los plazos planificados, 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 ocurren, lo que resulta en un retraso en la entrega, un aumento de los costos y, a menudo, una reducción de la calidad (según el principio The Mythical Man-Month ).
Con el timeboxing, la fecha límite es fija, lo que significa que el alcance debería reducirse. Como esto significa que las organizaciones tienen que centrarse en completar los entregables más importantes primero, el timeboxing a menudo va de la mano con un esquema para priorizar los entregables (como con el método MoSCoW ). [11]
Para gestionar el riesgo
Los timeboxes se utilizan como una forma de gestión de riesgos , para identificar explícitamente relaciones inciertas tarea / tiempo, es decir, trabajo que puede extenderse fácilmente más allá de su fecha límite. Las limitaciones de tiempo son a menudo un factor principal en la planificación y no deben cambiarse sin considerar las rutas críticas del proyecto o subproyecto. Es decir, suele ser importante cumplir con los plazos. Los factores de riesgo de los plazos incumplidos pueden incluir complicaciones antes 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 el respaldo / apoyo de la administración. Un error de planificación común es el desglose inadecuado de las tareas, lo que puede llevar a subestimar el tiempo necesario 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; falta de compromiso / impulso / motivación (es decir, una mala gestión y formación de equipos).
Para mantenerse dentro del plazo, las siguientes acciones contra las restricciones triples se evalúan comúnmente:
- Reducir el alcance: eliminar los requisitos de menor impacto (los que el usuario no pasará por alto directamente)
- El tiempo es la restricción fija aquí
- Aumente el costo: por ejemplo, agregue horas extra o recursos
Adopción en el desarrollo de software
Muchos proyectos de desarrollo de software exitosos utilizan timeboxing, especialmente los más pequeños. [12] La adopción del timeboxing triplicó con creces la productividad de los desarrolladores en DuPont en los años 80. [13] En algunos casos, las aplicaciones se entregaron completamente dentro del tiempo estimado para completar solo una especificación . [13] Sin embargo, Steve McConnell sostiene que no todos los productos son adecuados [13] y que el timeboxing solo debe usarse después de que el cliente acepta recortar características, no calidad. [13] Hay poca evidencia de una fuerte adopción entre la clase más grande de proyectos. [12]
El timeboxing ha sido adoptado por algunas metodologías de desarrollo de software notables :
- Método de desarrollo de sistemas dinámicos (DSDM) [11]
- En el desarrollo de software esbelto , la programación pull 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 se superpone . [14]
- 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 del timebox debe ser de 60 a 120 días. [13]
- Scrum fue influenciado por ideas de timeboxing y desarrollo iterativo . [15] Las unidades regulares de caja de tiempo conocidas como sprints forman la unidad básica de desarrollo. [16] La duración típica de un sprint es de menos de 30 días. [17] [18] La planificación de Sprint, la retrospectiva de Sprint y las reuniones de revisión de Sprint tienen un horario fijo. [17]
- En las metodologías de programación Extreme , la planificación del desarrollo se divide en iteraciones que suelen durar 1, 2 o 3 semanas. La empresa revaloriza las historias de usuarios pendientes antes de cada iteración. [19]
El desarrollo de software ágil aboga por pasar de un desarrollo impulsado por planes a un desarrollo impulsado por valores . La calidad y el tiempo son fijos pero se permite la 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 . [6]
La falta de especificaciones detalladas generalmente es el resultado de la falta de tiempo o la falta de conocimiento del resultado final deseado (solución). En muchos tipos de proyectos, y especialmente en la ingeniería de software, es imposible analizar y definir todos los requisitos y especificaciones antes del inicio de la fase de realización. El 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 los nuevos comentarios o conocimientos descubiertos durante el proyecto se reflejen en el resultado final. [11]
En la gestión del tiempo personal
El timeboxing se puede utilizar 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), y a menudo se denomina bloqueo de tiempo .
También se dice que el timeboxing personal actúa como un truco de 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 mayor presión). [20]
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 espacios de tiempo de 25 minutos de concentración enfocada separados por descansos que permiten que la mente se recupere. [21]
- Andy Hunt da el timeboxing como su 'T' en SMART . [22]
Referencias
- ^ Boehm, Barry W .; Boehm, Barry; Turner, Richard (2004). Equilibrar la agilidad y la disciplina: una guía para los perplejos . Addison-Wesley Professional. 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 Wayback Machine (22 de octubre de 2008)
- ^ Chatfield, Carl. "Un curso corto en gestión de proyectos" . Microsoft.
- ^ Dobson, Michael (2004). Las triples limitaciones en la gestión de proyectos . Viena, Virginia: Conceptos de gestión. ISBN 1-56726-152-3.
- ^ a b Kanabar, Vijay (2008). Fundamentos de MBA: Gestión de proyectos . Nueva York: Kaplan Pub. pag. 51. ISBN 978-1-4277-9744-5.
- ^ a b Leffingwell, Dean (2011). Requisitos de software ágil: prácticas de requisitos ajustados para equipos, programas y la empresa . Upper Saddle River, Nueva Jersey: Addison-Wesley. págs. 17-19. ISBN 978-0-321-63584-6.
- ^ Snedaker, Susan; Nels Hoenig (2005). Cómo hacer trampa en la gestión de proyectos de TI . Syngress. ISBN 1-59749-037-7.
- ^ Beck, Kent (2000). Programación extrema explicada: acepte el cambio . Reading, MA: Addison-Wesley. pp. 15 -19. ISBN 0-201-61641-6.
- ^ Dangelo, Mark (2005). Relevancia innovadora: realinear la organización con fines de lucro: no es una batalla por las "fronteras", es una lucha por un propósito . Nueva York: iUniverse. pag. 53. ISBN 978-0-595-67081-9.
- ^ Godin, Seth. Getting Real: La forma más inteligente, rápida y fácil de crear una aplicación web exitosa . 37 señales.
- ^ a b c Jennifer., Stapleton (1997). DSDM, método de desarrollo de sistemas dinámicos: el método en la práctica . Harlow, Inglaterra: Addison-Wesley. ISBN 0201178893. OCLC 36755892 .
- ^ a b Para todos los tipos de proyectos, el boxeo de tiempo ocupó el puesto 23 y se calificó como "Muy buena práctica"; para proyectos pequeños (1000 puntos de función ) clasificados en 7 y calificados como "Mejores prácticas" por la encuesta en Jones, alcaparras (2010). Lecciones de mejores prácticas de ingeniería de software de proyectos exitosos en las principales empresas . Nueva York: McGraw-Hill. ISBN 978-0-07-162162-5.
- ^ a b c d e McConnell, Steve (1996). Desarrollo rápido: domesticar los programas de software salvajes . Redmond, Wash: Microsoft Press. pp. 575 -583. ISBN 1-55615-900-5.
- ^ Poppendieck, Mary (2010). Desarrollo de software Lean líder: los resultados no son el punto . Upper Saddle River, Nueva Jersey: Addison-Wesley. págs. 137–140. ISBN 978-0-321-62070-5.
- ^ Coplien, James (2010). Arquitectura ajustada para el desarrollo de software ágil . Chichester Hoboken, Nueva Jersey: Wiley. pag. 25. ISBN 978-0-470-68420-7.
- ^ Cohn, Mike (2010). Tener éxito con Agile: Desarrollo de software usando Scrum . Upper Saddle River, Nueva Jersey: Addison-Wesley. pp. 257 -284. ISBN 978-0-321-57936-2.
- ^ a b Schwaber, Ken (2009). Gestión ágil de proyectos con Scrum . Nueva York: O'Reilly Media, Inc. ISBN 978-0-7356-3790-0.
- ^ Leffingwell, Dean (2011). Requisitos de software ágil: prácticas de requisitos ajustados para equipos, programas y la empresa . Upper Saddle River, Nueva Jersey: Addison-Wesley. pag. 15. ISBN 978-0-321-63584-6.
- ^ Beck, Kent (2000). Programación extrema explicada: acepte el cambio . Reading, MA: Addison-Wesley. págs. 85 –96. ISBN 0-201-61641-6.
- ^ Pash, Adam (2011). Lifehacker la guía para trabajar de forma más inteligente, más rápida y mejor . Indianápolis, Indiana: Wiley. Hack 29. ISBN 978-1-118-13345-3.
- ^ Nöteberg, Staffan (2009). Técnica Pomodoro ilustrada . Raleigh, NC: Estantería pragmática. ISBN 978-1-934356-50-0.
- ^ Hunt, Andrew (2008). Pensamiento y aprendizaje pragmático: refactorice su software . Raleigh: pragmático. ISBN 978-1-934356-05-0.