stringtranslate.com

Bloqueo de tiempo

En los principios ágiles , el timeboxing asigna una unidad máxima de tiempo a una actividad, denominada timebox , dentro del cual se lleva a cabo una actividad planificada. Se utiliza en los 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), y cada parte tiene sus propios entregables, plazo y presupuesto. [ cita requerida ] A veces se lo denomina cronograma como variable independiente (SAIV). [1] "El timeboxing funciona mejor en proyectos o tareas de varias etapas que requieren poco tiempo y se pueden incluir en el mismo intervalo de tiempo. También vale la pena implementarlo en el caso de tareas que tienen 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 medio de un triángulo. [8] [9] [10] ) Se supone que un cambio en una restricción afectará a las demás. [6]

Sin timeboxing, los proyectos suelen funcionar con un alcance fijo [11], en cuyo caso, cuando resulta evidente que algunos entregables no pueden completarse dentro de los plazos planificados, se debe ampliar el plazo (para disponer de más tiempo para completar el alcance fijo) o hay que involucrar a más personas (para completar el alcance fijo en el mismo tiempo). A menudo ocurren ambas cosas, lo que da como resultado una entrega retrasada, mayores costos y, a menudo, una calidad reducida (según el principio mítico del hombre-mes ).

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

Para gestionar el riesgo

Los timeboxes 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 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, normalmente es importante cumplir con los plazos. Los factores de riesgo de incumplimiento de los plazos pueden incluir complicaciones en la fase anterior del proyecto, errores de planificación dentro del proyecto, problemas relacionados con el equipo o ejecución defectuosa del plan. Los problemas en la fase anterior pueden incluir cambios en la misión del proyecto o en el respaldo/apoyo de la dirección. Un error de planificación común es el desglose inadecuado de las tareas, 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 de multifuncionalidad requerida; falta de compromiso/empuje/motivación (es decir, formación y gestión deficientes del equipo).

Para cumplir con el plazo, comúnmente se evalúan las siguientes acciones frente a las restricciones triples:

Adopción en el desarrollo de software

Muchos proyectos de desarrollo de software exitosos utilizan timeboxing, especialmente los más pequeños. [13] La adopción de timeboxing triplicó 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 sostiene que no todos los productos son adecuados [14] y que el timeboxing solo debería usarse después de que el cliente acepte reducir las características, no la calidad. [14] Hay poca evidencia de una fuerte adopción entre la clase más grande de proyectos. [13]

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

El desarrollo ágil de software aboga por pasar de un desarrollo orientado a la planificación a un desarrollo orientado al valor . La calidad y el tiempo son fijos, pero se permite flexibilidad en el alcance. Entregar primero las características más importantes conduce a un retorno de la inversión más temprano que el modelo en cascada . [7]

La falta de especificaciones detalladas suele ser consecuencia de la falta de tiempo o de 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. 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 se especifican todos los requisitos por completo desde el principio. Esto también permite que los nuevos comentarios o los nuevos conocimientos descubiertos durante el proyecto se reflejen en el resultado final. [12]

En la gestión del tiempo personal

El timeboxing se puede utilizar para tareas personales, en cuyo caso utiliza una escala reducida de tiempo (por ejemplo, treinta minutos) y de entregables (por ejemplo, una tarea doméstica en lugar de un entregable de un proyecto), y a menudo se denomina timeblocking .

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), 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

El timeboxing actúa como un elemento fundamental en otros métodos de gestión personal del tiempo:

Véase también

Referencias

  1. ^ 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.
  2. ^ "Timeboxing: ¿por qué deberías usarlo?". Firmbee . 2022-01-17 . Consultado el 2022-01-25 .
  3. ^ ¿Cuáles son las restricciones triples en la gestión de proyectos? Archivado el 20 de agosto de 2006 en archive.today , artículo de Rod Hutchings en Project Management Australia Archivado el 16 de febrero de 2009 en Wayback Machine (22 de octubre de 2008)
  4. ^ Chatfield, Carl. "Un curso breve sobre gestión de proyectos". Microsoft.
  5. ^ Dobson, Michael (2004). Las tres restricciones en la gestión de proyectos . Vienna, Va: Management Concepts. ISBN 1-56726-152-3.
  6. ^ ab Kanabar, Vijay (2008). Fundamentos de MBA: Gestión de proyectos . Nueva York: Kaplan Pub. p. 51. ISBN 978-1-4277-9744-5.
  7. ^ ab 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ágs. 17-19. ISBN 978-0-321-63584-6.
  8. ^ Snedaker, Susan; Nels Hoenig (2005). Cómo hacer trampa en la gestión de proyectos de TI . Syngress. ISBN 1-59749-037-7.
  9. ^ Beck, Kent (2000). Explicación de la programación extrema: acepte el cambio . Reading, MA: Addison-Wesley. pp. 15–19. ISBN 0-201-61641-6.
  10. ^ Dangelo, Mark (2005). Relevancia innovadora: realinear la organización para obtener ganancias: no es una batalla por las "líneas costeras", es una lucha por el propósito. Nueva York: iUniverse. p. 53. ISBN 978-0-595-67081-9.
  11. ^ Godin, Seth. Getting Real: La forma más inteligente, rápida y sencilla de crear una aplicación web exitosa . 37signals.
  12. ^ abc 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  .
  13. ^ ab Para todos los tipos de proyectos, el time boxing ocupó el puesto 23 y se calificó como "Muy buena práctica"; para proyectos pequeños (1000 puntos de función ), ocupó el puesto 7 y se calificó como "Mejor práctica" según la encuesta de Jones, Capers (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.
  14. ^ abcde McConnell, Steve (1996). Desarrollo rápido: cómo dominar los calendarios de software salvajes . Redmond, Washington: Microsoft Press. pp. 575–583. ISBN 1-55615-900-5.
  15. ^ Poppendieck, Mary (2010). Liderando el desarrollo de software Lean: los resultados no son el punto . Upper Saddle River, NJ: Addison-Wesley. págs. 137–140. ISBN 978-0-321-62070-5.
  16. ^ Coplien, James (2010). Arquitectura Lean para el desarrollo ágil de software. Chichester Hoboken, NJ: Wiley. p. 25. ISBN 978-0-470-68420-7.
  17. ^ Cohn, Mike (2010). Cómo tener éxito con Agile: desarrollo de software con Scrum . Upper Saddle River, NJ: Addison-Wesley. págs. 257–284. ISBN 978-0-321-57936-2.
  18. ^ de Schwaber, Ken (2009). Gestión ágil de proyectos con Scrum. Nueva York: O'Reilly Media, Inc. ISBN 978-0-7356-3790-0.
  19. ^ 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. 15. ISBN 978-0-321-63584-6.
  20. ^ Beck, Kent (2000). Explicación de la programación extrema: acepte el cambio . Reading, MA: Addison-Wesley. pp. 85–96. ISBN 0-201-61641-6.
  21. ^ 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.
  22. ^ Nöteberg, Staffan (2009). Pomodoro Technique Illustrated . Raleigh, Carolina del Norte: Pragmatic Bookshelf. ISBN 978-1-934356-50-0.
  23. ^ Hunt, Andrew (2008). Pensamiento y aprendizaje pragmático: refactorice su software. Raleigh: Pragmatic. ISBN 978-1-934356-05-0.