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:
- Dinamikus rendszerfejlesztési módszer (DSDM)[14]
- A karcsú szoftverfejlesztésben a Kanban segítségével történő lehívási ütemezés rövid távú időgazdálkodást biztosít. Nagy és összetett rendszer fejlesztésekor, amikor hosszú távú tervezésre van szükség, a timeboxot rétegezzük.[15]
- A Rapid Application Development (RAD) szoftverfejlesztési folyamat iteratív fejlesztést és szoftverprototípus-készítést tartalmaz. Steve McConnell szerint a timebox a RAD "legjobb gyakorlata", és a tipikus időkeret hossza 60-120 nap lehet.[12]
- A scrumot a timeboxing és az iteratív fejlesztés ötletei befolyásolták.[16] A rendszeres időkeretes egységek, az úgynevezett sprintek képezik a fejlesztés alapegységét.[17] A sprint tipikus hossza kevesebb, mint 30 nap.[18][19] A sprinttervezés, a sprint retrospektív és a sprint áttekintő találkozói időkeretben vannak rögzítve.[18]
- Az Extreme programozási módszertanokban a fejlesztési tervezést iterációkba foglalják, jellemzően 1, 2 vagy 3 hétig. A vállalkozás minden iteráció előtt átértékeli a függőben lévő felhasználói történeteket.[20]
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]- ↑ Boehm, Barry W.. Balancing Agility and Discipline: A Guide for the Perplexed (angol nyelven). Addison-Wesley Professional (2004. november 3.). ISBN 9780321186126
- ↑ Timeboxing – why you should use it? (angol nyelven). Firmbee, 2022. január 17. (Hozzáférés: 2022. január 25.)
- ↑ 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)
- ↑ Chatfield. „A short course in project management”, Microsoft
- ↑ Dobson, Michael. The triple constraints in project management. Vienna, Va: Management Concepts (2004). ISBN 1-56726-152-3
- ↑ a b Kanabar, Vijay. MBA Fundamentals: Project Management. New York: Kaplan Pub, 51. o. (2008). ISBN 978-1-4277-9744-5
- ↑ 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
- ↑ Snedaker, Susan. How to Cheat at IT Project Management. Syngress (2005). ISBN 1-59749-037-7
- ↑ Beck, Kent. Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley, 15–19. o. (2000). 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. New York: iUniverse, 53. o. (2005). ISBN 978-0-595-67081-9
- ↑ Godin, Seth. Getting Real: The smarter, faster, easier way to build a successful web application. 37signals
- ↑ 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
- ↑ 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
- ↑ a b Jennifer., Stapleton. DSDM, dynamic systems development method: the method in practice. Harlow, England: Addison-Wesley (1997. november 3.). ISBN 0201178893. OCLC 36755892
- ↑ 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
- ↑ Coplien, James. Lean Architecture for Agile Software Development. Chichester Hoboken, N.J: Wiley, 25. o. (2010). ISBN 978-0-470-68420-7
- ↑ 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
- ↑ a b Schwaber, Ken. Agile Project Management with Scrum. New York: O'Reilly Media, Inc (2009). ISBN 978-0-7356-3790-0
- ↑ 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
- ↑ Beck, Kent. Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley, 85–96. o. (2000). ISBN 0-201-61641-6
- ↑ Pash, Adam. Lifehacker the guide to working smarter, faster, and better. Indianapolis, Ind: Wiley (2011). ISBN 978-1-118-13345-3
- ↑ Nöteberg, Staffan. Pomodoro Technique Illustrated. Raleigh, N.C: Pragmatic Bookshelf (2009). ISBN 978-1-934356-50-0
- ↑ 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.