Throwback: üdv az agilitás világában

2016. ápr. 18.

Fejlesztői csapatunk jó pár éve alkalmazza a Scrum legfőbb elemeit: angol nyelvű stand up meetingek, user story-k, pontozási rendszer, burn down chart, sprintek, nyitó és záró meetingek. Legújabb agilis fejlesztési projektjeink legfőbb tapasztalatait próbáljuk most egy posztba sűríteni, a kezdeti nehézségeknek is köszönhetően azóta rengeteget tudtunk fejlődni.

Kezdeti sprintek: minden rendben halad

Az első agilis fejlesztéseink kezdetekor két hetes sprintek mellett döntöttünk. Rögtön a legelső sprintben számos funkcionalitást megvalósító grandiózus tervben állapodtunk meg a belső product owner-rel. Kialakítottuk a user story-jainkat, súlyoztuk őket, majd szétbontottuk feladatokra és felelősöket rendeltünk hozzájuk.

Az első sprintjeink mintaszerűen teljesültek, mindenki ráérzett a módszer előnyére, sok funkció készen is lett.

 

Utolsó sprintek: a hullámok összecsapnak

Az utolsó sprintekben azonban összecsaptak a fejünk felett a hullámok. Elmaradt a kiértékelés és az új sprintek tervezése is, leginkább a következőkre hivatkozva:

  • „Minden készen van, ami tervben van.”
  • „Az új sprint meg van tervezve, hiszen a maradék user story-kat kellett csak beledobálni a sprintbe.”
  • „Van egy halom egyéb módosítás, amiknek hamar készen kell lenniük.”
  • „Nincs idő a felesleges adminisztrációra.”

 

A fejlesztői csapatunk jelzéseit, hogy a módosításokért cserébe ki kellene venni funkciókat, elhárították – mondván, hogy ezeket mindenképpen kérte a megrendelő. A fejlesztő csapattagok sem voltak elégedettek a funkciókkal, egyre több eset került elő, amikor „szerintünk” nem helyesen reagált a rendszer. A tesztelésért és designért felelős csapattagok is hallatták hangjukat, hiszen a kinézet is elmaradt a tervekhez képest. A feszültség többször a tetőpontot súrolta, az odafigyelésnek és a megfeszített munkatempónak köszönhetően a projekt mégis sikeresen végződött, a Scrum elindítására vonatkozó álmunk megvalósult. A problémák azonosítása és kezelése után a leadás előtti káosz és hétvégézés szétbomlott jól kezelhető és azonosítható darabokra.

 

Tipikus problémák, és ahogy legyőztük őket

Az agilis fejlesztési projektjeink során azonosított problémák közül az alábbiak talán a legtipikusabbak, a rá adott megoldásunk pedig azóta számos projektben bizonyított.

 

A kialakított folyamattól való eltérés

Előfordul, hogy feladatok rossz helyre kerülnek a projektkövető rendszerben, vagy a régi módszer szerint közvetlenül kapjuk meg őket, amint beérkeznek a megrendelőtől. Ez sok félreértéshez vezethet, a scrum masternek külön kell figyelnie arra, hogy ne maradjanak ki feladatok, és minden kerüljön be a projektkövető rendszerbe. Esetlegesen a folyamat újra átbeszélése is szükséges lehet.

 

Félreértések és eltérések

Mindannyian emberek vagyunk, előfordul, hogy másképpen értetünk meg feladatokat, vagy az előre kigondolt megoldás valami miatt alkalmazhatatlanná válik. A clarification meetingek segítenek megoldani az ilyen helyzeteket.

 

A design funkciók későbbre halasztása

A gyakorlatban sajnos gyakran van olyan érzésünk, hogy amíg nincs minden kialakítandó funkció rendben, addig hagyjanak békén „ez a betűtípus mégsem megfelelő” jellegű problémákkal.  Többször beigazolódott, hogy ez igencsak helytelen hozzáállás; egy funkció akkor van kész, amikor minden megismert elvárásnak már megfelel. A mi megoldásunk, hogy egy user story-t egészben belső demózunk, hogy ne a végén essen be minden felületi probléma.

 

Fejlesztői büszkeség

„Én ezt még tuti bele tudom tenni, belefér a jelenlegi sprintbe”. Gyakran ismétlődő tapasztalat, hogy tényleg vannak olyan észrevételek, amiket csak akkor jeleznek a megrendelők, amikor látják a programot működés közben. Kritikus módosítás kivételével ezen észrevételek kezelése általában ráér a következő sprintek valamelyikéig. Az utolsó sprinteket azonban úgy kell ráhagyással tervezni, hogy bizonyos mennyiségű finomhangolást, utómunkát kezelnünk kell.

 

Mi akarjuk kitalálni, hogyan kellene működnie a programnak

Előfordulhat, hogy régi beidegződéseket kell leküzdeni, például a „vérre menő” vitákat a fejlesztők között arról, hogy pontosan hogyan is kellene működnie a programnak, illetve ilyen-olyan ötletek jók lennének még bele. A végeredmény szempontjából mindenképpen előnyös a megrendelői igények minél pontosabb ismerete, és azok szem előtt tartása. A sprint végi verzió bemutatáskor szükséges felvetni és egyeztetni az ötleteket a megrendelővel, különben elég sok idő elmehet olyasmire, amit nem is úgy akar majd a felhasználó.