Wikipedia

Tidsboks

metode i tidsstyring som tildeler et fast tidsvindu for en planlagt aktivitet

Innen smidig programvareutvikling er en tidsboks[1][2][3] (engelsk: timebox) et fastsatt tidsvindu for gjennomføring av en planlagt aktivitet der man arbeider for å oppnå et mål, og i så måte er dette en metode for tidsstyring. Tiden som er tildelt er fast og maksimal. Eksempel arbeider man innenfor scrum i tidsbokser (iterasjoner) med faste lengder som kalles sprinter.

Tidsboker brukes også i prosjektledelsesmetoder basert på smidige prinsipper og for personlig tidsstyring. Tidsbokser er ofte assosiert med smidig utvikling, men man kan også drive smidig utvikling uten å benytte tidsbokser.

Ofte er det et mål å unngå at tidsfristen forskyves, da metoden baserer seg på at man istedet styrer en tidsboks ved å prioritere arbeidet innenfor tidsboksen. Mindre tidsbokser kan bestå av noen dager eller uker (for eksempel en sprint), mens større tidsbokser kan fungere som en samling av mindre tidsbokser (for eksempel faser).[4]

I prosjektledelse rediger

Tidsbokser blir brukt som som en teknikk for prosjektering (prosjektplanlegging). Tidsplanen deles da inn i en rekke separate tidsperioder (tidsbokser) hvor hver del har egen frist, budsjett og leveranser.

Som et alternativ til fastsettelse av omfang rediger

Innen prosjektledelse snakker man ofte om prosjekttrekanten med de tre begrensningene tid (noen ganger tidsplan), kostnader (noen ganger budsjett) og omfang.[5][6][7][8][9] Kvalitet blir ofte lagt til som en fjerde begrensning (representert i midten av trekanten).[10][11][12] Forutsetningen er at endring i en av disse begrensningene vil påvirke de andre.[8]

Uten tidsbokser vil prosjekter ofte arbeide ut ifra et fastsatt omfang,[13] hvilket betyr at noen av leveransene ikke kan fullføres innen planlagt tidsskala, og da må enten tidsfristen utsettes (for å gi mer tid til å fullføre det fastsatte omfanget) ellers så må flere ressurser involveres (for å fullføre det fastsatte omfanget innen den angitte tiden). Ofte skjer begge deler, hvilket resulterer i forsinket leveranse, økte kostnader og ofte redusert kvalitet (i henhold til The Mythical Man-Month-prinsippet).

Med tidsbokser er tidsfristen helt og holdent fastsatt, hvilket betyr at omfanget må reduseres. Dette betyr at organisasjonen må fokusere på å fullføre de viktigste leveransene først, og tidsbokser går ofte hånd i hånd med med et system for prioritering av leveranser (som for eksempel MåSKVa-metoden).[14]

For risikohåndtering rediger

Tidsbokser brukes som en form for risikostyring ved å eksplisitt identifisere oppgaver hvor tidsforbruket er usikkert, altså oppgaver hvor tidsfristen enkelt kan overskrides. Tidsbegrensninger er ofte den primære driveren i planlegging, og bør ikke endres uten å vurdere kritiske stier[bør utdypes] i prosjekt eller delprosjekter. Med andre ord er det vanligvis viktig at tidsfrister blir tilfredsstilte. Risikofaktorer ved at tidsfrister ikke tilfredsstilles kan være komplikasjoner oppstrøms for prosjektet, planleggingsfeil innenfor prosjektet, teamrelaterte problemer, eller feil gjennomføring av planen. Oppstrømsproblemer kan inkludere endringer i prosjektets misjon eller endring i støtte fra ledelsen. En vanlig planleggingsfeil er mangelfull nedbrytning av oppgaver, hvilket kan føre til undervurdering av hvor mye tid som kreves for å utføre arbeidet. Teamrelaterte problemer kan inkludere utfordringer med kommunikasjon mellom ulike team, manglende erfaring eller manglende tverrfaglighet, manglende engasjement/drivkraft/motivasjon (altså dårlig lagbygging og ledelse).

For å holde tidsfrister evalueres ofte følgende handlinger opp mot begrensingene i prosjekttrekanten:

  • Reduser omfanget: Dropp kravene med liten innvirkning (de som ikke vil bli direkte savnet av brukeren).
  • Tiden er den faste begrensningen her.
  • Øk kostnadene: Eksempelvis legg inn overtid eller øk antall ressurser.

Bruk av tidsbokser innen programvareutvikling rediger

Mange vellykkede prosjekter innen programvareutvikling benytter tidsbokser, og da særlig mindre prosjekter. I 1980-årene mer enn tredoblet bruk av tidsbokser produktiviteten blant utviklerne hos DuPont,[15] og i noen tilfeller ble applikasjoner levert fullstendig innenfor tiden det ellers ble anslått å fullføre en den funksjonelle spesifikasjonen.[15] Imidlertid hevder programmøren Steve McConnell (som blant annet står bak boken Code Complete) at ikke alle produkter er egnet for bruk av tidsbokser,[15] og at tidsbokser bare bør brukes etter at kunden har godtatt å kutte på funksjoner og ikke kvalitet.[15] Det finnes lite bevis for sterk adopsjon av tidsbokser blant store prosjekter.

Tidsbokser har blitt tatt i bruk av noen nevneverdige metoder for programvareutvikling:

  • Dynamic systems development method (DSDM)[14]
  • I strømlinjeformet programvareutvikling gir pull-planlegging med Kanban et verktøy for kortsiktig tidsstyring. Ved utvikling av store og komplekse systemer hvor langsiktig planlegging er nødvendig blir tidsbokser delt i et lag over.[16][klargjør]
  • Rask applikasjonsutvikling (RAD) programvareutviklingsprosess med iterativ utvikling og prototyping av programvare. Ifølge Steve McConnell er tidsbokser en mønsterpraksis for RAD, og en typisk tidsbokselengde bør være 60-120 dager.[15]
  • Scrum har vært påvirket av ideer om tidsbokser og iterativ utvikling.[17] Innen scrum er de vanlige tidsboks-enhetene kjent som sprinter, og er den grunnleggende utviklingsenheten.[18] En typisk lengde for en sprint er mindre enn 30 dager.[19][20] Sprintplanlegging, sprint-retrospektiv og møter for sprint-gjennomgang foregår også ved hjelp av tidsbokser.[19]
  • Innen ekstrem programmering er den planlagte utviklingen delt inn i tidsbokser med iterasjoner av typisk 1, 2 eller 3 ukers lengde. Virksomheten re-prioriterer da kravene i påvente av brukerhistorier før hver iterasjon.[21]

Smidig programvareutvikling taler for å gå fra plandrevet til verdidrevet utvikling. Kvalitet og tid er da fastsatt, mens fleksibilitet i omfanget tillates. Å levere de viktigste funksjonene først fører til en tidligere avkastning på investeringen enn ved fossefallsmetoden.[9]

Mangel på detaljerte spesifikasjoner er ofte resultatet av begrenset tid eller kunnskap om det ønskede sluttresultatet (løsningen). I mange typer prosjekter (og særlig innen programvareutvikling) er det umulig å analysere og definere alle krav og spesifikasjoner før starten av realiseringsfasen. Tidsbokser kan være en gunstig type kontrahering for prosjekter hvor fristen er det mest kritiske aspektet og når ikke alle krav er helt spesifiserte forut. Dette gjør det også mulig at tilbakemeldinger og innsikt oppdaget underveis i prosjektet blir reflektert i sluttresultatet..[14]

Personlig tidsstyring rediger

Tidsbokser kan også brukes til personlige oppgaver, og da oftest i redusert tidsskala (for eksempel 30 minutter) og omfant (for eksempel husarbeid i stedet for store prosjekter), og refereres da ofte til som tidsblokker.

Personlige tidsblokker sies også å fungere som en hverdagstips for å bidra til å dempe perfeksjonistiske tendenser ved at man fastsetter et tidsvindu og dermed ikke overforplikter seg til en gitt oppgave, hvilket kan forbedre kreativitet og fokus ved at man skaper en følelse av hastverkt eller økt press.[22]

Tidsbokser kan kombineres inn i andre metoder for personlig tidsstyring, som for eksempel pomodoro-teknikken som er basert på 25 minutters tidsbokser med fokusert konsentrasjon atskilt med pauser.[23]

Se også rediger

Referanser rediger

  1. ^ «Tidsboks». Prince-2.no. Arkivert fra originalen 15. november 2021. Besøkt 15. november 2021. 
  2. ^ «Scrum - et enkelt rammeverk for komplekst arbeid». www.prosjektbloggen.no (norsk). Besøkt 15. november 2021. 
  3. ^ «Det smidige hjørne » Endringer i Scrum» (engelsk). Besøkt 15. november 2021. 
  4. ^ «Tidsboks». PRINCE2 wiki. Besøkt 15. november 2021. 
  5. ^ What are the Triple Constraints in Project Management Arkivert 2006-08-20 hos Archive.today, article by Rod Hutchings on Project Management Australia Arkivert 2009-02-16 hos Wayback Machine (22 Oct 2008)
  6. ^ Chatfield, Carl. «A short course in project management». Microsoft. 
  7. ^ Dobson, Michael. The triple constraints in project management. Vienna, Va: Management Concepts. ISBN 1-56726-152-3. 
  8. ^ a b Kanabar, Vijay. MBA Fundamentals: Project Management. New York: Kaplan Pub. s. 51. ISBN 978-1-4277-9744-5. 
  9. ^ a b Leffingwell, Dean. Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. ISBN 978-0-321-63584-6. 
  10. ^ Snedaker, Susan; Nels Hoenig. How to Cheat at IT Project Management. Syngress. ISBN 1-59749-037-7. 
  11. ^ Beck, Kent. Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley. ISBN 0-201-61641-6. 
  12. ^ Dangelo, Mark. Innovative relevance: realigning the organization for profit: it is not a battle for the "shore lines" - it's a struggle for purpose. New York: iUniverse. s. 53. ISBN 978-0-595-67081-9. 
  13. ^ Godin, Seth. Getting Real: The smarter, faster, easier way to build a successful web application. 37signals. 
  14. ^ a b c Jennifer., Stapleton (1997). DSDM, dynamic systems development method: the method in practice. Harlow, England: Addison-Wesley. ISBN 0201178893. OCLC 36755892. 
  15. ^ a b c d e McConnell, Steve. Rapid Development: taming wild software schedules. Redmond, Wash: Microsoft Press. ISBN 1-55615-900-5. 
  16. ^ Poppendieck, Mary. Leading Lean Software Development: Results are not the Point. Upper Saddle River, NJ: Addison-Wesley. ISBN 978-0-321-62070-5. 
  17. ^ Coplien, James. Lean Architecture for Agile Software Development. Chichester Hoboken, N.J: Wiley. s. 25. ISBN 978-0-470-68420-7. 
  18. ^ Cohn, Mike. Succeeding with Agile: Software Development using Scrum. Upper Saddle River, NJ: Addison-Wesley. ISBN 978-0-321-57936-2. 
  19. ^ a b Schwaber, Ken. Agile Project Management with Scrum. New York: O'Reilly Media, Inc. ISBN 978-0-7356-3790-0. 
  20. ^ Leffingwell, Dean. Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley. ISBN 978-0-321-63584-6. 
  21. ^ Beck, Kent. Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley. ISBN 0-201-61641-6. 
  22. ^ Pash, Adam. Lifehacker the guide to working smarter, faster, and better. Indianapolis, Ind: Wiley. Hack 29. ISBN 978-1-118-13345-3. 
  23. ^ Nöteberg, Staffan. Pomodoro Technique Illustrated. Raleigh, N.C: Pragmatic Bookshelf. ISBN 978-1-934356-50-0. 
Hentet fra «https://no.wikipedia.org/w/index.php?title=Tidsboks&oldid=23834977»