Vélemény: vádirat a Szigorú Scrum ellen

Talán mindenki ismeri “A császár új ruhája” című Andersen-mesét, amiben a takácsok a királyi udvar tisztviselőinek önhittségére alapozva mindenkit átvernek egy nemlétező ruha elkészítésével, amit csak az lát, aki nem buta és méltó a tisztségére. A trükkös takácsok csodálatos “módszertanát” mindenki megeszi, mert azt úgy prezentálják, mint a legújabb, legmodernebb “technológiát”. Természetesen beválik a trükk, mindenki saját magában keresi a hibát, ahelyett, hogy saját korlátain túllépve megvizsgálná a módszer valódi működését és annak eredményét. A leleplezés végül a nyilvánosság előtt történik meg, amikor a pózokat mellőző őszinte gyermek elsőként kiáltja el magát, hogy “Meztelen a király!”. Ekkor viszont már megtörtént a baj, a császár egy szál pöndölyben áll népe előtt.

A takácsokéhoz hasonló csodálatos, haladó és mindent megoldó módszertanok manapság is léteznek és - bár ezek célja nem a kitalálók közvetlen haszonszerzése - nagy népszerűségnek örvendenek főként a startupok körében, akik valamilyen oknál fogva alapvető üzleti céljaik mellett  (vagy épp helyett) feladatuknak érzik, hogy minden téren megfeleljenek az amúgy hamis startup lifestyle/image/divat diktálta elvárásoknak. Teszik mindezt anélkül, hogy a "csodaszerek" valódi működését értenék, vagy legalább a szándék meglenne erre.

Az egyik ilyen egy ideje már használatban lévő, de az utóbbi években mindenki számára kötelező elem a szigorú agilis módszertan, köztük is leginkább a scrum. Szeretnék most pár gondolat erejéig én lenni az egyszerű gyerek, aki elkiabálja magát, hogy “Meztelen a scrum!”

Trollok ellen

Bár a konstruktív kritikát, vitát, ellenvéleményt szívesen fogadom, sőt el is várom, szeretném leszögezni, hogy nem szeretnék semminek a megmondója lenni, tudójának látszani, egyszerűen megpróbálok adni egy új szemüveget ahhoz, amit mindannyian nézünk egy ideje, mindezt saját véleményem és tapasztalatom alapján. Tudatosan emelek ki egyoldalúan részleteket, sőt torzítok is, azzal a céllal, hogy átüssem a kész dolgokba kényelmesen belesüppedők ingerküszöbét.

Ez a cikk azoknak szól, akik bármilyen fejlesztői csapatot vezetnek, irányítanak, építenek, dolgoznak benne. Fejlesztőknek és az üzlettel foglalkozóknak egyaránt, mindenkinek, aki mások által kialakított eszközt, vagy módszert beépített már a produkciós ciklusába, de főleg azoknak akik scrumot használnak.

Az ellenség története

A méltán kritizált és mára már csak az erősen hierarchikus és nem éppen optimálisan működő nagy cégeknél használt vízesés modell megítélése nem volt mindig ennyire sötét. Sőt, létrejötte szükségszerűen adódott az iparosodó gazdaságban, ahol komplex projekteken  (mint egy híd építése )  több különböző szakértő dolgozott együtt valamilyen jól definiálható feladaton. Az elérendő cél, a kiszolgálandó közönség igényei alapján specifikált feladat egymásra épülő lépésekben (követelmények gyűjtése, specifikálás, tervezés, implementálás, tesztelés, átadás, üzemeltetés), különböző szakértők által hozzáadott értékkel haladt a jól definiált végeredmény felé.

Ez a módszer annyira sikeresnek bizonyult, hogy bizonyos klasszikus mérnöki területeken még mindig a sárga köves utat jelenti. Képzeljük csak el a fent említett hidat (vagy épületet, vagy gyógyszert, vagy mozdonyt) ami nem a fenti módszertan alapján készül. Gondolatban próbáljunk meg egy hidat úgy felépíteni (implementálni), hogy bármelyik, a modell szerinti korábbi lépést kihagyjuk. Bár ezekben az iparágakban is vannak törekvések ennek a modellnek a lebontására pl. moduláris építészeti szerkezetekkel, ezek mind kísérleti jellegűek és az ipari termelésben egyelőre nem használhatóak.

^{Modern módszertannal épített ház és a kívánt cél sematikus ábrája}

A modell vitathatatlan előnye, hogy pontosan tudjuk mikor vagyunk kész. Pontosan tudjuk, hogy hova kell eljutnunk, amikor azt mondhatjuk, hogy köszönjük szépen, lehet használni a “terméket”. Nincs kérdés, nincs vita. Az élet viszont nem mindig ilyen szép. A vízesés modell hátránya ugyanis pontosan ugyanez. Azt, hogy mi a kész termék, azt az akár nagyon hosszú ideig tartó projekt elején határozzuk meg, bármilyen változási igény indokolatlanul költséges változtatásokhoz, vagy a projekt újrakezdéséhez vezet.

Régen lassabban őrölt az idő malma, lassabban változtak az igények, vagy egyszerűen kevésbé volt elfogadott a végfelhasználók igényeit figyelembe venni. Egy jól kitalált híd esetében nem is nagyon tudok elképzelni olyan külső hatást, ami miatt már az építés megkezdése után változtatni kellene az egyik hídfő helyét, vagy a híd magasságát. Jöttek azonban új iparágak, felgyorsult a világ, nagyobb lett a verseny, erősebb érvényre jut a felhasználói akarat. Változás van, ennek kezelésére értelmes kereteken belül képtelen a vízesés modell.

A startup más

A startup fogalmának definiálásába nem szeretnék belemenni, ez egy parttalan vita lenne. Van aki szerint a következő feltételek egyikének, vagy több elemének teljesítése esetén beszélhetünk startupról; technológia fókusz, innovatív, skálázható üzleti modell, globális piacra szánt termék/szolgáltatás, 20 év alattiak gyülekezete, induló cég, trendi technológiákat használata, valamely piaci szegmens forradalmasítása, babzsákfotel az irodában - a sor tetszőlegesen folytatható. Szerintem eljutottunk odáig, hogy az startup, aki azt mondja magáról és ezt nem is szeretném megkérdőjelezni. Amiben viszont mindenképpen hasonlít egy startup bármilyen más cégre,  hogy minél kisebb csapattal, minél kisebb költségből, minél rövidebb idő alatt, minél kevesebb pénzből, minél nagyobb növekedést, felhasználót és profitot szeretnének elérni.

Ami biztosan megváltozott a vízesés modell korának cégeihez képest, hogy a szoftvertermék alapú projektek esetében lehetőség van a változó felhasználói igények folyamatos követésére a teljes projekt alatt és ezt a jóhoz szokott felhasználók és a versenytársak ki is kényszerítik a fejlesztő cégekből. Vége a jó világnak. Eljött a soha véget nem érő projektek, a soha be nem fejezett fejlesztések, az örök nyomás alatt dolgozó fejlesztők és az egy hónapnál tovább nem látható termékfejlesztési irányok kora. Ez a helyzet nem új keletű, gyakorlatilag a szoftverfejlesztéssel egy időben megjelent az igény a vízesés típusú termék és szoftverfejlesztési modell nehézkességét kiküszöbölő módszertanokra és megoldási javaslatok is születtek. A nem túl alapos olvasó azt gondolhatná, hogy a mostanában felkapott módszertanok az utóbbi pár év termékei, az igazság azonban az, hogy jó részük már évtizedek óta jelen vannak (esetleg más néven, kicsit másképp, de azonos alapelvekkel), de az elmúlt években a startup típusú vállalkozások elterjedésével váltak beszéd témává és kerültek be a mi gondolkodásunkba. A módszerek folyamatosan csiszolódnak, néha majdnem ugyanolyan elvek felhasználásával, új névvel és még inkább az újszerűség ígéretével végigsöpörnek a világon és beépülnek az erre fogékony vállalkozások mindennapjaiba, egészen addig, amíg nem jön a következő őrület.

Agilitás, agilis módszertan, scrum

Az agilitás klasszikus definíciója a változások kezelésének a képessége, a reakcióképesség, a rugalmasság. A fogalom szoftvercégek szótárában a fejlesztési módszertanok szócikknél szerepel és az agilis fejlesztési módszertanokat jelenti. Ez azonban téves gondolkodás. A konkrét projektszervezési módszertanok jelzője az agilis, ám korántsem merül ki ebben a jelentése. Az agilis módszertanok valóban arra lettek kialakítva, hogy egy csapat tágabb értelemben vett agilis viselkedését, tehát a változások kezelésének képességét támogassák, a két fogalom mégsem egyenlő egymással. Mindenféle módszertan nélkül is lehet agilisen kezelni a termékfejlesztést, a tervezési/fejlesztési lépéseket. Még nagyobb tévedés az agilitást valamely konkrét módszertani szabály és működési rendszerrel azonosítani.

Hogy konkrét és kézzelfogható dolgokról beszéljek, az állatorvosi lovam a scrum metodológia lesz, így a cikkben erre fókuszálunk. Jelenleg talán ez az agilis fejlesztési módszertanok közül a leggyakrabban használt. Alapja, ahogy minden agilis módszertannak, a feladatok szétdarabolása, az igények folyamatos gyűjtése, visszacsatolása és ez alapján a következő rövid távú feladatok meghatározása. Ebből adódó különbség a vízesés modellhez képest, hogy a tervezési feladatokat időben eltolja, így mindig csak azt tervezzük és valósítjuk meg, ami az értékteremtés következő lépéséhez szükséges, így építve fel a piaci igényekhez egyre jobban idomuló terméket az igények és hosszú távú célok folyamatos változása mellett.

^{A scrum módszertan szereplői és a folyamat termékei}

Aki többet szeretne megtudni a scrum projektmenedzsment részleteiről, az keressen rá, rengeteg jó anyagot fog találni hozzá. Itt csak a lényegi elemeit említeném meg, hogy a későbbi érvelésem érthető legyen - aki jártas a témában ugorjon a következő alfejezetre.

A scrum fejlesztési ciklusai a sprintek, amik rövid, a csapat által választott hosszúságú, általában 1 és 4 hét közötti futamok, amikor egy előre meghatározott tennivaló végére kerül pont úgy, hogy a sprint végén kerek egészként használható funkcionalitást kapjunk a kezünkbe. A scrum csapat szereplői a fejlesztőkön kívül a Product Owner (PO) és a Scrum Master (SM). A PO feladata a sprintek feladatainak összeállítása a fejlesztők által adott becslések (Story Point) és az üzlet által diktált prioritások alapján. A feladatok, amiket atomi feladatok helyett use-case alapú csoportokba (Story) rendeznek minden esetben a backlogból kerülnek az aktuális sprint teendői közé. A backlog kezelés is a PO feladata, ide kerülnek az ötletekből, visszajelzésekből, üzleti igényekből generálódott feladatok szigorú rendben.

Egy jó PO super powerje, hogy képes a backlogban folyamatosan rendet tartani és strukturálni a feladatokat. Ennek elvégzésére is vannak szabályok. A scrumban a PO képviseli a megrendelőt, ő a szó szoros értelmében is a termék menedzser, aki a termékfejlesztésért, a termék megfelelő irányban tartásáért, vagy irányba állításáért felel. Ha a klasszikus felálláshoz hasonlítjuk a SM a projektvezető, felel a a fejlesztés strukturált, mérhető és hatékony működéséért. Feladatai között van a meetingek szervezése és lebonyolítása, a módszertan betartatása, egyeztetés a PO-val, a felmerülő akadályok elhárítása a fejlesztési feltételek biztosítása.

^{Scrum meetingek}

A módszer termékei a backlog, a storyk, és az estimate-ek, vagyis az egyes storykra a fejlesztő csapat által adott becslések. A scrum erősen szabályozza meetingek rendjét. Minden sprint egy planning meetinggel kezdődik, amikor a következő sprint feladatait meghatározzák. A PO és SM vezetésével itt kerülnek megbeszélésre a storyk, a becslések és itt emelik át a backlogból a feladatokat. A sprint alatt minden nap egy daily scrum meetinggel kezdődik, amin mindenki részt vesz. A fejlesztők elmondják, hogy mivel foglalkoztak előző nap, mivel fognak foglalkozni és van e valamilyen elakadásuk. A daily scrum nem tarthat 10–15 percnél tovább és szigorúan csak beszámolás és problémafelvetés lehet a cél. Fontos megjegyezni, hogy probléma megoldás nem történik itt.

CI/CD-vel folytatódik az AWS hazai online meetup-sorozata! A sorozat december 12-i, ötödik állomásán bemutatjuk az AWS CodeCatalyst platformot, és a nyílt forráskódú Daggert is.

A sprint végén közös nagyobb megbeszélés a sprint review, ahol az SM értékeli az elvégzett feladatokat, a fejlesztőket, bemutatja a burndown chartot és a PO-val közösen eldöntik, hogy a megvalósított csomag release-be kerül-e. Minden, vagy minden valahanyadik sprint után a sprint retrospective megbeszélésen részletesebb értékelés hangzik el, itt van lehetősége a fejlesztésnek visszacsatolni, itt születik döntés arról, hogy az elkezdett feladatokat folytatják-e, ha igen milyen irányban. A retrospektív meetinget sok esetben el is hagyják. A scrum módszertan szabályrendszere nagyon letisztult és egyértelmű, a teljes fejlesztési folyamat minden lépését felölelő és szabályozó metodológia.

A módszertan nagyon erősen hangoztatott ígérete, hogy a fejlesztési idő csökken, az erőforrásigény csökken, a dokumentáltság és a tesztelési lefedettség nő amellett, hogy a termék minősége javul. Most már tehát mindenki hátradőlhet, megvan a megoldás a világ egyik nagy problémájára, nem kell többet ezzel foglalkozni, megy minden magától. Vagy mégsem?

Mi hát a baj?

Nem működik.

A szigorúan és adaptáció nélkül használt módszertanokkal sok probléma van. A legfőbb ezek közül, hogy nem működik. Az ígért erőforrás igény és feljesztési idő csökkenés szinte soha nem valósul meg, sőt, sok esetben még rosszabb lesz a helyzet, mint bármilyen kvázi-anarchia esetén. Bizonyos, nyilvánvalóan csak papíron létező ideális helyzetekben valóban levezethetőek a módszer fenti előnyei, ezt több könyv meg is teszi, azonban az összes többi, nem ideális esetben pont a szigorú menetrend gátolja megfelelő rugalmasságot.

A lejjebb részletesen kifejtett problémák mellett a hatékonytalanság egyik oka, hogy a módszer egyoldalúan üzletvezérelt. Erre mondhatnánk, hogy a vízesés is az, vagy hogy ez valójában nem baj, hiszen az üzletet az üzletnek kell meghatároznia. Alapvetően igazunk is lenne, azonban a vízesés modellbe az egymásra épülő lépések miatt van olyan folyamati rész, a tervezés, amit kizárólag a fejlesztés végez és az üzleti igények mint bemenet, illetve mint peremfeltételek (pénz, idő) vannak jelen. Ebben a lépésben lehetőség van a tények mérlegelésére, a mérnöki tudás kihasználására, az üzleti igény átalakítására a technikai kényszerek hatására, a folyamat nem megy tovább, amíg meg nem születik a mindenki számára elfogadható terv.

Képzeljük csak el a Tesla autók tervezését anélkül, hogy a mérnöki tudás és a technikai kényszerek ne szólnának bele az üzletbe. Annak a ténye, hogy lehetéges-e megfelelő kapacitású akkumulátor létrehozása egy IFA-nál kisebb méretben elég fontos kényszer és ezt az üzlet egyöntetű döntése, vagy az erős akarat sem változtatja meg. A teljes fejlesztői csapat részvételével történő sprintenkénti és napi meetingek összeadott ideje nem biztos, hogy elmarad egy bármilyen más módszer szerinti megbeszélési időigénye mellett, ráadásul a daily scrumokon nincs problémamegoldás, így elakadás, vagy bármilyen felmerülő kérdés esetén külön időt kell számolni ezek megoldására. A módszer megköveteli, hogy a fejlesztőcsapat mellett két dedikált embert fent kell tartani, akkor is, ha maga a fejlesztőcsapat is csak 3 fős. Sokan spórolnak azon, hogy összevonnak szerepköröket, ennek következményeiről később.

Nem fenntartható

A sprint alapú módszertanok létrehozását az ideiglenes válságkezelő csapatok igénye generálta. Nagyobb cégekben valamilyen, az üzletet veszélyeztető esemény elhárítására a cégben dolgozó senior szakértőkből válságkezelő csapatot állítanak fel, aminek jól definiált célja az adott válság minél hatékonyabb elhárítása. Ezek a csapatok rövid iterációkban, sprintekben dolgoznak, miközben az egyetlen üzleti cél a probléma megszüntetése, vagy gyors reagálás valamilyen váratlan helyzetben. Egyértelmű, hogy ilyenkor másodlagos szempont a tervezés, a dokumentálás és az, hogy a quick-fix milyen architekturális csapdákat hagy maga után. Ahogy a tűzoltó sem foglalkozik azzal, hogy vizes lesz e a kanapé, a cél a tűz eloltása.

A problémát generál viszont, ha a teljes fejlesztési folyamat így van felépítve, mindig a rövid távú hasznot legoptimálisabban megvalósítani és nem foglalkozni a hátrahagyott aknákkal. Láttam már olyan projektet, ahol annyira kimaradtak a nagy képet és hosszú távú célt  (ha egyáltalán van ilyen) figyelembe vevő rendszertevezési szempontok, hogy egy idő után már egy újabb gomb a UI-on is egy teljes sprintet vett igénybe és a fejlesztési erőforrások nagyobb része a rendszer összetartására ment el.

Közhely, hogy egy motivált fejlesztő jobban dolgozik, mint egy nem motivált, de igaz. A scrum több hibája is abból fakad, hogy nem veszi figyelembe, hogy emberek dolgoznak benne. A sprint, mint fogalom nem véletlenül kapta ezt a nevet. Ez egy rövid, célirányos, hatékony versenyfutás, ahol minden résztvevő a lehető legtöbbet kiad magából, mielőtt átszakítja a célszalagot. De mi van, ha a cél után következik a következő sprint? És mégegy és mégegy. Vagy nincs célszalag. Én jobban hiszek a kitartó kocogásban, ami hosszú távon is fenntartható és bár elsőre lassabnak tűnhet, a sprinter soha nem fog elérni a maraton végére, mert előbb megáll pihenni.

Az egyetlen a kapcsolódó irodalomban is megjelenő helyzet, ahol határozott és egyértelmű előnyt jelent a sprint-szerű működés a nagyobb, viszonylag egyszerű rendszereket fejlesztő sok ügyfeles ügynökségek (például WordPress weboldalakat készítő cég), ahol a véget nem érő projektre folyamatosan, de változó mennyiségben érkezik a feladat, ezek specifikálása és a igények validálása viszont nem a cég felelőssége. Ebben a felállásban az adott időn belül elvégezhető feladatok mennyisége közvetlenül befolyásolja a profitot, viszont a negatív hatások nagy része nem érvényesül. Kérdés, hogy melyik fejlesztő szeretne sokáig ilyen projekteken dolgozni.

Üzletvezérelt

Az üzletvezéreltség nem csak a feladatok ütemezésében, hanem a követelménykezelésben is zsákutcába tud vinni egy projektet. A fejlesztők legtöbbje azzal szeret foglalkozni, amihez ért: szoftvert fejleszteni. Ez különösen igaz egy olyan módszertanban, ami eleve erre (+ az estimate-ek elkészítésére) korlátozza a fejlesztők felől érkező bemenetet. Azt a lehetőséget ne is vizsgáljuk, ha a fejlesztőcsapat nem bízik abban, hogy a kulcsemberek (PO, SM) tudják, hogy mit akarnak és az általuk definiált feladatok megfelelnek az üzleti igényeknek. Ha viszont bíznak a definiált feladatokban, akkor semmi okuk nincs megkérdőjelezni, vagy véleményezni azt, ráadásul a módszertan értékelő méréseinek az elvégzett feladat az alapja, tehát motiváció sincs rá. A PM és SM inkább üzleti, mint technikai képzettsége garancia arra, hogy előbb-utóbb elkészüljön egy “Same in english” típusú feladatmegoldás.

Problémakerülő

A módszer lényege, hogy fájdalmasan rövidtávú a célok meghatározása. A feladatok hasznosságának becslés és hozzáadott érték szerinti priorizálása minden kockázatos, nagyobb lélegzetvételű, vagy üzletileg nem értelmezhető újítás fejlesztését kizárja. Okosok szerint csak olyan feladatot érdemes megoldani, aminek a kockázata nagyobb, mint nulla. A probléma az, hogy mindig lesz olyan feladat, aminek meg nincs kockázata. A könnyebb, de céltalan út követése hosszú távon nem feltétlenül jó választás. Ha megnézzük a fenyőfa nagy törzséből egyenletesen növő vékony ágakat, bizonyosak lehetünk benne, hogy a felsőbb erő valamilyen agilis módszertant tesztelt. De mi van, ha nekünk tölgyfa kell? Akkor is fenyőfa lesz!

A módszer nem díjazza a refaktorálást, a rendszeres kód karbantartó tevékenységet, hiszen ezek rövid távon semmilyen üzleti céllal nem indokolható befektetések. Hosszú távon azonban szükségszerűek az ilyen feladatok elvégzése, a technical debt leépítése (vagy legalább az elburjánzás meggátolása). Az előrelátóbbak fenntartanak dedikált code maintenance sprinteket, hogy elkerüljék a tervezési hiányából fakadó későbbi problémákat, de sajnos ez nem általánosan elterjedt szokás.

Kommunista

A scrum módszertan fontos eleme az agresszív és folyamatos mikromenedzsment. Ez egyfajta minőségbiztosítási megoldás, tervezni, folyamatosan rajta tartani a szemünket a haladáson, mérni, mérés alapján értékelni, tervet teljesíteni. Az információ iránya fentről lefelé vezet. Sokszor a gyakorlatban a fejlesztő egy teljesen csereszabatos, egységnyi, viszonylag alacsony tudású elemként szerepel. Pont, mint egy gyári munkás a szalag mellett, aki elé folyamatosan hordja a feladatot a futószalag.

A fejlesztői csapatban mindenki egyenlő. Egyenlően alacsonyan van. A fejlesztő feladata, hogy megbecsülje a feladatot, aztán tartsa magát a becsléshez, vagy próbálja meg még kevesebb idő alatt megcsinálni. Nincs tér arra, hogy eltérjünk az elénk kitűzött feladattól, hogy ha beleakadunk egy javítási lehetőségbe persze megcsinálhatjuk, de ezt aztán magyaráznunk kell, hiszen nem fogjuk teljesíteni a becslésünket. A felelősség egyszerre egyéni és csoportos, mindenki felel a saját elvégzett munkájáért és a sprint sikeréért, jobban mondva a felelősség a fejlesztőé, a siker a csapaté.

A csapat papíron önszerveződő és folyamatosan alakuló az aktuális feladatok szerint, valójában viszont tudjuk, hogy ez csak egy jól összeszokott, senior tagokból álló csapatban működik zökkenőmentesen. A folyamatosan aktuális kompetenciáknak megfelelő csapatszerveződés helyett az történik, hogy lassan kialakul egy belső hierarchia, ami hosszú távon is fennmarad, hiszen legitimitását természetszerűleg a belső erőviszonyok adják. Ez lassú folyamat és sokszor még az sem látja a pontos hierarchiát, aki a csapatban van, csak azt tudja, ki van alatta és felette. Ez persze bizonyos esetekben alakulhat jól is, de nagyon ritkán alapul a valós szakmai tapasztalaton és sok esetben frusztrációt okoz. Üzleti szemmel persze nagyon előnyös, ha egy csapat a tagjai cserélhetőek, átcsoportosíthatóak és működésükből fakadóan megjósolható viselkedésűek.

Demotiváló

Ahogy a mondás tartja: "az egyén kreativitása csökken, ha magyaráznia kell mit és miért csinál." A scrumban alkalmazott mikromenedzsment és a napi beszámolás pont ezt a kreativitást és motivációt romboló hatást éri el. Akiket ez különösen érint, azok a senoir emberek. Tulajdonképpen a senior szintű embereknek nincs is igazán helye egy scrum csapatban. Nincs valódi lehetőség a mérnöki szemlélet és tudás kamatoztatására, hiszen komplex, nagy léptékű tervezésre nincs szükség. A feladatok önálló felvétele, az ad-hoc “improvementek” és a refaktorálás pedig nem támogatott a módszertan által.

Egy igazán jó csapat gerincét pedig pont a senior csapattagok adják és junior utánpótlás kinevelése is az ő feladatuk. Ha nem tudunk nekik motiváló és értelmes feladatot adni, amiben kiteljesedhetnek, fejlődhetnek, nagyon gyorsan a csapaton kívül találjuk őket. Egy scrum master azt mondta (és úgy sejtem komolyan is gondolta) hogy a junior és a senior között az a különbség, hogy a senior pontosabb becslést tud adni. Valójában a scrum bőven elüzemel ezzel a különbséggel, pontosan ezért ne várjuk, hogy vonzó lesz az igazi szakmai kihívásokra vágyó senioroknak.

Karrier zsákutca

A juniorok öröme is korai még. Egyrészt ebben a környezetben nemigen várhatnak komoly szakmai fejlődést, hacsak a jobb becslés képességét nem annak élik meg. A scrum egy jó SM és CTO mellett elműködik akár belépő szintű csapattagokkal is. Olyanokkal, akik a pár hónapos tanfolyamok egyikén lettek “fejlesztők”. Valójában velük működik el a legjobban. A jelenlegi fejlesztői munkaerőhiány mellet ez egy nagyon pozitív dolog, a hiány pótolható a piacon megjelent tudással és néhány veterán elviszi a hátán a csapatot. Ezeknek a lelkes karrierváltóknak azonban az aktuális szintjüknek megfelelő feladatok mellett rengeteg mentoringra és seniorok okító törődésére van szükségük a fejlődésükhöz. Ezt pont nem kapják meg. Ehelyett azonban az a tudat, hogy ők fejlesztőként dolgoznak és valódi feladatokat tudnak megoldani elhiteti velük, hogy ők valóban kész fejlesztők.

Aki dolgozott fejlesztőként, vagy fejlesztőkkel, az tudja, hogy az átlagban 4–5 év munka és a harmadik munkahelye után jut el arra a tudásszintre, hogy komolyan lehet venni, amit csinál. Ebben benne van az, hogy nála sokkal tapasztaltabbakkal dolgozik az erejét meghaladó projekteken, hogy nehezebb feladatot kap, mint amit meg tud csinálni és be is bukja őket, hogy véletlenül kitörli az éles adatbázist, hogy előbb-utóbb, leginkább saját kárán megtanul mérnökként gondolkodni és szakmailag megalapozott döntéseket hozni. Ez sokkal több, mint ismerni egy programozási nyelvet és ebben megoldani a valódi kihívást nem jelentő feladatokat.

Mi marad hát a fiatal, tapasztalatlan, ámde annál nagyobb önbizalommal bíró fiatal jediknek az önmegvalósításra? Igen, az éppen csak 2 éve létező 0.7-es verziószámú, korábbi és későbbi verzióival sem kompatibilis egzotikus programozási nyelv, amit kizárólag nagyon trendi és sikeres fiatal startupok használnak, így hát egyértelmű, hogy ezek nélkül senkiből nem lesz nagyon trendi és fiatal startupper. Egyértelműen nem lehet sikeres egy startup, amennyiben a MongoDB, NodeJs, React, Angular, Go, D és társai listából nem használ legalább kettőt (természetesen a legújabb verziót), de mindenképpen kudarcra van ítélve, ha a PHP, Python, Jquery, RoR, MySQL (vagy bármely más nyelv, ami 3-nál több éve létezik és esetleg van a világon olyan ember, akinek hasonló időszakot felölelő tapasztalata van vele) közül akár csak egy is felhasználásra kerül. A rosszabb eset az, ha a CTO nincs résen és hagyja, hogy ezek kipróbált és már bizonyított technológiák bekússzanak a productionbe.

Félreértett, “félrehasznált”

Mivel a módszertan könnyen félreérthető és félrehasználható, ezt rendszerint meg is teszik. A legrosszabb, hogy ilyenkor tényleg elhiszik a csapatok, hogy jól csinálnak valamit. Sok menedzser, projektvezető önmagát sértené vérig, ha nem hinné el magáról, hogy 1–2 scrum könyv elolvasása után ő már készen áll akár egy PO, SM feladatkör ellátására. Valójában nagy bugrisság lenne ezt gondolni. Ezeknek a feladatköröknek betöltéséhez komoly ismeretek és tapasztalat szükséges.

A módszertan erősen épít arra, hogy a kulcsemberek a saját területükön jártasak, mind üzleti, mind technikai oldalon képben vannak, képesek embereket irányítani, adminisztrálni és a fejlesztők nem mindig egyszerű észjárását követni. Emellett persze el kell viselniük a borzasztóan rossz, ám annál gyakrabban alkalmazott fejlesztői humort is, aminek legtöbbször ők lesznek a célpontjai. A terminológia félreértése mellett (lásd később) leggyakoribb hiba az úgynevezett Scrum Norrisok alkalmazása. Ő az az ember, aki a költségtakarossági szempontból megspórolt SM, vagy PO, rosszabb esetben mindkettő szerepkörét betöltő projektvezető, még rosszabb esetben fejlesztő.

Mivel az SM, PO és fejlesztők feladatai érdekellentétben vannak egymással (backlog kezelés, becslés, story összeállítás, értékelés, sprint összeállítás, üzleti és technológia szempontok mérlegelése), a két szerepkör összevonása rögtön az alapfelállást kérdőjelezi meg, de legalábbis kiiktatja a kontrollpontokat. Talán még Caius Mucius Scaevola sem rendelkezett akkora akaraterővel, amivel hasonló helyzetben ellen tudott volna állni egy-egy feladat backlogból való eltüntetésének. Az ilyen csapatok a scrum által garantált kevés előnyt sem élvezik, miközben hisznek abban, hogy amit csinálnak az jó. A pár fős startupokban kialakított scrum csapatok Scrum Norrisaival pedig meg lehetne tölteni a Puskás Arénát.

A produktivitás téveszméje

A probléma az, hogy scrum, talán az őt övező divat miatt, nagyon jól belepasszol abba hamis startupper életérzésbe, ami minden céget körülleng, akinek előbb volt csocsóasztala, mint bevétele. Könnyű belekényelmesedni abba, hogy egy jól szervezett szigorú módszertan megoldja helyettünk az egyik legnehezebb problémánkat és így az üzleti oldal is hamisan azt érezheti, hogy a felelősség egy részét a módszertan viseli.

^{Hurrá, most már minden megy magától!}

A fejlesztési oldal is azt érezheti a folyamatos meetingek és mikromenedzsment miatt, hogy a dolgok haladnak, a feladatok fogynak, a meetingek zajlanak, minden sínen van és halad. A valóság viszont az, hogy a munka egy része maga a folyamat működtetése. Ez a hatékonyság illúzióját kelti: maga a módszertan ez egy eszköz, ami semmit nem old meg önmagától. Segít, hogy hatékonyabban legyünk, vagy mederben tart. A feladatokat azonban nekünk kell megoldani, a terméket nekünk kell fejlesztenünk, a piacot nekünk kell feltárni, a felhasználókat nekünk kell megismerni. Sőt a szabályokból adódó rugalmatlanságot is nekünk kell kezelni.

A félreértések elkerülésére

Fentebb említettem, hogy a fogalmak félreértelmezése is komoly problémák forrása lehet, álljon hát itt néhány gyakori értelemzavar, amit mindenképpen kerüljön el, aki jót akar. Az Agilis/Agilis módszertan/Scrum különbségére remélem már rávilágítottam, de mégis leírom, hogy az agilitás, mint csapatdinamika és hozzáállás, a módszertan, mint elvek és irányok gyűjteménye és a scrum, mint konkrét szabály- és folyamatrendszer hármasáról van szó.

^{A legtöbbször nem a termék az, amit el akarunk adni.}

Nagy hiba a termékfejlesztés és a szoftverfejlesztés keverése. A szoftverfejlesztés gyakorlatilag a forráskód írása, a fejlesztők által végzett tevékenység. A termékfejlesztés egy üzleti tevékenység, ami termék jövőbeni tulajdonságait határozza meg (pl. feature-ök), bele tartozik az üzleti és user inputok feldolgozása is. Bár az üzleti oldal szereplői gyakran nem veszik ezt figyelembe, az üzleti igény nem ugyanaz, mint a specifikáció. Az üzleti igény egy általános igény megfogalmazása, míg a specifikáció ennek egy eléréséhez szükséges lépések konkrét, egyértelmű megfogalmazása. Érdekes dolgokat lehet produkálni, ha a fejlesztő üzleti igényt kap specifikáció helyett. A scrum storykban gondolkodik atomi feladatok helyett, ami gyakorlatilag összetartozó, valamilyen üzletileg is értelmezhető komplett funkcionalitást megvalósító atomi feladatok csoportja.

Első pillantásra könnyű erre célként gondolni, azonban a story és a cél relációja hasonló a már említett termék- és szoftverfejlesztés párosához. A story eszköz a cél elérésében. A cél sohasem lehet valamilyen funkcionalitás elkészülte, a cél a funkcionalitás(ok)on keresztül elérhető “nyereség”. Például egy e-commerce site kosarának átalakítása story(k) megvalósításával éri el a célt, ami a churn (lemorzsolódás) csökkentése. Az egyszerű összefüggés csak a példa kedvéért.

A becslés nem tervezés. Könnyen gondolhatjuk azt, hogy azáltal, hogy a fejlesztő adott egy becslést az adott feladat elvégzésére, ő azt átgondolta és emiatt már nincs szükség külön tervezésre. Nagy hiba ezt gondolni, hiszen míg a becslés az adott feladatra koncentrál, addig a tervezés során a rendszerbe való illeszkedés és az architektúra minél kisebb megsértése is szempont. Azt mondhatjuk inkább, hogy a becslésnek tartalmaznia kell(ene) a tervezésre szánt időt is.

Erősen demotiválni lehet egy csapatot a mérés alapú összehasonlítás és az értékelés keverésével. Nem is a lelkizés része számít (bár minden ellenkező híresztelés ellenére lelke a fejlesztőknek is van), hanem hogy egy grafikon csak azt mondja; jó, rossz, jobb, mint múlt héten, 10%-al jobb, mint a Gabesz. Bármennyire is pontos és részletes egy ilyen eredmény, önmagában nem akcióképes. Viszonyítja a teljesítményt az elvárásokhoz, de a fejlődéshez szükséges lépéseket csak személyes értékelés során, közösen lehet meghatározni.

Személyes kedvencem az 1 iterációs iteratív fejlesztés. Mi iteratív fejlesztünk, de annyira királyak vagyunk, hogy minden elsőre megvan. Így hát élvezzük az iteratív fejlesztés minden előnyét. No komment.

A backlog nem szeméttelep. Bár csábító, hogy minden felmerülő feladatot és ötletet bedobjunk a backlogba, ne tegyük, mert nem erre való és előbb-utóbb pórul járunk, meg van ennek a kezelésére a megfelelő szabályrendszer. Kényelmes elhinni, hogy ami a backlogba bekerül, az nem fog elfelejtődni, azzal “foglalkozva van” és pont amikor szükség van rá a 674-ik feladat hirtelen bekerül a sprintbe. Valójában az fog történni, hogy az amúgy fontos feladatok is elvesznek a mocsárban és vagy nyitunk egy új backlogot, ahova sok munkával átmigráljuk a kigyomlált feladatokat, vagy lassan minden hajszálunkat elveszítjük.

Azt, hogy a refaktorálás nem céltalan munka már megbeszéltük, ne várjuk meg amíg a fejünkre nő a kód. A scrum elég erősen támogatja, hogy a fejünkre nőjön, úgyhogy legyünk résen. Ez elsősorban az üzleti oldal felelőssége, egy valamire való fejlesztő úgyis folyamatosan refaktorálni akar ("ha most csinálnám sokkal jobban meg tudnám csinálni"), ez sem jó, ne hagyjuk, de ez már a fejlesztésvezető/CTO felelőssége.

A feature és value keverése viszonylag gyakori és végzetes hiba. Általában abból adódik, hogy fogalmunk sincs, hogy a termékünket kinek szánjuk, mit fog vele csinálni a használó és milyen értéket ad ez neki. Ekkor jön az "azért nem használja, mert ez a feature még hiányzik belőle" felkiáltás. Ha elkezdjük nincs vége, mindent felemésztő, ámde teljesen céltalan végtelen ciklusba kerülünk.

Mi mást?

Ha már kiábrándultunk a scrumból, akkor jogos a kérdés, hogy mit használjunk. Ez így szerintem rossz kérdés, nagyon sok jól használható eleme van a scrumnak, amivel javíthatjuk a folyamatainkat és a hatékonyságot. Ami nem működik, az a szigorúan, formálisan betartott scrum, informális lazítás nélkül. Az modern fejlesztési módszertanok kevésbé szabályrendszerre, mint inkább irányelvekre épülő végén áll a Lean metodológia. Bár konkrétan táblázatos formában is szokták összehasonlítani az agilis módszertanokkal, akár a terminológiát, akár a folyamatokat megfeleltetve egymásnak a két rendszerben, valójában sok különbség van közöttük.

Definíció szerint az agilis módszertan egy idő alapú, iteratív termékfejlesztési folyamat amelyben a termék lépésről-lépésre (iteratívan) alakul ki és lehetőséget ad a változásokhoz való alkalmazkodásra. A lean filozófia pedig a build-measure-learn ciklust használja. Gyakori felhasználói teszteket hajt végre és a számukra nyújtott érték növelésére törekszik. Ahogy az agilis filozófiának is vannak konkrét módszertanai (pl. Scrum, XP, FDD), úgy a leannek is (pl. Kanban, Kazein).

^{A lean kanban sokkal kevesebb szabályt állít, mint a scrum. (forrás)}

Az agilis tehát a folyamatra koncentrál, hogy a termékfejlesztés iránya menet közben könnyen változtatható legyen és így gyorsan lehessen reagálni a piaci környezet változásaira. A lean a termékre és a userre fókuszál, hogy a termékfejlesztés iránya rugalmasan alakítható legyen a felhasználóktól begyűjtött adatok, visszajelzések alapján. A lean módszertanok sokkal kevesebb szabállyal működnek, ehelyett inkább kereteket fogalmaz meg, amik között sokkal nagyobb szabadsággal lehet mozogni, jobban érvényre lehet juttatni a mérnöki megfontolásokat ahogy az üzleti igényeket is. A meetingek, interakciók opcionálisak, a működtetéshez tapasztalt projektvezető szükséges. Álljon itt egy rövid magyarázat a lean kanban lényegi elemiről és a scrummal való viszonyáról.

MVP

A lean alapterméke az MVP (egyik fordítása Minimum Viable Product/Minimális Életképes Termék). Ez egy olyan minimális funkcióhalmaz, amivel a termék már valamilyen hozzáadott értéket teremt a felhasználónak, mindezt úgy, hogy törekszik a lehető legegyszerűbb és legkönnyebben megvalósítható megoldásra és a legkevesebb fejlesztésre. A lean iterációs ciklusokban (build-measure-learn) minden esetben MVP-k kerülnek megvalósításra.

Nagy különbség, hogy amíg az agilis fix sprint ciklusai határozzák meg az elvégzendő feladat mennyiségét, addig a leanben a megvalósítandó funkcióhalmaz a fix, amihez a változó hosszúságú ciklusok alkalmazkodnak. Bár erősebb termékfejlesztési kontrollt ad a fix hosszúságú ciklus, a változó hosszú iterációk jobban követik a feladathalmazok méreteit és előtérbe helyezik a terméket a folyamattal szemben. A változó hosszú ciklusok a cég különböző fejlettségi fázisban is lehetővé teszik, hogy a módszertan változatlan formában használható legyen. Pl. egy induló cégnél, a termék első verzióinál természetes a hosszabb távú gondolkodás és nagyobb lélegzetvételű funkció csomagok, így a ésszerűbbek a hosszabb iterációs ciklusok is. Ez agilis módszertanokkal ez jobbára a sprintek hosszának változtatásával követhető. Az MVP összeállítása nem egyszerű, a minimum termék meghatározásához az üzleti és technológiai oldal közös gondolkodása szükséges és általában a tapasztalatlan csapatoknak nem sikerül valóban minimális funkciókészletet definiálni.

Build-measure-learn

A lean kanban változó hosszúságú iterációs ciklusa a build-measure-learn ciklus. Ez tulajdonképpen egy iteratív tanulási ciklus, ahol minden funkcionalitás minimális, de használható verzióját adjuk a felhasználó kezébe és a használat alapján döntünk a következő funkcióhalmazról. A rövid távú célok itt is okozhatnak architekturális káoszt, de valamennyire javít a helyzeten, hogy szükség esetén nagyobb falat is tervezhető egyszerre, illetve hogy a megvalósított funkcionalitás a lehető legegyszerűbb és általában nem véglegesnek szánt. Egy-egy cikluson belül az üzleti és a fejlesztési oldal nem hierarchikus, ahogy a scrum esetében. Amíg a fejlesztés a builden dolgozik, addig az üzlet a learn fázisban van és generálja az inputot a következő iterációhoz. A measure általában közös munka.

^{Build-measure-learn ciklus}

A lean buktája szinte mindig az, ami miatt szerethető is, hogy nem definiál szigorú szabályokat és nem állít magas kerítéseket. A build-measure-learn ciklusban egyedül a build ami egzakt. A measure fázisban rajtunk múlik, hogy mit, milyen teljeskörűen és milyen hatékonysággal mérünk. A learn fázisban pedig rajtunk múlik, hogy a mérési eredményeket hogyan értelmezzük és milyen következtetéseket vonunk le belőlük. Mivel ez a módszer lelke, csak akkor lesz működőképes, ha nem azt mérjük, amit látni szeretnénk és nem azt a következtetés vonjuk le, amit hinni szeretnénk.

Validálás

A lean módszertan legnagyobb értékajánlata, hogy korai termékvalidációt tesz lehetővé és bár nem óv meg a zsákutcáktól - sőt, bátorít a kockázatos utak bejárására - minimalizálja a kockázatot azzal, hogy a lehető legkisebb erőforrásráfordítással mérhetjük meg egy-egy irány hatékonyságát. Erős mondás: bizonyosodj meg róla, hogy van piac a termékedre mielőtt megcsinálod. Ez sajnos a legtöbb esetben nem megvalósítható, valamit adni kell a felhasználó kezébe ami validája a célcsoportot, a terméket és az ezekkel kapcsolatos feltételezéseinket. De amennyire csak lehet, minimalizáljuk ennek költségét és kockázatát.

^{Kinek? Mit? Miért?}

Felhasználói visszajelzések kezelése

A build-measure-learn ciklus alapköve a felhasználói visszajelzések gyűjtése és értelmezése. A ciklus célja mindig valamilyen feltételezés vagy feltételezés halmaz validálása. Például ha lenne egy nagyobb előfizetési csomagunk, akkor a felhasználóink legalább 10%-a áttérne erre a csomagra. Ez egy olyan feltételezés, ami profit növekedést hozhat a cégnek, így mindenképpen érdemes kipróbálni.

A felhasználók közvetlen megkérdezése azonban nem fog jó eredményt hozni, a felhasználók gyakran legjobb szándékuk ellenére sem tudják a feltételezett körülmények között megjósolni saját viselkedésüket. A legjobb szimuláció az, ha valóban a megváltozott körülmények között (új csomag) kell használniuk a terméket. Mivel nem a funkcionalitás elérése a cél, hanem a feltételezés validációja, ebben az estben az MVP lehet a UI-ra kivezetett új csomag, ami valójában nem létezik, de a kattintások által mérhető a szándék és az igény. A mockolt funkcionalitás miatti bosszúságot enyhíthetjük például egy kedvezmény felajánlásával.

^{Így lesz funkciótemető a szoftvertermék}

Gyakori hiba, hogy a felhasználói visszajelzéseket közvetlenül, kérdőívvel, beszélgetések során gyűjtjük és minden felmerülő igényt validáltnak tekintünk, hiszen azt egy felhasználó mondta. Egyrészt ezek közel sem validált igények, másrészt az üzleti céljainkat mi ismerjük, nekünk kell lenni a kapuőrnek, hogy a termékfejlesztés ne a felhasználók random igényeit tartalmazó funkciótemető legyen. A sweet spot valahol az üzleti oldal feltételezéseinek validációja és felhasználók megkérdezése között van. Legjobb, ha ezek kölcsönösen hatnak egymásra.

Iteratív fejlesztés / value darabolása

Az iteratív fejlesztés legnehezebb része, hogy miként daraboljuk a feladatokat, hogy azok minden iteráció végén valamilyen használható funkcionalitást adjanak, mindezt úgy, hogy a lehető legrövidebb legyen, lehetőséget adjon a visszavonulásra (negatívan validált feltételezés esetén) és a üzleti/stratégiai célok felé vigye a termékünket.

^{Jól darabolt termék korai iterációs ciklusában}

Egy torta példájával élve, iterációnként egy-egy szelet kiadása jó megoldás, esetleg díszítés és gyertya nélkül, ezek rákerülhetnek később is, nem fogják az alapfunkcionalitást borítani. Ezen kívül azonban lehet egy tortát legalább 10 féle képpen rosszul szeletelni. Egy piskótalap, vagy egy tál krém leginkább csak egy gyereknek vonzó termék.

Keep It Simple Stupid

A lean filózófia, ahogy neve is sugallja (sovány, szikár) arra törekszik, hogy mindent a lehető legkisebb költségen, a lehető legkisebb hatással valósítson meg és validáljon. Ez a gondolkodásmód extrém esetek kivételével hosszú távon is kifizetődő. Bár az egyszerűség elvét elsősorban a fejlesztésre szokták érteni és alkalmazni, könnyű belátni, hogy más területeken (marketing, design, üzleti modell, kommunikáció) is előnnyel használható.

^{Feltételezés: emberek képet szeretnének akasztani a falra. Melyikkel bukunk kisebbet, ha megdől ez a feltételezés?}

Az egyszerűség elérése könnyűnek tűnik, de megfelelő piaci visszajelzés, üzleti tudatosság, fókusz és profi csapat nélkül nem egyszerű lesz a termékünk, hanem gagyi.

Tarisznyábavaló

A tarisznyábavaló az, hogy ismerjük meg ellenségünket is (jelen esetben a vízesés modellt) és vegyük fel vele a harcot, de előbb értsük meg, hogy mi az, amit nem szeretünk benne, mi az, ami miatt nem működik. Semmiképpen se fogadjuk el egy az egyben a mások által javasolt gyógyszert (jelen esetben a scrumot vagy akár a kanbant). Értsük meg, gondoljuk át, hogy a saját projektünkön, csapatunkban, piacunkon milyen előnyöket kínál és milyen akadályokat támaszt. A módszerek által állított korlátokat le tudjuk-e bontani ha szükséges, milyen elemeit tudjuk hasznosítani és azok hogyan passzolnak  (az amúgy nagyon nehezen megváltoztatható) csapatkultúránkba. Lássuk a módszer minden aspektusát (technológia, üzlet, csapat, egyén). A vízesés modelltől való legkisebb eltérés is hatalmas előnyökkel jár, nincsen általánosan rossz módszer, ahogy jó se. Ismerd meg, lopd el, alakítsd át, használd. Ne legyél a császár, aki egészen addig elhiszi hogy van rajta ruha, amíg büszkén ki nem masírozik az emberek elé.

A szerző Bujna András, a DreamJo.bs CTO-ja, full stack fejlesztő, architekt. A cikkhez kapcsolódó előadást András a Startup Safaryn adta elő, a kapcsolódó diák itt érhetőek el.