Egy hét scrum

Ritkán szoktam ide a munkámmal kapcsolatos dolgokat írni, márminthogy olyat ami konrétan a munkahelyemen történik, most viszont azt hiszem hosszú és érdekes hetünk volt.

Ahogy múltkor írtam, egy munkatársammal közösen dolgoztunk a UI tesztek Seleniumos megvalósításán. Ezután most a tesztelőnknek, aki eddig Visual Basic-ben kalapált egy ezer éves -és többezer dolláros- szoftverbe teszteket, adtunk egy eclipse-t, subersion hozzáférést és a srác még aznap elkezdett teszteket írni nekünk. Söt, tök jól haladt vele. Ez sokkal jobb mint amire számítottam, a learning curve egészen minimális volt. Még ezen a héten vissza is fizette a befektetett időnket a bárki által írható és futtatható automatikus teszt. Beidomítottam a Continuous Integration rendszerünket, hogy automatikus webapp deploy után futtassa le a UI teszteket is, és az aznap elszórt hibáinkat perceken belül megtalálta nekünk. Kézzel egyébként napokba tellene véggellenőrizni az alkalmazásunkat, elég cifrán el van bonyolítva :-D

A csapat felállása is megváltozott, ami már hónapok vagy talán évek óta érlelődött. Átálltunk a scrum metódikára, és egy hét munka után igazából azt lehet mondani hogy nagyon biztató a kezdet. Ez egyébként egy ismert (nem létezik hogy nem ismered) nemzetközi médiacég, az ilyenek nem a fürgeségükről és a rugalmasságukról ismertek, azaz valószinűleg az agile metodikák már majdnem teljesen mainstream dolgok lettek a világ minden részén.
Félig meddig külső segítségkünt kaptunk egy ausztrál srácot egy hétre, aki elmondta mindenkinek hogy miből áll az egész. Tisztáztuk hogy ki csirke és ki disznó (itt a rövid összefoglaló arról hogy miért), és hogy nekik mi a dolguk. Innetől kezdve, mivel disznó besorolást kaptam természetesen, nem kellett résztvennem olyan megbeszéléseken ahol konkrét példát említve valami skandináv országban tervezett marketingkampány részleteiről beszélnek :-) A csirkék egy részének ez úgy láttam kicsit fáj, nekik valamivel több munka az, hogy mi nem szedjük össze magnuknak az információkat a munkánkhoz, de úgy látszik beletörődnek és csinálják ezt a részt helyettünk. Pontosítok: eddig mi csináltuk helyettük. Egyébként a csapat egészén úgy láttam hogy nagyon megszerette az új rendszert és emögött én azt sejtem, hogy mindenki körülbelül azt csinál amit szeret csinálni: kódol, embereket irányít, tesztel, stb. A dologban nagy szerepe van a pozitív motivációnak is, látszott hogy most a project lényegesen jobban halad, több időt tudunk a munkánkra szánni, nem kell kisdobos találkozókra járnunk.
Az ausztrál srác nélkül nem hiszem hogy egy éven belül sikerült volna bármi ilyesmit összehozni, szóval ha van rá lehetőséged hogy külső segítséget kérj scrum bevezetéshez, akkor szerintem sokat segíthet. Egyrészt nagyon jól is adta elő a dolgokat, másrészt azt hiszem szükség volt arra hogy egy nagyjából külsős ember vezesse a cserét. Tőlem lázadásnak vették azt amit mástól reformnak.

Így néz ki a helyzet az első hét után, persze még hónapokba tellhet amíg a véglegesül az új módszer, talán fél év is lehet amíg a többi fejlesztőcsapatnak is megtetszik és követnek minket, akár évek is amíg a rendszergazdák, webmesterek, designerek megpróbálják bevezetni maguknál. Meglátjuk nálunk hogy muzsikál.

Most egy időre megint csend lesz, integrációs teszt megoldásokról fogok tanulni pár dolgot kicsit távolabb a nyolcker otthonos bűzétől. Többek közt.

Notworking networking

A következő tétel matematikai levezetés nélkül, csak úgy:

A határozatlan ideig ismétlődő találkozók, amelyeken kettőnél több különböző szerepkörű munkatárs vesz részt vagy a megbeszélésre szánt témák mennyisége 1-nél több, azok valószínűleg nem fogják a megoldásra váró problémát a megoldódáshoz segíteni.

Hasonló problémakör az alkalmazás szerverek session replikációs megoldásai: az all-to-all replikáció nagyon hamar eléri a korlátait, általában már 2 node-nál, rosszabb esetben 1-nél :-) Ezt hasonlítsuk össze a párokba állított szerverek esetével. Valamint a túl nagy session-méret is közismerten gyilkolja a teljesítményt.

Hiánycikk

Ma keresgettem olyan api-t, ami tud tar (azaz unix tape archive) formátumot olvasni mint stream. Egy közismert van: ant. Nem éppen erre találták ki, de van benne ilyen, egy task is épül rá.
Kicsit kényelmetlenül éreztem magam amikor a pom-ba bedobtam az antot mint függőséget, úgyhogy kicsit körbenéztem hogy mit lehetne helyette. Ezt találtam: commons-compress. Nagyon tetszik az API-ja, eltakarja a archiválás és a tömörtés implementációs részleteit, szép egységes interface mögé rejti, ilyesmi. Talán jó is lett volna, viszont nincs belőle release és incubatorban van jó ideje. Az én cuccomnak viszont pár héten belül szerepelnie kell, úgyhogy talán mégsem.

Viszont az szomorú, hogy az archivum formátumok kezelésére ezek szerint nincs elterjedt, fullos és kiforrott api. Egy ilyen hétköznapi formátum, mint a tar...