Helyzetjelentés – múlt, jelen, jövő

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.

Pár hete már nem írtam, mert volt egy kisebb gondom a felsofokon.hu Drupal rendszerével. Szerencsére megoldódott így tovább tudom folytatni az elmélkedést agilitásról. A mai téma: hol van az agilitás és a produktivitás határa?

A fejlesztések tervezése és ütemezése sosem egyszerű feladat, ennél csak ennek betartása még ennél is komolyabb feladat, amelyet nem sokan tudnak betartani és betartani. Jól működő multik esetében is vannak fennakadások, nem beszélve olyan helyekről, ahol a Scrum rendszer bevezetése és megszilárdulása még nem tökéletes. 

Nálunk több projekt is folyamatban van, de nem az elvárt ütemben készül. Ezzel egy probléma spirált létrehozva – ez kb. annyit jelent, hogy egy helyben toporzékolunk és egyre több be nem tartott ígéret sorakozik a polcon.

Már több hónapja futó hibajavítási sprintek után és a többször kitolt határidők miatt a fejlesztők, a termékgazdák szavahihetősége megkérdőjeleződött. A partnerek és ügyfelek elégedetlensége és a vezetőség felől érkező nyomás sem a produktivitást segítik elő.

Hibát senki sem szeret javítani, de meddig leget sprintekre osztani a hibákat, meddig lehet a rosszul megírt mégis átvett alkalmazást foltozni, hogy valamennyire prezentálható és eladható legyen?Mikor fogy el valamelyik oldalon a türelem?

A Scrum, mint módszertan nem megoldást ad, csak egy keretet. Védi a fejlesztőt és transzparensé teszi a munkát, ha megfelelően alkalmazzák és kellően rugalmasan értelmezik a szabályokat.

Pl. ha lefejlesztünk valamit és elfelejtjük dokumentálni, akkor nem másra kenjük a hibát, hogy a tesztelők nem tudnak dolgozni vagy éppen nincs kedvünk törölni az adatbázisból – ami kb. hozzáértőknek 5, max. 10 perc.

Meddig kell tűrnie egy termékgazdának a fejlesztők becsléseinek pontatlanságát, amely sikertelen sprintet okoz? Meddig kell egy vezetőnek a hátát tartania? Meddig kell egy tulajdonosnak bekötött szemmel elhaladni egy projekt mellett?

Mennyiben lett volna sikeresebb a projekt, ha nem Scrum vagy más agilis módszertant használtunk volna? A múlton nem érdemes töprengeni, mert nem visz előre. Ki kell elemezni a hibákat és felhasználni a következő alkalommal. DE ha nem lesz következő alkalom, akkor mit csinálunk? Mikor lehet azt mondani, hogy a Scrum vagy az agilis módszertanok elbuktak?

Ha idő előtt feladjuk, akkor bizonyára nem tudjuk, hogy a Scrum és a legtöbb módszertan nem rövidtávon térül meg, hanem évek alatt. De ki lehet várni az éveket úgy, hogy a cég nem adja ki a terméket?

A cikk kicsit zanzás lett, de nem baj, mert azt volt a célom, hogy meginduljanak a gondolataim és elég kérdést fel tudjak tenni ahhoz, hogy egy vagy több bejegyzésen keresztül ezt a témát elemezzem.

MEGOSZTÁS

Ha tetszett a cikk, akkor nyugodtan oszd meg ismerőseiddel, valószínű ők is örülni fognak neki.

HOZZÁSZÓLÁS

Ha nem hagy nyugodni az, amit a cikkben olvastál, akkor nyugodtan írd meg kérdésed vagy észrevételed kommentbe. Így szerzőnk könnyen tud neked válaszolni.

Vélemény, hozzászólás?