Szoftverfejlesztési módszertanok ügyfélre szabva

A LogiNetnél alapelvünk, hogy mindig az adott problémának megfelelő megoldást alkalmazzuk. Igaz ez a projektjeink keretét meghatározó fejlesztési módszertanok esetében is. A cikkben bemutatjuk, hogy milyen belső fejlődési folyamat mentén jutottunk el oda, hogy ügyfeleink számára a leginkább eredményre vezető, testreszabott megoldást nyújtsunk a projektmódszertanok terén.

Mint minden organikusan megnövekvő kis cég, kezdetben a LogiNet is úgy működött, hogy az első éveiben kialakult valamilyen projektlefutást vezérlő működési keretrendszer és a következő években a cég ezt alkalmazta a projektek szállításakor. Ez az akkori létszámhoz, működéshez és projekttípusokhoz megfelelő volt, de a növekedéssel párhuzamosan ennek egyre többször éreztük a hátrányait. Ezzel párhuzamosan új munkatársak jelentek meg a szervezetben, akik a saját tudásukat behozva némileg alakították, testre szabták a projektmódszertant, de érdemben azért nem változtatták meg azt.

Szoftverfejlesztési módszertanok: a változó igényekhez alkalmazkodni kell

Ebben az időben egyre többet tapasztaltuk meg azt, hogy a kezdeti, a korábbi évekből megörökölt projekt lefolyási metódus tartogat veszélyeket és egyre nehezebben kezelhető ez a folyamatosan növekvő LogiNet számára. Például elkezdtük belátni, hogy a projektek komplexitásának, hosszának növekedésével már nem tartható fenn az, hogy az első időszakban specifikálunk, majd elvonulunk 2-3 hónapra fejleszteni és visszatérünk a végeredménnyel. 

Ez meglehetősen nagy kockázatokat tartogatott: ekkora méretű scope-ot már nehéz olyan jól körbeírni, hogy abból a fejlesztés során valóban az a szoftver készüljön el, amelyet a megrendelő elképzelt. Ez egyre több félreértésben mutatkozott meg. Az ügyfélnek átadáskor derült ki, hogy bár a funkció megfelelő a specifikációnak, de a megrendelői oldal azt mégsem teljesen így képzelte. Ilyen helyzeteket nagyszámú „CR”-rel, változtatási kéréssel lehet megoldani, de az ügyfél számára nehezen elfogadható, hogy újabb változtatási körökbe fektessen. Hasonló - bár más területen jelentkező - nehézség volt az is, hogy a projektek átfutásainak növekedésével egyre hosszabbodott a fejlesztési szakasz is. Ez már kezdte elérni a több hónapos időtávokat.

Az agilis fejlesztési módszertan megjelenése

Már ekkor - 7-8 évvel ezelőtt - is nagy lázban égtek a szoftverfejlesztő cégek, hogyan álljanak át agilis működésre. Ez a témakör nálunk is gyakran előkerült és a fenti problémák egyre gyakoribb megjelenésével illeszkedni is láttuk az agilitást, mint megoldást a módszertani problémáinkra. Ekkor született meg az a döntés, hogy „most vagy soha”: láthatóan változtatnunk kell, új tudást, új módszertant kell behoznunk. Bár nem volt egyértelmű cél egy teljes agilis átállás, de az agilitással való ismerkedéshez külső tanácsadói segítséget is igénybe vettünk.

Az egész folyamat felpezsdítette a csapatot, mindenki nagy lelkesedéssel vetette magát bele egy készülő átalakulásba. Azonban ahogy egyre mélyebben mentünk bele, egyre inkább azt éreztük, hogy bizonyos pontokon a csapatok, a teljes szervezet már nem tud még több változást befogadni. Elértünk már nagyon pozitív irányba mutató részeredményeket. 

Ekkor alakult ki például az a módszertani alapvetés is, amelyet még ma is alkalmazunk, hogy a fix scope-okat is felbontjuk kisebb, egybefüggő, de emészthetőbb darabokra. Ezeket a darabokat iterációknak hívjuk, kb. 2-3 hetesek, és egymás után következnek. Lényegében sprinteket alkottunk, de nem annyira szigorú keretrendszerben, mint azt az agilitás megkívánja. 

Emellett még számtalan olyan elemet véltünk felfedezni, amelyek nagyban segítették a munkákat: a csapatok a napokat egy rövid megbeszéléssel kezdték, ahol a napon belüli feladatokat, várható problémákat hozták fel a felszínre. Az iterációk végén igyekeztünk kiértékelő beszélgetéseket lefolytatni, hogy a következő iteráció hogyan lehetne jobb. Lényegében elkezdtük daily standupot és a retrospektívet tartani.

Mindezek mellett azt tapasztaltuk, hogy a csapatok, az őket irányító projektmenedzserek némileg a saját stílusukra szabják a fejlesztési eljárást. Volt csapat, aki arról számolt be, hogy az adott iterációban túl nagy erőforrásnak érezték a napi szintű feladatbontást, a megoldandó problémák komplexitása miatt inkább 1,5-2 napos feladatokat alkottak. Így pedig elkezdtek azzal küzdeni, hogy a napi standup csak félig-meddig teljesítette be a tervezett célját, néha kicsit „semmitmondó” volt. 

Az ilyen és ehhez hasonló szituációknál pedig azt mondtuk, hogy ha ennek ellenére meg tudjuk tartani az alap módszertant, de ebben a helyzetben a csapat csak kétnaponta tart standupot, az még jó lehet. Ez a szabadság és rugalmasság pedig egy újabb lökést adott az átalakulásunknak.

A hibrid módszertan előnyei

Ez a folyamat pedig oda vezetett, hogy a csapatok, a projektmenedzser az adott feladatra, az adott környezetre tudta szabni a megoldást. Ha a fejlesztés elején az induló feladatok miatt szükség volt egy darab 4 hetes sprintre, akkor ezt hagytuk. Ha a csapat 2 naponta tartott standupot, hagytuk. Aki pedig már látott ilyen átalakulást, az meg is tudja jósolni, hogy mi következett: ha hagytuk, hogy 2 naponta legyen stadup, akkor mi baj lehet abból, ha ez 4-5 naponta van? Ha az induló sprint 4 hetes, akkor lehetne ez 6 hetes is, majd követhetné még egy darab 5 hetes. 

Persze ezek szélsőségek, de látható volt, hogy a keretrendszer kicsit szélesebbre nyitása teret adott az egyéni akcióknak is. Ekkor mondtuk ki azt, hogy itt kell megállnunk. Elsajátítottunk nagyon sok értékes metódust, tudást az agilitásból, de az akkori LogiNet ettől jobban egy lépésben nem tud tovább alakulni és nem is vehetjük ki a rendszerből a projektekhez, a környezetekhez illeszkedést biztosító rugalmasságot. Így alkottunk meg a korábban használt vízesés- és az újonnan tanult agilis módszertani elemekből a saját hibrid megoldásunkat.

A hibrid módszertan alapvetései a következők voltak:

• A scope-ot mindenképp szét kell vágni több iterációra
• Az iterációknak a felhasználó által könnyen érhető és ellenőrizhető eredményeket kell szállítani
• Az iterációk hossza 2-4 hét (az elején lehetnek hosszabbak, de a projekt végén a 2 hetes iterációkat kell célozni)
• A csapattagoknak beszélgetniük kell egymással, amelyet szervezett fórumok kényszerítenek ki: napi standup van, ami kivételes esetben tartható 2 naponta, vagy retrospektív van, ahol kevés kötöttség mellett a projektmenedzser irányítása mellett igyekszünk a tapasztalatainkból tanulni.
• Az iterációk hosszától függően 1-2 sprintenként demót tartunk az ügyfelünknek

Ezek elkezdték megoldani a legnagyobb problémáinkat: gyorsan, havi szinten kaptunk visszajelzést az ügyfeleinktől arról, hogy amit csinálunk, az jó-e. Ez persze új problémákat hozott be: például nem csak a projekt végén kellett átalakítanunk vagy javítanunk funkciókat, hanem már akár a fejlesztési szakasz első fele után is. Ez egy új élmény volt a csapatnak, de például a tesztelési folyamatainkat is egy jobb irányba kezdte elmozdítani.

Az ügyfélnek tartott demók jó visszajelzési pontok voltak és nagyon szépen illeszkedtek ahhoz az elképzelésünkhöz, hogy egy-egy hosszú fejlesztési folyamatnak ne csak a végén, hanem akár már közben is megkaphassunk az elvégzett munkánk ellenértékét.

Szoftverfejlesztési módszertanok: a jelen kihívásai

A saját hibrid módszertanunk alapjainak lerakása óta is már eltelt jó pár év. Nagyon sok tapasztalatot szereztünk ezzel, de továbbra is azt érezzük, hogy nekünk ez a megoldás az, ami igazán jól működik. Itt-ott persze finomítunk folyamatosan. Sőt bizonyos ügyfeleknél ez kap még egy extra agilis hátszelet és sokkal inkább hasonlít már agilitásra, mint hibrid módszertanra. Néha persze az is előfordul, hogy kisebb feladatoknál, belső pilot projekteknél még mindig visszanyúlunk a régi, klasszikus vízesés módszertanhoz. Ha megfelelő körültekintéssel választjuk, akkor ez még mindig tud működni.

Tehát összességében azt mondhatjuk, hogy a belső megvalósítású projektek a LogiNetben mindig a saját hibrid módszertanunkból indulnak ki, de a projekt és a körülmények jobb megismerése után nem zárkózunk el továbbra sem attól, hogy egy-egy feladat a klasszikus módon menjen végig, vagy jelentősen agilis fejlesztési módszertan irányba tolódjon el. Igyekszünk mindig alkalmazkodni a projekthez, a scope-hoz, az ügyélhez és úgy általában véve azokhoz a körülményekhez, amely az adott szoftverfejlesztési feladatot az adott pillanatban körülveszi.