Team 3 refactor

[pintergreg]

@SzFMV2020-Tavasz/team-a3 Sikerült elfogadnom az első PR-etetket úgy, hogy tele van elég csúnya megoldásokkal. Ez teljesen az én hibám (meg azoké, akik a csapaton belül átengedték), ráadásul már a második csapat kapta meg a PR-jére ugyanazokat az észrevételeket.

Dod:

• [x] Átolvasni a #77 kommentjeit
  • [x] kiválogatni ami a ti munkátokat érinti
  • [x] kijavítani a az összes findingot
  • [x] más néven alaposan refaktorálni az osztályaitokat

Határidő: legyen 1 hét: márc. 19.

[aether-fox]

Ez milyen igény? Product Owner? Product Manager? Architect?

Érdekelne az "ocsmányabbnál ocsmányabb" megoldások listája is.

Továbbá szeretnék panaszt emelni a Scrum Master-nél az agilis önszerveződésünket érintően. Bussiness oldalról beleszólnak az implementációs részletekbe, amikor egyébként is alig van időnk haladni az elvárások implementálásával egy számunkra alig ismert programnyelvben, amelyből a cég nem biztosít számunkra továbbképzést, amire egyébként sem lenne időnk. Esetleg egy full-time senior fejlesztő segítségét elfogadnánk kódolási segítségként, amennyiben a cég költségvetése megengedi.

Nekem úgy tűnik a vezetőség vízesés modellben gondolkodik - pedig mi inkremenseket szállítunk és idővel fejlesztünk a terméken. Számunkra az érték a működő termék. Goldplating-re egyes tagjaink, például jómagam is, hajlandó, sőt, hajlik, viszont csak azután, hogy a definition of done-t teljesíteni tudtuk. Úgy érzem ebből konfrontáció adódott a csapat és a vezetőség között, szeretném kérni a Scrum Master segítségét a konfliktus asszertív megoldásához!

[varszegimarcell]

Abszolút nem arról van szó, hogy háborogjunk a kritikán, csak egyszerűen szeretnénk konkrét problémákat látni, ha kritikát kapunk.

Fiatal, kezdő fejlesztők vagyunk mindannyian, és bár elméletben képzettek vagyunk, a gyakorlat alkalmazása abszolút más tészta, pláne egy ilyen komplikált szakmában, mint a programozás.

[pintergreg]

Ti egyelőre beküldtetek egy adag kódot, amit teljesen hanyag módon review-ztam. Önmagában véve ezért is, illetve a megfogalmazásért is elnézést kérek!

Az én szememben ez egy inkremens volt. Konkrétan vártam, hogy még valami történni fog. Igazából azóta sem lett kiegészítve, jelenleg nincs bekötve sehová, nem hívódik meg sehol, érdemi munkát nem végez, nem demózható. Teljesen jogosan meg lehet azzal vádolni, hogy írásban nem kértem ezt számon, ugyanakkor a múlt heti stand-up-on egyikőtök sem jelent meg, a távollétéről nem értesítette a menedzsmentet.

A csapat felelősségi köre az autó mozgatása. Konkrétan annak biztosítása, hogy az autó mozogjon. Nem csak annyit kell tenni, hogy előállítjátok azokat a metódusokat, ami elvégzi a mozgatáshoz szükséges fizikai számításokat, hanem meg kell oldani, hogy az autó mozogjon az előállított metódusok segítségével. Ez azt jelenti, hogy integrálni kell a többi csapat munkájával. Ha szolgáltatásként biztosítod a mozgatás logikáját, akkor be kell tanítanod azokat a kollégákat a használatára akitől azt várod, hogy majd használni fogja. Fognod kell a kis kezét, amíg önállóan nem tud sétálni. Ez egyáltalán nem történt meg. Nem láttam arra vonatkozó dokumentációt, kommunikációt itt GH-on. Igazából a sprintetek nincs lezárva. Ezt mondtam volna el akkor is, ha ma reggel az egyetemen találkozunk.

A „cég” definiált a projekthez egy fejlesztési folyamatot, valamint a kód formázására vonatkozó előírást, amely a „munkaviszony” kezdetekor már elérhető volt és a „belépési tájékoztatóban” szerepelt. Innentől kezdve elvárja, az ebben foglaltak betartását függetlenül attól, hogy a te személyes szépérzéked és „számomra ez így átlátható” hozzáállásod mit diktál. Továbbá a „cég” lokális tool-okat biztosít ezek (fél)automatizált betartatásához, amely a kiadott ismeretanyagban szintén részletesen bemutatásra kerülnek.

Jelen issue tartalma leginkább senior fejlesztői igény. Jelen környezetben egyszerre vagyok senior fejlesztő és megrendelő, pontosabban egy személyben, de időben elválasztva, külön szerepben. Ha azt mondom, hogy az autó kanyarodása során túlzottan driftel az egy megrendelői kérés, miközben azt szeretném, hogy ne így legyen. A kódot nem megrendelőként vizsgálom, hanem a szoftvert futtatva, így megrendelőként például nem is tudom figyelembe venni azt, hogy a sprintre küldtetek be kódot, csak azt látom, hogy az autó nem mozog (a skeleton sample úsztatását most figyelmen kívül hagyva). Megrendelőként azt látom, hogy az autó nem működik és ezért nem fizetek. Oktató szerepre leképezve ez azt jelenti, hogy a sprint elégtelen.

A feladatok scope-ja figyelembe vesz egy 4 kredites tárgy nehézségi fokát, azt, hogy TVSZ szerint ennyi krediért mennyi munkát lehet 4 hallgatóra róni. Ez nem azt jelenti, hogy leszarjuk a többi tárgy terhelését, sőt még a tanulmányaitok melletti munkát is igyekszünk figyelembe venni (holott erre a TVSZ a legcsekélyebb mértékben sem kötelez. Egy nappali tagozatos hallgató jogilag főállású egyetemista, hogy emellett mivel tölti az idejéét az az oktató számára irreleváns.) Ahogy a félév ütemezése arra is igyekszik -a lehetőségekhez mérten- tekintettel lenni, hogy jellemzően végzősök vagytok (vö. szakdoga).

A jelenlegi tantervben -javítsatok ki ha tévednék- szerépel 1 félév Java, ráadásul a SzFMV tárgy nem teljesíthető szakmai szigorlat nélkül, amely magában foglalja az OO nyelvek általános, a C# min. középhaladó és talán a Java bevezető szintű ismeretét. Mindezek ellenére tudom, hogy hogy néz ki az a bizonyos Java tárgy, azt is tudom, hogy a tooling amit mi javasolunk nem ugyanaz. A fejlesztői környezetet meg kell szokni (bár aki androidot programozott annak az IDEA nem lehet felületileg ismeretlen, de erre nem építünk).

Én személy szerint elvárom egy informatikus mérnöktől (most, hogy 1 vagy 2 félévre vagytok a papírtól itt olyan sokat nem oszt, nem szoroz), hogy ha leültetem egy számára ismeretlen szoftver elé, akkor rövid időn belül képes legyen megérteni annak felépítését, hiszem a GUI struktúrák standardizáltak valamilyen szinten. Ha eléd teszem a Kdenlive videóvágót, akkor anélkül, hogy előzetesen előadást tartanék róla elvárhatónak gondolom, hogy létre tudj hozni egy új projektet és tudj importálni egy videó állományt, hiszen a fájl megnyitás, létrehozás műveletek nagyságrendileg megegyeznek a notepad-től egy IDE-n át egy CAD szoftverig mindenben. Nem várom el viszont a videóvágás ismeretét úgy default. Nem tudom, hogy ez a szakasz mennyire világos mondanivalóját illetően.

Visszatérve a nyelvre. Nektek fizikát kell implementálni egy OO nyelven. A swing mint grafikus platform sokkal több nyelvspecifikus kihívást tartogat mint a pusztán üzleti logikát tartalmazó fizikai metódusok. A projektet a maven fogja össze, amiről nektek annyit elegendő tudni, hogy van és, hogy támogatja a függőségek kezelését. Ez utóbbi azért hasznos, mert szükségtelenné teszi olyan kódok megírását amit már mások megírtak. De pont nálatok jött elő az előjel függvény újraimplementálása ami Java standard library. Én személy szerint módfelett baromságnak tartom, hogy bárki is osztályokat és metódusokat magoljon be, így el sem várom azt. Ahogy azt sem várom el, hogy tudd, hogy létezik a Javában signum függvény. A józan fejlesztői szemlélet (aka lustaság) keretein belül viszont elvárom, hogy ha találkozol egy problémával, akkor ne úgy próbálj vele megküzdeni, hogy megírsz mindent magadnak, hanem, hogy megnézed, hogy valaki kitalálta-e már erre a magoldást.

Nekem személy szerint régen az az alapelvem, hogy ha „én találkozok egy problémával, akkor azzal más is találkozhatott már”. Ha pedig valaki már találkozott vele, akkor megoldása is lehet rá: GOOGLE IT. Mondom ezt úgy, hogy dolgoztam olyan projekten, amin tudvalevő volt, hogy azzal a problémával amivel én találkoztam garantáltan nem találkozott még senki más ezen a bolygón.

Viszonylag kevés konkrét nyelvi kérdéssel fordultak hozzám ebben a félében. Hogy mire gondolok? Pl. itt van ezen a branchen az a kód, nekem ezért és ezért nem működik, nézd már meg, hogy mi lehet a gond. Vagy, hogyan kell Javában idiomatikusan leírni azt amit C#-ban így kell... (ez mondjuk guglizható). Ha a full time senior alatt azt érted, akkor én nem fogok kódolni ebben a projektben, ha a supportot érted, akkor meg el kell küldeni a kérdést. És én sem fogok tudni mindent tökéletesen megoldani, de a projektet illetően összehasonlíthatatlanul nagyobb a tapasztalatom, szóval lehet eszembe jut majd valami. Arról nem is beszélve, hogy adott szerepben én vagyok a megrendelő (szerk: ami azért lényeges, mert konszenzus alapján módosíthatunk a követelményeket, ahogy valós helyzetben is tárgyalhatsz a a megrendelővel az agilis fejlesztásben).

Arra vonatkozó észrevételt sem látok, hogy a kiadott feladattal követelmény szempontjából ellenvetésetek lett volna. A #3-ban legalábbis nincs a DoD-t illető megjegyzés.

Viszont ha ránézek a Team 3 boardjára, akkor azt látom, hogy finoman szólva is 50% körüli a feladatok teljesítettsége a határidő napján. Stale állapotú (egy hét magára hagyás után lesz az) taskok sorakoznak todo-ban, van ami review-ban áll. A process betartása itt sem érhető tetten.

Miből gondolod, hogy vízesés modellben gondolkodok? Ez kifejezetten érdekel, hiszen a tárgy későbbi felépítésére is hatással lehet ez az észrevétel. Az oktatási keret heti egy stand-up-ot tesz lehetővé, egy kontaktóra van (amivel éltek vagy sem), de ez nem jelenti azt, hogy egy héten csak egyszer nézek rá a projektre (és hogy online nem lehet elérni). Az eddig leszállított inkremensetekről már leírtam a véleményemet funkcionálisan, a goldplating request nem lett valami kulturált, de fennáll és az után is ráér ha a funkcionalitást rendbe tettétek, amely után elvben oly elkötelezettek vagytok. Valójában pont úgy néz ki, hogy a PR befogadása után félretettétek a tárgyat mintha nem egy inkremens készült volna el, hanem a megrendelő kifizette volna a terméket. Én határozottan nem tettem ilyet.

Örülök annak, hogy a csapat hajlik a DoD teljesítésére, remélem ez nem csak kommunikációs fogásként jelenik majd meg, hanem modulintegráció tekintetében is.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity.