Timeboxing

Timeboxing is het vooraf beperken van de hoeveelheid tijd die men aan een bepaalde activiteit wil en mag besteden. Dit om te voorkomen dat iets uitloopt.

Gebruik[bewerken | brontekst bewerken]

Het wordt veel gebruikt, alleen heeft men er (nog) geen goed Nederlands woord voor.^[bron?] Ouders kunnen bijvoorbeeld hun kinderen toestaan om tot een bepaalde (beperkte)tijd TV te kijken. Vergaderingen hebben vaak een begin- en eindtijdstip en daarmee een timebox. Hetzelfde geldt voor cursussen, examens en vakanties. Ook het weekend is een timebox.

In projectmanagement[bewerken | brontekst bewerken]

Verschillende projectmanagement methoden gebruiken timeboxing.^[1] Timeboxing wordt gebruikt als een methode om projecten te plannen. De planning bestaat uit een aantal verschillende perioden (timeboxes), met elk hun eigen producten, budget en deadline.

Als een alternatief voor het bevriezen van de specificaties[bewerken | brontekst bewerken]

Bij projectmanagement bestaat de duivelsdriehoek uit tijd, kosten (soms budget), en scope (soms performance).^[2]^[3]^[4]^[5]^[6] Kwaliteit wordt hier vaak aan toegevoegd,^[7]^[8] soms vervangt dit de scope.^[9] Het veranderen van een beperking heeft waarschijnlijk gevolgen voor de rest.^[5]

Als er geen timeboxing gebruikt wordt hebben projecten meestal vastgelegd aan welke specificaties het eindproduct moet voldoen, de scope^[10] hierdoor kan het gebeuren dat het project uitloopt of er worden meer mensen bij betrokken om toch op tijd klaar te zijn. Meestal doet men beide en lukt het toch niet om binnen de planning en budget te blijven, vaak gaat het zelfs ten koste van de gewenste kwaliteit (features).

Als men timeboxing gebruikt staat de opleveringsdatum vast, dit gaat dan ten koste van de kwaliteit. Hierdoor concentreert men zich op de belangrijkste eisen. Hierbij is het dan belangrijk dat de prioriteiten bepaald worden door de gebruikers / klant, bijvoorbeeld met de MoSCoW-methode, in plaats van door de softwareontwikkelaars.

Risicobeheersing[bewerken | brontekst bewerken]

Timeboxes worden ook gebruikt als een vorm van risk management, om duidelijk bepaalde taken te benoemen die gemakkelijk kunnen uitlopen. De tijd is een belangrijke factor in veel planningen en kan niet zomaar veranderd worden zonder dat er gekeken wordt naar de gevolgen die dit heeft voor het kritieke pad. Normaal gesproken is het van belang om deadlines te halen. Gemiste deadlines kunnen later in het project gevolgen hebben, het kan leiden tot fouten in de (eerder afgegeven) planning. Ook kunnen de teamleden er problemen mee krijgen. Zelfs het hele plan kan fout lopen. Het kan leiden tot het niet halen van doelstellingen en tot management dat vervelend gaat doen. Een bekende fout is dat taken niet genoeg gedetailleerd zijn, wat snel leidt tot een te lage tijdsschatting. Door timeboxing wordt snel duidelijk dat dingen niet goed lopen. Het kan bijvoorbeeld ook aan het team liggen. Dingen die fout kunnen gaan binnen een team zijn de communicatie binnen het team, gebrek aan ervaring en te weinig generalisten/breed inzetbare mensen die collega's kunnen en willen helpen. Ook kan er een gebrek aan motivatie zijn.

Om deadlines te halen kunnen de volgende acties overwogen worden:

Vermindering van het aantal zaken dat opgeleverd wordt, minder belangrijke zaken laat men vallen, dingen die niet direct gemist worden door de gebruiker/klant.
De tijd staat vast, die kan niet veranderen
Toename van de kosten: bijvoorbeeld door overwerk of het inzetten van extra personeel.

Toepassing bij softwareontwikkeling[bewerken | brontekst bewerken]

Veel succesvolle softwareprojecten gebruiken timeboxing, vooral de kleinere.^[11] Door timeboxing toe te passen ging de productiviteit met een factor 3 omhoog bij DuPont in de jaren 80.^[12] Soms worden applicaties volledig opgeleverd binnen de tijd die stond voor het opleveren van enkele features, alleen maar door timeboxing te gebruiken.^[12] Echter, Steve McConnell stelt dat niet elk product hier even geschikt voor is^[12] en dat timeboxing alleen maar gebruikt kan worden met de instemming van de klant, die moet durven snijden in toeters en bellen en niet in kwaliteit.^[12] er is weinig bewijs dat men ook aan timeboxing wil doen bij grotere projecten.^[11]

Timeboxing is een onderdeel van enkele belangrijke software ontwikkelingsmethoden:

Dynamic systems development method (DSDM)
In lean softwaredevelopment, pull scheduling met Kanban heeft ook timeboxing met heel kleine perioden. Als er een groot en ingewikkeld systeem ontwikkeld wordt waarbij langetermijnplanning wordt gebruikt gebruikt en ook timeboxing.^[13]
Rapid application development (RAD). Volgens Steve McConnell is timeboxing een "Best Practice" van RAD en een normale timebox is hier 60 tot 120 dagen.^[12]
Scrum gebruikt ook veel timeboxing en iteratieve ontwikkeling.^[14] Bij Scrum wordt uitsluitend in sprints gewerkt.^[15] De typische lengte van een sprint is 30 dagen.^[16]^[17] Sprintplanning, sprintretrospective en sprintreviews zitten allemaal in een timebox.^[16]
Extreme programming heeft als kenmerken communicatie, eenvoud, feedback en moed.^[18] Hierbij wordt de planning en ontwikkeling gedaan in timeboxen, iteraties van 1, 2 of 3 weken. De gebruikers bepalen de prioriteit van de requirements in de vorm van user stories vlak voor de iteratie.^[19]

Agile-softwareontwikkeling zegt dat men niet moet sturen op een plan maar op de waarde die geproduceerd wordt. De kwaliteit en de tijd liggen vast maar er kan gevarieerd worden met hoeveel er opgeleverd wordt. Het aan het begin opleveren van de belangrijkste zaken leidt tot een betere return on investment dan de watervalmethode.^[6]

Een gebrek aan gedetailleerde specificaties is typisch het resultaat van tijdsgebrek of onduidelijkheid over wat er precies gewenst is. In veel projecten en speciaal in software projecten is het vrijwel onmogelijk om vooraf al de requirements en specificaties boven tafel te krijgen.

In persoonlijk tijdmanagement[bewerken | brontekst bewerken]

Mensen gebruiken in hun privéleven ook timeboxing. Hierbij worden kleinere tijdseenheden gebruikt, bijvoorbeeld een half uur in plaats van een week. Dit om bijvoorbeeld huishoudelijke taken te doen zoals de hond uitlaten en stofzuigen. Er wordt gezegd dat het gebruik van timeboxing in het persoonlijke leven ertoe kan leiden dat perfectionistisch gedrag beperkt wordt. Adam Pash schrijft dat timeboxing uitstelgedrag helpt voorkomen. Veel mensen zeggen dat zij onder tijdsdruk goed presteren en dat dit uitstekend is voor hun creativiteit en concentratie.^[20]

Overig gebruik[bewerken | brontekst bewerken]

Timeboxing wordt veel gebruikt in methoden van persoonlijk tijdmanagement.

De Pomodorotechniek is gebaseerd op timeboxes van 25 minuten concentratie met kleine pauzes om het geheugen tot rust te laten komen.^[21]
Andy Hunt zegt dat timeboxing de 'T' is in SMART-principe.^[22]

Zie ook[bewerken | brontekst bewerken]

Externe links[bewerken | brontekst bewerken]

Bronnen, noten en/of referenties

↑ Poppendieck, Mary (2010). Leading Lean Software Development: Results Are Not the Point. Addison-Wesley, Upper Saddle River, NJ, p. 139. ISBN 978-0-321-62070-5.
↑ What are the Triple Constraints in Project Management, article by Rod Hutchings on Project Management Australia (22 Oct 2008)
↑ Chatfield, Carl, "A short course in project management", Microsoft.
↑ Dobson, Michael (2004). The triple constraints in project management. Management Concepts, Vienna, Va. ISBN 1-56726-152-3.
↑ ^a ^b Kanabar, Vijay (2008). MBA Fundamentals: Project Management. Kaplan Pub, New York, 51. ISBN 978-1-4277-9744-5.
↑ ^a ^b Leffingwell, Dean (2011). Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Addison-Wesley, Upper Saddle River, NJ, 17–19. ISBN 978-0-321-63584-6.
↑ Snedaker, Susan, Nels Hoenig (2005). How to Cheat at IT Project Management. Syngress. ISBN 1-59749-037-7.
↑ Beck, Kent (2000). Extreme programming eXplained: embrace change. Addison-Wesley, Reading, MA, 15–19. ISBN 0-201-61641-6.
↑ Dangelo, Mark (2005). Innovative relevance: realigning the organization for profit: it is not a battle for the "shore lines" - it's a struggle for purpose. iUniverse, New York, p. 53. ISBN 978-0-595-67081-9.
↑ Godin, Seth. Getting Real: The smarter, faster, easier way to build a successful web application. 37signals.
↑ ^a ^b For all project types time boxing ranked 23 and rated "Very Good Practice"; for small (1000 functiepunten) projecten ranked 7 and rated a "Best Practice" bij een onderzoek in Jones, Capers (2010). Software engineering best practices lessons from successful projects in the top companies. McGraw-Hill, New York. ISBN 978-0-07-162162-5.
↑ ^a ^b ^c ^d ^e McConnell, Steve (1996). Rapid Development: taming wild software schedules. Microsoft Press, Redmond, Wash, 575–583. ISBN 1-55615-900-5.
↑ Poppendieck, Mary (2010). Leading Lean Software Development: Results are not the Point. Addison-Wesley, Upper Saddle River, NJ, 137–140. ISBN 978-0-321-62070-5.
↑ Coplien, James (2010). Lean Architecture for Agile Software Development. Wiley, Chichester Hoboken, N.J, p. 25. ISBN 978-0-470-68420-7.
↑ Cohn, Mike (2010). Succeeding with Agile: Software Development using Scrum. Addison-Wesley, Upper Saddle River, NJ, 257–284. ISBN 978-0-321-57936-2.
↑ ^a ^b Schwaber, Ken (2009). Agile Project Management with Scrum. O'Reilly Media, Inc, New York. ISBN 978-0-7356-3790-0.
↑ Leffingwell, Dean (2011). Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Addison-Wesley, Upper Saddle River, NJ, pp. 15. ISBN 978-0-321-63584-6.
↑ Beck, Kent (2000). Extreme programming eXplained: embrace change. Addison-Wesley, Reading, MA, 29–35. ISBN 0-201-61641-6.
↑ Beck, Kent (2000). Extreme programming eXplained: embrace change. Addison-Wesley, Reading, MA, 85–96. ISBN 0-201-61641-6.
↑ Pash, Adam (2011). Lifehacker the guide to working smarter, faster, and better. Wiley, Indianapolis, Ind. ISBN 978-1-118-13345-3.
↑ Nöteberg, Staffan (2009). Pomodoro Technique Illustrated. Pragmatic Bookshelf, Raleigh, N.C. ISBN 978-1-934356-50-0.
↑ Hunt, Andrew (2008). Pragmatic thinking and learning: refactor your wetware. Pragmatic, Raleigh. ISBN 978-1-934356-05-0.

[1] Poppendieck, Mary (2010). Leading Lean Software Development: Results Are Not the Point. Addison-Wesley, Upper Saddle River, NJ, p. 139. ISBN 978-0-321-62070-5.

[2] What are the Triple Constraints in Project Management, article by Rod Hutchings on Project Management Australia (22 Oct 2008)

[Chat-3] Chatfield, Carl, "A short course in project management", Microsoft.

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

[Kanabar-5] Kanabar, Vijay (2008). MBA Fundamentals: Project Management. Kaplan Pub, New York, 51. ISBN 978-1-4277-9744-5.

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

[7] Snedaker, Susan, Nels Hoenig (2005). How to Cheat at IT Project Management. Syngress. ISBN 1-59749-037-7.

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

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

[10] Godin, Seth. Getting Real: The smarter, faster, easier way to build a successful web application. 37signals.

[Capers-11] For all project types time boxing ranked 23 and rated "Very Good Practice"; for small (1000 functiepunten) projecten ranked 7 and rated a "Best Practice" bij een onderzoek in Jones, Capers (2010). Software engineering best practices lessons from successful projects in the top companies. McGraw-Hill, New York. ISBN 978-0-07-162162-5.

[McConnell-12] McConnell, Steve (1996). Rapid Development: taming wild software schedules. Microsoft Press, Redmond, Wash, 575–583. ISBN 1-55615-900-5.

[13] Poppendieck, Mary (2010). Leading Lean Software Development: Results are not the Point. Addison-Wesley, Upper Saddle River, NJ, 137–140. ISBN 978-0-321-62070-5.

[14] Coplien, James (2010). Lean Architecture for Agile Software Development. Wiley, Chichester Hoboken, N.J, p. 25. ISBN 978-0-470-68420-7.

[15] Cohn, Mike (2010). Succeeding with Agile: Software Development using Scrum. Addison-Wesley, Upper Saddle River, NJ, 257–284. ISBN 978-0-321-57936-2.

[Schwaber-16] Schwaber, Ken (2009). Agile Project Management with Scrum. O'Reilly Media, Inc, New York. ISBN 978-0-7356-3790-0.

[17] Leffingwell, Dean (2011). Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Addison-Wesley, Upper Saddle River, NJ, pp. 15. ISBN 978-0-321-63584-6.

[18] Beck, Kent (2000). Extreme programming eXplained: embrace change. Addison-Wesley, Reading, MA, 29–35. ISBN 0-201-61641-6.

[19] Beck, Kent (2000). Extreme programming eXplained: embrace change. Addison-Wesley, Reading, MA, 85–96. ISBN 0-201-61641-6.

[20] Pash, Adam (2011). Lifehacker the guide to working smarter, faster, and better. Wiley, Indianapolis, Ind. ISBN 978-1-118-13345-3.

[21] Nöteberg, Staffan (2009). Pomodoro Technique Illustrated. Pragmatic Bookshelf, Raleigh, N.C. ISBN 978-1-934356-50-0.

[22] Hunt, Andrew (2008). Pragmatic thinking and learning: refactor your wetware. Pragmatic, Raleigh. ISBN 978-1-934356-05-0.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]