Egyáltalán nem triviális és nem is egyszerű hatékonyan vinni egy projektet, megszervezni a munkát, menedzselni a feladatokat. A szoftverfejlesztés sokszor rapid döntéshozatalt és rugalmas projektszemléletet kíván meg. Az elmúlt években egyre kiforrottabbá váltak az úgynevezett agilis szoftverfejlesztési modellek. Az egyik legnépszerűbb a Scrum. A módszerről az egyik hivatalosan is elismert tanácsadócég, a Sprint Consulting alapítójával, Bodó Árpád Zsolttal beszélgettem jó háromnegyed órát. A beszélgetés első részének leiratát olvashatjátok...
Hogyan mondanád el egyszerű magyarul, hogy miről szól a Scrum?
Egy projekt általában egy ötlettel kezdődik. Először elkezdik címszerűen összeírni, hogy mit is kell tartalmaznia a terméknek ahhoz, hogy az ötlet megvalósuljon. Ezt a terméket leíró listát nevezzük product backlog listának. Majd ha az ötletek összegyűltek, elkezdik kidolgozni a mögöttes tartalmat is - kicsit hasonlóan a követelmény-specifikációkhoz. A szép az egészben az, hogy ahhoz, hogy elindítsuk a projektet, a teljes kép ugyan meg kell, hogy legyen, de a teljes lista (minden részletében kidolgozva) nem kell, hogy rendelkezésre álljon. Ennek az az előnye, hogy egyrészt hamarabb elkezdhetünk fejleszteni, másrészt úgyis meg fognak változni a projekt során a követelmények, és akkor legalább nem kell majd átírogatni a teljes dokumentumot. Hanem... Ami nagyon fontos, hogy ez a lista egy jól meghatározott sorrendbe rendezett lista kell, hogy legyen. A sorrendet pedig a Business Value-nak nevezett paraméter határozza meg, ami azt jelenti, hogy azok a magasabb prioritású elemek, amik a legtöbbet jelentik a termék számára, és ezekkel kezdünk el foglalkozni először. Létrehozzuk a termék vázát és utána feltöltjük a legértékesebb fícsörökkel, minek eredményeként lehet, hogy már el is tudjuk kezdeni értékesíteni a terméket, miközben folyhat tovább a fejlesztési munka.
Nos, tehát aki képviseli és tulajdonolja ezt a listát, őt hívjuk Product Ownernek. Ő mondja el a teljes képet a fejlesztőcsapatnak egy kick-off meeting keretében, hogy mindenkinek a fejében meglegyen, hogy miről szól ez a termék. Ez nagyon fontos. Ezt követően elkezdődnek az iterációk, amiket a Scrumban sprinteknek nevezünk. A product owner és a fejlesztőcsapat összeül, és ennek a listának egy, a tetején lévő részhalmazát, amiről a product owner úgy gondolja, hogy belefér egy sprintbe, odaadja a teamnek, azzal, hogy "Na fiúk, ezt szeretném, ha megcsinálnátok az első iterációban. Vagy legalábbis a lista tetejéből annyit, amennyit tudtok." Nagyon részletesen elmagyarázza nekik ezeket az elemeket, a fejlesztők pedig addig kérdeznek, amíg világos nem lesz számukra minden részletében a feladat. Majd a fejlesztői csapat valamilyen módszer szerint (idő, komplexitás) megbecsli a feladatokat. Ezután a product ownerrel közlik, hogy most ennyi fér bele a "kívánságlistából". Megegyeznek, kezet ráznak. És innentől nevezik ezt a listát sprint backlog listának. Ebben a pillanatban a sprint backlog lista befagy. Kőbe van vésve. Nem lehet sem hozzáadni, sem elvenni belőle úgynevezett storykat, vagyis listaelemeket. Csak és kizárólag közös megegyezéssel (PO és team), de az már kivételkezelést igényel.
A lista elemeit taskokra bontják, amelyek már a teljesség igényével készülnek. Egy story akkor lesz kész, amikor a hozzá tartozó összes task készen van. Az ideális sprint 30 naptári nap. A sprint végén a fejlesztők leszállítják a fícsöröket. Nagyon fontos, hogy a sprint backlog listában nem rétegeket felépítő dobozok vannak, hanem függőleges szoftver funkciók. Azaz ezekben benne van a UI, a backend munka, az adatbázis munka, és minden, ami csak szükséges a fícsör működéséhez. Így a sprint végére a fícsörökhöz többé már nem kell hozzányúlni, és így ragasztjuk a termékhez minden sprintnél az újabb fícsöröket.
Mi lesz az eredmény? Egy káposzta. Nem eredményez egy szép szoftverarchitektúrát, de megvan az ellenszer: a refaktorálás. Míg hagyományos módszereknél nem is biztos, hogy ismerik vagy alkalmazzák, a Scrum esetében szükséges dolog a refactoring. Oké. Azzal azonban nem ér véget a dolog, hogy a team lefejlesztette a bevállalt fícsöröket. Nekik is kell eladniuk azokat a product ownernek. Demózzák: ezt kérted, és mi így valósítottuk meg. Egyenként végigmennek a lefejlesztett fícsörökön, és a product owner értékel. Majd a végén elfogadja vagy nem fogadja el a leszállított fejlesztéseket.
Szintén fontos elem, hogy minden nap van egy úgynevezett daily scrum, vagy daily standup nevű szeánsz, amikor a team maga (pont az önszervezésből adódóan) megbeszéli, hogy mit csináltak az előző standup óta, mit tervezek csinálni a következő standupig, és van-e valami akadályozó tényező, amire azonnal ugrik is a Scrum Master (SM), akinek feladata, hogy elhárítsa ezeket az akadályokat.
Mi a probléma a waterfall modellel, azokkal a projektvezetési, projektmenedzsmenti modellekkel, amikor linárisan történnek a dolgok egy fejlesztés esetén? Tehát van egy tervezési, fejlesztési, tesztelési szakasz, majd kitelepítik a szoftvert és marad az üzemeltetés a végére... Mi a probléma a hagyományos projektmenedzsmenttel?
A hagyományos projektmenedzsmenttel az a probléma, hogy az 50-es években alakult ki, majd a szoftveripar megjelenésével nem teljesen követte azt Az iparosodás környékén gyárakat, meg üzemeket építettek, akkor találták ki azt a Gantt chartot, amit azóta is használunk például az MS Projectben. Az épülettervezéshez ez volt az ideális, de közben megjelent a szoftveripar és jobb híján ehhez nyúltak, és mai napig használjuk a waterfall modellt, valamint az ezen alapuló módszertanokat. Így hát számos hátránya van a szoftverfejlesztésben, az építkezéshez képest.
Mik ezek?
Mutatok egy ábrát... A waterfall azzal kezdődik, hogy az elején megnézzük, melyek a követelmények, ügyfélnek összefoglaljuk, hogy így értette-e, majd ezek alapján megtervezzük a szoftverterméket és lekódoljuk. Ha kell összeintegráljuk, teszteljük majd installáljuk és átadjuk.
Üzleti oldal és fejlesztő oldal közti kommunikáció hiánya: Az egyik fontos különbség a hagyományos és az agilis módszertan között, hogy a hagyományos módszernél az ügyféllel mindössze két alkalommal találkozunk igazán: a projekt elején és a végén. Egy hosszabb terjedelmű, féléves, másfél éves projekt közben nem találkozunk az ügyféllel, hiszen ő sem igényli, meg mi sem. Jóllehet, mindkét oldalnak szüksége lenne rá, ennek nincsenek tudatában. A végén, amikor átadjuk a terméket, az ügyfél dob egy hátast, hogy ő nem ezt akarta. Akkor jön a vita, a claim-menedzsment, hogy ki hibázott. Elővesszük a követelményspecifikációt és látszik belőle, hogy hát ez van ideírva, csak azt ő máshogy értette, mint mi. Igazából teljesen mindegy, hogy ki értette félre, az biztos, hogy a végén valaki ezért fizetni fog. Vagy mi vállaljuk ezt be, és olyanná alakítjuk a szoftvert, amilyenné ő valójában szerette volna, vagy pedig rajta verjük le, hogy ő írta le, és ezért fog ő fizetni. Ügyfél nem lesz elégedett, további költségek jelentkeznek, és valaki ezt megfizeti.
A másik dolog, hogy az átadáskor nem ér véget rögtön a fejlesztés, nem tudjuk valójában átadni, hisz tovább kell fejleszteni, hogy olyanná alakítsuk, amilyenné az ügyfél valójában szerette volna. Tehát a plusz költségek mellett határidőcsúszással és bevétel kieséssel is számolhatunk.
A harmadik, hogy mivel ez a hagyományos modell fázisokból áll (követelményelemzés, tervezés, kódolás, integráció, tesztelés stb), ha bármelyik egy picit is megcsúszik, az összes utána következőt tolja maga előtt. Ismét határidőcsúszás az eredmény.
Szintén nagy különbség magában a projektcsapat összeállításában van. Egy szoftver rétegekből épül fel: UI, backend, adatbázisréteg, stb. A hagyományos módszertan szerint általában úgy alakítják a fejlesztői csoportokat, hogy a különböző teamek különböző rétegeket fejlesztenek. Ezek jól meghatározott interfészek mentén vannak elvágva.
Agilis szoftverfejlesztésnél ez nem így működik. Itt cross-functional csapatok vannak, "függőleges fejleszésű" fícsöröket, azaz nyomogatható, kész, használható fícsöröket szállítanak a fejlesztőcsapatok...
Ezeket a problémákat az agilis módszertanok, vagy konkrétan a Scrum hogyan oldja fel, milyen előnyöket nyújtanak?
Nézzük a lehetséges problémákat: Ha követelmény változik, akkor mindig vissza kell térni az elejére, kvázi antigravitációs logika szerint újra engedélyeztetni kell a módosításokat, újra bele kell nyúlni a tervekbe. Ha tehát az ügyfél a projekt elindulása után rájön, hogy változtatnia kell a követelményeken, és ha ez a tervezés ideje alatt történik, akkor szól nekünk, és mi beletesszük a módosításokat. Ha viszont kódolási időszak alatt történik mindez, akkor csak úgy tudjuk beépíteni ezt a változtatást, ha visszanyúlunk a tervezéshez. Integrációkor, vagy teszteléskor, általában már le is szokták hülyézni az ügyfelet, hogy mégis mit gondol, hogy képzeli? Egy tanulmány szerint, ha a projekt elején egy követelmény 1 forintba kerül, akkor annak beépítése a projekt 75%-ánál, már 100 forintos költséget jelent. Tehát minden ilyen változtatás plusz költséget generál, de nagyságrendileg is nagyobb kiadás, mintha az elején derült volna ki.
A hagyományos szoftverfejlesztési módszertan nem tudja kezelni a változtatást: rugalmatlan. Hogy változtatásra miért van szükség? Fejlesztők körében van egy elterjedt axióma, hogy a ügyfél hülye. Valójában az ügyfél azért nem tudja, hogy mit akar, mert abban a pillanatban nem tudhatja, hogy mi várható a piacon, nem tudhatja, hogy hogyan lehetne ebből a legjobb terméket létrehozni. Hiszen nincs a kezében a termék. És csak akkor tudná ezt igazán megmondani, ha már nyomogathatná, használhatná, a terméket, és mondhatná, pl. hogy jobb lenne, ha ez a fícsör másképp nézne ki, ez a gomb kerüljön a másik oldalra, satöbbi. A piac változik, jogszabályok változnak, sokszor ezért is kell neki követelményt változtatnia. Tehát nem mindig az ügyfél felületessége miatt jelentkeznek ezek a problémák.
Ehhez képest az agilis módszertan mit feltételez?
Az ügyféllel nem az elején és a végén találkozunk, hanem az elején, majd pedig minden egyes iteráció, sprint során. Tehát sok lehetősége van arra, hogy beleszóljon és változtasson. Az előbb említett esetben, hogy ha valami nem úgy alakul, ahogy az ügyfél szerette volna, valaki fizetni fog. Scrumnál - mivel időről-időre találkozunk az ügyféllel - időben előjönnek a módosítási igények. Mivel menet közben látja, hogy alakul a termék, egyszerűen és költséghatékonyabban tud változtatni. Ha meg változtat, akkor egyből látni is fogja, hogy ez mivel jár, mennyibe kerül. Tehát kétszer is meg fogja gondolni, hogy mennyit változtat.
Tehát a Scrum fő előnye a kommunikációs részében van, hogy sokkal intenzívebb a kommunikáció a szereplők között?
Inkább a fő eszközének nevezném a kommunikációt. A fő előnyei közül, ha nem konkrét részleteket nézünk, akkor azt emelném ki, hogy abból a pénzből, amit az ügyfél az adott projektre elkölt, a lehető legtöbbet hozzuk ki, a legtöbbet kapja. Ez neki is előny, és nekünk is, hiszen a reputációnk megítélésekor nem lesz mindegy, hogy az ügyfél elégedett vagy sem. Másik előnye, hogy kockázatot csökkent. Az agilis módszertanok a waterfallhoz képest csípőből kilőnek számos kockázatot. Saját cég esetében ezt éri meg alkalmaznom, mert produktivitást növel és az emberek jobban érdekeltek abban, hogy jól működjön a cég. Ennek feltétele és eszköze a kommunikáció. Kommunikáció ezerrel mind cégen belül, mind ügyféllel. A siker feltétele az is, hogy az ügyfél is agilisan gondolkozzon és megélje azt, hogy tartjuk a kapcsolatot és együttműködünk. Máshogy nem fog működni.
A szerepkörök hogyan változnak meg?
Változnak, mert a hagyományos projekteknél vannak projektmenedzserek, vannak fejlesztők, akik elvégzik a munkát, van az ügyfél, akit valaki képvisel és van business analyst-szerű valaki, aki segít abban, hogy leírja a követelményeket. A teamet meg lebonthatjuk architektúrával, UI-jal, dizájnnal, fejlesztéssel, adatbázissal foglalkozó egyénekre. A Scrumban ezekre a munkákra ugyanúgy szükség van, csak másképp történik a szervezés. Projektmenedzsert a Scrum sem mindig tud nélkülözni, viszont ez a szerepkör 3 részre oszlik. A legnagyobb szerep a product owneré, aki az ügyfelet képviseli. A második maga a scrum team, a fejlesztőcsapat, és a harmadik a scrum master. A scrum mastereknek - akik legtöbbször projektmenedzserekből lesznek - van a legkisebb hatalmuk a projektszervezésben, azonban vétójuk van a módszertan alakulásában...
Történetileg azt látjuk, hogy a menedzseri rétegnek a 20. század eleje óta nagyon fontos szerepe van egy vállalat működtetésében és a projektszervezésben is. Mindenki azon szocializálódik, hogy a menedzser az, aki összeszedi helyettünk, hogy mit mikor kell csinálni, hogyan kell dolgozni. Ezzel szemben azt mondod, hogy nagyon sokat ebből a felelősségből vissza lehet delegálni a csapatnak. Ez a filozófiai váltás a lényeg?
Igen, ez a filozófiai váltás lényege és eszköze az agilis módszertanoknak. Abból ered, hogy a munkát azok tudják legjobban megszervezni, akik ténylegesen elvégzik, ők tudják legjobban maguk közt felosztani. Ami nem jelenti azt, hogy többé nincs szükség menedzserekre. Például most a 120 fős projektemben van 9 Scrum-team, de attól még kell projektmenedzser, mert össze kell fogni az egészet. Ez a váltás nem működik egyik napról a másikra.
Hagyományos felállásban a projektmenedzserek attól félnek, hogy a fejlesztők nem képesek megszervezni maguk a munkájukat. Van egy bizalomhiány a dolgozó emberek felé a megrendelő vagy vezetői oldalról is. Elvárják, hogy legyen ott egy ember, egy menedzser, aki tud határidőt tartani, irányítani stb.
Igen, így van. A Scrum és az agilis módszertanok akkor fognak működni, ha a csapat tényleg képes lesz önszerveződni. Ken Schwaber, a Scrum atyja, azt mondja, hogy mindenki legyen expert. Tudjuk, hogy nem teljesen így van, hiszen ha egy cégben mindenki szuper expert, akkor az a cég anyagilag bedőlne. Egy bizonyos fokú tapasztalati szintre azonban tényleg szükség van ahhoz, hogy a team meg tudja szervezni a saját munkáját. A másik feltétel, hogy lelkes motivált emberek alkossák a csapatot.
Ha őszintén ránézünk a világ egy tetszőleges cégére, akkor ott nem csak motivált, boldog, a munkájához legjobban értő embereket fogunk találni. Az élet sokszor úgy hozza, hogy az emberek nem mindig érzik úgy, hogy a legtökéletesebb pozícióban dolgoznak. Egy kicsit túl ideális állapotot feltételez a Scrum...
Talán úgy tűnik, hogy túl ideálisat felételez, de ez nem így van. A motiváltságnak öngerjesztő folyamatként kell működnie. Azáltal, hogy hagyjuk, hogy a csapat tagjai maguk oldják meg a saját munkájukat, szabadságot kapnak. Illetve tényleg rájuk van bízva a sprint végén a fícsörök leszállítása, tehát egyben felelősséget is kapnak. Megértik és átélik a munkájukat. Olyan, mint a biciklizés, meg az úszás: nem elég tudni a szabályokat, át kell tudni érezni. Egy Scrum tréningen két nap alatt agymosás folyik. Megértik a folyamatot, megtanulják a módszertant, hisznek benne, de ettől még nem fog egyből 300-400%-on pörögni a termelékenység. Csak ha a team ráérez az egészre.
Amint viszont ez megtörténik, akkor élvezni fogják a munkát. Elismerik őket és egyre motiváltabbak lesznek. Csak egy jó Scrum bevezetés kérdése az egész. Egy sztori erre: Moszkvában szegezték nekem ugyanezt a kérdést, hogy gondolom én azt, hogy reggel az emberek majd maguktól felveszik a munkát és el is végzik azt? "Ha nincs ott egy projektmenedzser, aki korbáccsal a kezében kiosztja, majd behajtja rajtuk, akkor az emberek maguktól nem fognak semmit dolgozni." Hát, ha így állunk hozzá, akkor valóban nem fog működni a Scrum.
Tovább az interjú második részéhez...
A Webisztán postcímeit 10 másodperc alatt alakítottam át Droid Serif betűtípusra. Ehhez mindössze a html-be és a css-be kellett egy-egy sort beszúrni. Ráadásul még IE6-ban is működik a dolog. A fejlettebb böngészőkről nem beszélve. A lényeg itt tényleg az egyszerűség és az akadálymentes működés. Próbáljátok ki!
