En los principios ágiles , el timeboxing consiste en asignar una unidad máxima de tiempo a una actividad, denominada timebox , dentro de la cual se desarrolla una actividad planificada. Se utiliza en enfoques de gestión de proyectos basados en principios ágiles 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 (timeboxes), cada uno con sus propios entregables, fecha límite y presupuesto. A veces se le denomina cronograma como variable independiente (SAIV). [ 1 ] "El timeboxing funciona mejor en proyectos o tareas de varias etapas que requieren poco tiempo y que se pueden integrar en el mismo intervalo de tiempo. También es recomendable implementarlo en el caso de tareas con plazos de finalización previsibles." [ 2 ]
Como alternativa a la fijación del alcance
En la gestión de proyectos , generalmente se consideran tres restricciones : tiempo (a veces cronograma ), costo (a veces presupuesto ) y alcance . [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] ( La calidad a menudo se agrega como una cuarta restricción, representada como el centro de un triángulo. [ 8 ] [ 9 ] [ 10 ] ) Se asume que un cambio en una restricción afectará a las demás. [ 6 ]
Sin la limitación de tiempo, los proyectos suelen trabajar con un alcance fijo, [ 11 ] en cuyo caso, cuando queda claro que algunos entregables no pueden completarse dentro de los plazos previstos, o bien hay que ampliar el plazo (para disponer de más tiempo para completar el alcance fijo) o bien se involucra a más personas (para completar el alcance fijo en el mismo tiempo). A menudo ocurren ambas cosas, lo que resulta en retrasos en la entrega, mayores costes y, con frecuencia, una menor calidad (según el principio del "hombre-mes mítico ").
Con la técnica de timeboxing, el plazo es fijo, lo que implica que el alcance debe reducirse. Dado que esto significa que las organizaciones deben centrarse en completar primero los entregables más importantes, el timeboxing suele ir de la mano con un esquema para priorizar los entregables (como el método MoSCoW ). [ 12 ]
Para gestionar el riesgo
Los plazos de tiempo se utilizan como una forma de gestión de riesgos , para identificar explícitamente relaciones inciertas entre tareas y tiempo, es decir, trabajo que puede extenderse fácilmente más allá de su fecha límite. Las restricciones de tiempo suelen ser un factor determinante en la planificación y no deben modificarse sin considerar las rutas críticas del proyecto o subproyecto. Es decir, generalmente es importante cumplir con los plazos. Los factores de riesgo para el incumplimiento de plazos pueden incluir complicaciones previas al proyecto, errores de planificación dentro del proyecto, problemas relacionados con el equipo o una ejecución defectuosa del plan. Los problemas previos pueden incluir cambios en la misión del proyecto o el respaldo/apoyo de la gerencia. Un error común de planificación es la división inadecuada de tareas, lo que puede llevar a una subestimación del 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 de la funcionalidad transversal necesaria; falta de compromiso/impulso/motivación (es decir, mala formación y gestión del equipo).
Para cumplir con el plazo, se suelen evaluar las siguientes acciones en relación con las tres restricciones:
- Reducir el alcance: eliminar los requisitos de menor impacto (aquellos que el usuario no echará de menos directamente).
- El tiempo es la restricción fija aquí.
- Aumento de costes: por ejemplo, añadir horas extras o recursos.
Adopción en el desarrollo de software
Muchos proyectos exitosos de desarrollo de software utilizan la técnica de timeboxing, especialmente los más pequeños. [ 13 ] La adopción de timeboxing triplicó con creces la productividad de los desarrolladores en DuPont en los años 80. [ 14 ] En algunos casos, las aplicaciones se entregaron completamente dentro del tiempo estimado para completar solo una especificación . [ 14 ] Sin embargo, Steve McConnell argumenta que no todos los productos son adecuados [ 14 ] y que timeboxing solo debería usarse después de que el cliente acepte recortar funcionalidades, no calidad. [ 14 ] Hay poca evidencia de una fuerte adopción entre la clase de proyectos más grandes. [ 13 ]
La técnica de gestión del tiempo por bloques ha sido adoptada por algunas metodologías de desarrollo de software destacadas :
- Método de desarrollo de sistemas dinámicos (DSDM). [ 12 ]
- En el desarrollo de software lean , la programación pull con Kanban proporciona una gestión del tiempo a corto plazo. Al desarrollar un sistema grande y complejo, donde se requiere una planificación a largo plazo , se añade la técnica de timeboxing . [ 15 ]
- El proceso de desarrollo de software de desarrollo rápido de aplicaciones (RAD) se caracteriza por el desarrollo iterativo y la creación de prototipos de software . Según Steve McConnell , la asignación de plazos (timeboxing) es una "mejor práctica" para RAD y la duración típica de un plazo debería ser de 60 a 120 días. [ 14 ]
- Scrum fue influenciado por las ideas de timeboxing y desarrollo iterativo . [ 16 ] Las unidades regulares de timeboxing conocidas como sprints forman la unidad básica de desarrollo. [ 17 ] Una duración típica para un sprint es menos de 30 días. [ 18 ] [ 19 ] Las reuniones de planificación del sprint, retrospectiva del sprint y revisión del sprint tienen timeboxing. [ 18 ]
- En las metodologías de programación extrema , la planificación del desarrollo se divide en iteraciones con plazos fijos, generalmente de 1, 2 o 3 semanas de duración. La empresa reevalúa las historias de usuario pendientes antes de cada iteración. [ 20 ]
El desarrollo ágil de software aboga por pasar de un desarrollo basado en la planificación a un desarrollo basado en el valor . La calidad y el tiempo son fijos, pero se permite flexibilidad en el alcance. Entregar primero las funcionalidades más importantes conduce a un retorno de la inversión más rápido que el modelo en cascada . [ 7 ]
La falta de especificaciones detalladas suele deberse a la falta de tiempo o al desconocimiento del resultado (solución) deseado. En muchos tipos de proyectos, y especialmente en ingeniería de software, analizar y definir todos los requisitos y especificaciones antes del inicio de la fase de realización es imposible. El timeboxing puede ser un tipo de contrato favorable para proyectos en los que el plazo de entrega es el aspecto más crítico y cuando no todos los requisitos están completamente especificados de antemano. Esto también permite que la retroalimentación o las nuevas ideas descubiertas durante el proyecto se reflejen en el resultado. [ 12 ]
En la gestión del tiempo personal
La técnica de 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 un entregable de proyecto), y a menudo se denomina timeblocking .
También se dice que la gestión del tiempo personal actúa como un truco para ayudar a controlar las tendencias perfeccionistas (al establecer un tiempo fijo y no comprometerse demasiado con una tarea), lo que también puede mejorar la creatividad y la concentración (al crear una sensación de urgencia o mayor presión). [ 21 ]
Relación con otros métodos
La técnica de la gestión del tiempo por bloques actúa como un elemento fundamental en otros métodos de gestión del tiempo personal:
- La técnica Pomodoro se basa en bloques de tiempo de 25 minutos de concentración enfocada separados por descansos que permiten que la mente se recupere. [ 22 ]
- Andy Hunt da el timeboxing como su 'T' en SMART . [ 23 ]
Véase también
- El sprint de diseño es un proceso de cinco fases con límite de tiempo que se utiliza en el pensamiento de diseño.
Referencias
- ↑ Boehm, Barry W.; Boehm, Barry; Turner, Richard (2004). Equilibrando agilidad y disciplina: una guía para los perplejos . Addison-Wesley Professional. ISBN 9780321186126.
- ↑ "Timeboxing: ¿por qué deberías usarlo?" . Firmbee . 17/01/2022 . Consultado el 25/01/2022 .
- ↑ ¿Cuáles son las restricciones triples en la gestión de proyectos? Enlace obsoleto archivado el 20/08/2006 en archive.today , artículo de Rod Hutchings en Project Management Australia Archivado el 16/02/2009 en Wayback Machine (22 de octubre de 2008)
- ↑ Chatfield, Carl. "Un curso breve de gestión de proyectos" . Microsoft.
- ↑ Dobson, Michael (2004). Las tres restricciones en la gestión de proyectos . Vienna, Va: Management Concepts. ISBN 1-56726-152-3.
- ^ Kanabar , Vijay (2008). Fundamentos del MBA: Gestión de proyectos . Nueva York: Pub Kaplan. pag. 51.ISBN 978-1-4277-9744-5.
- 1 2 Leffingwell, Dean (2011). Requisitos de software ágiles: prácticas de requisitos Lean para equipos, programas y la empresa . Upper Saddle River, NJ: Addison-Wesley. pp. 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: acepta el cambio . Reading, MA: Addison-Wesley. pp. 15-19 . ISBN 0-201-61641-6.
- ↑ Dangelo, Mark (2005). Relevancia innovadora: realinear la organización para obtener beneficios: no es una batalla por las "líneas de costa", es una lucha por el propósito . Nueva York: iUniverse. pág. 53. ISBN 978-0-595-67081-9.
- ↑ Godin, Seth. Getting Real: La forma más inteligente, rápida y sencilla de crear una aplicación web exitosa . 37signals.
- 1 2 3 Jennifer., Stapleton (1997). DSDM, método de desarrollo de sistemas dinámicos: el método en la práctica . Harlow, Inglaterra: Addison-Wesley. ISBN 0201178893OCLC 36755892
- 1 2 Para todos los tipos de proyectos, la gestión del tiempo (time boxing) ocupó el puesto 23 y fue calificada como "Muy buena práctica"; para proyectos pequeños (1000 puntos de función ), ocupó el puesto 7 y fue calificada como "Mejor práctica" según la encuesta realizada en Jones, Capers (2010). Software engineering best practices lessons from successful projects in the top companies . Nueva York: McGraw-Hill. ISBN 978-0-07-162162-5.
- 1 2 3 4 5 McConnell, Steve (1996). Desarrollo rápido: cómo controlar los cronogramas de software descontrolados . Redmond, Wash: Microsoft Press. págs. 575–583 . ISBN 1-55615-900-5.
- ↑ Poppendieck, Mary (2010). Liderando el desarrollo de software Lean: Los resultados no son lo importante . Upper Saddle River, NJ: Addison-Wesley. pp. 137–140 . ISBN 978-0-321-62070-5.
- ↑ Coplien, James (2010). Lean Architecture for Agile Software Development . Chichester Hoboken, NJ: Wiley. p. 25. ISBN 978-0-470-68420-7.
- ↑ Cohn, Mike (2010). Succeeding with Agile: Software Development using Scrum . Upper Saddle River, NJ: Addison-Wesley. pp. 257–284 . ISBN 978-0-321-57936-2.
- 1 2 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 ágiles: prácticas de requisitos Lean para equipos, programas y la empresa . Upper Saddle River, NJ: Addison-Wesley. pág. 15. ISBN 978-0-321-63584-6.
- ↑ Beck, Kent (2000). Programación extrema explicada: acepta el cambio . Reading, MA: Addison-Wesley. pp. 85-96 . ISBN 0-201-61641-6.
- ↑ Pash, Adam (2011). Lifehacker: la guía para trabajar de forma más inteligente, rápida y eficaz . Indianápolis, Indiana: Wiley. Hack 29. ISBN 978-1-118-13345-3.
- ↑ Nöteberg, Staffan (2009). Técnica Pomodoro ilustrada . Raleigh, NC: Pragmatic Bookshelf. ISBN 978-1-934356-50-0.
- ↑ Hunt, Andrew (2008). Pensamiento y aprendizaje pragmáticos: refactoriza tu software biológico . Raleigh: Pragmatic. ISBN 978-1-934356-05-0.
- Gestión del tiempo
- Método de desarrollo de sistemas dinámicos
- Gestión de proyectos de software
- Desarrollo ágil de software
- Fabricación ajustada