Wikipédia

Timeboxing

Az agilis elvekben a timebox egy tevékenységhez rendelt maximális időegység, amelyen belül a tervezett tevékenység végbemegy. Az agilis elveken alapuló projektmenedzsment megközelítéseknél és a személyes időgazdálkodás során használják.

A projektmenedzsmentben szerkesztés

A timeboxingot projekttervezési technikaként használják. Az ütemterv több különálló időszakra (időkeretre) van felosztva, mindegyik résznek megvan a maga leszállítása, határidője és költségvetése. Néha ütemtervnek független változónak nevezik (SAIV).[1] "A timeboxing többlépcsős projektekben vagy olyan feladatokban működik a legjobban, amelyek kevés időt vesznek igénybe, és ugyanabba az időrésbe illeszthetők. Olyan feladatok esetében is érdemes végrehajtani, amelyek teljesítési határideje előre látható."[2]

Alternatívaként a rögzítő hatótávolság helyett szerkesztés

A projektmenedzsmentben általában három korlátot tartanak számon: idő (néha ütemezés), költség (néha költségvetés) és hatókör.[3][4][5][6][7] (A minőséget gyakran adják hozzá negyedik megszorításként --- egy háromszög közepeként ábrázolják.[8][9][10]) Az a feltételezés, hogy az egyik megszorítás változása hatással lesz a többire is.[6]

Timebox nélkül a projektek általában fix hatókörben működnek,[11] ilyenkor, ha világossá válik, hogy bizonyos teljesítéseket nem lehet a tervezett határidőn belül teljesíteni, vagy meg kell hosszabbítani a határidőt (hogy több idő legyen a rögzített hatókör teljesítésére) vagy több személy érintett (a rögzített hatókör egyidejű teljesítéséhez). Gyakran mindkettő megtörténik, ami késleltetett szállítást, megnövekedett költségeket és gyakran romló minőséget eredményez (a mitikus emberhónap elv szerint).

A timeboxing egy olyan módszer, amely rögzített határidőn alapul. Ez azt jelenti, hogy a szervezeteknek csökkenteniük kell munkájuk körét a határidő betartása érdekében. A legjelentősebb szállítmányok priorizálása érdekében a timeboxingot gyakran párosítják egy kézbesítési prioritási rendszerrel, például a MoSCoW módszerrel.

A kockázat kezelésére szerkesztés

A timeboxokat a kockázatkezelés egy formájaként használják, hogy egyértelműen azonosítsák a bizonytalan feladat/idő összefüggéseket, azaz olyan munkákat, amelyek könnyen túlléphetnek a határidőn. Az időkorlátok gyakran a tervezés elsődleges mozgatórugói, és nem szabad ezeket megváltoztatni a projekt vagy alprojekt kritikus útvonalainak figyelembevétele nélkül. Vagyis általában fontos a határidők betartása. A határidők elmulasztásának kockázati tényezői lehetnek a projekt előtti bonyodalmak, a projekten belüli tervezési hibák, a csapattal kapcsolatos problémák vagy a terv hibás végrehajtása. Az upstream problémák magukban foglalhatják a projekt küldetésének változásait vagy a menedzsment támogatását. Gyakori tervezési hiba a feladat nem megfelelő lebontása, ami a munka elvégzéséhez szükséges idő alábecsüléséhez vezethet. A csapattal kapcsolatos problémák magukban foglalhatják a csapatok közötti kommunikációval kapcsolatos problémákat; tapasztalat hiánya vagy szükséges keresztfunkcionalitás; az elkötelezettség/hajtás/motiváció hiánya (azaz gyenge csapatépítés és vezetés).

A határidő betartása érdekében a következő intézkedéseket szokták értékelni a hármas megkötésekkel szemben:

  • Csökkentett hatókör: kisebb hatású ejtési követelmények (azok, amelyeket a felhasználó közvetlenül nem hagy ki)
  • Az idő itt a rögzített korlát
  • Növelje a költségeket: pl. adjon hozzá túlórákat vagy erőforrásokat

Átvétel a szoftverfejlesztésben szerkesztés

Sok sikeres szoftverfejlesztési projekt alkalmaz timeboxingot, különösen a kisebbek. A timeboxing alkalmazása több mint háromszorosára növelte a fejlesztők munkatermelékenységét a DuPontnál a '80-as években.[12] Egyes esetekben az alkalmazásokat teljes egészében a specifikáció teljesítéséhez szükséges becsült időn belül teljesítették.[12] Steve McConnell azonban azzal érvel, hogy nem minden termék alkalmas,[12] és hogy a timeboxingot csak akkor szabad használni, ha az ügyfél beleegyezik a funkciók, nem pedig a minőség csökkentésébe.[12] Kevés bizonyíték van arra, hogy a projektek legnagyobb csoportjai erőteljesen alkalmazkodnak.[13] Adopting timeboxing more than tripled developer productivity at DuPont in the '80s.[12]

A timeboxingot néhány figyelemre méltó szoftverfejlesztési módszer alkalmazta:

Az agilis szoftverfejlesztés a tervvezérelt fejlesztésről az értékvezérelt fejlesztésre való áttérést támogatja. A minőség és az idő rögzített, de a rugalmasság megengedett. A legfontosabb jellemzők bemutatása előbb a befektetés korábbi megtérülését eredményezi, mint a vízesés modell.[7]

A részletes specifikáció hiánya jellemzően az időhiány, vagy a kívánt végeredmény (megoldás) ismeretének hiánya. Sokféle projektben, és különösen a szoftverfejlesztésben lehetetlen az összes követelmény és specifikáció elemzése és meghatározása a megvalósítási fázis megkezdése előtt. A timeboxing kedvező szerződéskötési típus lehet olyan projekteknél, amelyeknél a határidő a legkritikusabb szempont, és amikor nincs minden követelmény előre pontosan meghatározott. Ez azt is lehetővé teszi, hogy a projekt során feltárt új visszajelzések vagy meglátások tükröződjenek a végeredményben.[14]

A személyes időgazdálkodásban szerkesztés

A timeboxot személyes feladatoknál is lehet alkalmazni, ebben az esetben lerövidített időkeretet (nagyjából harminc percet) és szerényebb célokat (például házi feladat elvégzése, nem pedig egy teljes projekt befejezése) jelentene. Ezt a technikát általában időblokkolásnak nevezik.

A személyes timeboxról azt mondják, hogy életmentőként is működik, és segít megfékezni a perfekcionista hajlamokat (azáltal, hogy határozott időt tűz ki és nem vállalja túl magát egy feladat mellett), ami szintén fokozhatja a kreativitást és a fókuszt (a sürgősség érzését vagy a fokozott nyomást keltve).[21]

Kapcsolat más módszerekkel szerkesztés

A timebox más személyes időgazdálkodási módszerek építőköveként működik:

  • A Pomodoro-technika a koncentrált koncentráció 25 perces időkeretén alapul, amelyeket szünetek választanak el egymástól, amelyek lehetővé teszik az elme felépülését.[22]
  • Andy Hunt a timeboxot adja "T"-ként a SMART-ban.[23]

Jegyzetek szerkesztés

  1. ↑ Boehm, Barry W.. Balancing Agility and Discipline: A Guide for the Perplexed (angol nyelven). Addison-Wesley Professional (2004. április 26.). ISBN 9780321186126 
  2. ↑ Timeboxing – why you should use it? (angol nyelven). Firmbee, 2022. január 17. (Hozzáférés: 2022. január 25.)
  3. ↑ What are the Triple Constraints in Project Management Archiválva 2006. augusztus 20-i dátummal az Archive.is-en, article by Rod Hutchings on Project Management Australia Archiválva 2009. február 16-i dátummal a Wayback Machine-ben. (22 Oct 2008)
  4. ↑ Chatfield. „A short course in project management”, Microsoft 
  5. ↑ Dobson, Michael. The triple constraints in project management. Vienna, Va: Management Concepts (2004). ISBN 1-56726-152-3 
  6. ↑ a b Kanabar, Vijay. MBA Fundamentals: Project Management. New York: Kaplan Pub, 51. o. (2008). ISBN 978-1-4277-9744-5 
  7. ↑ a b Leffingwell, Dean. Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley, 17–19. o. (2011). ISBN 978-0-321-63584-6 
  8. ↑ Snedaker, Susan. How to Cheat at IT Project Management. Syngress (2005). ISBN 1-59749-037-7 
  9. ↑ Beck, Kent. Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley, 15–19. o. (2000). ISBN 0-201-61641-6 
  10. ↑ 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, 53. o. (2005). ISBN 978-0-595-67081-9 
  11. ↑ Godin, Seth. Getting Real: The smarter, faster, easier way to build a successful web application. 37signals 
  12. ↑ a b c d e f McConnell, Steve. Rapid Development: taming wild software schedules. Redmond, Wash: Microsoft Press, 575–583. o. (1996). ISBN 1-55615-900-5 
  13. ↑ Jones, Capers. Software engineering best practices lessons from successful projects in the top companies. New York: McGraw-Hill (2010). ISBN 978-0-07-162162-5 
  14. ↑ a b Jennifer., Stapleton. DSDM, dynamic systems development method: the method in practice. Harlow, England: Addison-Wesley (1997. április 26.). ISBN 0201178893. OCLC 36755892 
  15. ↑ Poppendieck, Mary. Leading Lean Software Development: Results are not the Point. Upper Saddle River, NJ: Addison-Wesley, 137–140. o. (2010). ISBN 978-0-321-62070-5 
  16. ↑ Coplien, James. Lean Architecture for Agile Software Development. Chichester Hoboken, N.J: Wiley, 25. o. (2010). ISBN 978-0-470-68420-7 
  17. ↑ Cohn, Mike. Succeeding with Agile: Software Development using Scrum. Upper Saddle River, NJ: Addison-Wesley, 257–284. o. (2010). ISBN 978-0-321-57936-2 
  18. ↑ a b Schwaber, Ken. Agile Project Management with Scrum. New York: O'Reilly Media, Inc (2009). ISBN 978-0-7356-3790-0 
  19. ↑ Leffingwell, Dean. Agile Software Requirements: Lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley, 15. o. (2011). ISBN 978-0-321-63584-6 
  20. ↑ Beck, Kent. Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley, 85–96. o. (2000). ISBN 0-201-61641-6 
  21. ↑ Pash, Adam. Lifehacker the guide to working smarter, faster, and better. Indianapolis, Ind: Wiley (2011). ISBN 978-1-118-13345-3 
  22. ↑ Nöteberg, Staffan. Pomodoro Technique Illustrated. Raleigh, N.C: Pragmatic Bookshelf (2009). ISBN 978-1-934356-50-0 
  23. ↑ Hunt, Andrew. Pragmatic thinking and learning: refactor your wetware. Raleigh: Pragmatic (2008). ISBN 978-1-934356-05-0 

Fordítás szerkesztés

Ez a szócikk részben vagy egészben a Timeboxing című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

A lap eredeti címe: „https://hu.wikipedia.org/w/index.php?title=Timeboxing&oldid=26928790”