Szubjektív SCRUM történet

Egyre inkáb nevetség tárgyává válik a közösségi médiában a SCRUM és azt hiszem azok akik az utóbbi 10 évben ismerkedtek meg ezzel a dologgal a munkahelyükön valószináleg nem értik hogy hogy rajonghattunk valaha is érte. Gondoltam akkor megírom a történetét röviden.

2008 körül dolgoztam elösször a SCRUM-mal. Akkor éppen egy virtuális világ projekten dolgoztunk, kemény határidő volt, igyekeztünk tartani, de volt pár kihívás. Az egyik legjelentősebb kihívást a projekt vezetése jelentette: minden napra betettek nekünk 4-5 óra meetinget. Minden meetingre meghívtak mindenkit: a designereket, a rendszergazdákat, a szoftverfejlesztőket, a producereket és mindenkinek végig kellett halgatnia minden témát. Mire az ember kikeveredett a meetingekről, utánna már tényleg alig maradt idő a munkára. Vicces kis hack-eket csináltunk a dologból, pl lefoglaltunk egy munkatársammal egymás naptárjában 2 órát meetingre, amikor egymás mellett ültünk és dolgoztunk. Ha valaki jött hogy meeting kezdődne, akkor azt mondtam, hogy "bocsi most van egy meetingem Józsival", és ez teljesen igaz is volt, közben persze dolgoztunk beszélgetés helyett.
De ez félmegoldás és nyilván maradt egy nagy probléma: a projekt vezetője a meetinget tartja munkának és a munkát haszontalan időtöltésnek veszi.

És ekkor jött egy srác Londonból (ez azért fontos mert az volt a CÉG központja és tehát az ő véleménye nagyobb súlyt kapott) és bemutatta a SCRUM metodikát a csapatnak.

• A SCRUM standup max 15 perces procedúra volt
  
• Konkrétan tényleg állva csináltuk végig, nem volt betelefonálás közben email böngészés
  
• Csak az kaphatott szót, aki vagy aznap, vagy előző nap tényleg csinált valamit. Ennek a betartására egy studió mikrofon vándorolt kézről kézre és aki úgy próbált beleszólni, hogy nem volt nála a mikrofon, azt úgy tettünk mintha nem hallanánk, vagy szóltunk neki hogy baj lehet az erősítőjével.
  A mikrofont mi kértük, nem nyomta oda senki nekünk ha nem kértük.
  
• Mindenki ennyit mondott el: mit csináltam tegnap, mit fogok ma csinálni és mik az akadályok - azaz ma kivel kell együtt megoldani valamit
• A feladatokra nem vártunk, a feladatokat magunkhoz vettük amikor az előző feladatot befejeztük
• Egyszerre egy feladat. Csináld amig kész nem lesz.

Ezt az egészet fejlesztők hozták be, fejlesztők csinálták és mind nagyon élveztük, a "nem tudom hogy leszünk kész" érzést a "haladunk" érzés váltotta fel. Kivétel a projektmanagert. Rajta láttam hogy a helyét keresi, ő valószinűleg úgy érezte, valami trónfosztás-szerűség történt, valami proletár-diktatúra.
Nekem viszont szuper élmény volt, és úgy hívták: scrum.

Tekerjünk gyorsan előre 2024-be, nagycéges környezet, és nézzük mit történik egy mai SCRUM daily meetingen:

• A projekt vezető végigmegy a csapaton és mindenki beszámol arról hogy hol tart a feladatával. Ez egy "report event". Amennyiben koordinációnak nevezzük, akkor gyakran inkáb csak a projekt vezetőjével koordinálunk, nem annyira a csapattal.
  
• A feladatokat hozzánk rendelik, nem mi húzzuk be amikor készen vagyunk az előzővel
• Ennek következtében N darab folyamatban levő feladatom van és zsonglőrködhetek velük.
• Nem csak hogy nem állunk fel, de többnyire be se megyünk.
• A projekt iterációk valahogy rémesen hasonlítanak kis vizesésekhez.
  

Valahogy az egész olyan, mintha még mindig a régi Waterfall process-t csinálnánk, csak most néhány hónapos ciklusokban.

Most gyorsan tekerjünk vissza kb 1700 évet. A kereszténységet a római birodalomban tiltották és a követőit keresztre feszítették, oroszlánokkal etették fel, gályákra küldték vagy eladták rabszolgának. Nem tűnhetett akkor túl penge ötletnek kereszténynek lenni.
Egészen addig, amíg Konstantin császár hatalomra nem jutott, ő ugyanis a birodalom hivatalos vallásává tette a kereszténységet. A birodalom kb 100 millió lakója alighanem vegyes érzelmekkel próbálta megérteni, miről is szól egyáltalán a kereszténység, hogy aki eddig Jupiternek áldozott az most kinek kellene hogy áldozzon, satöbbi. Amennyiben az ókori római vallás és a katolikus kereszténység között valaki valami hasonlóságot vélne felfedezni (ó ne, micsoda eretnek gondolat), akkor valószinűleg azt gyanítaná, hogy hát persze, ugyanarra a kultúrára ráhúzták az új vallást, már hogy ne lenne hasonló.


Na és szerintem valami ilyesmi történt a SCRUM-mal is. Nem az számít, hogy SCRUM-nak vagy minek nevezzük. Ezt valamikor a 2000-es évek elején olyan írták le, akik így szerettek dolgozni, akik nem akartak pöcsölni sok meetingen, csak gyorsan meg akarták beszélni, hogy hol járnak és merre tovább. Aztán ezt a metódust ráhuzták egy olyan kultúrára, ami viszont nem ilyen. Bár a felirat rajta az hogy "SCRUM", de nem tud lazítani, nem sikerült megszabadulnia a waterfall gondolatmenettől, sok project managernek nem sikerült elengednie a dolgozói kezét, nem hiszi el hogy akkor is megcsinálnák a munkát, ha nem lihegne a nyakukba, és tényleg sok dolgozó csak leadja a jelentését a standupon, nem érdekli hogy mivel lehetne még lendíteni (és miért is érdekelje?) Akkor meg mitől lenne más?

AWS kaland

Van egy érdekes adathalmaz, sajnos 2 TB bz2 tömörítve. Csináltam egy kis programot az elő feldolgozásához. Hát elég kínkeservesre sikerült, rettenetes türelem kellett hozzá hogy az első szeletét a laptopomon feldolgozzam. Lenne igény új IT felszerelésre, csak éppen válság van és másra még nagyobb szükség van.
Gondoltam meghúzom amazon-on. Indítottam egy VM-et, 4 epyc core, 16 GB RAM. A munka tizedével végzett kicsit több mint egy hét alatt, közbe 50 dollárnyi számlát csinált. Tehát a teljes munka nagyjából 500 dolláerba kerülne.

500 dollár az elgondolkodtató, mert az egy használható munka-laptop árának a fele lenne. Szóval akkor elgondolkodtam rajta, hogy vajon hol lenne jobb helyen a pénz. Válság van, ha nem jutna eszembe minden szaros percben.

Akkor milyen egyéb opció van? Csináltam pár éjszaka JMH teszteket a program részeire és találtam is pár dolgot, amit igazán jobban is meg lehet csinálni, tulajdonképpen ezek vitték el az idő túlnyomó részét. Sikerült leküzdenem a feldolgozás idejét 5 napra. Újabb tiz százalékkal közelebb a célhoz, annélkül hogy újabb 50 dolcsiba került volna. Mert most már nem AWS-en folytattam, hanem egy öreg használaton kivüli NUC-on. Lassan odaérek majd hogy raspberry-n fut minden.

Még egy optimalizációt találtam, azzal már a feldolgozás ideje leesett 1 napra a nyomi öreg kis NUC-on. Ezzel már néhány nap alatt befejezem. Az 500 dollárnak majd találok valami más helyet.

Végülis nem olyan rossz egy válság, legalább az ember elkezd végre értelmesen gondolkodni, ahelyett hogy minden problémát a hitelkártyájával intézne el.

Valamire jó lesz

 

Vasárnap esti sztori.

Régebben egy magyar cégnek dolgoztam. A főnököm egyik ötlete az volt, hogy csináljunk egy riport generálót ami PDF-be köpi ki a riportot. Végigmutogattam neki az akkori open source cuccokat, egyik se tetszett neki, azt mondta mind túl lassú. Nem győzött meg igazán, de engem nem is kellett meggyőzni mert ő volt a főnök. Azért nem szokunk ilyet csinálni, mert

1. Igyekszünk a munkánk eredményét minnél elöbb eljuttatni a felhasználóknak/vevőknek. Ha mindenből sajátot csinálunk, azzal ez messzire eltolódhat - vagy esetleg valaki beelőz és nézhetünk szomorúan.
   
2. Ha felhasználjuk azokat a komponenseket, amiket mások is használnak, talán azok a mások már megtalálták és kijavították a hibákat benne.
3. Sajnos tényleg, a szoftverfejlesztő gyakran sokkal drágább, mint a CPU-idő. Például ezért van maga a JAVA is. Hiszen amit assembly-ben nem lehet megcsinálni, azt nem lehet megcsinálni.
   

De akkor nem volt más, nekiláttam egy PDF-et generáló riport komponesnek, ehhez át kellett olvasnom a PDF formátum dokumentációját.

Pár hónappal később a főnököm autóbalesetet szenvedett, kórházba került több hónapra, és a végén az orvosok nem tudtak rajta segíteni, meghalt. Vigyázzatok az utakon :( Az új főnöknek nem volt erről a projectről és az előzményeiről lövése se, kicsit zűrös fickó volt, úgyhogy én elbúcsúztam tőlük. Aki átvette tőlem ezt a PDF generáló cuccot, az egyetlen kérdése az volt a dologgal kapcsolatban, hogy "te hülye vagy, bammeg?" Én is valahogy úgy ástam el az agyam valamelyik zugában a PDF formátum technikai részleteit, hogy na ezt egészen biztosan soha többé nem kell előássam.

Eltellett 20 év, mint egy pillanat.

Idén valamikor egy felhasználó panaszkodott, hogy a feltöltött dokumentumából valami hiányzik, kevesebb oldal van, mint amennyit ő feltöltött. A panaszelhárítók második védelmi vonala nem tudott mit kezdeni a dologgal, átírányították hozzám, nézzem meg nem szúrt-e el valamit a becses szoftverünk. Elkértem feltöltött a dokumentumot tőlük, megnéztem egy szővegszerkesztővel és ezt még fejből el tudtam mondani válaszként gyorsan:
A PDF dokumentum a végén kezdődik, ott van egy katalógus, amelyikben minden oldal fel van sorolva. Ha nincs ott a PDF katalógus, akkor a PDF olvasód sem tud mit kezdeni a dokumentummal, akkor az sérült. Ha viszont ott van a katalógus, akkor látod benne az oldalak számát, tehát nem veszthettünk el belőle semmit. A felhasználót tehát elküldtük más balekot keresni magának. Akkor jutott eszembe, hogy mikor és hol olvastam a PDF formátum párezer oldalas specifikációját.

Talán tényleg nincs teljesen felesleges tudás. Talán ha nagyon sokat várok rá, az egyetemi dolgoknak is megtalálom a kicsi kis értelmét, valahol majd megtakarít nekem napokat, vagy talán csak egy órányi fejtörést.

Vagy ahogy a költő mondta "tegyetek el befőttet, lesz még a világ jövőre"

Ha a szoftvered egy ház lenne

Az ember évezredek óta épít házakat, a ma élő emberek életük legnagyobb részét falak között töltik. Nem vagyok történész, de azt gondolom, hogy ez a civilizációnk egyik sikertörténete. Kb 7 milliárd embernek van ötlete arról, hogy ezeknek a falaknak milyennek kell lennie és bár különbözőek az igényeink és elképzeléseink (pl legénylakás, családi ház, művészgarzon, hippitelep, gengszterbarlang) nagyon sok ponton egyetértünk pl hogy ne nyíljon a wc a konyhába, hogy ne a hálószobába nyíljon a főbejárat, satöbbi. Néha láthatsz valamit, ami nagyon meglepő. Akikkel együt nézed, azokkal könnyen meg tudod beszélni az élményeidet, van rá egy közös nyelvünk és szavaink amit mindenki ért, hiszen ezt csináltuk egész eddigi életünkben: falak között vagyunk. Ennyire alapvető közös élmény talán csak az evés lehet, vagy az utazás. És ha esetleg valakivel nem beszélünk egy nyelvet, még akkor is látja a házainkat. Egy teljesen átlagos napon többszáz házat megnézhetsz, el se fáradsz és hamar véleményt alakítassz ki róluk.
Még ha az árak szempontjából nézzük is, a legtöbb embernek van ötlete vagy legalább véleménye egy ingatlan áráról, hogy egyáltalán ér-e annyit vagy teljesen irreális. Az árakat általában az telekár, az anyagköltségek és a munkaerő ára határozza meg. Ha ugyanarra a dologra két különböző beszállítótól kérsz ajánlatot, várhatóan a különbség esetleg 10-20% körül lesz, nem tizszeres árat kérnek.

A szoftver architektúra sajnos eléggé más kérdés. Alig néhány évtizede használunk szoftvereket, bár egyre aktívabban, de azért a valahol lakás élményével szerintem nem lehet összehasonlítani. Még mindig van egy csomó ember, aki egyáltalán semmilyen szoftvert nem használ. Pl Magyarországon még lehet a vonaton jegyet venni, ha a vasútállomáson nem lehetett.
A legtöbb ember csak használ szoftvert, azoknak az aránya, akik módosítanak vagy esetleg teljesen újat írnak viszonylag alacsony a felhasználókhoz képest.
A szoftver-fejlesztés nyelve nem igazán része a hétköznapi kommunikációnak. Látsz valami furcsát, nincsenek rá szavaid hogy egszerűen elmondd a családodnak. Ha megpróbálod, sokág tart, nem értik, furcsán néznek rád, nem is tudják a szoftver furcsa-e, vagy inkáb te. Egy idő után talán te se tudod.
Emiatt viszonylag kevés konvenció van. Nap mint nap találkozol olyan megoldásokkal, aminek az építészeti megfelelője talán egy iglu lenne a szaharában, viszont elég sok időre van szükséged ahhoz, hogy akár a projektmanagerednek megmagyarázd, hogy ez nem oda való. Elmondja, hogy járt a sarkkörön és egy iglu megmentette az életét, hosszasan magyarázhatod, mi a különbség a sarkkör és a szahara között és hogy ez egy tényleg fontos különbség. Nem látható, nem tapintható, a legtöbb ember számára nem egyértelmű. A marhaságnak néha se eleje, se vége.
Ja és végül a szoftver ára... nyilván ez is piacelven működik, de nincs rá tradíció, hogy mennyibe kerülhet egy jó CAD szoftver, vagy mennyibe kerül egy jó IDE, mennyit adnál egy relációs adatbázis szoftverért, az árkülönbségek egészen döbbenetesek.

Ha a szoftvered egy ház lenne... hát igen, az nagyon klassz lenne.

Kapcsolódó: Tvik írása többek közt a lakásfelújításokról

Review Antipattern: a sötét oldal

Ma egy kis anti-pattern csoportról írnék

1. fenyegetés
2. félelem
3. bosszantás

Példa: a szoftverben, amin dolgoztam, elkezdett felhamozódni egy rakás kód, ami teljesen más konvenciókat és ötleteket követett, mint a többi. Python név-konvenciók. Küldtem rá pár patchet és valaki gyorsan be is mergelte. Azt hiszem már másnap meg is jelent egy mérges szoftverfejlesztő és azzal fenyegetett (első pattern), hogy ha nem csinálom vissza, akkor azzal aláz meg, hogy ő reverteli. Hagytam, had dühöngjön. (harmadik pattern: bosszantás, mit gondoltál, hogy valami szent-ember vagyok, aki odatartja a másik orcáját is?) Értelmesen beszélni nem lehetett vele sajnos.
Közben odajött egy ismerős srác és mondta, hogy ne hergeljem fel azt a pythonos csókát, mert ő a "nagyfőnök kis kedvence". Az, aki a patcheimet bemergelte szintén pánikszerű visszavonulót tartott, még elnézést is kért. - második pattern: beparáztak a nagyfőnök kis kedvencétől.

Szép kis alakok vagyunk, mindenki mást csinált, mint ami elvárható lett volna tőle. És hát jaaa, a cég is olyan... más mint a marketinganyagokban. Nagyfőnök kis kedvence? hmm...

Nagyon szeretném, ha ez egy extrém és ritka helyzet lenne, de nagyon sokszor láttam már hasonló helyzetet, máshol is. A másik baj pedig az, hogy nem is tudom volt-e olyan, amikor nem működött. Sajnos talán nem. Ha a szinvonal már odáig züllött, akkor simán be lehet vetni.
Döntsd el, hogy mit csinálsz vele, de én látok némi igazságot abban a mondásban, hogy többet ront rajtad egy gáz munkahely, mint amennyit te javítassz rajta.

Szóval a pattern nagyon egyszerű, nem kell mást csinálni, csak üvölteni, viszont az ehhez szükséges pozíciót el kell foglalni - nagyfőnök kis kedvence, jótékony diktátor, 10x developer, vagy a többi marhaság. De látod milyen sokan megcsinálták.

Review Antipattern: köpj bele és hagyd ott

Ez egy nagyon gyors és rendkívül hatékony antipattern, arra az esetre, ha pl szabadság elött még valakinek tönkre akarod tenni a munkáját.

Ihlető történet: kollégiumokban kaját nagyon nem volt célszerű elölhagyni, rárepülnek a legyek, vagy mégrosszabb. Hogy ezt megelőzzék az ocsmány bentlakók, mielött elhagyták a helységet beleköptek a saját levesükbe. Persze lehet aztán más is, de valószinűleg egyáltalán nem azt akarta az emberünk elérni vele, hogy később ő megehesse, hanem azt, hogy más se egye meg.
Ez nem annyira kedves emlék nekem Magyarországról. Valljuk be gusztustalan, mint egy anti-pattern, de magyarabb akárhány pusztai gémeskútnál akár még szürkeménessel együt is.

A pattern: nagyon egyszerű, csak egy kommentet írj egy nagyon nagyon nagyon általános és bizonyíthatatlan ellenvetéssel. Például:

• ez a változás ellentétben áll az OOP alapelveivel (ha úgy nézzük, minden a világon)
  
• sérti a REST szabályait
• egy anti-pattern-en alapul (hát persze, hiszen minden pattern valakinek antipattern, de melyik az és miért)

A lényege az, hogy ilyenkor senki sem meri majd elfogadni a változást, mert van egy ellenvetés, ami bár homályos, de nem kezdődik majd róla vita, mert akkor elöbb a saját tájékozatlanségukat kellene beismerniük az embereknek, legalább egymás elött. Na igen, ez az anti-pattern akkor nem működik, ha az emberek őszintén és félelem nélkül be tudják egymásnak vallani azt, hogy fingjuk nincsen miről beszél ez a marha. Ez nem mindenhol van így. Hála istennek, ilyen anyagot nyom az ipar nagy része, hogy rock-star engineer, meg 10x engineer, ja meg persze senior mindenki.
Szóval kis kivétellel mindenhol bevethető, gyors, hatékony.

Ennyi. Buenosz étvágyosz.

Review Antipatterns: Egy tonna ez-az

 A code review kiválló eszköz arra, hogy egy csapat szoftverfejlesztő

• átnézze és tesztelje egymás változtatásait, megelőzzön hibákat
  
• megossza egymással a felelősséget
• megosszon egymással ötleteket

Bár a fentiekre is lehet használni, lehet arra is hogy:

• egyébként működö fejlesztést szabotálj vele
• karriert építs a cég és a csapatod kárára
• te legyél a domináns izé, a vezérfarkas, a matriarcha, ilyesmi
  
• bosszút állj valakin, aki bosszút állt rajtad valamiért... lehet ez egy hosszú és bonyolult történet, de biztosan ő kezdte
  

Gondoltam összeszedek pár mintát azokból az esetekből, ami a másodikra jó. Ezeket önkényesen anti-patternnek nevezem el, mert azért a jó arcok mégis az elsőt próbálják. Szoftvert csinálnak is vele, de karriert azt nem.

Itt jön az első anti-patternem:

Egy tonna ez-az

Egyszer gyerekkoromban édesanyám tökfőzelékkel várt haza. Természetesen még most is rühellem a tökfőzléket, főleg ha van benne kapor is és persze volt. Csak ültem felette és nem csúszott le. Édesanyám kérdezte, hogy mi a baj vele. Mondtam hogy semmi íze nincs, talán egy kis só kellene még hozzá. Kaptam egy kis sót rá, akkor azt mondtam hogy most már túl sós és inkáb egy kis cukrot kérnék rá. Aztán megint sót, fahéjat, kecsapot és így tovább amig nyilvánvalóan még a legyek se szállnának rá többé az eredetileg teljesen szabványos tökfőzelékre. Természetesen az volt a vége, hogy édesanyám lecsűrt egy nyaklevest és kidobott a konyhából.

Ez azért egy kedves emlék, édesanyám rájött egy perc alatt arra, amivel szoftverfejlesztők szivatják egymás éveken és évtizedeken át, pedig soha nem írt egy betűnyi szoftvert se.

A pattern: addig-addig kérj újabb és újabb kiegészítéseket a munkatársadtól, amíg a munkája nyilvánvalóan egy teljesen megmagyarázhatatlan szerencsétlenséggé nem válik. Innentől már ott is hagyhatod a többi reviewernek, hogy ők hánnyák le, vagy csak valami marhasággal palástold el saját felelősséged az üggyel kapcsolatban "nem halad a megfelelő irányba"
Persze ha valaki rászánná az időt és végigolvasná a review menetét, akkor kiderülhetne, hogy mit csináltál. De hát nem fogja úgyse soha senki végigolvasni, meg mit kezdene vele ha mégis.

Kész. En guete :)