tifyty

pure Java, what else ?

Ott vagyunk már?

A Shreck film nem is tudom hanyadik része jutott a múltkor az eszembe, amikor is utaznak valahová, és a szamár állandóan kérdezgeti, hogy megérkeztek-e már. Akkor jutott eszembe, amikor egy projekt során egy feladatot megcsináltunk, majd kiderült, hogy bizony nincsen kész, mert még hiányzott, ez meg az, meg amaz. Csupa olyan dolog, amit teljes természetességgel kívánt meg a megrendelő (ebben az esetben nem cég ügyfél, csak projekt menedzsment), és igaza volt, csak éppen nem volt előre megmondva, hogy ezeket a dolgokat mind meg kell csinálni. Mert az természetes, hogy kell dokumentáció, csak persze nem mindegy, hogy milyen szintű.

Fontos, hogy legyen DoD, azaz definition of done (és nem védelmi minisztérium).

Az installáláshoz egy Java alkalmazásnál például elég lehet másfél oldal, amiből egy olyan rendszer gazda, akit joggal lehet annak nevezni, fel tudja installálni az alkalmazást, ha pedig valami nem működik, akkor telefonál, és segítünk. De lehet kívánni olyan dokumentációt is, amelyik lépésről lépésre leírja, hogy milyen parancsokat kell végrehajtani, mit hova kell másolni, mikor hova kell kattintani az egérrel. Azt is meg lehet kívánni, hogy ez a dokumentum a változó részeket, ami nem feltétlenül ugyan az minden környezetben, például direktori nevek, vagy application alias helytartóval (place holder) jelöljön, amiket a dokumentumban global search and replace módon lehet az aktuálisra kicserélni, így állítva elő a konkrét installálási utasítást, benne a megfelelő üres helyekkel, ahova a papíron kézzel írhatja be a rendszergazda, hogy pontosan mikor hajtotta végre azt a parancsot, kattintott, és mit tapasztalt, hogy pontos dokumentáció legyen az installációról.

A paceholder vs. helytartó fordításért elnézést kérek, egy réges régi projektnél így szerepelt a kiírásban, és nem tudtam ellenállni, hogy ide leírjam, hátha varázsol egy mosolyt a ráncos homlokok alá.

És nagyon nem mindegy, hogy mindez előre definiálva van-e, mert a másfél oldal megírása nagyon más erőforrást kíván, mind időben, mind minőségben, mind junior/senior kvalitásban, mint a legutolsó, legextrémebb példa. És ha nincs előre definiálva, hogy mit is kell pontosan megcsinálni, akkor amikor kiderül tisztázni kell azt is: ki fizeti a révészt, mert ha arra az obulusra számítunk, ami projekt cadaver nyelve alatt van, akkor már régen rossz.

Bizony nem egy olyan ügyfél van, aki rossz ösztönöktől vezérelve direkt, vagy csak tudat alatt nem tisztázza előre a pontos kívánalmait. A szállító is gondol valamit, meg a megrendelő is, és ez két dolog. A megrendelő pedig, amikor a projekt már fix áras akkor áll elő azzal, hogy ő pontosan hogyan is gondolta. Sok megrendelő ezt tudatosan űzi, és arra számít, hogy majd jól, gyorsan és olcsón kap mindent. Sőt azt is gondolja, hogy ha nem így tenne, akkor túlfizetné a szállítót, és borsos árat perkálna valami olyasmiért, ami nem ér annyit. És persze ezt sem az ujjából szopja, hanem a tapasztalataiból. Ez pedig azoknak a fejlesztőknek és csapatoknak a hibája, akik szembekerülve egy tapasztalatlan, és erőtlen ügyféllel kihasználják a helyzetet. Vagy csak ők is tapasztalatlanok, mint az ügyfél, és sokszor az első alkalom emléke, amikor a két fiatal ügyetlenkedik egész életre meghatározó. És amikor az ügyfél az egyetlen olyan módon akarja, ahogy a legtapasztaltabb prosti sem tudja (gy.k: ingyen) akkor van az, hogy az ügyfél képviselője, miközben ég a bőr a képéről, kénytelen azt mondani: “A főnökeim véleménye az…”, mert már a saját nevében nincs becsülete kimondani, hogy a róka csontvázáról még mennyi szőr és bőr kellene. (Ezt egyébként régi barátom szájából hallottam, akivel az élet során a szállító-megrendelői asztal hol egyik, hol meg a másik oldalán ültünk.)

Aztán ott a másik véglet, amikor a sprint vége felé közeledve egyszer csak felgyorsult a csapat, és egymás után lökte ki magából a feature-öket. Hát kicsit több volt a bug, a bug fix meg már a következő sprintre lett betervezve. Aztán belenéztem a kódba és leestem az asztal alá: majdnem üres osztályok, metódusok. Kész vannak? Ja, csak egy “kicsit” bugosak. És ezen, ha ilyen a csapat hozzáállása az sem segít ha megköveteljük a unit teszteket, és a kód lefedettséget, mert a kódlefedettség, meg a funkcionális lefedettség az nem ugyanaz, és ilyen esetben a különbség nem elhanyagolható. Azt a curry szószos mindenit, gondoltam magamban, pedig nem is funkcionális nyelven programoztak a kollégák. (Nem árulhatom el, hogy milyen nemzetiségűek voltak.)

Mostanában kicsit rendezettebb körülmények között dolgozom, nem is kicsit, de azért akármilyen a környezet, csodákkal, kód review során, mindig lehet találkozni.

One response to “Ott vagyunk már?

  1. Király Péter szeptember 18, 2013 1:12 du.

    A DoD mellett létezik a DoR Definition of Ready is, amiben azt mondjuk meg, hogy melyek a feladatkitűzés követelményei, elvi szempontból. Például: a dolog (alkalmazás, vagy akár csak egy picike része) specifikálva van, és meg vannak határozva a elfogadás kritériumai is (acceptance criteria). Továbbá, ha az adott dolog egy felületi elem, akkor a feladathoz mockupot is kell csatolni, ha egy hiba, akkor a hibajelenség előállításának lépéseit stb. Ha van ilyen alapelvgyűjtemény, és ezt mindkét fél elfogadta, akkor a DoD már némileg egyértelműbb lehet.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: