Sebesség a Szoftvefejlesztésben I.

Minden IT cég ügyvezetője a szoftvereit gyorsabban szeretné elkészíttetni. Az idő a legdrágább és legértékesebb erőforrás, így azt nem pazarolhatjuk el újraírásra, refaktorálásra, megbeszélésekre és különböző fizikai tevékenységekre. Igaz ez? Hát, ez attól függ...

Sok cég gyorsan növekszik, lelassul, majd meghal. A megfelelő fejlesztési sebesség esszenciális eleme a túlélésnek. Képzeld el, hogy van egy remek víziód, ami többször bizonyított és sokan hisznek benne. Természetesen tudod (persze ritka ez a valóságban, de tüzeljük egy kicsit a képzeletünket oké?), hogy ez a termék egy valódi sikersztori lehet. Már csak be kellene fejezni.

Van egy csapatod tucatnyi tehetséges és tapasztalt fejlesztővel, összeraktatok és leszállítottatok valamit az elmúlt 2 évben. A csapat kimerült. A jelenlegi termék a vízió kb. 10%-át valósítja meg. Mindenki azt mondja, hatalmas potenciál van benne, de a 10% pont nem elég ahhoz, hogy betörj a piacra. Küzdesz még pár hónapig, átlagos a látogatottság, átlag alattiak az értékesítések, elfogy a pénz, és egyszer csak vége, vége a cégednek. A nagy víziók lassú halált halnak. Kit hibáztathatunk? Lehet, hogy a probléma volt túl nehéz és a 2 év éppen csak elég lett volna a megvalósításra? Lehet, hogy a csapat túl gyorsan rohant előre, volt pár jó release-ük, de a végén eltemette őket a probléma komplexitása és a felhalmozódott technológiai adósságok? A sebesség a szoftverfejlesztésben egy meglehetősen extrémen összetett entitás. Egy csomó dolog hat rá, meglepően különös módokon. Ebben a cikkben a sebességgel kapcsolatos gondolataimat próbálom megosztani.

A sebesség két oldala

A legtöbb ember hajlamos azt hinni, hogy a Sebesség egy egyszerű dolog, de ez nem így van. Két nagyon eltérő típusa van a sebességnek: Rövidtávú sebesség (Sprint) és Hosszútávú sebesség (Maraton). A Sprint és Maraton egy tökéletes analógia ebben az esetben. A szoftverfejlesztésben (és természetesen a futásban is) nem csinálhatod egyszerre mind a kettőt. Vegyünk egy absztrakt becslési mértékegységet, mint például a pont. Teljes gázon dolgozva egy Sprintben 100 pontot is képes szállítani a csapat havonta. Itt is van az első véleményem:

Nem tudsz üzemeltetni ilyen sebességű Sprinteket egy hosszútávú termékfejlesztésnél.

Meglehet, hogy 3-6 hónapig is képes vagy 100 pont/hónap sebességen pörögni, de nagyon valószínűtlen, hogy ezt tudod egy évig csinálni. Sőt mi több, erős visszaesés (recoil) várható a nagy iramú (pace) fejlesztéseknél. És egy napon meg fogsz bánni mindent.

Egy ponton a legtöbb fejlesztő el fogja érni a "fuck it" pontot (piros pötty) és óriásit fog esni a teljesítményük.

A te célod a lehető legnagyobb sebességen teljesíteni folyamatosan hosszútávon (évekig). Erről szól a Maraton. Kitartásra és egyenletességre van szükséged.

Hogyan csináljunk szoftvert hosszútávon? Nah ez az "1 millió dolláros kérdés". A legvalószínűbb, hogy a válasz minden cégre egyedi, de építhetünk egy ésszerű elnagyolt modellt, ami segíthet a dolog megértésében.

Sprint, Maraton és... Ciklikusság!

Első ránézésre csak három lehetőségünk van...

Első lehetőség: Extrém Sprint

Pöröghetsz teljes sebességen, dolgozhatsz 12-14 órát naponta, töltheted magadba az energiaitalt, koffeint, cukrot és isten tudja még mi egyebet. Lehetsz éjjeli bagoly, alhatsz néhány órát naponta, és minimalizálhatod a kajálásra, higéniára és a mozgásra fordított időt. Egy hónapot adok neked. Esetleg hármat, ha nagyon jó formában vagy. A legjobb ebben az üzemmódban, hogy mindenki tudja mennyire rossz. A kiégés garantált és gyors.

Széljegyzet
Ismertem egy embert, aki egy egész éven át ebben az üzemmódban dolgozott! Egy csomó dolgot tanult és hatalmasat fejlődött, de ez nem volt ingyen. Valószínű, hogy a jelenlegi egészségügyi problémáit az Extrém Sprint üzemmód okozta. Okos ötlet elcserélni az egészséget a tapasztalatra? Nem hiszem.

Második lehetőség: Mérsékelt Sprint

Dolgozhatsz 8-10 órát naponta, kipréselve magadból a maximális produktivitást. Nincs diskurálás, nincs munkahelyi sport és nincs semmi szórakozás. Néhány cég nem tesz semmit azért, hogy a munka izgalmas és kihívásokkal teli legyen vagy éppen szórakoztató. A projektek mindig késésben vannak és mindenki nyomás alatt dolgozik. Sajnos, ez az üzemmód évekig is eltarhat. Az emberek hozzá tudnak szokni és már észre sem veszik, hogy milyen szánalmasak. Megpróbálnak otthon kompenzálni a családdal és a hobbyval. Valódi veszély, hogy néhány hónapot követően a produktivitás esik és ezt észre sem veszi senki. Évekbe telhet mélyebben elgondolkodni magadról és megérteni, hogy mi történik.

Harmadik lehetőség: Maraton

Ez az üzemmód tűnik optimálisnak. A legjobb formádat hozod 6-8 órában naponta és marad idő pihenésre és mozgásra. Nem akarsz minden egyes percet kihasználni és azt a luxust is megengeded magadnak, hogy egy problémán kicsit elgondolkozzál. Nem kell a dolgokat AZONNAL áttolni! Ez jól hangzik. Habár, sok menedzser nem elégedett a Maraton üzemmód iramával. Gyorsabban akarják a dolgokat elkészíteni. Hiszem, hogy ez az egyszerű mód igen ritka a valóságban. A legtöbb cégnél a menedzserek megpróbálják a sebességet felturbózni a leghülyébb módokon, túlóráztatnak, tolják a feladatokat és próbálnak a "mi vagyunk a hősök" érzéssel motiválni.

Első ránézésre úgy tűnik, hogy nincs több lehetőségünk. De én azt hiszem, egy mégis csak akad. Bár őszintén szólva erről még soha nem hallottam.

Negyedik lehetőség: Ciklikus fejlesztés

Nem az Iteratív fejlesztésről beszélek. Tény, hogy az iteratív fejlesztést egyaránt alkalmazni lehet a Mérsékelt Sprintben és a Maraton üzemmódban is. A Ciklikus fejlesztés azonban az, amikor vegyíted az üzemmódokat. Egy rövid időre Sprintelhetsz, majd váltasz a Maraton üzemmódba. Véleményem szerint a helyes ütemezés:

1 hónap - Gyors Sprint
3 hónap - Maraton
1 hónap - Gyors Sprint
...

Hadd magyarázzam el mit értek Gyors Sebesség Üzemmódon. Ebben az üzemmódban a csapat (vagy akár egy teljes cég is) felhagy minden másodlagos tevékenységgel: az összes jövővel kapcsolatos megbeszélések, tanulás, HR tevékenységek, stb. A csapat az értékteremtésre fókuszál: kódírás, tesztelés, dokumentáció és szállítás.

A Gyors Sebesség Üzemmód egy relaxációs héttel ér véget. Ez a hét dedikáltan a refaktorálásra, a beszélgetésekre és a jövővel való foglalkozásra van szánva.

A haszon tiszta - az átlagsebesség magasabb lesz, mint a Maraton módban. A Gyors Sebesség Üzemmód a megfelelő Maraton periódusok után nem stresszes. Sőt mi több, az olyan alkalmak motiválóak lesznek, amikor a csapat felgyűri az ingujját, teszi a dolgát és gyorsan szállítanak. Amikor szállítasz valamit, az jó érzéseket vált ki benned. Ez egy remek teljesítmény, egy mérföldkő elérése. Kábító érzés tud lenni. Talán ezért van az is, hogy az emberek néha hajlandóak Extrém Sprint üzemmódban dolgozni.

Folytatás: Sebesség a Szoftverfejlesztésben II.

Az erdeti cikk itt található: 

https://www.targetprocess.com/articles/speed-in-software-development/