Timeboxing

En principis àgils, el timeboxing assigna una unitat màxima de temps a una activitat, anomenada timebox, dins de la qual té lloc una activitat planificada. S'utilitza per enfocaments àgils de gestió de projectes basats en principis i per a la gestió personal del temps.

En gestió de projectes

Timeboxing s'utilitza com a tècnica de planificació de projectes. El calendari es divideix en una sèrie de períodes de temps separats (caixes de temps), amb cada part amb els seus propis lliuraments, termini i pressupost. De vegades s'anomena programa com a variable independent (SAIV).^[1] "Timeboxing funciona millor en projectes multietapa o en tasques que requereixen poc temps i pots encaixar-los en la mateixa franja horària. També val la pena implementar-ho en cas de tasques que tinguin terminis previsibles d'execució".^[2]

Com a alternativa a la fixació d'abast

En la gestió de projectes, generalment es considera que hi ha tres limitacions: temps (de vegades programació), cost (de vegades pressupost) i abast.^[3]^[4]^[5] (La qualitat s'afegeix sovint com una quarta restricció --- representada com la meitat d'un triangle.^[6]^[7]^[8]) El supòsit és que un canvi en una restricció afectarà les altres.^[4]

Per gestionar el risc

Les caixes de temps s'utilitzen com una forma de gestió de riscos, per identificar de manera explícita les relacions tasques/temps incertes, és a dir, treballs que es poden estendre fàcilment més enllà del seu termini. Les limitacions de temps solen ser un factor principal en la planificació i no s'han de canviar sense tenir en compte els camins crítics del projecte o subprojecte. És a dir, normalment és important complir els terminis. Els factors de risc per als terminis incomplerts poden incloure complicacions aigües amunt del projecte, errors de planificació dins del projecte, problemes relacionats amb l'equip o execució defectuosa del pla. Els problemes aigües amunt poden incloure canvis en la missió del projecte o el suport/suport de la direcció. Un error de planificació comú és el desglossament inadequat de les tasques, que pot conduir a subestimar el temps necessari per dur a terme el treball. Els problemes relacionats amb l'equip poden incloure problemes amb la comunicació entre equips; manca d'experiència o funcionalitat transversal necessària; manca de compromís/empenta/motivació (és a dir, mala formació i gestió d'equips).

Adopció en desenvolupament de programari

Molts projectes de desenvolupament de programari amb èxit utilitzen timeboxing, especialment els més petits. L'adopció del timeboxing va triplicar la productivitat dels desenvolupadors a DuPont als anys 80.^[9] En alguns casos, les aplicacions es van lliurar completament dins del temps estimat per completar només una especificació.^[9] Tanmateix, Steve McConnell argumenta que no tots els productes són adequats ^[9] i que el timebox només s'hauria d'utilitzar després que el client accepti retallar les característiques, no la qualitat.^[9] Hi ha poques evidències d'una adopció forta entre la classe més gran de projectes.

Timeboxing ha estat adoptat per algunes metodologies de desenvolupament de programari notables:

Mètode de desenvolupament de sistemes dinàmics (DSDM).
En el desenvolupament de programari ajustat, la programació d'extracció amb Kanban proporciona una gestió del temps a curt termini. Quan es desenvolupa un sistema gran i complex, on es requereix una planificació a llarg termini, la caixa de temps es troba a la part superior.
El procés de desenvolupament de programari de desenvolupament ràpid d'aplicacions (RAD) inclou desenvolupament iteratiu i prototipat de programari. Segons Steve McConnell, la caixa de temps és una "pràctica millor" per a RAD i la durada típica de la caixa de temps hauria de ser de 60 a 120 dies.
Scrum va ser influenciat per idees de timeboxing i desenvolupament iteratiu. Les unitats de temps normals conegudes com sprints formen la unitat bàsica de desenvolupament. La durada típica d'un sprint és inferior a 30 dies. La planificació de l'esprint, la retrospectiva de l'esprint i les reunions de revisió de l'esprint tenen un calendari.
En les metodologies de programació extrema, la planificació del desenvolupament es divideix en iteracions, normalment d'1, 2 o 3 setmanes de durada. L'empresa revaloritza les històries d'usuari pendents abans de cada iteració.

Per mantenir-se en el termini, s'avaluen habitualment les següents accions contra les restriccions triples:

Reduir l'abast: baixar els requisits de menor impacte (els que no passaran directament a faltar per l'usuari)
El temps és la limitació fixa aquí
Augmentar el cost: per exemple, afegir hores extraordinàries o recursos

Referències

↑ Boehm, Barry W. Balancing Agility and Discipline: A Guide for the Perplexed (en anglès). Addison-Wesley Professional, 2004. ISBN 9780321186126.
↑ «Timeboxing – why you should use it?» (en anglès). Firmbee, 17-01-2022. [Consulta: 25 gener 2022].
↑ Dobson, Michael. The triple constraints in project management (en anglès). Vienna, Va: Management Concepts, 2004. ISBN 1-56726-152-3.
↑ ^4,0 ^4,1 Kanabar, Vijay. MBA Fundamentals: Project Management (en anglès). New York: Kaplan Pub, 2008, p. 51. ISBN 978-1-4277-9744-5.
↑ Leffingwell, Dean. Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise (en anglès). Upper Saddle River, NJ: Addison-Wesley, 2011, p. 17–19. ISBN 978-0-321-63584-6.
↑ Snedaker, Susan. How to Cheat at IT Project Management (en anglès). Syngress, 2005. ISBN 1-59749-037-7.
↑ Beck, Kent. Extreme programming eXplained: embrace change (en anglès). Reading, MA: Addison-Wesley, 2000, p. 15–19. ISBN 0-201-61641-6.
↑ Dangelo, Mark. Innovative relevance: realigning the organization for profit: it is not a battle for the "shore lines" - it's a struggle for purpose (en anglès). New York: iUniverse, 2005, p. 53. ISBN 978-0-595-67081-9.
↑ ^9,0 ^9,1 ^9,2 ^9,3 McConnell, Steve. Rapid Development: taming wild software schedules (en anglès). Redmond, Wash: Microsoft Press, 1996, p. 575–583. ISBN 1-55615-900-5.

[1] Boehm, Barry W. Balancing Agility and Discipline: A Guide for the Perplexed (en anglès). Addison-Wesley Professional, 2004. ISBN 9780321186126.

[2] «Timeboxing – why you should use it?» (en anglès). Firmbee, 17-01-2022. [Consulta: 25 gener 2022].

[3] Dobson, Michael. The triple constraints in project management (en anglès). Vienna, Va: Management Concepts, 2004. ISBN 1-56726-152-3.

[Kanabar-4] 4,0 ^4,1 Kanabar, Vijay. MBA Fundamentals: Project Management (en anglès). New York: Kaplan Pub, 2008, p. 51. ISBN 978-1-4277-9744-5.

[Leffingwell-5] Leffingwell, Dean. Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise (en anglès). Upper Saddle River, NJ: Addison-Wesley, 2011, p. 17–19. ISBN 978-0-321-63584-6.

[6] Snedaker, Susan. How to Cheat at IT Project Management (en anglès). Syngress, 2005. ISBN 1-59749-037-7.

[7] Beck, Kent. Extreme programming eXplained: embrace change (en anglès). Reading, MA: Addison-Wesley, 2000, p. 15–19. ISBN 0-201-61641-6.

[Dangelo-8] Dangelo, Mark. Innovative relevance: realigning the organization for profit: it is not a battle for the "shore lines" - it's a struggle for purpose (en anglès). New York: iUniverse, 2005, p. 53. ISBN 978-0-595-67081-9.

[McConnell-9] 9,0 ^9,1 ^9,2 ^9,3 McConnell, Steve. Rapid Development: taming wild software schedules (en anglès). Redmond, Wash: Microsoft Press, 1996, p. 575–583. ISBN 1-55615-900-5.

[1]