Kihagyás

Projekt menedzsment

Issue megismerése

Cél az átvett projekt megismerése, és a kiválasztott issue elhelyezése a projekten belül. Ez a feladat két fő részre bontható. Azon kódrészletek, komponensek azonosítására melyek kapcsolódnak a kiválasztott issue-hoz. Valamint a kapcsolódó issue-k feltérképezésére.

Kapcsolódó komponensek megismerése

A feladat részeként keressük meg azokat a kódrészleteket, melyeket előreláthatólag módosítani kell majd a feladat végrehajtása során. Ezután vegyük sorra azokat az elemeket, melyek felhasználják a módosított elemeket.

Ezen komponensek szerkezetét (UML package, osztály vagy egyéb szerkezeti diagram, pl. E/K) és fő funkcióit (UseCase, szekvencia diagram, funkcióleírások screenshotokkal) ábrázolhatjuk.

Mennyi diagramra van szükség?

Mennyi italt kell meginni a JATE-klubban hogy jól érezd magad? A válasz hasonló az issue-k esetében is. Sok mindentől függ. Ki és mit iszik? Mennyire fáradt? Mit evett előtte? Stb. Általánosságban elmondható, hogy a következő lépéseket célszerű követni.

Hol van? Egy vagy több áttekintő ábrán bemutatni a projekt fő elemeit és ezek kapcsolatát, kijelölve (és a hozzá kapcsolódó leírásban kiemelve) a megoldandó issue helyét a rendszerben. Erre a komponens- és a deployment-diagram az egyik eszköz.
Mire lesz jó? Ha az issue új funkciót valósít meg, akkor röviden ismertetve a lehetséges felhasználási eseteket (pl. egy használati-eset diagramon keresztül).
Hogyan működik? Be kell mutatni a folyamatokat, melyeket végrehajt a kapcsolódó rész. Ezt szekvencia-, állapot-diagram vagy folyamatábra felhasználásával szokták megoldani.
Hogyan lesz megvalósítva? A technikai részleteket és módosítandó kód közvetlen környezetét osztály-, csomag-, vagy komponens-diagramal ábrázolják.

Lapos a buli? - Ne legyünk részegek.

Az előző JATE-s példát tovább gondolva, fontos (és bizony kihívás is) hogy ne becsüljük alá vagy túl a szükséges információt. A cél, hogy egy másik fejlesztő az általunk adott adatok alapján megtudja válaszolni a fenti kérdéseket.

Egy jó teszt lehet, hogy mennyi magyarázat kell a közölt adatokhoz. Ha túl sok mindent kell még elmondani akkor az adatok hiányosak, ezeket a magyarázatokat célszerű leírni. Ha inkább azt kell megmutatni, hogy mit hol talál az illető, akkor lehet, hogy túl sok, vagy nem elég rendszerezett az információ.

Mindenkinek értékelhetőnek kell lennie

Az értékelés miatt összesen legalább annyi diagramot kell átadni ahány fő dolgozik az adott issue-n (javasolt diagram típusok: 1, 2). A feltöltés során mindenki a saját felhasználóját használja, hogy egyértelműen el tudjuk dönteni melyik rész kinek a munkája.

Az issue (és a projekt) megismerése során tapasztalt hiányosságok, nehézségek, esetleg pozitívumok rögzítése szintén fontos lehet a feladat végrehajtása során. A projektek komplexitása tetszőleges lehet, ezt átlagember egyszerűen nem képes átlátni. Szerencsére nincs is szükség emberfeletti memóriára, hiszen az issue-khoz rengetek információ kapcsolható, amely szükség esetén elérhető.

Újra kell telepíteni a gépet

Tegyük fel hogy teljesen összeomlott az operációs rendszer a laptopodon. Szerencsére a munkádat feltöltötted a verziókövető rendszerbe, így az nem veszett el, de a gépet újra kell telepíteni. Vagyis a fejlesztési környezetet újra létre kell hozni és be kell állítani.

Mennyivel egyszerűbb dolgod lenne, ha a különböző környezeti változók értékeinek beállításait megtalálnád az issue alatt kigyűjtve. Nem kell rá emlékezni, hogy mik voltak, sem azt hogy vajon hova írtad fel őket hiszen minden az issue-hoz kapcsolódó tudás elérhető az issue alatt.

Csak akkor tudunk segíteni tudunk a problémáról!

A feladat megoldása során felmerülő komplikációkról azonnal tájékoztatni kell a gyakorlatvezetőt (ha másképp nem rendelkezik akkor e-mail-ben).

Ezt vajon miért írtam fel?

Ha egy issue-hoz másikat kapcsolunk mindig adjuk meg hogy mi a kapcsolat köztük.

Melyik segít többet? #42 vagy előfeltétele: #42

Értékelés

A kapcsolódó komponensek megismerése részfeladatra összesen 3 pontot lehet szerezni. Az issue-hoz kapcsolódó információkat az issue alá kell gyűjteni. Az folyamat során azonosított hibákat, fejlesztési javaslatokat és alfeladatokat új issue-ként kell rögzíteni és említéssel belinkelni a fő issue alá.

Kapcsolódó issue-k összegyűjtése és munka összehangolása

Keresztbe-módosítás

Képzeljük el hogy egy adott feladatot, pl. az egyik eszköz parancssori kimenetének színezését több különböző könyvtárral is meglehet oldani. Teszt Elek a HiperSzínes csomagot, míg Pró Béla a SzívárványConsole csomagot választja. A fejlesztés egészen addig gond nélkül folyik amíg össze nem ér a két rendszer. Pl.: szeretnénk kiemelni a hibaüzenetek színét egy közös helyre, hogy egységes legyen minden eszközben.

Ilyenkor az egyik megvalósítást át kell írni a másik javára, vagyis vagy Elek vagy Béla fölöslegesen dolgozott. Ez a kellemetlen helyzet és a projekt számára kidobott erőforrás (munkaidő) elkerülhető lett volna, ha Béla és Elek tisztában vannak az issue-k közötti kapcsolatokkal.

A példában bemutatott helyzet elkerülése érdekében az issue-kat (legalább) említésekkel össze szokták kötni. Az issue-k egy gráfot vagy hálózatot alkotnak. Azonban nem szabad elfelejteni, hogy a hálózat mögött emberek (szoftverfejlesztők) és az ő munkájuk közötti kapcsolat húzódik. A nagyobb méretű vagy összetett csapat-hierarchiával rendelkező projektek esetén ritka, hogy egy ember képes legyen átlátni az egyes feladatok közötti kapcsolatokat. Vegyük figyelembe, hogy a feladatokhoz technikai részletek is tartoznak, például, hogy melyik könyvtárcsomagot vagy tervezési mintát használjuk.

Ezek a jelenségek a projektmunka kapcsán is megfigyelhetőek. Bár a CodeMetropolis közepes méretű rendszerek közül a kisebbek közé tartozik, de a több gyakorlaton és szemeszteren átívelő fejlesztés növeli a folyamatok összetettségét. Ezt az alábbi csomag- és objektum-diagram mutatja.

issue-network

Látható, hogy bizonyos esetben a hallgatók által választott issue-k olyan más issue-khoz kapcsolódnak amit másik gyakorlatra járó hallgató társuk választott. Az is előfordulhatnak olyan issue-k melyek ebben a félévben nem kerülnek megoldásra.

Az issue-k társas lények

Nagyon ritkán fordul elő, hogy egy issue-ban leírt feladat független a többi issue-ban definiálttól. Az issue-k általában összetett hálózatot alkotnak, mely megismerése fontos lépés a feladat elvégzése során.

Fontos felismerni, hogy bár az issue-k listája szétbonthatóak kisebb csoportokra a kapcsolataik mentén, de ezek végül egy közös rendszerhez kapcsolódnak, ami itt a CodeMetropolis projekt. Vagyis szükséges összehangolni az egyes részeken végzett munkát. Ezt a projektszintű összehangolást a gyakorlatvezetők fogják végezni a hallgatók segítségével.

Egységesség

Képzeljük el, hogy vezetőként el kell döntenünk hogy a projektben mennyire készültek el a naplózás funkciók. Ez 3 issue-ban került kiosztásra 3 különböző fejlesztőnek. Kakszi Lajos szereti az angol (amerikai) szakkifejezéseket, például naplózás helyett loggol-ást használ. A szleng és a poénok megszállottja Turbók Imre szenior fejlesztő, soha nem hagy ki egyetlen szóviccet se, még akkor se ha csak ő érti. Végül Király Sándor, egy junior fejlesztő, nem igazán ismeri a szakkifejezéseket, ezért gyakran rosszul használja, például keveri a kimenet és a naplófájl fogalmát.

Vezetőként mennyilyen érzés lenne egymás után olvasni a 3 issue alá írt megjegyzéseiket? Mennyi időt venne el az egyes stílusok közötti váltás? Mire fordítnád az egységes stílus bevezetése után felszabaduló időd?

Az egyes funkciócsoportok egységességének biztosítása érdekében kijelölt vagy vállalt felelősöket szoktak alkalmazni a projekt menete során. A felelősöknek feladata, hogy az elkészült részek dokumentáltsága egységes formátumú és stílusú legyen. Ezt a kisebb módosítások és formázások (tipok, csoportosítás, tartalomjegyzék) elvégzésével, de legtöbb esetben a többi fejlesztő figyelmeztetésével és tanácsokkal éri el.

A felelős nem uralkodó

Az egyes részek felelőse nem parancsol és nincs mindig igaza. De az ő felelőssége hogy szemelőt tartsa az egységességet és ezzel kapcsolatban kifejezze az irányelveket és tanácsokat.

Lali segít - egy-pontos kapcsolattartó

Az előző példát folytatva, Kakszi Lajos legújabb kedvenc rövidítése a SPOC (single point of contact). Ezért eldöntötte, hogy segít a projekt-menedzsernek. Készített egy sablont az issue-k számára, ami minden fontos információt tartalmaz. Létrehozott egy Wiki oldalt a projektkezelőben, amely az egyes kapcsolódó szakkifejezéseket tartalmazza. Végül ezek alapján (példaként) kijavította saját megjegyzéseit és issue-át.

A többieknek is átküldte az elkészült anyagot. Elmagyarázta Sanyinak, hogy miért fontos a megfelelő szakkifejezések használata. Felhívta Csoki (Imre) figyelmét, hogy sajnos a vicces megjegyzései sokszor félrevezetik a kezdő fejlesztőket, valamint sokkal nehezebb kiszűrni a lényeget.

A menedzser sokkal hamarabb végzett Lali és Sanyi issue-inak átnézésével. Így volt ideje a projektzáró sörözés megszervezésére, ahol sokat beszélgetett mindenkivel. Kiderült, hogy Sanyi szívesen képezné magát. Lalit a következő projekt során több funkciócsoport felügyeletére is felkérték, végül a bértárgyalás során fizetésemelést kapott konstruktív és felelősségteljes hozzáállásáért.

Sajnos Csoki stílusa nem sokat változott. A vezetőség felé egyre több panasz érkezett, hogy hátráltatja a munkát. Ezért a következő értékelés során közös megegyezéssel elhagyta a céget.

A felelős nem dolgozik senki helyett!

Ha a felelős nem kerül kijelölésre, minden érintett pontot veszít. Ha a hallgató figyelmen kívül hagyja a felelős jogos tanácsát, akkor tőle pontot vonunk le, de a felelős nem veszít emiatt pontot.

Egyeztessünk!

A hallgatók megfelelő issue-k választásával befolyásolhatják, hogy kivel kell szorosabban együtt dolgozniuk.

A munkát kritizáld ne az embert!

A negatív véleményeket, javításra vonatkozó tanácsokat általában illik privátban jelezni az érintett felé. Sajnos a vitás esetek elkerülése érdekében a gyakorlatvezetőket muszáj bevonni a felelős és a többi hallgató kommunikációjába. Ez a Coospace-n történik majd. Fokozottan ügyeljünk rá, hogy ne szégyenítsünk meg senkit a többiek előtt és törekedjünk az építő szándékú tanácsokra.

A felelősök számára csak az igazolható munkáért tudunk pontot adni: kommunikáció Coospace-n vagy GitLab-on.

Értékelés

A Kapcsolódó issue-k összegyűjtése és munka összehangolása részre a hallgató összesen 5 pontot kaphat. A hallgató feladata, hogy a kapcsolódó issue-kat hivatkozza (említse) a választott issue-ja alatt. Fontos hogy a feladat elvégzésének része az egymás közötti kommunikáció és egyeztetés.

Az összekapcsolódó issue-kat választó hallgatók közösen megegyeznek az adott funkciócsoport egységességéért felelős hallgató személyében. Ezt egy új issue létrehozásával jelzik <funkciócsoport neve> egységesítése, melyhez a felelős hozzárendeli magát és megjelöli benne a kapcsolódó issue-kat. Ezt az issue-t célszerű abba a gyakorlathoz tartozó projektbe létrehozni, ahol a felelős is található, mivel így könnyebb lesz megjelölni. Az élőző példa alapján az új issue naplózás egységesítése lenne, amihez Lali rendeli hozzá magát és a három issue kerül benne említésre.

részfeladat maximális pontszám kinek?
kapcsolódó issue-k megjelölése 2 mindenki
felelős választása és megjelölése 1 mindenki
egységesség segítése 2 felelősök
egységesség alkalmazása 2 nem felelősök

Mindenki szerezhet 3 pontot + (felelős szerezhet 2 pontot vagy nem felelős szerezhet 2 pontoz) = 5 pont mindenkinek.

A fejlesztési és egyéb folyamatok követése

Tudod mit kódoltál tavaly nyáron?

Ha igen, honnan? Miért pont azt a részt írtad meg? Meddig tartott megkeresni a választ?

Ha nem, miért nem? Elfelejtetted?

A szoftver rendszerek az életciklusuk során folyamatosan változnak. Új verziók készülnek el, gyorsabb hardver jelennek meg, új operációs rendszer frissítéseket telepítenek. A technikai jellegű változásokon kívül a felhasználók igényei is folyamatosan alakulnak.

Kihez fordulnál segítségért?

Képzeljük el, hogy frissen becsatlakozol egy hosszú ideje futó fejlesztési projektbe. A munkád során feltérképezed, hogy a feladatot melyik osztályt érinti. Sajnos a módosítás során előjön egy olyan kivétel, amelyet nem tudsz értelmezni.

Kihez fordulnál segítségül?
Biztos hogy mindegyik szenior átlétja a program minden részét?
A vezető fejlesztő mindenre tudja a választ?

A fenti kérdéseket a verziókövetéssel és a projekt menetének folyamatos dokumentálásával érhető el. Egy jól felépített és helyesen használt verziókövető rendszer esetén nem csak az adott osztály, de akár a kérdéses sor szerzőét is pillanatok alatt le lehet kérdezni.

Forráskód verziókövetése

Szoftver rendszer régészet

A CodeMetropolis jelenleg szorosan támaszkodik a BlockModifier csomagra. Vajon miért került ez ennyire kiszervezve? Miért nem része a render eszköznek?

Egyáltalán miért fontos ezt tudnunk? A központi projektbe beemeléssel csökken a kezelendő függőségek száma, egyetlen egy fordítási folyamattal elő tudjuk állítani a BlockModifier és a CodeMetropolis legfrissebb változatát.

Bár a rendszer használ verziókövetést, ezt úgy tűnik ebben az időszakban elég hiányosan tette. A vizsgált könyvtár egyetlen egy commit-ban szerepel, abban ami valószínűleg a teljes projektet átemelte egy korábbi verziókezelő rendszerből. Ez 2016-ban volt, gyakorlatilag az első olyan commit amiben tényleges forráskód szerepel.

A fejlesztők nem emlékeznek a pontos okra, hogy miért került ez a csomag külön, így ez örökre feledésbe merül. A tudás hiánya sajnos rizikót is jelent. Vajon ha beemeljük a központi projektbe azzal nem okozunk-e olyan problémát amire már nem emlékszünk?

Értékelés

A hallgató a Forráskód verziókövetése részfeladatra összesen 4 pontot szerezhet. A hallgató feladata a forráskódon végzett módosítások folyamatos verziókövetése Git rendszer segítségével.

részfeladat maximális pontszám kinek?
Git és GitLab használat 2 mindenki
git flow követése 2 mindenki

A hallgatónak törekednie kell hogy segítse a további módosítások bevezetését. A fejlesztés során használjuk a git-flow branching modelt. Az értékelés során csak azokat az elemeket vesszük figyelembe ami a saját felhasználóval került fel a hallgatói GitLab szerverre.

Fejlesztési folyamatok dokumentálása

A fejlesztés során a forráskódon kívül sok más információ is keletkezik. Ezek nyomon-követése és gyűjtése legalább annyira fontos mint a kódbázis maga.

Éjszakázás ellen

Pró Barbara és Teszt Elek hallgatók ugyan azon a funkció csoporton dolgoznak a félév során. Hétfőn mindkettőjüknek elmarad egy órája, így van idejük megbeszélni a következő lépéseket. Barbi nemrég hallott egy új programcsomagról ami szerinte remekül illene a feladathoz. Elek szeretné meg befejezni a választott issue-jához kapcsolódó rész átnézését. Így a csomag kipróbálását Barbi vállalja. A maradék időben a főbb megvalósítandó funkciókról esik szó.

Mindketten hazaindulnak, de Barbi a TIK-ben felejtette a táskáját ezért vissza kell mennie érte. A villamos lerobban félúton. Szóval ez nem az ő napja. Másnap eszébe jut a Kalkulus 2 ZH így egész héten arra készül. Elekkel péntek délután fut össze aki kíváncsian kérdi milyen az új programcsomag.

Barbinak nem érti mire gondol, volt valami a Rendszerfejlesztés 2 projektmunkával kapcsolatban, de kisebb gondja is nagyobb annál, hogy most ezzel foglalkozzon. Sajnos a határidő ettől nem változik, így mindketten egész hétvégén az új csomag megismerésével foglalkoznak, amit végül sikerül működésre bírni. Hétfő hajnalban már egyikőjük se mer módosítani a kódon, nem értik miért működik, ezért félnek hogy elromlik.

A fenti vitás helyzet és a határidőhöz közeli kapkodás részben elkerülhető lett volna a folyamatok megfelelő naplózása segítségével. A megbeszélések után célszerű memo-kat írni, melyből kiderül milyen döntésekben állapodtak meg. Az új feladatokat issue-k formájában szokták rögzíteni. A korábbi feladatokhoz kapcsolódó információkat az issue-k alá megjegyzésben írják, hogy minden egy helyen legyen. A határidőket és az egyes feladatok haladását, felelősét frissíteni kell az issue-k alatt. Ezzel nem csak azt érjük el, hogy mindenki számára egyértelmű lesz a saját felelőssége, hanem hogy ezeket az információkat bármikor a többiek zavarása nélkül is elérheti.

Nagy bináris fájlok Git-ben

A (nagy) bináris fájlok tárolása nagyon lelassítja a Git működését. Ezért nem szoktunk ilyeneket feltölteni. Minden bináris fájlnak számít amit nem tudsz elolvasni, ha egyszerű Notpad-el megnyitod. Általában semmilyen generált fájlt sem töltünk fel, hiszen ezek előállíthatóak a forráskódból. Gitben nagy bináris állományok (*.class, *.jar, *.zip, *.rar, ...) tárolása tilos (max. 3 pont levonás jár érte), a .gitignore fájl segíthet ennek követésében.

Értékelés

A hallgató a Fejlesztési folyamatok dokumentálása részfeladatra összesen 5 pontot szerezhet. A félév során a következő fejlesztési elemek dokumentált használatát pontozzuk.

részfeladat maximális pontszám kinek?
issuek karbantartása 1 mindenki
heti megbeszélés memo (példa) 2 felelősök
aktív részvétel heti megbeszélésen 2 nem felelősök
összegző dokumentum egységesítése 2 felelősök
összegző dokumentum kapcsolódó részeinek kitöltése 2 nem felelősök

Mindenki szerezhet 1 pontot + ((felelős szerezhet 2 + 2 pontot) vagy (nem felelős szerezhet 2 + 2 pontoz)) = 5 pont mindenkinek.

Az agilis módszertanokhoz hasonlóan kövessük nyomon a feladatok végrehajtását. Mindenkinek legyenek saját issuejai (válalt feladatok és részfeladatai). Ezek állapotát a hallgatói GitLab szerveren a saját gyakorlathoz tartozó issue board-on kell frissíteni folyamatosan a félév során.

A projekt lezárásaként egy összegző dokumentumot kell készíteni. Az összegzést a GitLab projekthez tartozó Wiki-ben kell elhelyezni és MarkDown formátumban kell elkészülnie. Az oldalnak tartalmaznia kell kulcsfontosságú információkat.

A következőknek mindenképpen szerepelnie kell a dokumentumban:

  • Felhasznált témák és technológiák bemutatása
  • Leadandók eredményei linkjei
  • Leadandókról született dokumentációk linkjei
  • Összefoglalás és konklúzió

A dokumentumnak bizonyítania kell, hogy a hallgató elsajátította a módszereket és technológiákat, ami egy projekt karbantartásához kell. Ahhoz, hogy ezt bizonyítsa átfogóan de lényegre törően kell bemutatni az alkalmazott technikákat a beadandó projekten. Ehhez hozzá tartozik a probléma lépésről lépésre történő megoldásának leírása az alkalmazott eszközök és azoknak használatával kibővítve. Egy korábbi példa amiből ki lehet indulni.

Értékelés összefoglalása

részfeladat maximális pontszám kinek?
kapcsolódó komponensek megismerése 3 mindenki
Kapcsolódó issue-k összegyűjtése és munka összehangolása kapcsolódó issue-k megjelölése 2 mindenki
felelős választása és megjelölése 1 mindenki
egységesség segítése 2 felelősök
egységesség alkalmazása 2 nem felelősök
Forráskód verziókövetése Git és GitLab használat 2 mindenki
git flow követése 2 mindenki
Fejlesztési folyamatok dokumentálása issuek karbantartása 1 mindenki
heti megbeszélés memo (példa) 2 felelősök
aktív részvétel heti megbeszélésen 2 nem felelősök
összegző dokumentum egységesítése 2 felelősök
összegző dokumentum kapcsolódó részeinek kitöltése 2 nem felelősök

Utolsó frissítés: 2022-03-23 06:55:52