Mindig van idő

Aki egyetemre, főiskolára járt, annak biztosan ismerős az a helyzet, amikor az ember ismeri a vizsga időpontját, és szépen kiszámolja, hogy naponta hány tételt kell megtanulni ahhoz, hogy a vizsgáig az összes sorra kerüljön. 

Igazából a tanulás elmarad, szépen telnek a napok, az ember pedig azzal nyugtatgatja magát: "nem baj, nem maradtam le még semmiről, a tervezett napi 2 helyett majd 3 tételt tanulok meg". Aztán pár nap múlva már 4-5-nél járunk, a vizsga előtt 2 nappal pedig tényleg rászánjuk magunkat, és elolvassuk együltő helyünkben az összes tételt. Jó esetben a vizsga sikerülni is szokott.

Valami hasonló a helyzet a projekt határidőkkel. Az elején még kényelmesen dolgozgatnak az emberek, aztán a határidő előtt megkezdődik a hajtás, felpörögnek az események. A végeredmény (jó esetben) pedig átadás lesz. 

Miben lenne más, ha pár nappal korábban lenne a határidő? Semmiben. Ugyanúgy elkészülne a feladat.

Ezt az elvet egy Parkinson nevű angol közgazdász is felismerte, és azóta Parkinson törvényének hívják (1955). Nevezetesen: "A munka addig terjeszkedik, hogy kitöltse a teljesítéséhez rendelkezésre álló időt."

Ha le akarunk fejleszteni egy adott funkcióhalmazt, és meghatározunk egy határidőt, akkor Parkinson törvénye - saját meglátásom szerint - azért működik, mert ahogy a határidő egyre közeledik, annál inkább kapnak szerepet a valódi prioritások. A valódi prioritások határozzák meg a tényleges értékeket, amelyektől sikeresek lehetünk. Még ha egy prioritásos feladaton dolgozunk is, annak az implementálását is sokféleképpen lehet elvégezni. A prioritásokat az implementáció közben is figyelembe lehet (kell) venni.

Rövid határidők

Nem véletlen, hogy krízishelyzet esetén, amikor a projektmenedzsmentet komolyabban is veszik, rövid határidőket szabnak. A rövid határidők segítenek abban, hogy egy-egy feladaton fókuszáltan dolgozhassunk. Nem "folyik szét" a munka a kezeink között.

A Scrum fix hosszúságú (1-4 hetes) sprintjei is azt garantálják, hogy rövid idő alatt a prioritásos feladatokon érjen el eredményeket a csapat.

Automatizált tesztek, refaktorálás

Mi szokott lenni az első számú ellenérv, kétely a unit-tesztekkel, integrációs tesztekkel, ill. a refaktorálással szemben? Az, hogy nincs idő rá. Ha valaki ilyet állít, az csak olyan lehet, akinek fogalma sincs arról, hogy mit jelentenek ezek a fogalmak a valóságban.

Itt van az ellenérvem velük szemben: ha a Parkinson törvénye működik, és kevesebb idő is elég ahhoz, hogy egy munkát megcsináljunk, akkor miért nem építjük be a szoftverfejlesztési folyamatunkba az automatizált tesztek írását? Ha gány a kód, miért nem szánunk arra időt, hogy rendbe rakjuk, hogy refaktoráljunk? Úgyis kész leszünk határidőre, és így legalább olyan lesz a kódunk, hogy:

• mások is megértik, 
• bármikor lehet benne változtatni, mert nem bonyolult,
• bármikor lehet benne változtatni, mert a tesztek mutatják, ha elrontottunk valamit.
  

...és ezzel összességében még több időt nyerünk.

Sok mindent lehet az időre és a határidőre fogni. A valóság viszont az, hogy pontosan arra van időnk, amire időt szánunk.

Mindig van idő.