"Megértik és átélik a munkájukat" - a Scrum módszerről (1. rész)

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...

Címkék: dev interjú projektmenedzsment scrum agilis szoftverfejlesztés produktvitás
2010.05.17. 15:45. írta: hírbehozó

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Bár egy ideje én is agilis módszereket használok, és tényleg nagyon jó, kicsit démonizálva érzem itt a waterfall modellt. A kommunikációt citálni szerintem hülyeség, a waterfall modell önmagában nem gátolja, hogy ugyanannyit kommunikáljunk az ügyféllel, egyeztessünk részteljesítéseket, mint egy agilis módszer esetén. Egyszerűen csak sokkal nehezebb lekövetni a változtatási igényeket.

Ahhoz pedig tényleg álomcsapat kell, hogy önszerveződően hozza a sprint végére az elvárt eredményt piaci környezetben. Szerintem átlag csapatnál ez nem megy, maximum valami hobby projektnél. Az a tapasztalatom, hogy agilis módszertanban több mint egy év gyakorlattal rendelkező csapatnál is van olyan, hogy a csapattagok maguk szólnak, hogy közbe kellene lépni, ha "lazul a gyeplő".
Félreértés ne essék, a waterfall nem a megtestesült rossz, hanem csak hiányosságokkal küzd, amelyeket az agilis módszertanok kilőnek. Persze az agilis módszertanoknak is lehetnek bizonyos környezetben hátrányai.

Ami a hobby projekteket és az álomcsapatot illeti, az én esetemben 40 fős, 120 fős, meg pici 5-15 fős projektek sora és számos elégedett ügyfél bizonyítja, hogy ha jól vezetjük be a Scrum-ot, akkor bizony gyönyörűen működik. Ezek éles ügyféllel, akár havi közel tízmilliós eurós forgalommal értendők. (Ennyi véletlen egyszerre nem lehet.)
Nekem nem világos, miért dőlne be egy cég, ahol mindenki szuper expert. Egy ilyen cégnél kevesebb fejlesztő is elég ugyanazon munka elvégzéséhez, mert gyorsabban dolgoznak, és nem kell a béna vagy közepes fejlesztők által összehozott problémákat megoldani.
120 fős projektteam, 9 csapat azt jelenti, hogy átlagosan egy csapatban 13+ ember van.

A Scrum ajánlásai szerint 7 fő alatt (körül) célszerű tartani a csapat méretet. (Erre már a Scrum előtt is rájöttek elődjeink.) E fölött már lehetetlen kommunikálnia a keresztfunkcionális csapatnak, aki egy szobában van, egy tervezésen, egy napi standupon vesz részt. Mik a mostani tapasztalataid ezen a téren?

A sprint végére potenciálisan szállítható terméket kell(ene) készíteni. 9 csapatnál borzasztó nehéz lehet megoldani az integrációt úgy, hogy mindegyik a sprint végére "potenciálisan szállítható terméket" állítson elő. Ráadásul az egyes csapatok sikertelen sprintjei meg is hiúsíthatják a többi csapattal történő sikeres integrációt. Hogyan valósul meg az integráció?

Még egy dolog jutott eszembe: mivel a Scrum (és más agilis módszerek is) üdvözlik a menet közbeni változást, ezért refaktorálással, unit-tesztekkel készülnek fel arra, hogy a változó prioritásokat, váratlan helyzeteket kezelni tudják. Az én tapasztalatom a magyarországi helyzetet tekintve eléggé lesújtó: a programozók nagy része nem tudja alkalmazni ezeket az elveket (jobb esetben már hallott arról, mi az, hogy refaktorálás). Nem tudom, hogy ebből a szempontból az EPAM hogy áll, de véleményem szerint, ha minden második embert is érint ez a probléma, akkor is 60 ember intenzív szoftverfejlesztési felzárkoztatásáról van szó. Jelentkeznek-e ezek a problémák Nálatok?
@bodozs: a projekt és ügyfélméret nem feltétlenül aduász egy társalgásban. Ugyanúgy: waterfall modell, 50000+ részvevő és 5+ milliárd Ft költségvetés szerintem semmit nem bizonyít.

Érdemes lenne elválasztani a projektvezetési és a szoftverfejlesztési módszertant a fenti leírásban, valószínűleg úgy jobban érthetővé válna a Scrum/Agile létjogosultsága.

Az én értelmezésemben alapvetően arról van szó, h a mai követelményeknek megfelelő szoftverfejlesztési tevékenység az nem projekt-szerű, tehát nem hatékony projektvezetési módszertan alá bezsúfolni.

A felsorolt hiányosságok egyike sem kötelező "eleme" a PM megközelítésnek: kommunikáció, rugalmas követelmény-kezelés, delegálás, revalidálás, partneri kapcsolat az ügyféllel mind a megengedett eszköztárba tartozik.
@Marhefka István: van tapasztalatotok virtuális csapatokkal?
@Amby: Arra gondolsz, hogy a csapat egy része fizikailag máshol van?

"Szerencsére" nem volt még ilyen jellegű tapasztalatom :)
@Marhefka István: vagy akár az egész :-D Nekem nincs kollégám, akivel egy irodában, városban, vagy akár országban lennék ;-)

Ez csapat- és projekt-modellben is gond, de több lerobbanásunk volt már agile módban ebből, mint projekt-módban (a cikkben "hagyományosként" jelzett értelemben).

Eddig kevés scrum/agile példát találtam virtuális környezetben, h megértsem, hátránya-e a megközelítésnek.
@Amby: Hát, megértem a gondodat :)

Ha már próbálkoztatok vele, akkor biztosan tudod, hogy az egész "agilizmus" a kommunikáción alapszik. Nem gyártunk felesleges doksikat, hanem egymással beszélgetünk, és így oldjuk meg a problémát.

Ez már akkor is nehéz, ha Te meg én csak telefonon (vagy Skype-on tudunk beszélni), de még nehezebb, ha kulturális és/vagy nyelvi különbség is van a felek között... Vagy netán még telefonon se tudunk beszélni, mert más időzóna szerint dolgozunk. Esetleg az említettek mindenféle kombinációja :)

A videokonferenciát szokták említeni megoldásként. Pl. standupokon így vesznek rész a távollévő felek.

Bár nem voltam ilyen szituációban, úgy gondolom, próbálnám a maximumot kihozni a helyzetből, és semmiképpen nem térnék vissza a hagyományos megközelítéshez, és az agilis pályán maradnék.

Egyébként - véleményem szerint - akkor sem egyszerű az agilitást véghez vinni, ha a virtuális csapat problémája nem áll fenn. Sok dolognak kell klappolnia egyszerre. Pl. kell egy jó csapat, a projektnek és az ügyfélnek is megfelelőnek kell lennie.

Nem irigyellek :)
Az volna a kérdésem, hogy ilyenkor hogyan fizet a megrendelő? Órabérben? Ugye az elején nem lehet tudni a project pontos költségeit.

A másik dolog, hogy weboldal fejlesztéseknél hogyan lehet ezt alkalmazni?
@Balbekk: Nem nagyon ismerek olyan céget, ahol csupa szeniorok dolgoznának. Anyagilag ez nem kivitelezhető. Ezt értettem a bedőlés alatt.
@Marhefka István:
Nem, nem az jelenti. A fejlesztők egy ekkora projektben csupán egy részhalmaz. A Scrum teamek 5-8 főböl állnak, és mindegyikben van funkcionális tesztelő is. Továbbá van business oldal (Product owner board), deployment team, performancia team, regressziós tesztelő csapat, stb.

Igen, az inetgráció nehéz. A release-ek kb 6 hetes ciklust követnek. A sprintek 2-3 hetesek. Nem minden sprint végén lesz release.
A sok team-ből nem mindegyik kerül be mindegyik release-be. A busines dönti el, hogy melyik team mikor megy egy adott release-be.

Unit test: a projektünkön az új kódrészeknél 70-90%-os a unit test coverage. A régí kódnál akkor nő, ha valaki változtatja.

A funkcionális tesztjeink pedig vagy manuálisak, vagy automaták. A sprint végén a funkcionális tesztek átminősülnek regressziós tesztekké.

Ami a branching stratégiánkat illeti, a két véglet között (1 brancs vs teamenként 1 branch) most keressük az arany középutat. Sok a szempont: pl. performancia kérdés, melyik team okozta a lassulást. Egy branch-en nehéz ezt megtalálni. Ugyanakkor a sok branch esetében ott az iszonyú költség amelyet az integráció jelent.
@Marhefka István: Nekem volt sok ilyen tapasztalatom. Annál is van rosszabb, amikor egy projekten a különböző csspatok különböző országban vannak: ha egy team lesz több országra szétosztva.
@sajt:
Ügyfél főleg óradíjasan fizet, ez a legelterjedtebb. Ezért a pénzért a fejlesztő csapat az ügyfél képviseletét ellátó PO által vezérelve szállít.

Az általam említett projekt egy nagy szállodafoglaló weboldal fejlesztéséről szól. De konkrétabb példák erre pl. az ingatlan.com, ninimo.com vagy a ustream.tv.
Akkor már csak az volna a kérdés, hogy hogyan tudnám ezt az egészet bevezetni a cégnél, ahol dolgozom?
@bodozs: mi történik akkor, ha az ügyfél fix áras ajánlatot kér?
@bodozs: Elég jó projekteken dolgozhatsz. Én amióta dolgozom (kb. 7-8 éve), egyszer sem találkoztam olyannal, hogy az ügyfél óradíjban fizetne. A jellemzőbb inkább a fix áras ajánlat, amivel persze, nincs gond, ha - fix határidőt feltételezve - a szkóp mozgó. Ez utóbbit tekintve már voltak változások a projektekben.

Unit-teszt: Annyira természetes, hogy mindenki tud unit-tesztet írni? Szerintem a jó unit-teszt írása nem triviális. Ha rosszul írják őket (és általában ez a jellemző), akkor a változások miatti folyamatos tesztkarbantartás rengeteg időt visz el. Az eredeti kérdésemben is igazából ezt próbáltam feszegetni. Mi volt a tapasztalatod: az EPAM-nál mindenki tud unit-tesztet írni, és ismeri az XP technikákat?

Azt írtad, hogy a régi kódhoz akkor növekszik a code coverage, ha abban változtat valaki. Ebből arra következtetek, hogy korábban nem készült unit teszt, hanem utólag pótolják őket. Tehát egy legacy rendszer fejlesztéséről van szó. Az ilyen helyzetekben tipikusan nem lehet unit-teszteket írni, hiszen az eredeti kód mindig egy nagy maszlag (nem unit-tesztelhető). Nem lehet, hogy ebben a projektben nem unit-tesztek, hanem integrációs tesztek készülnek?

Neked mi a véleményed? Mi az oka annak, hogy 120 ember kell ahhoz, hogy ez a projekt elkészüljön? Miért nem elég - mondjuk - 20?
Tök jó cikk, köszönjük. De azért az idegen szavak majdnem felét magyarul is lehetett volna mondani...
@sajt:
Keress meg, és szívesen leülünk veled beszélgetni. Természetesen térítésmentesen...
@Amby:
Ilyen is van. Azt látni kell, hogy az agilis módszertanok csak akkor fognak működni, ha az ügyfél is megérti és megéli azt. Ha ez nem így van, akkor inkább nem agilist kell alkalmazni. Ha viszont így van, akkor az ügyfél tudja, hogy azért a fix árért megkapja a terméket amit akar, sőt a legjobb formában, minőségben, DE nem teljesen azzal a feature set-tel, amit előre kitalált, hanem picit mással. Ennek két oka van: 1. a scope az amin változtatni lehet/kell, 2. maga az ügyfél fogja a termék fejlődése során megváltoztatni a saját eredeti elképzelését. Így viszont folyamatosan beleszólhat, és ellenőrizheti hogyan is költjük a pénzét.
@Marhefka István:
Nem panaszkodom. Valahogy az elmúlt 11 évben a fő állásaimban kevés fix áras projektem volt, ilyenek főleg tenderek esetében voltak (pl. ESA-NASA). Akkor és ott éppen nem agilis módszertanban dolgoztunk.
A sok óradíjas projekt valószínűleg abból adódik, hogy többnyire nagy projektjeim voltak nagy ügyfelekkel. Consulting területen már több fix árassal találkoztam.
Ha egy fix áras projekt esetében, a scope nem rugalmas, akkor csak házon belül lehet eljátszadozni az agilis módszertanokkal, vagy azoknak elemeit lehet használni csupán.
@Marhefka István:
Unit teszt: sajnos ez sehol sem természetes és sehol sem tud mindenki jó egyből jó unit tesztet írni. De szerintem már az is nagy haladás, ha egy ilyen döntés születik, és mindez úgy, hogy az ügyfél is helyesli. A többi meg a tanulási folyamat része. Ugyanezt elmondhatom az automata funkcionális teszt témában is.
Ha jól sejtem, a bodozs nick mögött az interjúalany rejtőzik.

Elég érdekesnek találom az agilis módszertanok bevezetésével való próbálkozást kishazánkban, ahol a fejlesztő cégek 80%-a ott tart, hogy a programozó, az majd mindent megcsinál (kövspec, funkc. spec, technikai spec, dbterv, sw architektúra terv, kód, unit teszt, funkc teszt, userteszt, bevezetés...).

Nemrég az álláskereső tapasztalatok indexes topikban volt erről egy jó kis vita, alapvetően a rendszerszervező szerepéről.
Ezzel szemben programozót keresnek a cégek ezerrel, de más projektszereplő mintha nem is létezne...

Olyan hirdetés is fut, ami kifejezetten programozói pozi, de azért userünk végezze el a szervezői feladatokat is. Vicc...

(én meg nem találok szervezői melót hónapok óta.. :( )

Mit gondolsz, mi kellene ahhoz, hogy a cégek normálisan, a hatékonyságot szem előtt tartva építsék fel végre a projektcsapatokat?
Olvasva az interjút:

1. szép és jó a priorizálás, de ha van egy olyan alacsony fontosságú dolog, ami miatt a rendszer alapjaiba kell belenyúlni, akkor az nem túl költséghatékony. Azt akarom ezzel mondani, hogy nem elég a kivitelezésnél és tervezésnél csak az egy sprintre eső dolgokat figyelembe venni, bele kell kalkulálni azokat is, amik még befolyásolhatják az aktuális sprint alakulását. Ez akkor okoz igazán gondot, ha egy feladat csak később derül ki ("Ezt nem így gondoltam"). Szóval az ellen nem véd :)

2. a fejlesztő nem mindig tudja, hogy mit illetve mennyi idő alatt tud megcsinálni. Viszont egy PM meg tudja mondani, hogy ki lesz, aki ebbe beletanul és ledokumentálja, közössé teszi a tudást, illetve implementálja.

3. mindenen felül pedig ott vannak a normák, az alapszabályok, irányelvek, amit egy csapatnak mindenképpen követni kell ahhoz, hogy a rendszert később is fejleszteni és karbantartani lehessen. És mivel nem mindenki expert, közös nevezőre szükség van, amit a túlzott szabadság megcsorbíthat. Szóval azt gondolom nem érdemes átesni a ló túloldalára sem.

Olvasva a kommenteket:

4. szó esett a díjazásról, mert tőlem mindig egy ajánlatot kérnek, mielőtt megbíznak egy projekttel. Ezt változó követelmények mellett hogyan lehet kivitelezni, vagy ilyenkor milyen ajánlatot érdemes adni?
Zseniális összefoglaló a Scrum-ról. Sajnos nem tér ki azokra az esetekre, amikre viszint nem ad választ (vagy nem egyértelmű választ) Készítettem egy összefoglaló szösszenetett erről:

www.qualityontime.eu/extracts/megertik-es-atelik-munkajukat-scrum-modszerrol-1-resz
@bodozs: egymondatos osszefoglalasnak talan akkor erdemes lenne ezt hasznalni. (Valtozo scopebol a legjobbat kihozni.)

Nekem a definicio azert erdekes, mert az agilis szervezesi modszertanok nem csak szoftverfejlesztesre ervenyesek, vagy alkalmazhatoak.

Trening teruleten iranyitok egy kozepes meretu projektvezetoi irodat es a projektek kis resze izolalhato jol merheto folyamatra. Legtobbszor nincs eselyunk 2-4, de gyakran 12 hetnel gyakoribb releasekre (meropontokra) se. De keressuk a lehetoseget, hogy azokban az esetekben is el tudjuk vallalni a feladatot, amikor az ugyfel nem tudja mit akar.
@deejayy:

1. Ha jól értettem arra gondolsz, hogy ha egyben tekintünk át egy problémát, és azt normálisan végiggondoljuk, akkor hatékonyabban lehet egyszerre megoldani, mintha azt sok kis szeletre bontanám, és prioritások szerint rendezve mindig csak azzal foglalkoznék, amivel éppen kell. Az így kapott kis feladatok a végén különböző időpontban készülnek el, ráadasul több újradolgozásra (rework) lenne szükség, mintha egyszerre csinálnánk meg. És ez költséges.

Elméletben igazad van, azonban a gyakorlatban ez másképpen történik. Gyakran kiderül, hogy a kisebb prioritású elemekre nincs is idő, pénz, nem is fontosak(!!), ezért kihagyhatóak. Pontosabban agilis megközelítés esetén meghagyjuk a lehetőségét annak, hogy ezek helyett az alacsony prioritású elemek helyett valóban fontos funkciókat fejlesszünk ki. Olyanokat, amikre eredetileg nem gondoltunk.

Sokan nem is gondolják, hogy mennyi felesleges funkciót fejlesztetnek ki velünk az ügyfelek, akik megálmodják a rendszert! A _valódi prioritások_ meghatározásához pontosan kell ismerni az ügyfelet és az üzleti problémát.

A szoftverfejlesztésben a folyamatos refaktorálás, automatizált tesztek (unit- és integrációs tesztek) biztosítják azt, hogy egy későbbi változás nem lesz költséges. A kód folyamatosan karbantartott, könnyen olvasható, módosítható, az automatizált tesztek pedig biztosítják, hogy ha módosítunk, nem rontunk el más részeket. (Vagy legalábbis hamar értesülünk róla.)

Ez régen nem így volt, és valóban szükség volt arra, hogy először jól végiggondoljunk mindent az elején.

2. Azt szokták "viccesen" mondani (nem mindenkinek lesz vicces), hogy egy jó (agilis) csapat munkáját a PM azzal tudja támogatni, hogy pizzát hoz nekik. Nem gondolnám, hogy a PM felesleges, viszont érdemes abba belegondolni, hogy a legjobb szakmai döntést nem egy olyan személy tudja meghozni, aki a legtöbbször nem is ért a szakmához. Nem is a vezető fejlesztő, aki ért hozzá, hanem maga a teljes szoftverfejlesztő csapat. Pont ez a Scrum egyik lényege: felruházza a csapatot a döntés jogával, hogy mit hogyan valósítson meg (empowering teams). Egy idő után, feltéve, hogy a csapat megfelelő környezetben dolgozik, kialakítja magának a legjobb munkamódszert. Ezt értik önszerveződő csapatokon. Ez csak akkor működik, ha a csapatban dolgozó emberek motiváltak és hozzáértőek (vagy vannak benne olyanok, akik meg tudják tanítani a többieket jól dolgozni). A motiváltság nem mindig magától jön. Ha egy csapatban megbíznak, aki így önnönmaga meghozhatja döntéseit, ha a csapat találkozhat az ügyféllel minden demó során, és mindenki saját maga bemutatja, hogy mit dolgozott a sprint közben, akkor a motiváció öngerjesztővé válik. Ezért lehet jó a Scrum. Ha a Scrum átfajul "ipari Scrummá", ahol azért alkalmazzák a Scrumot, mert az "menő", és igazából csak szolgaian követik a Scrum szabályait, olyan sokat nem profitálnak belőle. Nem fog kialakulni a profi csapat, aki a legjobb döntéseket hozva folyamatosan tanul és minőségi munkát végez.

3. Valóban vannak szabályok, de ezeket a szabályokat maga a csapat alkotja, és ha kell változtat rajtuk. Miért ne bíznánk meg egymásban? A későbbi továbbfejlesztés, karbantartás miatt pedig állandó refaktorálásra, unit- és integrációs tesztekre van szükség. Ha ez a tudás nincs meg a csapatban, akkor kellenek olyan fejlesztők, akik ezt be tudják hozni.

4. Hát, ez már nem egy könnyű kérdés :) Az ügyfeledtől és a projekttől függ. (Nincs aranyszabály, mindenki úgy köt szerződést, ahogy tud.) Korábbi hozzászólásomban küldtem egy linket, ami agilis szerződésekkel foglalkozik.
@Amby:
A release helyett gondolom sprinteket, iterációkat akartál mondani.

Mások is küszködnek hasonló kérdésekkel. Én magam nem nagyon szeretek írogatni, de ha gondolod, találkozzunk pl. egy kávé mellett és beszéljünk erről.
@bodozs: ha otthon járok, benevezek majd :)
Hahaha... Mint fejlesztő, már több olyan projektben is részt vettem mit ezzel a mondvacsinált módszerrel szerettek volna menedzselni. :) Ez az egész csak arra jó, hogy méginkább üssék a fejlesztők fejét és még több túlórát sózzanak rájuk, nekem volt olyan projektem - amit marhára divatosan Scrummal vezényeltek le; ahol több mint 200 órányi túlmunkám jött ki a projekt végére, amit persze utána nem fizettek ki és felmondtam. Ez az egész egy nagy blamázs, üres blabla, amit a felgyorsult életvitel kiszolgálására találtak ki, sem az emberség, sem a kreativitás, sem a szép, vállalható munkamódszer és fejlesztési módszer nem fér bele (a Refaktoring emlegetése csak blabla, kibúvó)... Szóval errő ennyit. A hagyományos fejlesztési módszertanoknál is főleg csak akkor jelentkezik az "ügyfél hülye" effektus, ha nem elsősorban az ügyfél hibázik, hanem a managment félreérti, nem tervez rendesen hanem csak ész nélkül bevállal egy projektet és utána a fejlesztők előtt megpróbálja az ügyfelet demonizálni... Hazugság ez az egész.
Ha scrum nem is alkalmas minden esetben azért akad pár módszer, amit ki lehet ragadni és használni bármilyen szoftverfejlesztési környezetben:

1. iterációk
2. incrementális delivery
3. big visible charts
4. daily standup
5. retrospektív

www.qualityontime.eu/articles/mit-tegyunk-ha-scrum-nem-jo
@Marhefka István:

1. tegyük fel, csak az okulás kedvéért, hogy egy alacsony prioritású igényt a végére hagytak a fejlesztők, van rá idő és pénz (reális, az igényre szánt pénz), és persze még az igény is él. Viszont a fejlesztést alapjaiban változtatja meg.

Szerintem blama lenne a fejlesztést visszautasítani (vagy emiatt jelentősen költséget növelni) a módszertan miatt. Mi a teendő?

2. Az empowering nagyon jól hangzik a vezetőknek, mert lehet még lejjebb tolni a felelősséget. Példa nélkül mondjuk elég nehéz erről vitatkozni :\

De egy csapat szerintem nehezebben hoz döntést, mint egy személy. Hiszen miért kellene mindenkinek egyetértenie minden kérdésben?

Más kérdés, hogy amíg a csapattagok a szakmát kenik vágják, menedzsmentből meg bénák, akkor hozhatnak olyan döntést (vagy többet), ami később megbosszúlja magát. És ezt egy tapasztalt vezető előre látta volna.

3. kulcsszó: fluktuáció. Nincs az a csapat, aminek az összetétele ne változna az idők folyamán. Jó esetben mondjuk bővül, jön még több szakértelem, amiket bele kell idomítani a csapatba. Ez is idő. Rövid sprintek vagy független fejlesztések esetén a túl korai refaktorálást is elhozhatják, mert a csapattagok még csak most szoknak össze, máshogy fejlesztenek, stb.